4 ms·

Not my area but... > the other of course is the sad truth that hardware people need to innovate under the compiler instead of in cooperation with it Can you e

Not my area but... > the other of course is the sad truth that hardware people need to innovate under the compiler instead of in cooperation with it Can you expand a little on that please. > register windows was one. but maybe we can wire up producers and consumers more explicitly in the ISA? Register windows, at least in sparc, were a bugger because they substantially block OO execution, but I'd be curious about what your 'wiring up of producers and consumers in the ISA' would look like, can you elaborate?

convolvatron 3y ago
Just that compilers and hardware people both build to the isa. It’s a fixed point in the design space that lets them both iterate independently. But as such, it makes it hard to refactor. A couple times recently I’ve seen projects propose exposing microcode, and while that had trade offs I guess, that’s one way to provide for a somewhat easier back and forth. It’s sort of an industry-wide comedy’s law. In the second point - you can think of registers as edges in a dataflow graph (people do). If we run out of registers (names really) then we start writing to memory and we obscure the producer consumer relationship because of aliasing and we can’t do our register renaming (which is where this paper comes in). Imagine we had a weird instruction encoding that let us specify the graph though direct relations insteadd of the names. I guess another idea would be to have hierarchical names (register pages). It’s interesting to think about since we’ve been stuck on this point for a while in isa design. The only reason I brought up register windows is not that I’m a huge fan of stack based evaluation, or that they were a good idea, but it was one identifiable way we did explore about about how to map that state more implicitly and keep a tight encoding. I guess another potentially fruitful and related area here is to think about how me manage the cache, I think there is a very defensible argument that these should be scratchpads (again moving the isa boundary up into the compiler). This makes the naming of those memory locations more explicit
- _a_a_a_ 3y ago
  Interesting, thanks. A quick note, SPARC designers apparently did not talk to the compiler writers so didn't understand how much inlining could do, and implemented register windows as the wrong solution. Conversely I understand the alpha AXP ISA was designed with the hardware and compiler writers pretty much in the same room, and its beautiful and fast. If I understand you correctly, I think the solution is to have ISA-independent low-level code (ANDF and C-- were/are examples) I think register pages might bring you right back into the same issue as register windows; blocking of 000 execution. Given the extraordinary cost of cache I think the idea of scratchpad memory is very promising, but I don't know how it would best be exposed to the compiler.

convolvatron 3y ago

Just that compilers and hardware people both build to the isa. It’s a fixed point in the design space that lets them both iterate independently. But as such, it makes it hard to refactor. A couple times recently I’ve seen projects propose exposing microcode, and while that had trade offs I guess, that’s one way to provide for a somewhat easier back and forth. It’s sort of an industry-wide comedy’s law. In the second point - you can think of registers as edges in a dataflow graph (people do). If we run out of registers (names really) then we start writing to memory and we obscure the producer consumer relationship because of aliasing and we can’t do our register renaming (which is where this paper comes in). Imagine we had a weird instruction encoding that let us specify the graph though direct relations insteadd of the names. I guess another idea would be to have hierarchical names (register pages). It’s interesting to think about since we’ve been stuck on this point for a while in isa design. The only reason I brought up register windows is not that I’m a huge fan of stack based evaluation, or that they were a good idea, but it was one identifiable way we did explore about about how to map that state more implicitly and keep a tight encoding. I guess another potentially fruitful and related area here is to think about how me manage the cache, I think there is a very defensible argument that these should be scratchpads (again moving the isa boundary up into the compiler). This makes the naming of those memory locations more explicit

_a_a_a_ 3y ago
Interesting, thanks. A quick note, SPARC designers apparently did not talk to the compiler writers so didn't understand how much inlining could do, and implemented register windows as the wrong solution. Conversely I understand the alpha AXP ISA was designed with the hardware and compiler writers pretty much in the same room, and its beautiful and fast. If I understand you correctly, I think the solution is to have ISA-independent low-level code (ANDF and C-- were/are examples) I think register pages might bring you right back into the same issue as register windows; blocking of 000 execution. Given the extraordinary cost of cache I think the idea of scratchpad memory is very promising, but I don't know how it would best be exposed to the compiler.