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:41, skrev Johnny Billquist:
On 2021-07-06 10:28, Anders Magnusson wrote:
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.

I would disagree, unless we then say we do not care about anything larger than 64 bits.

The reason EMUL and EDIV exists is because you needed a way of doing multiplications and division with larger than 32-bit values. I think it was very obvious they were needed, and not strange at all.
Those instructions are quite useless today as well.  Since EMUL takes two 32-bit signed integers and produces 64-bit signed output it is a very special case when it even can be used. The same is true with EDIV, it is possible to get a s32 remainder, but the rest needs extra code.

If you have two 64-bit values which you multiply, there is a fair chance the result will not fit into 64 bits, and a carry won't be enough to handle the overflow. :-) Then what? Just give up. Leave it all to be done in software? Or add some instruction that can assist you?
Yes, do it in software.  You don't have any modern language that want to deal with the upper part anyway.

-- R

Adding a UMULL on the VAX would not have removed the need for EMUL. But it would have been nice to also have an EUMUL.


Home | Main Index | Thread Index | Old Index