register windows machines, are so bad ?

[legacy]

I have designed (and implemented in fpga) an architecture called Arise v2, it's RISC without pipeline, and it comes with register windows
I like this feature, which was presented in Berkeley RISC, and implemented in machines like SPARC, AMD 29000, i960

what do you think about "register windows" ? do you like or dislike ? (in case, can you provide a motivation?)

thanks 


edit:
wikipedia link

[westfw]

I haven't used any extensively, but I have two impressions:
1) context switching becomes expensive, because you have to save all the registers; not just the active window.
2) I'm not sure that registers are commonly "in short supply" in most modern architectures.  ABIs that provide 4+ registers that are callee-mungeable don't seem to end up spending a lot of time saving/restoring registers anyway.  Look at how rare it is for gcc to actually push arguments on the stack, for instance.  (Languages other than C, with other ABIs, may benefit more from register windows.)

[ataradov]

Register windows are one of those things that sound like a good idea, but in reality are hard to manage. It all looks good in the middle, but then your window slides to the end of the register bank, and your compiler has to handle that. With interrupts it becomes a PITA.

Any load-store architecture with at least 8 32-bit register is good enough (and probably optimal).

[helius]

In machines like the SPARC, the compiler doesn't "handle" the register window. There is a background hardware device that spills and refills the windows from memory transparently. The windows are also not "reloaded" when you do a context switch, because it would literally be impossible: software cannot see them anyway. The way different processes use the windows without interference is that each of them is tagged with a process ID, just like a virtually tagged cache.
This fact is quite bad when you want to grovel in the stack to see what's going on in saved frames, because the windows aren't addressable. Any function that passes the address of one of its variables forces its allocation in the (memory) stack instead of the window. If you want to scan the stack (garbage collector), or profile the stack contents, it screws you harder.

[Karel]

In general, I don't like CPU registers. They are just a workaround or compensation to solve the problem of slow memory.
But I don't have a better solution.

[jwm_]

Much smarter compilers, register coloring algorithms, and register aliasing has basically made them obsolete in mainstream CPUs. There was a window (Harhar) where they were a significant win, but it has passed.

That said, they still may make sense for a custom one off CPU you are writing your own compiler for or doing assembly, if you can't leverage modern compiler advancements  then they may still be a win.

[Kalvin]

In general, I don't like CPU registers. They are just a workaround or compensation to solve the problem of slow memory.
But I don't have a better solution.

Is there any CPU does not any generic purpose data register? Let along control/status registers.
PS. If you read everything from L2, even L1, without prefetching pipeline and GP registers, your code will be as slow as frozen.

TMS9900.

[legacy]

In machines like the SPARC, the compiler doesn't "handle" the register window. There is a background hardware device that spills and refills the windows from memory transparently. The windows are also not "reloaded" when you do a context switch, because it would literally be impossible: software cannot see them anyway. The way different processes use the windows without interference is that each of them is tagged with a process ID, just like a virtually tagged cache.
This fact is quite bad when you want to grovel in the stack to see what's going on in saved frames, because the windows aren't addressable. Any function that passes the address of one of its variables forces its allocation in the (memory) stack instead of the window. If you want to scan the stack (garbage collector), or profile the stack contents, it screws you harder.

sad

[retrolefty]

In general, I don't like CPU registers. They are just a workaround or compensation to solve the problem of slow memory.
But I don't have a better solution.

Is there any CPU does not any generic purpose data register? Let along control/status registers.
PS. If you read everything from L2, even L1, without prefetching pipeline and GP registers, your code will be as slow as frozen.

 In the early 70s I worked with a in-house (GTE information systems) built and used 16 bit mini-computer with 16K core memory. All the registers accept the main ALU accumulator were just reserved main memory addresses, including the program address counter. Worked on several mini-computer systems after that but never came across another one that tried to so minimize hardware by using the main memory to replace hardware registers.

[legacy]

to replace hardware registers.

soft-registers 

[ataradov]

