In a way, GPU shader languages "fit" parallel GPU architecture (though not cache-aware).
Maybe... limited loop code-length to fit in cache; No pointer chasing (though you can workaround anything in a TM).
Some java subsets for very limited hardware might be instances.
Cell SPUs had explicit user managed cache and host DMA, and Intel ISPC and Unity Burst compiler/ECS (variants of C and C#) are good examples of programming environments that try to more explicitly encourage parallelism and/or optimal cache utilization.
just a nitpick, but explicitly user managed caches aren't. They are really better known as scratchpads. A cache is supposed to be mostly transparent except for the performance implications.
What you mean is that the popular Instruction Set Architectures (x86, ARM) don’t expose these pragmatics. (Though the microcode architectures of the processors executing these ISAs probably do.)
There are other ISAs (e.g. Itanium, most Very Long Instruction Word ISAs) that do expose these pragmatics, constraining what instructions can appear when in an instruction stream. Which in turn means that assembly code for these ISAs needs to be written with awareness of these pragmatics.