[Simh] Needed: RH750 specification

Wed Aug 12 08:13:44 EDT 2015

If it helps I have access to a working VAX-11/750 which has a RH750 adapter
(but no devices attached to the massbus).

Now if there would be no RH750 specification surfacing then I could try to
attach a logic analyzer to the CMI bus to investigate this if that would
help solving this issue.

/Mattis

2015-08-12 13:47 GMT+02:00 Timothe Litt <litt at ieee.org>:

> 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):
> >
> Having been responsible for several microdes and having worked with CPU
> instruction set architects, I am familiar with their behaviors...and the
> complications in the SRM text that lead to them.  And the long meetings
> and discussions in the architecture notes files...
>
> It's rare that we disagree on a VAX issue, but in this case I think
> you're focusing on the wrong text.  (I've played SRM lawyer too.)
>
> This is a case of the *software* not conforming to the SRM, and relying
> on an UNDEFINED implementation choice.  BB* is not allowed to have an
> operand in I/O space, and the result of such an instruction is
> UNDEFINED.  UNDEFINED operations are not constrained by most other parts
> of the SRM.  But in this case, I don't think there's a conflict.
>
> > "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.
> >
> This was the subject of some discussion.
>
> It doesn't contradict the SRM section that I  cited - 7.5.5 (3), which
> states that a field operand can not be in I/O space.  Nor 7.5.3, which
> explicitly disallows BB* references to I/O space.
>
> My world (HPS/Aquarius) concluded that in context this means that only
> the byte referenced by the base and position contributes to the observed
> effects of the instruction.  Given that field instructions are illegal
> in I/O space, only memory references matter.  We took advantage of this
> in a couple of ways -- reading more than required often saves time.  The
> IBox prefetches the quadword at the base address before the position
> (and for other field instructions, size) is evaluated.  Instruction
> traces showed that the vast majority of field references hit that
> quadword, which allowed the EBox to avoid an explicit operand read
> (which is much further down the pipeline and would stall).  Of course if
> the EBox determines that the bit is somewhere else, the prefetched data
> is discarded along with any exception it might have incurred.  For
> non-field references, the "byte mask" is used by the MBox to rotate
> (align) data put into the operand queue.  The gory details of field
> references escape me at the moment.  There are also some conditions
> where operands can be read more than once - which is perfectly OK for
> memory.  Tryggve (Fossum, the Aquarius system architect) was very
> aggressive about finding (and getting the box leaders to find)
> opportunities for performance optimization.  We could and did spend
> gates and complexity for performance.  I had the fun of arguing
> software's case where there was ambiguity.  And debugging the beast.
> The VAX chip world world (at that time) was optimizing for space - just
> getting things to fit was their big challenge.  So treating I/O and
> memory references the same naturally falls out.
>
> The SRM also defines what bytes a FIELD can reference in 3.4 & 1.2.10.
> These conflict; the former amounts to "the minimum number of *bytes*
> needed to contain the field, except for INSV", while the latter says
> "minimum number of *aligned longwords*."
>
> Given the restriction on I/O space, why (6d)  talks about the memory
> read is somewhat mysterious at first reading.  Memory read can have no
> visible side effects, except when crossing a page boundary.  And one
> would expect BB to read either the bye, or an enclosing aligned entity
> that would not cross a page boundary.  The full context of your
> reference is:
>
>      "BB{S,C}, BB{S,C}{S,C}. Only the single byte <containing the test
> bit> specified by the base and position operands is read.  <If the test
> bit does not need to change state, it is UNPREDICTABLE whether the byte
> is written back.>"
>
> This rather awkward construction does constrain the write of
> BB{S,C}{S,C} to the single selected byte.  And that does matter for the
> atomicity/visibility rules.  (Though BB{S,C} should never write...})  I
> think that's the point that's being made here, as the previous sections
> cover the constraints on read.
>
> Being more specific, (6d) would control interpretation to the extent
> that there are conflicts.  But it does not allow an I/O space operand.
> So if an I/O space operand is referenced, from an SRM point of view what
> happens is UNDEFINED.  (SRM 7.5.2 (5) "...and field references in the
> I/O space result in UNDEFINED behavior.") It *might* be a byte access,
> it might be no access, or anything other than hanging the processor or
> console. (SRM B.1.6)
>
> > 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,
> And BB* can only reference memory.
> > the VAX chips made no distinction between memory space and IO space
> > and would generate proper byte masks for all reads. The
> This is an implementation choice that SRM conformant software was
> forbidden to rely upon.  It effectively extended the architecture,
> allowing field references (including BB*) to operate on I/O space.  It
> happened to be convenient for the "chip" VAXes, but it would not have
> been convenient for other technologies.  As I've noted, Aquarius (at
> least) made use of the restriction to avoid extra logic (and time) that
> would have been required to disable legal optimizations when referencing
> I/O space.  There was nothing "improper" about this - the programmer
> writing SRM-conformant code can not detect the implementation
> differences.  And because any peripheral hardware must be in I/O space
> where field references can't be made, neither can hardware.
>
> SRM section 7.5.3 (p. 7-25) lists the only instructions and operand
> addressing modes that can be used to reference I/O space.  The list
> excludes BB*.  The implementation note on p 7-26 of the SRM is explicit
> about this exclusion -- "For reference instructions were discarded as
> follows"... (7) "operand types: ... BB{S,C}, BB{S,C}{S,C}..."
>
> All that said, the VAX chips are SRM compliant - they are not required
> to enforce the rule that field references may not be to I/O space.
> Their behavior in this UNDEFINED case happens to be predictable - and
> some coder got away with relying on it.  It's the CODE, not the machine
> that is violating the SRM.  Unfortunately.  This is why we encouraged
> implementations to check for violations whenever possible.
>
> NVAX borrowed some of its microarchitecture from Aquarius (and in fact,
> our RQT machines ran the NVAX simulations).  I'm not sure what it did
> with this case - it simplified things to fit in the VLSI of the time.
> But had development continued, I expect that eventually the chip VAXes
> would have made more aggressive use of the SRM's opportunities for
> optimization.  And this code fragment would have caused an issue on them
> as well.
>
> > 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.
> >
> Since it's a *memory* read (and as you note), the byte masks need not be
> passed to the cache.  What matters to the SRM is whether the programmer
> can detect a reference beyond the selected byte.  Assuming the ucode
> doesn't do something stupid (like reference beyond the end of a page and
> report an undeserved exception), reading a byte, a word, a longword or
> an octaword doesn't contravene the SRM.  Internally, the memory
> subsystem is almost certain to read more than a byte due to ECC.  As
> long as the instruction selects the correct bit to branch on, the
> reference type doesn't matter.  (If the BB were a BBx{S,C}, then the
> write would have to obey the atomicity rules.  But that doesn't apply to
> the reported case.)  So I don't agree with your "in contravention of the
> SRM."
>
> If a programmer can't distinguish an implementation from the SRM
> description, it's legal.  Just like SRM 2.6 which says that the
> architecture assumes a sequential model where "no instruction is
> processed, (even partially) until the one before it completes."  If
> implementations adhered literally to that, there could be no instruction
> or data prefetch, branch prediction, or speculation.  And every VAX
> would be non-conformant.  The SRM is interpreted to mean that an
> implementation must work from a programmers point of view "as if" it
> literally follows the text.  But what's under the covers is fodder for
> creativity.
>
> Now if it's a reference to I/O space, this does become important.  But
> that's what is in contravention of the SRM.  This instruction is not
> allowed to have an operand in I/O space.  To correctly support I/O
> space, including registers that have read side-effects, byte masks need
> to be supplied and obeyed.  I guess the good news is that if this is
> only being done with MBA registers, offhand I can't think of a Massbus
> device that has registers with read side-effects.
>
> I don't know whether the 750 spec says that the machine will support all
> types of references to I/O space, even those disallowed by the SRM.   If
> it does, no software engineer should have relied on the statement.
> Except, perhaps a platform-specific diagnostic coder in some corner
> case.  Specs weren't required to list what happens in all the UNDEFINED
> cases.
>
> You're probably right that the the RH750 doesn't check lengths.  I hope
> that the RH or CPU spec clarifies this for you, but as it's an
> UNDEFINED, I wouldn't bet on whether there's enough information in the
> specs to tell.
>
> What *is* clear is that this particular bit of code worked on the real
> 750 hardware & that SRM issues aside, SimH will have to make it work
> too.  Exactly how painful that must be depends on how pervasive this
> non-compliant coding is...and the SimH 750 code, which I haven't
> examined.  From your description, the RH shouldn't be throwing an error...
>
> > /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
> >>> >
> >
> > _______________________________________________
> > Simh mailing list
> > Simh at trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/27039d7d/attachment-0001.html>