Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780

[Ethan Dicks]

On Thu, May 18, 2017 at 5:25 PM, Johnny Billquist  wrote:
> RX50. And yes, I installed MicroVMS on a MicroVAX II in 1986.

We got a MicroVAX I in late 1984 or early 1985 and later upgraded it
to a MicroVAX II ($17K upgrade, IIRC).  Our uVAX-II distro medium was
TK50, but we kept that MicroVAX-I on RX50 distros until we stopped
paying support on it (late 80s).

> A really weird
> story, which is why I remember it so well. I don't remember the exact
> number, but I think it was between 20 and 30 floppies.

Sounds about right.  I think it was several savesets applied in turn,
not just a monolithic 1/30, 2/30... so I don't recall the exact number
either.

>> I believe that the first "Micro" versions of VMS started with MicroVMS 4.4
>> when the MicroVAX family was added.

I might still have our MicroVMS 1.0 floppies in a box, but they jumped
from that to MicroVMS 4.x in sync with "regular" VMS once it was all
part of the general release schedule.

I think MicroVMS 1.0 only runs on the KA610, not the KA630.  Not sure
exactly when KA630 support came in, but it would have been mid-1985.

-ethan
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] ASTLVL

[Bob Supnik]

From page 6-6 of DEC STD 032 (the VAX architecture spec): "Execution of 
MTPR src, #PR$_ASTLVL with src<31:0> GEQU 5 results in UNDEFINED 
behavior. The preferred implementation is to cause a reserved operand 
fault." MicroVAX II, CVAX, and Rigel all conform to the preferred 
behavior, as does the current simulator, which was written from the CVAX 
microcode. NVAX masks to 3b and does not take an exception on a value 
GEQU 5.


The 1982 Architecture Handbook describes ASTLVL as a 3b register, with 
src<31:3> ignored/read as zero, and exceptions taken on values GEQU 5. 
The780 microcode masks the input value to 3b before doing the GEQU 5 test.


So yes, the ASTLVL test needs to be model specific. I'm sending the 
overall fix and updates for CVAX and the 780 to Mark.


I suspect the behavior became undefined when MicroVAX II simplified the 
original test to save a microword. I do not see how the code fragment 
Matt references could work on a MicroVAX II, which was supported under 
4.5. Perhaps the device Matt mentions couldn't exist on a MicroVAX II?


For those who wants the gory details... uVAX, CVAX, and Rigel do an 
unsigned compare on the unmasked src and the constant 5. Carry out means 
reserved operand. Overflow is ignored. So an input of 0x8002 - 
0x0005 (done in the data path as 0x8002 + 0xFFFB) generates 
overflow (ignored) and carry out.


/Bob





___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780

[Paul Koning]

> On May 18, 2017, at 3:26 AM, Johnny Billquist  wrote:
> 
> On 2017-05-18 03:23, Paul Koning wrote:
>> ...
> 
>> Is MT_ASTLVL defined as a register where only the low byte has meaning?
> 
> Seems like it was using even fewer than 8 bits... Looked like it was only 3 
> bits. But the register itself seems to be defined as 32 bits. I'm not even 
> sure any processor internal registers can be anything else.
> 
> All that said, Matt Burke seems like he already identified the issue pretty 
> correctly. The VAX 11/780 Hardware Handbook seems to clearly say that bit 
> 3-31 are ignored, and returns as 0 on read. So for that model, I guess the 
> value should be masked.
> 
> However, this might be different on different CPU models, so I suspect this 
> should be applied with care. He was testing VAX/VMS V4.5, which is pretty 
> ancient. The models supported by that version would probably only be the 
> VAX-11 models. (And yes, I include the 86x0 in the VAX-11 series.)

The VAX architecture reference manual shows that register the same way (3 LSB 
are meaningful, rest is ignored on write, read as zero).  So that seems to say 
this is a standard definition, not a model-specific one, and it is safe for 
software not to worry about those other bits when writing the register.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780

[Armistead, Jason]

Johnny Billquist wrote:

>However, this might be different on different CPU models, so I suspect this 
>should be applied with care.
>He was testing VAX/VMS V4.5, which is pretty ancient. The models supported by 
>that version would probably only be the VAX-11 models. (And yes, I include the 
>86x0 in the VAX-11 series.)

MicroVMS 4.5B was available for MicroVAX 2000 circa 1987.  I remember loading 
it from a large stack of between 50 and 70 RX33 (?) floppies ...  what fun !

I believe that the first "Micro" versions of VMS started with MicroVMS 4.4 when 
the MicroVAX family was added.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780

[Sergey Oboguev]

Matt Burke  wrote:

> Whilst experimenting with a new device on VAX/VMS V4.5 I got a fatal
> bugcheck (exception whilst above ASTDEL). The problem turned out the be
> a reserved operand fault and I traced it back to the following code
> (shown here from the VMS 3.0 source listings):
> 
> MOVL    PCB$L_PHD(R0),R0    ; Get PHD address
> MOVB    PHD$B_ASTLVL(R0),R0    ; And fetch ASTLVL
> MTPR    R0,#PR$_ASTLVL  ; Update current value

FWIW, the sequence does not appear to be present in 3.7-dev, 4.0 or 7.3 sources.

(For 3.x and 4.x I checked only ASTDEL, not ASMP code -- speaking on which, 
would not it be fun to emulate 11/782 or 11/784?)

Is this exact sequence actually indicated by the instruction trace when running 
4.5?

Thanks,Sergey
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780

[Johnny Billquist]

On 2017-05-18 03:23, Paul Koning wrote:



On May 17, 2017, at 8:00 PM, Matt Burke  wrote:

On 18/05/2017 00:18, Johnny Billquist wrote:


Hum. Do I remember wrong? I seem to remember that when you MOVB to a
register, the value should be sign extended. So not just the low byte
should have been modified.

   Johnny



I think you may be thinking of MOVZBL (and MOVZWL for words).


Or the PDP11, where indeed MOVB sign extends.


Yeah, it definitely does it on the PDP-11. I always feel divided on 
whether I think it should or not.


But I was obviously remembering wrong. MOV instructions on the VAX does 
not sign extend. The CVT instructions are used if you want that.



Is MT_ASTLVL defined as a register where only the low byte has meaning?


Seems like it was using even fewer than 8 bits... Looked like it was 
only 3 bits. But the register itself seems to be defined as 32 bits. I'm 
not even sure any processor internal registers can be anything else.


All that said, Matt Burke seems like he already identified the issue 
pretty correctly. The VAX 11/780 Hardware Handbook seems to clearly say 
that bit 3-31 are ignored, and returns as 0 on read. So for that model, 
I guess the value should be masked.


However, this might be different on different CPU models, so I suspect 
this should be applied with care. He was testing VAX/VMS V4.5, which is 
pretty ancient. The models supported by that version would probably only 
be the VAX-11 models. (And yes, I include the 86x0 in the VAX-11 series.)


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh