[Simh] Needed: RH750 specification

Wed Aug 12 07:47:59 EDT 2015

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

-------------- 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/197a3729/attachment.bin>