VSI FreeAXP Student kit and MONITOR display problem
- Bruce Claremont
- Topic Author
- Visitor
3 years 10 months ago #5784
by Bruce Claremont
Replied by Bruce Claremont on topic RE: VSI FreeAXP Student kit and MONITOR display problem
Thanks Volker. We'll see if VSI will assistance.
Please Log in or Create an account to join the conversation.
- VolkerHalle
- Topic Author
- Visitor
3 years 10 months ago #5785
by VolkerHalle
Replied by VolkerHalle on topic RE: VSI FreeAXP Student kit and MONITOR display problem
The problem is absolutley reproducable on the new VSI 2021.1 Student Kit (OpenVMS Alpha V8.4-2L2) containing FreeAXP 4.0.0.646
When running MONITOR.EXE from OpenVMS Alpha V8.2 or E8.4 on this installation, the problem does NOT show up.
So the problem clearly is being triggered from 'some specific instruction stream' inside the MONITOR.EXE image from OpenVMS Alpha V8.4-2L2 on FreeAXP !
After creating a forced process dump from a running MONITOR TIMER operation and dumping the complete code section of the resulting MONITOR.DMP file (using SDA>exa/ins 40000:70ec0+30) , it could be shown, that the V8.4-2L2 MONITOR.EXE image uses some EV6-specific instructions:
$ sea monitor_inst.lis itof ! does V8.4-2L2 monitor use new EV6 instructions ?
MONITOR+3C128: ITOFT R25,F1
MONITOR+3C130: ITOFT R16,F0
...
$ sea monitor_inst.lis ftoi
MONITOR+3CC68: FTOIT F0,R23
MONITOR+3DEB4: FTOIS F10,R19
...
So the correct implementation of the emulation of these instructions should probably be closely examined first
Volker.
When running MONITOR.EXE from OpenVMS Alpha V8.2 or E8.4 on this installation, the problem does NOT show up.
So the problem clearly is being triggered from 'some specific instruction stream' inside the MONITOR.EXE image from OpenVMS Alpha V8.4-2L2 on FreeAXP !
After creating a forced process dump from a running MONITOR TIMER operation and dumping the complete code section of the resulting MONITOR.DMP file (using SDA>exa/ins 40000:70ec0+30) , it could be shown, that the V8.4-2L2 MONITOR.EXE image uses some EV6-specific instructions:
$ sea monitor_inst.lis itof ! does V8.4-2L2 monitor use new EV6 instructions ?
MONITOR+3C128: ITOFT R25,F1
MONITOR+3C130: ITOFT R16,F0
...
$ sea monitor_inst.lis ftoi
MONITOR+3CC68: FTOIT F0,R23
MONITOR+3DEB4: FTOIS F10,R19
...
So the correct implementation of the emulation of these instructions should probably be closely examined first
Volker.
Please Log in or Create an account to join the conversation.
- VolkerHalle
- Topic Author
- Visitor
3 years 10 months ago #5786
by VolkerHalle
Replied by VolkerHalle on topic RE: VSI FreeAXP Student kit and MONITOR display problem
Looks like the error is in the emulation of the FTOIS instruction
What I've done to diagnose this:
- patch the image header of a copy of MONITOR.EXE to set the EIHD$V_DEBUG flag and add/ modify the transfer addresses to first invoke $IMGSTA and then the real transfer address
- $ define/SYS/EXE monitor Dev:<dir>copy-of-monitor
- I tried DBG> set br/ins=(itoft,ftoit) and it failed:
%DEBUG-E-INTERR, debugger error in DBG$PARSE_INSTRUCTION - NYI for Alpha or session corruption
- so I set breakpoints on ALL occasions of the new EV6 instructions ITOF* and FTOI*
- run patched MONITOR with debug and a little MONITOR.DAT input file created by 3 cycles of MONITOR/RECORD TIMER - this guarantees the SAME input being processed every time !
- only 3 of all the above breakpoints were really being hit
- created a small DEBUG .COM file to examine the registers used on those 3 EV6 instructions BEFORE and AFTER the execution, the important one is this:
SET BR 10000+4A218 DO (EXA/INS @PC; EXA/S_FLOAT F10; EXA/HEX F10; STEP/INS ; EXA R26; STEP/INS; EXA/T_FLOAT F11; EXA/HEX F11)
- compared the BEFORE and AFTER values when executing these instructions on the FreeAXP and a CHARON-AXP/DS20 (sorry, I have no real EV6 machine).
... and finally found the problem:
$ type monitor_debug_ds20.log
!SHARE$MONITOR+4A218: FTOIS F10,R26
g
!break at SHARE$MONITOR+4A218
!SHARE$MONITOR+4A218: FTOIS F10,R26
!0\%F10: 0.0000000E+00
!0\%F10: 0000000800000000 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A21C: ITOFT R26,F11
!0\%R26: 0000000000000040 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A220: STL R26,(R18)
!0\%F11: 0.316202013338398E-321
!0\%F11: 0000000000000040
SYS$SYSROOT:[SYSMGR]MONITOR_DEBUG_FREEAXP.LOG;2
!SHARE$MONITOR+4A218: FTOIS F10,R26
g
!break at SHARE$MONITOR+4A218
!SHARE$MONITOR+4A218: FTOIS F10,R26
!0\%F10: 0.0000000E+00
!0\%F10: 0000000800000000 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A21C: ITOFT R26,F11
!0\%R26: 0000000000000000 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A220: STL R26,(R18)
!0\%F11: 0.000000000000000
!0\%F11: 0000000000000000
The FTOIS F10, R26 instruction delivers a different output value of R26 for the same input value of F10 when run on FreeAXP. This is worth further analysis...
Volker.
What I've done to diagnose this:
- patch the image header of a copy of MONITOR.EXE to set the EIHD$V_DEBUG flag and add/ modify the transfer addresses to first invoke $IMGSTA and then the real transfer address
- $ define/SYS/EXE monitor Dev:<dir>copy-of-monitor
- I tried DBG> set br/ins=(itoft,ftoit) and it failed:
%DEBUG-E-INTERR, debugger error in DBG$PARSE_INSTRUCTION - NYI for Alpha or session corruption
- so I set breakpoints on ALL occasions of the new EV6 instructions ITOF* and FTOI*
- run patched MONITOR with debug and a little MONITOR.DAT input file created by 3 cycles of MONITOR/RECORD TIMER - this guarantees the SAME input being processed every time !
- only 3 of all the above breakpoints were really being hit
- created a small DEBUG .COM file to examine the registers used on those 3 EV6 instructions BEFORE and AFTER the execution, the important one is this:
SET BR 10000+4A218 DO (EXA/INS @PC; EXA/S_FLOAT F10; EXA/HEX F10; STEP/INS ; EXA R26; STEP/INS; EXA/T_FLOAT F11; EXA/HEX F11)
- compared the BEFORE and AFTER values when executing these instructions on the FreeAXP and a CHARON-AXP/DS20 (sorry, I have no real EV6 machine).
... and finally found the problem:
$ type monitor_debug_ds20.log
!SHARE$MONITOR+4A218: FTOIS F10,R26
g
!break at SHARE$MONITOR+4A218
!SHARE$MONITOR+4A218: FTOIS F10,R26
!0\%F10: 0.0000000E+00
!0\%F10: 0000000800000000 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A21C: ITOFT R26,F11
!0\%R26: 0000000000000040 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A220: STL R26,(R18)
!0\%F11: 0.316202013338398E-321
!0\%F11: 0000000000000040
SYS$SYSROOT:[SYSMGR]MONITOR_DEBUG_FREEAXP.LOG;2
!SHARE$MONITOR+4A218: FTOIS F10,R26
g
!break at SHARE$MONITOR+4A218
!SHARE$MONITOR+4A218: FTOIS F10,R26
!0\%F10: 0.0000000E+00
!0\%F10: 0000000800000000 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A21C: ITOFT R26,F11
!0\%R26: 0000000000000000 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
!stepped to SHARE$MONITOR+4A220: STL R26,(R18)
!0\%F11: 0.000000000000000
!0\%F11: 0000000000000000
The FTOIS F10, R26 instruction delivers a different output value of R26 for the same input value of F10 when run on FreeAXP. This is worth further analysis...
Volker.
Please Log in or Create an account to join the conversation.
- Bruce Claremont
- Topic Author
- Visitor
3 years 10 months ago #5787
by Bruce Claremont
Replied by Bruce Claremont on topic RE: VSI FreeAXP Student kit and MONITOR display problem
Thanks Volker. You'll have it solved soon<img src='../images/smiley/smile.gif' alt='smiley'>.
Camiel had been examining the new/modified instructions in VMS 8.4-2L2. As you've shown, the problem lies there.
The bad news is that for people running on real pre-EV6 hardware, VMS 8.4 is likely their last fully supported release.
Camiel had been examining the new/modified instructions in VMS 8.4-2L2. As you've shown, the problem lies there.
The bad news is that for people running on real pre-EV6 hardware, VMS 8.4 is likely their last fully supported release.
Please Log in or Create an account to join the conversation.
- Bruce Claremont
- Topic Author
- Visitor
3 years 10 months ago #5788
by Bruce Claremont
Replied by Bruce Claremont on topic RE: VSI FreeAXP Student kit and MONITOR display problem
We've developed a fix, which will be available in the next release. No release date as of yet.
Please Log in or Create an account to join the conversation.
Moderators: iamcamiel
Time to create page: 0.179 seconds