but never came across another one that tried to so minimize hardware by using the main memory to replace hardware registers.

Some small ATtiny parts have their registers addressed as a part of normal SRAM. I don't know how exactly they are implemented internally, but write to SRAM changes registers and change in register results in change in the SRAM. Instruction set is still AVR of course, so you still have to use register names to manipulate data.

[ataradov]

I personally like more practical approach ARM took with their implementation. Changing stack frame during function calls is expensive, so they simply added a number of instructions for faster stack frame manipulation. In practice, it is good enough. You don't always need to have absolutely the best.

[helius]

Worked on several mini-computer systems after that but never came across another one that tried to so minimize hardware by using the main memory to replace hardware registers.

In the PDP-10 architecture, which was implemented by over a dozen different processors, registers occupy the first 16 memory addresses. All instructions are register-memory: you simply use the address of register B to do A+B.

[coppice]

In general, I don't like CPU registers. They are just a workaround or compensation to solve the problem of slow memory.
But I don't have a better solution.

Is there any CPU does not any generic purpose data register? Let along control/status registers.
PS. If you read everything from L2, even L1, without prefetching pipeline and GP registers, your code will be as slow as frozen.

TMS9900.

Not just the TMS9900, but the whole TI 990 minicomputer family, which was one of the biggest sellers of its day.

[dfmischler]

Not just the TMS9900, but the whole TI 990 minicomputer family, which was one of the biggest sellers of its day.

Great for interrupt processing, but not as good for general purpose computing.  And when more performance was needed they added a "workspace cache" of hardware registers, with automatic load and store logic, for the 990/12.

[edavid]

In machines like the SPARC, the compiler doesn't "handle" the register window. There is a background hardware device that spills and refills the windows from memory transparently. The windows are also not "reloaded" when you do a context switch, because it would literally be impossible: software cannot see them anyway. The way different processes use the windows without interference is that each of them is tagged with a process ID, just like a virtually tagged cache.
This fact is quite bad when you want to grovel in the stack to see what's going on in saved frames, because the windows aren't addressable. Any function that passes the address of one of its variables forces its allocation in the (memory) stack instead of the window. If you want to scan the stack (garbage collector), or profile the stack contents, it screws you harder.

This is about 90% incorrect for SPARC.  To get the real story, see: http://ieng9.ucsd.edu/~cs30x/sparcstack.html

[amyk]

but never came across another one that tried to so minimize hardware by using the main memory to replace hardware registers.

Some small ATtiny parts have their registers addressed as a part of normal SRAM. I don't know how exactly they are implemented internally, but write to SRAM changes registers and change in register results in change in the SRAM. Instruction set is still AVR of course, so you still have to use register names to manipulate data.

The registers are just mapped to SRAM addresses. The 8051 is similar.

[westfw]

Is there any CPU does not any generic purpose data register?

