4 ms·

> 16 registers divided into to areas: R0 to R7 are in fact a window to a register bank containing 256 times 8 registers while R8 to R15 are fixed. This archite

by chalst 7y ago

> 16 registers divided into to areas: R0 to R7 are in fact a window to a register bank containing 256 times 8 registers while R8 to R15 are fixed. This architecture makes subroutine calls and saving registers very easy (just increment/decrement the register bank pointer which is part of the status register). All in all QNICE features 256 * 8 + 8 = 2056 registers. This is indeed nice and the kind of thing whose availability can affect the design of low-level languages, e.g. non-ISO local variables in a Forth dialect. Cf. http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Gforth-locals.html http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Gfor...

zimpenfish 7y ago
Pretty neat but doesn't seem to be making it to the Real World(tm) despite several attempts. https://en.wikipedia.org/wiki/Register_window https://en.wikipedia.org/wiki/Register_window
- chalst 7y ago
  Decent link, thanks. It doesn't surprise me that having more visible registers and doing a good job of register allocation in the compiler is a better strategy (i.e., both more efficient and more flexible), but doing so means you are not so close to the metal. From the point of view of an efficiency feature that doesn't ask for complexity in the compiler, I see some appeal to register windows.
  - JoshTriplett 7y ago
    It's not just that. If you have a huge internal register file and register renaming, along with a few other tricks, then it's at least as efficient (and potentially more efficient) to just push and pop the registers that actually get used.
    - throwaway_pdp09 7y ago
      Is 'efficient' what you want though? For embedded, yes. For maximum speed where you are willing to blow large power use, you can be much faster but it will cost you efficiency, badly (think Xeons). Without quantifying what you're trying to do, 'efficient' is only a metric not a target.
      - JoshTriplett 7y ago
        I'm suggesting that a large register file and register renaming is likely to be the better alternative by many different metrics, yes.
        throwaway_pdp09 7y ago
        Apologies, I misread you.
throwaway_pdp09 7y ago
This sounds like Spark's register windows https://en.wikipedia.org/wiki/SPARC#Features https://en.wikipedia.org/wiki/SPARC#Features I got it from a very reliable source, someone who was involved in evolving that hardware, that this feature caused Sun "an awful lot of pain" (his words, best I can recall). My understanding is that it greatly destroyed the ability to do out-of-order execution, which was on top of the original designer's failure to understand what the compiler could do with inlining that would largely negate the value of this. From what I've read over the years, the Sparc hardware guys didn't talk to the compiler guys - a trap the designers of the DEC Alpha very carefully did not fall into. Since this is a teaching project, I'm sure that feature is fine, but just saying.
- chalst 7y ago
  This is a very nice comment. The Wikipedia article would benefit from a citeable source for the problems they had: is that something you could help find?
  - throwaway_pdp09 7y ago
    I heard it said by a guy at a conference. This guy: https://en.wikipedia.org/wiki/Ivan_Sutherland https://en.wikipedia.org/wiki/Ivan_Sutherland Sutherland was interested in the Sparc, surprising given he's better known for graphics but there you go. As it happened, Steve Furber was there too. Irrelevant but bragging rights & all that. A criticism from wiki itself after a very quick DDG: https://en.wikipedia.org/wiki/Register_window#Criticism https://en.wikipedia.org/wiki/Register_window#Criticism HTH
    - chalst 7y ago
      Sutherland was something like a cofounder of Sun Labs, so I guess he was likely to develop some interest. I'm afraid I couldn't track down anything more specific, but I'll keep my eyes peeled. An interesting point I did find: the SPARC architecture was later extended so that register windows could be saved and restored other than via SUB calls, allowing instruction reordering and their use for context switching. The Register window article doesn't talk about Sun's experience or the issue of reordering instructions.

by chalst 7y ago

zimpenfish 7y ago

Pretty neat but doesn't seem to be making it to the Real World(tm) despite several attempts. https://en.wikipedia.org/wiki/Register_window https://en.wikipedia.org/wiki/Register_window

chalst 7y ago
Decent link, thanks. It doesn't surprise me that having more visible registers and doing a good job of register allocation in the compiler is a better strategy (i.e., both more efficient and more flexible), but doing so means you are not so close to the metal. From the point of view of an efficiency feature that doesn't ask for complexity in the compiler, I see some appeal to register windows.
- JoshTriplett 7y ago
  It's not just that. If you have a huge internal register file and register renaming, along with a few other tricks, then it's at least as efficient (and potentially more efficient) to just push and pop the registers that actually get used.
  - throwaway_pdp09 7y ago
    Is 'efficient' what you want though? For embedded, yes. For maximum speed where you are willing to blow large power use, you can be much faster but it will cost you efficiency, badly (think Xeons). Without quantifying what you're trying to do, 'efficient' is only a metric not a target.
    - JoshTriplett 7y ago
      I'm suggesting that a large register file and register renaming is likely to be the better alternative by many different metrics, yes.
      - throwaway_pdp09 7y ago
        Apologies, I misread you.

throwaway_pdp09 7y ago

This sounds like Spark's register windows https://en.wikipedia.org/wiki/SPARC#Features https://en.wikipedia.org/wiki/SPARC#Features I got it from a very reliable source, someone who was involved in evolving that hardware, that this feature caused Sun "an awful lot of pain" (his words, best I can recall). My understanding is that it greatly destroyed the ability to do out-of-order execution, which was on top of the original designer's failure to understand what the compiler could do with inlining that would largely negate the value of this. From what I've read over the years, the Sparc hardware guys didn't talk to the compiler guys - a trap the designers of the DEC Alpha very carefully did not fall into. Since this is a teaching project, I'm sure that feature is fine, but just saying.

chalst 7y ago
This is a very nice comment. The Wikipedia article would benefit from a citeable source for the problems they had: is that something you could help find?
- throwaway_pdp09 7y ago
  I heard it said by a guy at a conference. This guy: https://en.wikipedia.org/wiki/Ivan_Sutherland https://en.wikipedia.org/wiki/Ivan_Sutherland Sutherland was interested in the Sparc, surprising given he's better known for graphics but there you go. As it happened, Steve Furber was there too. Irrelevant but bragging rights & all that. A criticism from wiki itself after a very quick DDG: https://en.wikipedia.org/wiki/Register_window#Criticism https://en.wikipedia.org/wiki/Register_window#Criticism HTH
  - chalst 7y ago
    Sutherland was something like a cofounder of Sun Labs, so I guess he was likely to develop some interest. I'm afraid I couldn't track down anything more specific, but I'll keep my eyes peeled. An interesting point I did find: the SPARC architecture was later extended so that register windows could be saved and restored other than via SUB calls, allowing instruction reordering and their use for context switching. The Register window article doesn't talk about Sun's experience or the issue of reordering instructions.