[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New Vax - future directions :-)
On 2021-07-06 16:22, Mouse wrote:
I sortof agree with Jason here. In a sense, it's a bit more strange
to start affecting neighbouring registers.
Yes, I sort-of agree with him too. But I don't entirely agree with
him; I was arguing the opposing point of view because it _was_ the
opposing point of view. Not because I want to be difficult, but
because I think that we'll get the best result if we examine all the
Fair enough. In the end, I am happy with the way the VAX did it, so this
is sortof a nit-picking thing. :-)
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
Yes, but so is CLRQ.
Arguable much less so.
While the various registers involved is clearly documented for each of
the other instructions mentioned, the implicit effect on another
register in the Q instructions are only explained in a different place
that covers the general behavior of quad values in registers.
It's really just the instructions that deals with quads
...or octawords; there's no ASHO, but there are CLRO and MOVO (and
MOVAO and PUSHAO, which appear to be less upsetting).
There is no CLRO or MOVO. I checked. :-)
But had there been, it's the same story, yes.
MOVAO and PUSHAO does not affect any implicit registers, since there
we're just dealing with an address, which always fits into one register.
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.
But EMUL could have been
opcode mulr.rl, muld.rl, add.rl, prodl.wl, prodh.wl
instead, with a similar change to EDIV.
True. I would have considered it more ugly than the quad in a register
using Rn/Rn+1, but it would have been a possibility.
But that then also leads to the implied concatenation of registers when
we talk about D-floats, G-floats and H-floats...
Should all instructions there then also explicitly list all registers to
be used for all the parts?
It would become very unwieldy. :-)
The question is, though, if EMUL should be changed to work on
octawords in a VAX64 instead.
Yes, I think it should be: either drop it or make it a 64×64->128
multiply. (I think EMULU would be more useful, but that's independent
of the 32->64 bit shift.)
I agree. :-)
EMUL is not needed for 64 bit multiplications then,
No, but do you think the desire for fullword×fullword->doubleword
multiply will go away? I don't. It's just a guess, but I would guess
that most of the EMUL instructions executed are, conceptually, not just
doing 32×32->64 but rather being part of >64-bit arithmetic. (That's
one reason I would like EMULU; it's more useful for that.)
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.
My impression - though that's all it is - is that Jason would have been
happier to see EMUL/EDIV have two explicit operands for the two halves
of the 64-bit operand, as I sketched above. I speculate - and, again,
that's all it is - that the reason DEC didn't do that is PDP-11
heritage giving them an inclination towards pasting two registers
The PDP-11 does it slightly differently, but it usually ends up the
same. And as I am so used to it, I don't have any real problems.
It took me a little while to find the correct place in the processor
handbook that explained it, but after that I was happy.
But I do agree it is a bit of a problem in that it's an implied register
reference that is slightly different, and which clearly should change
some if we were to extend the size of the registers.
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 |