Liste des Groupes | Revenir à c arch |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:Good point. It probably isn't too bad for the arithmetic operations, etc, but once you extend it as I suggested in the last paragraph it gets ugly. :-(The idea is to add 32 bits to the processor state, one per register...
(though probably not physically part of the register file) as a tag. If
set, the bit indicates that the corresponding register contains a
floating-point value. Clear indicates not floating point (integer,
address, etc.). There would be two additional instructions, load single
floating and load double floating, which work the same as the other 32-
and 64-bit loads, but in addition to loading the value, set the tag bit
for the destination register. Non-floating-point loads would clear the
tag bit. As I show below, I don’t think you need any special "store
tag" instructions.But we can go further. There are some opcodes that only make sense forCertainly makes reading disassembler output fun (or writing the
FP operands, e.g. the transcendental instructions. And there are some
operations that probably only make sense for non-FP operands, e.g. POP,
FF1, probably shifts. Given the tag bit, these could share the same
op-code. There may be several more of these.
disassembler).
OK, but in the vast majority of cases (i.e. unless there is something like a conditional branch that uses floating point or integer depending upon whether the branch is taken.) the flag bit that a register will have can be known well in advance. As I said, IANAHG, but that might make it easier.That is as far as I got. I think you could net save perhaps 8-12 opIn in OoO CPU, that's pretty heavy.
codes, which is about 10% of the existing op codes - not bad. Is it
worth it? To me, a major question is the effect on performance. What
is the cost of having to decode the source registers and reading their
respective tag bits before knowing which FU to use?
But actually, your idea does not need any computation results forBut even here, you almost certainly know what the tag bit for any given register is long before you execute the EXIT instruction. And remember, on MY 66000 EXIT is performed lazily, so you have time and the mechanism is in place to wait if needed.
determining the tag bits of registers (except during EXIT),
so youYes.
probably can handle the tags in the front end (decoder and renamer).
Then the tags are really separate and not part of the rgisters that
have to be renamed, and you don't need to perform any waiting on
ENTER.
However, in EXIT the front end would have to wait for the result of
the load/store unit loading the 32 bits, unless you add a special
mechanism for that. So EXIT would become expensive, one way or the
other.
Les messages affichés proviennent d'usenet.