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, [email protected] wrote:
Message: 3 Date: Mon, 10 Aug 2015 15:02:48 -0400 From: Timothe Litt
<[email protected]> To: [email protected] Subject: Re: [Simh] Needed:
RH750 specification Message-ID: <[email protected]>
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
>
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
