t-tedt@microsoft.UUCP (Ted Timar) (02/26/88)
>] 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.
jesup@pawl18.pawl.rpi.edu (Randell E. Jesup) (02/29/88)
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 complicated (and thus slower/bigger). // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
ccplumb@watmath.waterloo.edu (Colin Plumb) (03/02/88)
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 >complicated (and thus slower/bigger). 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 would work, or allow prefixes to span skips, so you could have prefix skip operation Both would take the same time, but I don't know which would be easier to implement. 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. 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. 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? 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. > > //Randell Jesup Lunge Software Development > // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 > \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 > \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup > >(-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-) -- -Colin (watmath!ccplumb) Zippy says: I've got a COUSIN who works in the GARMENT DISTRICT...
oconnor@sungoddess.steinmetz (Dennis M. O'Connor) (03/03/88)
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 :-)