Re: New Vax - future directions :-)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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
angles first.

> 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.

Yes, but so is CLRQ.

> 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).

> 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.

> 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.)

> 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
together.

I think part of the reason this wasn't brought up upthread is that,
while that makes sense for EMUL and EDIV, it makes less sense for CLRQ
or MOVQ, and CLRQ is where the conversation started.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B