🚀 go-pugleaf

In article <1545@geovision.gvc.com> gd@geovision.gvc.com (Gord Deinstadt) writes:
 > In a pipelined machine, would it not be more efficient to just deactivate
 > a couple of instructions rather than go through the pain of a forward
 > branch?  In other words just keep grinding forward, but inhibiting
 > execution for a specified number of cycles, rather than trying to
 > change course.

Interestingly, this is what a very old (and not very RISC) machine did.
I am talking about the Electrologica X8 of 60s vintage.  It had a single
condition bit.  (Nearly) Every instruction had a 2 bit field that encoded
one of the following:
	Execute always
	Execute if condition is Yes
	Execute if condition is No
	Execute but do not deliver result
also there was a 2 bit field that encoded how the condition would be set:
	Do not set
	Set on positive
	Set on zero
	Set on even parity
It was easy to ge jumpless abs and max and so on:
	M[x] = abs(M[y])
translates to (A is a register, M[.] is a reference to memory):
	   A = M[y], P		Set condition if positive
	N, A = -A		If negative, negate
	   M[x] = A
And M[x] = max(M[y], M[z]) translates to:
	   A = M[y]
	U, A - M[z], P		Set condition to A-M[z] but do not store
	N, A = M[z]		If negative get M[z]
	   M[z] = A

Apart from the assembler syntax which is very different from your kitchen
variety (Herman Rubin would like it; I did like it, just as I like the
Cray assembler syntax), there are a number of problems with these conditional
executions with RISC architectures.  In general the condition following
instruction immediately follow the condition setting instructions.  This
again might impose a delay on pipelined machines.  Although, because you
can inhibit exceptions and result storing on condition following instructions
that ought not to be executed, this delay might be minimal (and possibly
even zero).  It becomes more tricky if a condition following instruction is
also condition setting (you must inhibit the condition setting also).

What I have seen from it, it works very well, and leads to cleaner code in
a number of situations.  E.g. the C code
	M[a] = (M[b] >= 0 ? M[c] : M[d]);
translates to:
	U, A = M[b], P		Set condition if M[b] positive
	Y, A = M[c]		If yes get M[c]
	N, A = M[d]		Else get M[d]
	   M[a] = A
And here we find the biggest problem I think, how to cater with a condition
following instruction that does a load?  We really want it to abort as soon
as the condition is known to be false.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl