RISC and waste
On Sun, 24 Mar 1996, Jaap van Ganswijk wrote:
> RISC is of course a very interesting approach, but it wastes memory
> (and disk-space and program load time) and because of it's
> register structure can't handle a variable number of arguments correctly etc.
RISC is wasteful, but this is not because it does not handle printf()
well.
The main reason is the register 3-operand architecture. Specifying 3 times
one of 32 registers (3x5 bits) in each instructon, one is pressed to go to
instructions beyond 16-bit, 32-bit being the most common. The opcode
table is extremely sparce, and all combinations of (source1,source2,dest)
triplets are used with extremely ununiform frequency. This means in
practice, that the most precious resource in todays RISC implementations
-- primary cache and processor-memory bandwidth, are wasted on bits, that
are completely irrellevant to the program.
Having written code for MIPS, what struck me is the requirement to specify
three registers each time, even when one or (in rare cases) two would have
been enough. Having 3-operand architecture does not speed up things
significantly, since it's only very rarely need.
If the architecture were 2-operand, one would dispence with 10 bits for
registers and 6 bits for opcodes, thus doubling the instructions per
memory fetch, and doubling the instructions resident in primary cache.
This would only incur in very rare circumstances the need for one
3-operand instruction to be coded as two 2-address ones.
Of course, one might be able to go further that line, by having
one-operand instructions and stuffing three of them in a 32-bit word.
Or even further, by having no-operand instructons (stack architecture) and
stuffing 6 of them in a 32-bit word.
None of the above has much to do with the high level language being
executed. Of course, the architecture can provide additional fascilities
for specific langauges, but it is not obvious that they will end up being
different from each other.
To wrap it up, the stack(s)-based (no-operand/implied-addressing)
instruction set, along with a few (implied) special-purpouse registers,
seems to be the most orthogonal (memory-bandwidth-saving) architectute for
general purpose computing. Of course, this frees the die area for
application-specific coprocessors, which are immensely more powerful, that
the general purpose solution.
Long live MISC!
:-)
--
Penio Penev <Penev@pisa.Rockefeller.edu> 1-212-327-7423
