[Simh] Needed: RH750 specification

[Timothe Litt]

For the non-"SRM lawyers":  the short(er) form of my long reply:

1) Yes, SimH needs to match the 750's behavior.

2) No, the SRM doesn't tell you how to do it. 

3) The *code* in question violates the SRM because this instruction is
not allowed to reference I/O space.  The result is UNDEFINED, which
means that the 750 implementation can do anything except hang the
processor or console.  This includes executing the instruction as if the
operand was in memory, but that's not the only possibility.  Singing
"God save the Queen" on the paper tape punch and clearing memory is
equally valid.  Really. :-)

So any argument that defines useful behavior based on the SRM is not
dispositive.

4) Exactly how the instruction is implemented when the operand IS in
memory can differ from the literal SRM text, as long as the programmer
sees results AS IF the SRM text was followed literally.  Which is hard
because the text is somewhat confused.  But memory behavior is fairly
flexible.  Attempting to apply this to I/O space gets complicated,
because I/O space has special characteristics and rules. (This is why
there are restrictions on which instructions can be used.)

What SimH does now is SRM-compliant.  It's just not useful in that the
hardware does something different.

The 750 specs may or may not describe what happens in this UNDEFINED
case.  They're not required to.

An intelligent guess would suffice for this case.  Reading the byte or
reading the aligned longword and extracting the byte would both work. 
SimH can choose based on its internals.

Supporting all the field instructions for I/O space, especially those
that modify the field, is more involved.  Multi-bit fields can span
bytes and longwords (EXTV, FF, etc).  The 750 probably has restrictions
(perhaps documented, certainly practical) on how this interacts with I/O
space.  E.g. INSV to a field that crosses two longword I/O registers
probably doesn't work as expected. 

To keep the scope of this effort reasonable, one probably wants to do
the "simple obvious" thing, and deal with the messy cases if code
surfaces that invokes them.  And hope that none does...

On 11-Aug-15 16:11, Bob Supnik wrote:
> Actually, the SRM spells out exactly how BBS/BBC behave in 7.3,
> subparagraph 6d (now you know why microcoders were called SRM lawyers):
>
> "BB{S,C}, BB{S,C}{S,C}. Only the single byte specified by the base and
> position operands is read."
>
> In short, a byte access, mandated by the SRM.
>
> Now, most VAXen could only read a whole longword or quadword from
> memory, but the system bus contained a byte mask or other encoding to
> say which bytes really mattered. This could be ignored on memory
> reads, of course. In generating byte masks, the VAX chips made no
> distinction between memory space and IO space and would generate
> proper byte masks for all reads. The 780 microcode used byte accesses
> for BBxy, so I assume it did the same.
>
> Only two hypotheses are possible: either the 750 microcode makes a
> real longword reference (all byte mask bits set), in contravention of
> the SRM; or the RH750 doesn't check operand lengths. I incline to the
> latter hypothesis, but we need either the  RH750 spec to be sure.
>
> /Bob
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/e505aac6/attachment.bin>