[Simh] Problem with MT_ASTLVL on the VAX-11/780
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): MOVLPCB$L_PHD(R0),R0; Get PHD address MOVBPHD$B_ASTLVL(R0),R0 ; And fetch ASTLVL MTPRR0,#PR$_ASTLVL ; Update current value As you can see R0 will contain an S0 address after the first instruction, then only the lower byte is overwritten with the new AST level. The whole longword is then written to the ASTLVL IPR. Currently the test for this IPR in vax_cpu1.c is: if (val > AST_MAX) RSVD_OPND_FAULT; Due to S0 addresses having bit 31 set this triggers the reserved operand fault. The VMS code is clearly expecting a mask to be applied to the value. I've checked various manuals to try and find the answer but the results were not totally conclusive. EB-17835-18 - VAX-11/780 Hardware Handbook (1979) http://manx-docs.org/details.php/1,8111 Page 71 - Bits <31:3> ignored, returns 0 EK-VAXV2-HB-002 - VAX Maintenance Handbook (VAX-11/780) (Mar 1983) http://manx-docs.org/details.php/1,2826 http://www.bitsavers.org/pdf/dec/vax/780/EK-VAXV2-HB-002_vaxMaintHbk_Mar83.pdf Page 119 - Reserved operand fault if not valid i.e. MBZ /= 0 EP-ES0AA-DL-124 - VAX-11/780 Microcode (Jan 1982) http://www.bitsavers.org/pdf/dec/vax/780/fiche/EP-ES0AA-DL-124_4of6_780uCode_Jan82.pdf Page 678 - A mask of 0x7 is applied at line 25908 I've also looked at the VAX-11/750 and came up with similar results: EK-VAXV3-HB-001 - VAX Maintenance Handbook (VAX-11/750) (Mar 1983) http://manx-docs.org/details.php/1,2827 Page 20 - Reserved operand fault if not valid i.e. MBZ /= 0 CMT098.MCX - VAX-11/750 Microcode (Nov 1983) http://www.bitsavers.org/pdf/dec/pdp11/xxdp/fiche_200dpi/0187_CMT098.MCX_750uCod.pdf Page 855 - A mask of 0x7 is applied at line 35030 I guess the microcode listings are the ones to trust and the two VAX Maintenance Handbooks are probably incorrect. I've prepared a fix to add a machine specific test for the AST level IPR but I just wanted to open this up for comments before sending a pull request in case I might have overlooked something. Matt ___ 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
Hi. On 2017-05-18 00:55, 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): MOVLPCB$L_PHD(R0),R0; Get PHD address MOVBPHD$B_ASTLVL(R0),R0 ; And fetch ASTLVL MTPRR0,#PR$_ASTLVL ; Update current value As you can see R0 will contain an S0 address after the first instruction, then only the lower byte is overwritten with the new AST level. The whole longword is then written to the ASTLVL IPR. Currently the test for this IPR in vax_cpu1.c is: 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 -- 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
Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780
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). Matt ___ 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
No. MOVZx is when you don't want to have the value sign extended. Ie. move *zero* extended. Johnny Matt Burke skrev: (18 maj 2017 02:00:21 CEST) >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). > >Matt > >___ >Simh mailing list >Simh@trailing-edge.com >http://mailman.trailing-edge.com/mailman/listinfo/simh -- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___ 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
Hi Johny, > 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. I thought so too, but decided to check and found this is not true. From the “VAX Architecture Handbook”, 1981, page 179: “Unlike the PDP-11, but like the other VAX-11 instructions, MOVB and MOVW do not modify the high order bytes of a register destination. Refer to the MOVZxL and CVTxL instructions to update the full register contents.” Regards, Jeremy Begg +-+ |VSM Software Services Pty. Ltd. | | http://www.vsm.com.au/ | | "OpenVMS Systems Management & Programming"| | Web & Email Hosting| |-| | P.O.Box 402, Walkerville, | E-Mail: jer...@vsm.com.au | | South Australia 5081 | Phone: +61 8 8221 5188 | |---| Mobile: 0414 422 947 | | A.C.N. 068 409 156 | FAX: +61 8 8221 7199 | +-+ ___ 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
> 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. Is MT_ASTLVL defined as a register where only the low byte has meaning? 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
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
Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780
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 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
> 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
On 2017-05-18 15:20, Armistead, Jason wrote: 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 ! RX50. And yes, I installed MicroVMS on a MicroVAX II in 1986. 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. I believe that the first "Micro" versions of VMS started with MicroVMS 4.4 when the MicroVAX family was added. I was trying to remember when the uVAX hardware and support came, and 4.5 is at the verge when it happened. Either way, I was still thinking that this might behave differently on different VAX implementations, and such an early version might have had to be changed later with new models. But it seems Paul think the register is actually defined to mask away all but the low 3 bits according to VARM. Oh well. It might be that it should be done generally in that case. 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
Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780
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
Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780
On 18/05/2017 09:11, Sergey Oboguev wrote: > 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): > > > > MOVLPCB$L_PHD(R0),R0; Get PHD address > > MOVBPHD$B_ASTLVL(R0),R0; And fetch ASTLVL > > MTPRR0,#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 Actually this is the ASMP code :) The file is [MP.LIS]MPINT.LIS and I think this instruction sequence is present from VMS 3.0 to 4.7 Matt ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
