Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New Vax - future directions :-)



Den 2021-07-06 kl. 10:16, skrev Johnny Billquist:
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.
In 64-bit mode nothing should ever span multiple registers.
EDIV/EMUL are strange creatures anyway, no reason to have a 64-bit counterpart.  DIVQ/UDIVQ/REMQ/UREMQ/MULQ/UMULQ will solve the problem.

-- R




Home | Main Index | Thread Index | Old Index