3 Oct
2007
3 Oct
'07
12:10 p.m.
Chuck Guzis wrote:
While a workspace point defining the location of a set of "registers"
in main memory sounds like a good idea, is it? While one avoids the
need for 16 words of on-chip register RAM, it comes at a cost of
making an external memory access (not to mention an address
calculation) each time a register is addressed (most of the
instructions do this, so the cost in cycles is very high).
It seems to me to be far better to employ the S/360 method of using
STM/LM-type instructions to change the context. The multiple
register load and store instructions are present on many other CPUs
since then, but it seems that S/360 was the first to make use of
this.
While the in-memory "registers" could certainly be cached by the CPU
(watch out for "dual" reference issues!), that seems to be less
flexible than an architecture that allows any number of registers to
be stored or loaded explicitly as part of a context switch.
Thoughts?
My 'feeling' was that for general purpose computing and modern software
developed in stack-oriented languages, with a lot of function calls/system
calls/context switches/argument passing - where the focus of data activity is
around the stack - relative to the amount of 'basic' calculation, the benefits
of machine registers becomes less due to the amount of save/restore/other
stack work that has to be done one way or the other.
(An informed judgement needs piles of program execution profiling data at
hand, but then I do believe the issue has been studied to death.)
I'm not very familiar with modern RISC processors at the machine level, but I
thought that was the direction general purpose RISC processors had gone with
register windows & c. Nowadays high speed cache reduces the margin of benefit
of machine registers and one can throw a lot of straight combinatorial logic
at address calculation to minimise the amount of time needed for such.
For things like DSPs where one is doing a lot of the same calculation on a
(perhaps narrower) stream of data in time sequence I can see the benefit of
sticking more towards machine registers (or vector machine registers).