> Just curious, do we need a dedicated zero register and sink register?
> The zero register always reads zero, and can not be written. The sink
> register can not be read, and write to it can be ignored.
I brain-stormed this idea a while ago, and here's what I came up with.
We're not RISC, so we don't need to worry about mapping "mov %r1 -> %r2"
to "or %r1, %r0 -> %r2", which is probably the most common use.
Additionally we'll always be able to use constants of size 32/64bits.
RISC could only use 8-22bit constants so often times it was easiest to
operate on a full 32bit zero. We could always add a second constant
parameter to an instruction if it was demed useful enough.
As for a bit-buck, I can't imagine why you'd use it. Side effects and
no-ops are all I can remember them ever being useful for. But again we're
not RISC, we have a no-op, and can add separate functions for
side-effects.
Lastly, the main reason I say no:
AUTO_OP add_i_i_i {
int p2_val = 0, p3_val = 0;
if ( P2 != 0 ) {
p2_val = REG_INT(P2);
}
if ( P3 != 0 ) {
p3_val = REG_INT(P3);
}
if ( P1 == 0 ) {
p2_val+p3_val;
} else {
REG_INT(P1) = p2_val+p3_val;
}
}
Any questions?
You could have an optimizer convert all %i0 to constants and rearrange the
op-code so it maps to a real one, but you could just have had the compiler
produce proper code in the first place. I don't think we're looking to
use assembly as one of the "supported" language layers. Due to it's
propensity to change.
-Michael
