Hacker News Reader

Comment by convolvatron | Hacker News Reader

isn't it a little more? I admit to just skimming and having a pretty incomplete grasp. but rather than implementing a spacio-temporal cache (lines over usage), this is explicitly trying to match producers and consumers of individual words.

so yes, like a cache, but it approached naming of values in a slightly different way.

two things bother me here. one is that we have the space for more registers, but we can't afford to pay for them in the instruction encoding. the other of course is the sad truth that hardware people need to innovate under the compiler instead of in cooperation with it.

on the first point, it seems like there may be other approaches to solving the naming issue. register windows was one. but maybe we can wire up producers and consumers more explicitly in the ISA?

View on HN

There is Clockhands (and STRAIGHT before that): https://dl.acm.org/doi/fullHtml/10.1145/3613424.3614272

Previous discussion: https://news.ycombinator.com/item?id=38581719

I think such things make sense only as a means for more compact instruction encoding. Eventually, you will get bigger chips that will implement some form of register renaming anyway, to compensate for bottlenecks in the ISA.

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?

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

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.

Reply on news.ycombinator.com