🚀 go-pugleaf

>>>>> On 21 Jun 91  davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) said:

Bill> In article <825@adpplz.UUCP> martin@adpplz.UUCP (Martin Golding) writes:

Martin> This isn't a process of data compression, it's a process of function
Martin> compression, ie, ea instruction encodes a series of machine operations.
Martin> For a [..] RISC type example, take a look at your generated assembly
Martin> code, and estimate the resulting size increase if you removed address
Martin> calculation from all of the load/store instructions.

Bill>   No doubt the code would be tighter if you didn't calculate the
Bill> addresses, but it wouldn't *work* very well.

But the point is that a (hypothetical) CISC instruction
	mov @(r0[r1])+, #somevalue
supposed to do
	int r1; char * r0[N]; 
	*(r0[r1])++ = SOMEVALUE;
is equivalent to the RISC sequence:
	add r2,r1,r0  ; to get &(r0[r1])
	load r3, (r2) ; fetch the address
	add  r3, 4    ; increment
	store r3,(r2) ; store post-increment address
	load r4, (r3) ; do indirection
	store #somevalue, (r4)

to give a contrived example. All the operations that are 'encoded' by
subsequent RISC instructions, are encoded compactly within the CISC
instruction word; the compactness comes thanks to the fact that only a
limited subset of all combinations of adds/loads (defined by available
addressing modes) is allowed. 

If your code used such addressing modes a lot, you would loose
terribly in the code density department. The nice thing is that both
RISC proponents and CISC manufactures agree that the very complicated
addressing modes do not get used much (vide the fate of the fancy
addressing modes in 68040). The orthogonal set of registers would make
programming RISC in assembly nice, if it wasn't for delay slots and
branch delays. Then of course, smart assemblers do it for you. Then
again, machines get faster almost more rapidly than you tune your
code, so by sitting back and waiting for the next model you might be
as productive as the guy next door hand-assembling his critical
routines :^).
--
			przemek klosowski (przemek@ndcvx.cc.nd.edu)
			Physics Department
			University of Notre Dame IN 46556