Re: New Vax - future directions :-)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jul 5, 2021, at 5:50 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>>> The idea that an operation that takes a single register as an argument woul$
> 
> That's certainly a defensible position.  I'm not sure whether I agree.
> I see arguments each way.
> 
> But I'm curious: what's the difference between CLRQ R0 (operates on R1
> as well) and PUSHL R0 (operates on SP as well)?  Does PUSHL upset you
> too, and, if not, why the difference?  (I see plenty of possible
> reasons; I'm curious about yours.  If, that is, PUSHL doesn't bother
> you similarly.)

The difference is that PUSHL is defined as “push long into the stack", and it would behave equivalently in either mode.  You can consider that a syntactic alias for the equivalent MOVL statement, and I I would not object for the same reason.

My problem with CLRQ R0 is that is **necessarily** behaves radically differently in 32-bit mode vs a hypothetical 64-bit mode, because in 64-bit mode the register is Q-wide, so it would only operate on one register.

> Would you feel better if the assembler syntax were "CLRQ R0-R1" or some
> such instead?

No, I’d PREFER if “CLRQ R0” on a 32-bit system threw an illegal instruction fault :-). But, as you say, I’m a bit late in my outrage.

> Does it also bother you that 3/4 of the bytes that exist in registers
> are not accessible using byte instructions?  Why or why not?

No, because they behave equivalently in 32-bit mode vs a hypothetical 64-bit mode (ok, ok, 7/8 in that case, but you get my point :-)

And before you get tripped up about buy “mode bit changes behavior of the control flow insns”, note that the control flow insns are implicitly defined as “manipulate a register’s worth of data”, and the registers are necessarily bigger in a hypothetical 64-bit mode.

-- thorpej