Arguably, the 8-bit PICs fit into this category, having only an 8bit accumulator (W) and "memory", with most operations happening between W and a memory location.
It's a bit blurred because the PIC "memory" also has some register-like properties, so it's not really clear whether you should consider them registers or memory (but either way, the PIC doesn't really have "both"!) (The most dramatic effect of this is that the PICs top out at 4k of "ram", and need an annoying bank switching scheme to access that much, compared to most 8bit architectures that have SOME way to access 64k)

Some small ATtiny parts have their registers addressed as a part of normal SRAM.

This happens in ALL of the AVRs (but not in the Xmega chips.)  But being able to address the registers as RAM is not the same thing as not having GP registers.  This is pretty common in register/memory architectures (8051 and PDP10 have already been mentioned.)

In the PDP-10 architecture, which was implemented by over a dozen different processors

"Over a dozen?"  I guess, if you include versions that were never sold, or sold in vanishingly small quantities.
(DEC: KA, KI, KL, 2020, Minnow (not sold), Jupiter (not sold)  Foonly: F1 - F5 (VSQ), Systems Concepts: 2 versions?, XKL: 2 versions? (VSQ), Xerox Parc: MAXC (not sold) - did I miss any?  (ah, what a lovely instruction set, back when 1MB of memory was a huge amount.)  I occasionally think that it would make for an interesting "microcontroller", if you're willing to give up "modern" concepts like byte addressability.)

[MrSlack]

I prefer to go up an abstraction level and think there.

IMHO stack machines get it right. No registers required and therefore no register allocation, windowing or other horrible hacks required.

Plus they're simple enough to be reduced into physical hardware, software or translated into register machine code.

PIC16 (last line I used) are a horrible artifact of register machines. 50% of object code is moving stuff around, worrying about what page it is on and scratching your head and trying not to blow the stack.

[jwm_]

IMHO stack machines get it right. No registers required and therefore no register allocation, windowing or other horrible hacks required.

Plus they're simple enough to be reduced into physical hardware, software or translated into register machine code.

Except they are horrible to write an optimizing compiler for and almost impossible to create a superscalar architecture for. And where does your stack live, RAM? if so every operation has to access slow ram, if not, then you have a limited stack anyway so why not make them directly addressable as registers, if they overflow to ram at a point, then you have re-invented register windows.

   John

[MrSlack]

IMHO stack machines get it right. No registers required and therefore no register allocation, windowing or other horrible hacks required.

Plus they're simple enough to be reduced into physical hardware, software or translated into register machine code.

Except they are horrible to write an optimizing compiler for and almost impossible to create a superscalar architecture for. And where does your stack live, RAM? if so every operation has to access slow ram, if not, then you have a limited stack anyway so why not make them directly addressable as registers, if they overflow to ram at a point, then you have re-invented register windows.

   John

I wrote a large rant here about how register machines are the originator of these problems, have deleted it and will just write the conclusion:

Take a Xeon E5 core's real estate, drop 500 stack machine cores on it with individual data and return stacks, connect them in a 2d torus structure via shallow FIFOs, add a read optimised 25Mbyte L2 cache for program code, give it an Erlang-like supervisor and compiler front end, throw away C.

These guys have the right idea: http://www.greenarraychips.com/

[helius]

Is there any CPU does not any generic purpose data register?

Arguably, the 8-bit PICs fit into this category, having only an 8bit accumulator (W) and "memory", with most operations happening between W and a memory location.

Accumulator machines use their accumulator implicitly, so it is not specified as a register by instructions; as with Stack machines that have already been mentioned. There are also Transport Triggered Architectures, like Dallas/Maxim MAXQ10/20/2000. They only implement a single instruction which moves data from one location to another, such as from a memory operand to a functional unit input, or from a functional unit output to another functional unit. Registers are not needed.

In the PDP-10 architecture, which was implemented by over a dozen different processors

"Over a dozen?"  I guess, if you include versions that were never sold, or sold in vanishingly small quantities.
(DEC: KA, KI, KL, 2020, Minnow (not sold), Jupiter (not sold)  Foonly: F1 - F5 (VSQ), Systems Concepts: 2 versions?, XKL: 2 versions? (VSQ), Xerox Parc: MAXC (not sold) - did I miss any?  (ah, what a lovely instruction set, back when 1MB of memory was a huge amount.)  I occasionally think that it would make for an interesting "microcontroller", if you're willing to give up "modern" concepts like byte addressability.)

I was only counting the commercial processors, including the Type 166. SC Group had three: the SC-30M, SC-25, and SC-40.

[westfw]

Arguably, the 8-bit PICs [lack GP registers]

Accumulator machines use their accumulator implicitly, so it is not specified as a register by instructions

Yes, that sounds like the PIC.  ADDWF, SUBWF, ANDLW, etc - most instructions use W implicitly (explicit in the mnemonic, but no alternative non-W versions), with a limited number able to operate on "file registers" directly.

I was only counting the commercial [PDP10-like CPUs) including the Type 166

"Type 166" was the PDP-6?  I found this: http://pdp10.nocrew.org/cpu/processors.html but it doesn't mention the XKL machines.