Re: New Vax - future directions :-)

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

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

Maybe not in some VAXen, or some versions of the VARM.  But they're in
the VARM as of EL-00032-00-decStd32_Jan90.  CLRO is 7CFD, on page 3-14
along with CLRB, CLRW, CLRL, and CLRQ, and MOVO is 7DFD, on page 3-25
along with MOVB, MOVW, MOVL, and MOVQ.  (7CFD is also CLRH on page
3-123; MOVH is 70FD, on 3-134, not the same as MOVO.)

MOVO, MOVH, and CLRO/CLRH _are_ in an optional instruction group, but
they're well-defined.

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

I'm not sure whether I'd consider it more or less ugly.  In isolation
from all the rest of the quadword stuff, I think I would prefer it with
the explicit halves.  In conjunction with the rest of the quadword
stuff, I think using the existing quadword support was the right call.

> But that then also leads to the implied concatenation of registers
> when we talk about D-floats, G-floats and H-floats...

Indeed.

> Should all instructions there then also explicitly list all registers
> to be used for all the parts?

No, I think not.  [DGH]-float form another part of the (IMO compelling)
argument in favour of Q and O being in consecutive registers, with only
the lowest of them explicitly named.

I'm not sure it wouldn't've been better to work the way (say) the SPARC
double-float support does and require that a quadword be in an even
register and the next-higher odd register, but that would rather fly in
the face of the VAX's "no alignment required" philosophy.  (Arguably no
more so than the inaccessibility of 3/4 of the bytes in registers to
byte instructions....)

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

Well, there's a slight subtlety.

CLRQ is two things on VAX-32, and they do not map to the same thing on
VAX-64.  CLRQ is both "clear 64-bit datum" and "clear double-word
datum", and those are no longer the same thing on VAX-64.  Given the
way the naming conventions are set up, I think the name CLRQ should be
attached to the 64-bit - single-word - operation on VAX-64.

It's possibly arguable that there should be a CLRR or some such, taking
a .rw operand and clearing all registers that correspond to set bits in
the operand, likely with a reserved operand fault if the 0x8000 bit is
set.  But that's probably unwarranted tinkering with the instruction
set, like various other instructions I'd kinda like to see but probably
won't, such as FLS, FLC, COUNT, and ALU, though admittedly CLRR feels
less VAXy than the others, in that instructions that work only on
registers are relatively rare.

/~\ 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