[Simh] SIMH handling of G floating indexed operands -- poor mans fix

BMLV / LRUE / EDV Si lrue.edv.si at bmlv.gv.at
Tue Aug 14 08:28:33 EDT 2007


Thanks for the hint,

changed line 1453 and 1454 in vax_cpu.c ('/* index */' section case MQ:) the
'write access' WA to 'read access' RA in both read statements.
My g_float indexed access problem is fixed - no side effects yet.

Andreas Huemer
----- Original Message ----- 
From: <bsupnik at comcast.net>
To: <simh at trailing-edge.com>
Sent: Monday, August 13, 2007 7:03 PM
Subject: [Simh] SIMH handling of G floating indexed operands


> 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




More information about the Simh mailing list