Path: utzoo!mnetor!uunet!steinmetz!sungoddess!oconnor
From: oconnor@sungoddess.steinmetz (Dennis M. O'Connor)
Newsgroups: comp.arch
Subject: Re: Prefix instructions (Was: RPM-40 microprocessor; data from ISSCC)
Message-ID: <9765@steinmetz.steinmetz.UUCP>
Date: 3 Mar 88 04:37:40 GMT
References: <448@imagine.PAWL.RPI.EDU>
Sender: news@steinmetz.steinmetz.UUCP
Reply-To: oconnor%sungod@steinmetz.UUCP
Organization: GE Corporate R&D Center
Lines: 87

An article by ccplumb@watmath.waterloo.edu (Colin Plumb) says:
] 
] beowulf!lunge!steinmetz.UUCP!jesup wrote:
] >In article <1199@microsoft.UUCP> ccplumb@watmath (Colin Plumb) writes:
] >>The only funny question is the semantics: what does a prefix do to an
] >>instruction without an immediate constant?
] >
] >In the RPM-40, nothing.  Goes to the great bit-bucket in the sky.
] >In the more general case you mentioned, you COULD seperate prefixes from
] their instructions, but it would really make the reorganizer hard to write
] (I know, I've written them!)  Also, the prefix logic would be more
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
              Uh, not by yourself, though, eh ? :-)

] >complicated (and thus slower/bigger).

Also, the maximum distance over which the instruction stream could
have a pending effect on the context goes up. But maybe this IS a win,
I don't think it adds to size-of-context or IVR decoder. Hmmm.

] Well, what happens if you conditionally skip an instruction with
] prefixes?  There are two appraoches:
] Skip until the next non-prefix instruction, so
] 
] skip
] prefix
] operation

And this is indeed what is done. More, actually. But I'm not sure
if I can tell how much more yet. Sorry. DARPA Contract restriction.
 
] would work, or allow prefixes to span skips, so you could have
] 
] prefix
] skip
] operation

This assumes the "skip" instruction ( we call then "COND"s, but 
"skip" might be better ) does not itself use an immediate. MAny,
if not most, will. But if it DOESN'T, and you were using the "prefixes
hang around till somebody uses them" model, I think that would be OK too.
] 
] Both would take the same time, but I don't know which would be easier
] to implement.

From what I remember of the circuit design, they'd be about the same.

] For chips with delayed jumps, prefix instructions are a pain, since you
] can't put a prefix-using instruction into the delay slot.  Another
] special case for the code reorganizer to worry about.

Uh, that's assuming a SINGLE delay slot. But for any REASONABLE number
of delay slots, you are right, this is a limitation. Tradeoffs, always
people say to me, another damn tradeoff :-)

] And can you put a prefix instruction into the delay slot?  If it's
] the target of the jump, it's advantageous to move it back to the
] no-op, but a bit confusing.

Sure you can put prefixes in a branch slot, just like any other
instruction you move there. Just make sure it either works for both
directions of the branch ( assuming, of course, a conditional branch )
or that it gets "undone" (in this case, "harmlessly used", such as
by moving to an always-zero null register) on the rarely-taken path.

] Essentially, prefix instructions add non-register context which is, as
] a general rule, A Bad Thing.  However, they simplify instruction
] decode, A Good Thing.  It really only becomes a problem when you're
] dealing with skip instructions or delay slots, where you're applying
] special-case logic to *one* instruction?  Is a prefix a full-fledged
] instruction, or part of a larget unit?

As implemented, prefixes, though decoded seperately, are semantically
part of the instruction to which they apply. 

] I hope I've made my concerns clear; now can someone soothe them?
] I'd love to see a really neat solution to all this.

I'm gonna think about some of the one's you've proposed. Hmmm... 
there's obviously a mind at work out there. Better be careful...

] >     //Randell Jesup			      Lunge Software Development
] 	-Colin (watmath!ccplumb)
--
    Dennis O'Connor			      oconnor%sungod@steinmetz.UUCP
		   ARPA: OCONNORDM@ge-crd.arpa
   (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)