register windows machines, are so bad ? - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: February 25, 2016, 07:43:06 pm
content: I have designed (and implemented in fpga) an architecture calledArise v2, it's RISC without pipeline, and it comes with register windowsI like this feature, which was presented in Berkeley RISC, and implemented in machines like SPARC, AMD 29000, i960what do you think about "register windows" ? do you like or dislike ? (in case, can you provide a motivation?)thanksedit:wikipedia link

author: westfw
author_rank: Super Contributor
timestamp: February 26, 2016, 06:33:23 am
content: 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.)

author: ataradov
author_rank: Super Contributor
timestamp: February 26, 2016, 06:44:40 am
content: 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).

author: helius
author_rank: Super Contributor
timestamp: February 26, 2016, 07:20:41 am
content: 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.

author: Karel
author_rank: Super Contributor
timestamp: February 26, 2016, 07:38:39 am
content: 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.

author: jwm_
author_rank: Frequent Contributor
timestamp: February 26, 2016, 08:21:21 am
content: 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.

author: Kalvin
author_rank: Super Contributor
timestamp: February 26, 2016, 09:17:14 am
content: Quote from: blueskull on February 26, 2016, 08:13:59 amTMS9900.

author: legacy
author_rank: Super Contributor
timestamp: February 26, 2016, 12:21:44 pm
content: Quote from: helius on February 26, 2016, 07:20:41 amsad

author: retrolefty
author_rank: Super Contributor
timestamp: February 26, 2016, 12:34:11 pm
content: Quote from: blueskull on February 26, 2016, 08:13:59 amIn 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.

author: legacy
author_rank: Super Contributor
timestamp: February 26, 2016, 12:42:43 pm
content: Quote from: retrolefty on February 26, 2016, 12:34:11 pmsoft-registers

author: ataradov
author_rank: Super Contributor
timestamp: February 26, 2016, 05:22:47 pm
content: Quote from: retrolefty on February 26, 2016, 12:34:11 pmSome 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.

author: ataradov
author_rank: Super Contributor
timestamp: February 26, 2016, 05:26:49 pm
content: 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.

author: helius
author_rank: Super Contributor
timestamp: February 27, 2016, 09:14:23 am
content: Quote from: retrolefty on February 26, 2016, 12:34:11 pmIn 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.

author: coppice
author_rank: Super Contributor
timestamp: February 27, 2016, 01:57:57 pm
content: Quote from: Kalvin on February 26, 2016, 09:17:14 amNot just the TMS9900, but the whole TI 990 minicomputer family, which was one of the biggest sellers of its day.

author: dfmischler
author_rank: Frequent Contributor
timestamp: February 27, 2016, 03:26:12 pm
content: Quote from: coppice on February 27, 2016, 01:57:57 pmGreat 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.

author: edavid
author_rank: Super Contributor
timestamp: February 27, 2016, 04:01:11 pm
content: Quote from: helius on February 26, 2016, 07:20:41 amThis is about 90% incorrect for SPARC. To get the real story, see:http://ieng9.ucsd.edu/~cs30x/sparcstack.html

author: amyk
author_rank: Super Contributor
timestamp: February 27, 2016, 05:25:42 pm
content: Quote from: ataradov on February 26, 2016, 05:22:47 pmThe registers are just mapped to SRAM addresses. The 8051 is similar.

author: westfw
author_rank: Super Contributor
timestamp: February 27, 2016, 11:05:51 pm
content: QuoteArguably, 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)QuoteThis 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.)Quote"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.)

author: MrSlack
author_rank: Frequent Contributor
timestamp: February 27, 2016, 11:34:04 pm
content: 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.

author: jwm_
author_rank: Frequent Contributor
timestamp: February 27, 2016, 11:43:03 pm
content: Quote from: MrSlack on February 27, 2016, 11:34:04 pmExcept 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

author: MrSlack
author_rank: Frequent Contributor
timestamp: February 28, 2016, 12:39:53 am
content: Quote from: jwm_ on February 27, 2016, 11:43:03 pmI 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/

author: helius
author_rank: Super Contributor
timestamp: February 29, 2016, 08:05:09 pm
content: Quote from: westfw on February 27, 2016, 11:05:51 pmAccumulator 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.QuoteI was only counting the commercial processors, including the Type 166. SC Group had three: the SC-30M, SC-25, and SC-40.

author: westfw
author_rank: Super Contributor
timestamp: March 01, 2016, 02:12:39 am
content: QuoteYes, 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.Quote"Type 166" was the PDP-6? I found this:http://pdp10.nocrew.org/cpu/processors.htmlbut it doesn't mention the XKL machines.