http://www.righto.com/2019/10/how-special-register-groups-invaded.html
Half a century ago, the puzzling phrase "special register groups" started showing up in definitions of "CPU", and it is still there. In this blog post, I uncover how special register groups went from an obscure feature in the Honeywell 800 mainframe to appearing in the Washington Post.
While researching old computers, I found a strange definition of "Central Processing Unit" that keeps appearing in different sources. From a book reprinted in 2017:1
"Central Processor Unit (CPU)—Part of a computer system which contains the main storage, arithmetic unit and special register groups. It performs arithmetic operations, controls instruction processing and provides timing signals."
At first glance, this definition seems okay, but a few moments thought reveals some problems. Storage is not part of the CPU. But more puzzling, what are special register groups? A CPU has registers, but "special register groups" is not a normal phrase.
It turns out that this definition has been used extensively for over half a century, even though it doesn't make sense, copied and modified from one source to another. Special register groups were a feature in the Honeywell 800 mainframe computer, introduced in 1959. Although this computer is long-forgotten, its impact inexplicably remains in many glossaries. The Honeywell 800 allowed eight programs to run on a single processor, switching between programs after every instruction.3 To support this, each program had a "special register group" in hardware, its own separate group of 32 registers (program counter, general-purpose registers, index registers, etc.).
(Score: 2) by Immerman on Friday October 25 2019, @12:25AM
The lines have definitely not blurred, the popular languages have just gotten further from the hardware. And even with languages like C, modern compilers can usually perform the relevant optimizations almost as well as a good programmer. Just because you usually don't have to think about the differences as a programmer though, doesn't mean that they're not huge.
First there's the functional differences - registers can often be used for many things that RAM simply can't - vector operations in particular usually can't reference RAM at all. You can also use data in a register in the same clock cycle that an instruction references it. In comparison, reading data from RAM typically requires at least an extra 5-20 clock cycles.
Another big change is the introduction of large amounts of cache - which can be accessed far more quickly than RAM (though still far more slowly than registers), assuming the data you need has already been pulled from RAM in the recent past and is still lying around in the cache. Pipelining has also helped dramatically, hiding much of the RAM latency by fetching data from RAM many cycles before the operation referring to it is performed.
Still - being able to fit all the needed data for a piece of code into registers alone can often deliver a tenfold or greater speed improvement. Well worth it for performance critical inner loops and much real-time processing.