[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New Vax - future directions :-)
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
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
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
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
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.
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?
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.
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Main Index |
Thread Index |