[Simh] SIMH handling of G floating indexed operands

[bsupnik at comcast.net]

This is a real bug; thanks for reporting it.

>From the earliest days, the specifier decoding logic for index had a 'short cut', trying to treat the read-access floating point data types as being 'identical' to some underlying integer data type.  So read.F was mapped to read.L, D to Q, and O to Q, which worked fine.  But read.G couldn't be mapped to read.Q, because that underlying type was already used by read.D.  So read.G was mapped to modify.Q, because (according to the comments) read.Q and modify.Q are treated "identically."  But they are not identical: read access operands are read checked, modify access operands are write checked.  This causes the bug.

It affects all indexed read-access G floating operand types.

The fix is not straightforward and will require extensive testing.  Essentially, the index operand code must not mask out the 'special dispatch' bit and must provide extra case points for the special dispatches.  I will get this fix into the next release of SimH, as soon as I can test it adequately.

/Bob Supnik

 -------------- Original message ----------------------
From: simh-request at trailing-edge.com
> Send Simh mailing list submissions to
> 	simh at trailing-edge.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.trailing-edge.com/mailman/listinfo/simh
> or, via email, send a message with subject or body 'help' to
> 	simh-request at trailing-edge.com
> 
> You can reach the person managing the list at
> 	simh-owner at trailing-edge.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Simh digest..."
> 
> 
> Today's Topics:
> 
>    1. 2nd try problem: simh 3.7-1 VAX accvio reason=4 during addg3
>       indexed access to second operand (BMLV / LRUE / EDV Si)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 13 Aug 2007 09:37:53 +0200
> From: "BMLV / LRUE / EDV Si" <lrue.edv.si at bmlv.gv.at>
> Subject: [Simh] 2nd try problem: simh 3.7-1 VAX accvio reason=4 during
> 	addg3	indexed access to second operand
> To: <simh at trailing-edge.com>
> Message-ID: <004801c7dd7c$db9a8a90$0283e00a at ZE083006>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hello,
> 
> I hope this is the correct mailbox for problem reporting.
> 
> my simh  vax emulator (3.7-1) fails while executing mth$gsind under vms 7.0.
> the debugger identified the failing code
> 
> .psect data nowrt,noexe
> table: .g_floating 0.0, 90.0
> 
> .psect code nowrt,exe
> addg3 r0, table[r4], r2
> 
> the addg3 access to the second operand (table[r4]) causes an access violation 
> (reason=4).
> the table is not-writable but the instruction seems to access it in write mode.
> 
> addg3 r0, table, r2 
> 
> works without problems.
> the d_float and h_float variant of mth$sind works too.
> the same code works on my real vax (VAXstation 4090) without problems.
> 
> Do you have a hint for me where to look for a fix in the simh-code??
> 
> 
> Andreas Huemer
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://mailman.trailing-edge.com/pipermail/simh/attachments/20070813/f59e6e9e/at
> tachment-0001.html 
> 
> ------------------------------
> 
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> 
> End of Simh Digest, Vol 45, Issue 8
> ***********************************