On 2021-07-06 05:45, Mouse wrote:
My problem with CLRQ R0 is that is **necessarily** behaves
radically differe$
Depends on how you look at it.
CLRB R0: clears the lowest 8 bits starting at the low end of R0.
CLRW R0: clears the lowest 16 bits starting at the low end of R0.
CLRL R0: clears the lowest 32 bits starting at the low end of R0.
CLRQ R0: clears the lowest 64 bits starting at the low end of R0.
CLRO R0: clears the lowest 128 bits starting at the low end of R0.
The only thing that's at all notable about CLRQ and CLRO is that,
because they affect a datum larger than a register, they necessarily
affect more than one register.
Yes, CLRO (and CLRQ, on VAX-32) affect more than one register, because
they affect more than one register holds. And CLRB and CLRW (and
presumably CLRL on VAX-64) affect less than one register, because they
affect less than one register holds - so?
Look at the register file as a bitstring and CLRx Rn affects an
x-sized
string of those bits, starting at the bottom end of Rn. Where the
register boundaries happen to fall doesn't have much to do with it.
That's my take on the countering interpretation, at least.
I sortof agree with Jason here. In a sense, it's a bit more strange
to start affecting neighbouring registers.
PUSH is only one example of an instruction that affects registers
not mentioned explicitly. But the implicit effect on the SP is
clear, obvious, and always. So I can't say I see any similarity to
this situation.
If you wanted to go extreme, you would have brought up CALL, which
goes crazy on registers. But it's all very clearly documented and
intentional.
It's really just the instructions that deals with quads that get
funny when we use a register, and which will start behaving rather
differently if we were to extend the registers to be quad sized.
Everything else pretty much will still behave the same as before.
But, being used to the PDP-11, the same thing more or less exists
there with a few instructions that also pair registers up to get
larger size.
So I usually don't reflect too much about it.
But support for quads in VAX is limited, as observed. But I can see
that it is needed. The CLRQ and MOVQ could arguably have been
skipped. But the EMUL is pretty much needed, so the problem could
never go away.
The question is, though, if EMUL should be changed to work on
octawords in a VAX64 instead. EMUL is not needed for 64 bit
multiplications then, since you should have a MULQ (obviously). And
so, EMUL would then still hit two registers for the product.
Hmm. There are some things to ponder here, obviously... :-)
I do hope Jason sees the problem, and comes to the same conclusion
that something like EMUL will need to hit two registers always.
And obviously, EDIV also needs two registers for the dividend.