[Simh] Needed: RH750 specification

[Bob Supnik]

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

On 8/11/2015 12:00 PM, simh-request at trailing-edge.com wrote:
> Message: 3 Date: Mon, 10 Aug 2015 15:02:48 -0400 From: Timothe Litt 
> <litt at ieee.org> To: simh at trailing-edge.com Subject: Re: [Simh] Needed: 
> RH750 specification Message-ID: <55C8F558.1060508 at ieee.org> 
> Content-Type: text/plain; charset="utf-8" On 10-Aug-15 14:13, Bob 
> Supnik wrote:
>> >Mark Pizzolato sent me a note about a code sequence in the original
>> >VAX750 bootstrap that fails on the 750 simulator. The code is doing a
>> >
>> >BBC #7,address,10$
>> >
>> >where the address is in the RH750 Massbus adapter. The sequence fails
>> >because the simulated RH750 throws an error - the operand access is
>> >not an aligned longword.
>> >
>> >BBC and the other bit branches use a byte access operand. The SRM says
>> >that VAX implementations must access the precise byte specified by the
>> >base address and the byte part of the bit offset. There's no leeway in
>> >the wording, and the VAX chips (and the 780) do precisely that.
>> >
> This is not exactly correct.  BB uses a FIELD access, not a pure byte
> access.  SRM 3.5 (p. 3-56 "BB") "opcode pos.rl, base.vb, displ.bb,
> {field.mv}" Note the "v".
>
> Fields are 1-5 bytes, and "access the minimum number of aligned
> longwords necessary to to contain the field".  (SRM 1.2.10)  (Rev. J
> added a reference to INSV in 3.4, but this postdates the 750 and isn't
> relevant here.)
>
> The SRM also says that BBC is not legal in I/O space.  See 7.5.5 (3) --
> BBC is a control instruction with a field operand.  Operand types of
> field are not legal in I/O space.
>
> As a practical matter, BB is problematic in I/O space.  For example,
> Aquarius fetches a quadword around the base address, which can have side
> effects reading the unwanted register... (And yes, the implementation
> conforms to 1.2.10 from the programmer's perspective when the field is
> in memory.)  I remember finding and removing a number of OS/driver bugs
> where I/O space was used...
>
> That said, programmers do things that are unspecified & when they "seem
> to work" on the hardware they're using, move on.
>
> Apparently the 750 hardware deals with whatever access the CPU generates
> for BBC - which architecturally can be anything from a byte read to a
> longword.
>
> I don't have the RH750 specification - but this is unspecified
> behavior.  I would be mildly surprised if the spec bothered to mention it.
>
> The spirit of SimH, of course, is to make the software work despite
> implementation bugs.  I'd say this is an unspecified behavior in the
> RH750 simulator that SimH needs to fix there... Removing the check is
> probably the right hack - with a suitable comment.
>
>> >If the 750 microcode is correctly implemented, then the best
>> >explanation is that the RH750, unlike the RH780, does not in fact
>> >check the length (and possibly not the alignment) of register
>> >accesses. This is true of the respective Unibus adapters: the 780's
>> >does lots of checking, the 750's does none.
>> >
> Either the 780 driver doesn't do this, or this particular case isn't
> checked for in the 780 hardware.  The hardware is not obliged to check
> for UNSPECIFIED behavior (FIELD in I/O space).  If the 780 ucode happens
> to make a longword reference to fetch the byte for BB (which is valid
> for memory, so long as it's aligned & won't pagefault), things would
> "appear to work".  Without looking at the hardware, that would be my guess.
>
>> >The 750 simulator is not mine, but I'd like to track this problem
>> >down. The RH750 schematics don't help, because the critical logic is
>> >inside gate arrays. What's needed is an RH750 specification. Does
>> >anyone have it?
>> >
>> >Thanks,
>> >
>> >/Bob Supnik
>> >