Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!ll-xn!mit-eddie!uw-beaver!microsoft!t-tedt
From: t-tedt@microsoft.UUCP (Ted Timar)
Newsgroups: comp.arch
Subject: Prefix instructions (Was: RPM-40 microprocessor; data from ISSCC)
Message-ID: <1199@microsoft.UUCP>
Date: 26 Feb 88 05:03:10 GMT
References: <9651@steinmetz.steinmetz.UUCP> <9678@steinmetz.steinmetz.UUCP>
Reply-To: ccplumb@watmath (Colin Plumb)
Organization: Microsoft, Inc., Redmond, Washington
Lines: 63
Confusion: U. of Waterloo, Ontario


>] I find this a very interesting architecture. My first impression is
>] that the prefix instruction makes the 16 bit instructions reasonable.
>] (A big win in my opinion.) It is rather like having an extra register
>] for holding immediate operands only. I guess it might complicate
>] exception handling though.
>
>Thanks for the complement. WE like it too. PREFIX instructions, BTW,
>is adapted from the InMOS transputer concept of building instructions
>a byte at a time. It's essentially a simplified version. An
>interesting point : it makes the RPM40 instruction set totally
>oblivious to data word size. The registers could be any number of
>bits, and the instruction set would cope gracefully. It also makes the
>instruction set "context independent", a feature of MANY if not ALL
>RISC architectures : once you have an instruction in hand, you don't
>need to know where it came from to know what it is. This is unlike,
>say, the VAX and 68K families, which have immediate values imbedded
>within the instruction stream which are only distinguishable if the
>previous "instruction" word is known. Makes dis-assembly tougher.
>Probably makes instruction decoding tougher too.
>
>Back to PREFIX : using our PREFIX scheme, we handle commonly occuring
>small constants quickly, and larger constants more slowly, but without
>using additional user-visible resources. The cost of a large constant
>is "step-wise proportional" to the constants length in bits.  Given
>what we could find in the research about constants, this is the
>correct "RISC philosophy" thing to do.

The only funny question is the semantics: what does a prefix do to an
instruction without an immediate constant?  On the Transputer, this
doesn't come up, because all instructions have immediate constants, but
in more conventional instruction sets, this is an issue.  One reaction
is to ignore it, but if you can bump the prefix instruction back an 
nstruction, it may be useful to fill a pipeline delay slot.  E.g.

LOAD value, R1
TEST value, R2
JGT  address_too_big_to_fit_in_one_instruction_without_a_prefix

If the prefix for the JGT is bumped to before the TEST, it fills the
latency of the LOAD.  This is good, but can lead to obscure code if you
put prefix instructions before a jump (or in the delay slot).

Can you just imagine, a compiler pulls the prefix instruction at the
destination of a jump into the delay slot, then notices that nobody's
using the prefix, and deletes it?  It would confuse the hell out of a
debugger (program or human).  This is worse than opcode/extension word
disambiguation.

And, of course, prefixes do add context.

>All you 32-bit instruction advocates : how many of your 32-bits of
>instruction are usually wasted ( like by leading zeroes or ones, or
>unused register specifications ) ? If it sounds like I'd welcome a
>debate on the merits of 16 vs 32 bit instructions : sure. Isn't that
>what comp.arch is for ? And I said a DEBATE, not a fire-fight :-)

Or how about prefix instructions?  Despite the problems I mentioned
above, I still think prefix instructions are a win.  But anybody have
any better ideas?
--
	-Colin (watmath!ccplumb)

"(int *)charptr is an lvalue" - Heard around campus today.