<div dir="ltr">If it helps I have access to a working VAX-11/750 which has a RH750 adapter (but no devices attached to the massbus). <div><br></div><div>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.</div><div><br></div><div>/Mattis</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-12 13:47 GMT+02:00 Timothe Litt <span dir="ltr"><<a href="mailto:litt@ieee.org" target="_blank">litt@ieee.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11-Aug-15 16:11, Bob Supnik wrote:<br>
> Actually, the SRM spells out exactly how BBS/BBC behave in 7.3,<br>
> subparagraph 6d (now you know why microcoders were called SRM lawyers):<br>
><br>
</span>Having been responsible for several microdes and having worked with CPU<br>
instruction set architects, I am familiar with their behaviors...and the<br>
complications in the SRM text that lead to them. And the long meetings<br>
and discussions in the architecture notes files...<br>
<br>
It's rare that we disagree on a VAX issue, but in this case I think<br>
you're focusing on the wrong text. (I've played SRM lawyer too.)<br>
<br>
This is a case of the *software* not conforming to the SRM, and relying<br>
on an UNDEFINED implementation choice. BB* is not allowed to have an<br>
operand in I/O space, and the result of such an instruction is<br>
UNDEFINED. UNDEFINED operations are not constrained by most other parts<br>
of the SRM. But in this case, I don't think there's a conflict.<br>
<span class=""><br>
> "BB{S,C}, BB{S,C}{S,C}. Only the single byte specified by the base and<br>
> position operands is read."<br>
><br>
> In short, a byte access, mandated by the SRM.<br>
><br>
</span>This was the subject of some discussion.<br>
<br>
It doesn't contradict the SRM section that I cited - 7.5.5 (3), which<br>
states that a field operand can not be in I/O space. Nor 7.5.3, which<br>
explicitly disallows BB* references to I/O space.<br>
<br>
My world (HPS/Aquarius) concluded that in context this means that only<br>
the byte referenced by the base and position contributes to the observed<br>
effects of the instruction. Given that field instructions are illegal<br>
in I/O space, only memory references matter. We took advantage of this<br>
in a couple of ways -- reading more than required often saves time. The<br>
IBox prefetches the quadword at the base address before the position<br>
(and for other field instructions, size) is evaluated. Instruction<br>
traces showed that the vast majority of field references hit that<br>
quadword, which allowed the EBox to avoid an explicit operand read<br>
(which is much further down the pipeline and would stall). Of course if<br>
the EBox determines that the bit is somewhere else, the prefetched data<br>
is discarded along with any exception it might have incurred. For<br>
non-field references, the "byte mask" is used by the MBox to rotate<br>
(align) data put into the operand queue. The gory details of field<br>
references escape me at the moment. There are also some conditions<br>
where operands can be read more than once - which is perfectly OK for<br>
memory. Tryggve (Fossum, the Aquarius system architect) was very<br>
aggressive about finding (and getting the box leaders to find)<br>
opportunities for performance optimization. We could and did spend<br>
gates and complexity for performance. I had the fun of arguing<br>
software's case where there was ambiguity. And debugging the beast.<br>
The VAX chip world world (at that time) was optimizing for space - just<br>
getting things to fit was their big challenge. So treating I/O and<br>
memory references the same naturally falls out.<br>
<br>
The SRM also defines what bytes a FIELD can reference in 3.4 & 1.2.10.<br>
These conflict; the former amounts to "the minimum number of *bytes*<br>
needed to contain the field, except for INSV", while the latter says<br>
"minimum number of *aligned longwords*."<br>
<br>
Given the restriction on I/O space, why (6d) talks about the memory<br>
read is somewhat mysterious at first reading. Memory read can have no<br>
visible side effects, except when crossing a page boundary. And one<br>
would expect BB to read either the bye, or an enclosing aligned entity<br>
that would not cross a page boundary. The full context of your<br>
reference is:<br>
<br>
"BB{S,C}, BB{S,C}{S,C}. Only the single byte <containing the test<br>
bit> specified by the base and position operands is read. <If the test<br>
bit does not need to change state, it is UNPREDICTABLE whether the byte<br>
is written back.>"<br>
<br>
This rather awkward construction does constrain the write of<br>
BB{S,C}{S,C} to the single selected byte. And that does matter for the<br>
atomicity/visibility rules. (Though BB{S,C} should never write...}) I<br>
think that's the point that's being made here, as the previous sections<br>
cover the constraints on read.<br>
<br>
Being more specific, (6d) would control interpretation to the extent<br>
that there are conflicts. But it does not allow an I/O space operand.<br>
So if an I/O space operand is referenced, from an SRM point of view what<br>
happens is UNDEFINED. (SRM 7.5.2 (5) "...and field references in the<br>
I/O space result in UNDEFINED behavior.") It *might* be a byte access,<br>
it might be no access, or anything other than hanging the processor or<br>
console. (SRM B.1.6)<br>
<span class=""><br>
> Now, most VAXen could only read a whole longword or quadword from<br>
> memory, but the system bus contained a byte mask or other encoding to<br>
> say which bytes really mattered. This could be ignored on memory<br>
> reads, of course. In generating byte masks,<br>
</span>And BB* can only reference memory.<br>
<span class="">> the VAX chips made no distinction between memory space and IO space<br>
> and would generate proper byte masks for all reads. The<br>
</span>This is an implementation choice that SRM conformant software was<br>
forbidden to rely upon. It effectively extended the architecture,<br>
allowing field references (including BB*) to operate on I/O space. It<br>
happened to be convenient for the "chip" VAXes, but it would not have<br>
been convenient for other technologies. As I've noted, Aquarius (at<br>
least) made use of the restriction to avoid extra logic (and time) that<br>
would have been required to disable legal optimizations when referencing<br>
I/O space. There was nothing "improper" about this - the programmer<br>
writing SRM-conformant code can not detect the implementation<br>
differences. And because any peripheral hardware must be in I/O space<br>
where field references can't be made, neither can hardware.<br>
<br>
SRM section 7.5.3 (p. 7-25) lists the only instructions and operand<br>
addressing modes that can be used to reference I/O space. The list<br>
excludes BB*. The implementation note on p 7-26 of the SRM is explicit<br>
about this exclusion -- "For reference instructions were discarded as<br>
follows"... (7) "operand types: ... BB{S,C}, BB{S,C}{S,C}..."<br>
<br>
All that said, the VAX chips are SRM compliant - they are not required<br>
to enforce the rule that field references may not be to I/O space.<br>
Their behavior in this UNDEFINED case happens to be predictable - and<br>
some coder got away with relying on it. It's the CODE, not the machine<br>
that is violating the SRM. Unfortunately. This is why we encouraged<br>
implementations to check for violations whenever possible.<br>
<br>
NVAX borrowed some of its microarchitecture from Aquarius (and in fact,<br>
our RQT machines ran the NVAX simulations). I'm not sure what it did<br>
with this case - it simplified things to fit in the VLSI of the time.<br>
But had development continued, I expect that eventually the chip VAXes<br>
would have made more aggressive use of the SRM's opportunities for<br>
optimization. And this code fragment would have caused an issue on them<br>
as well.<br>
<span class=""><br>
> 780 microcode used byte accesses for BBxy, so I assume it did the same.<br>
><br>
> Only two hypotheses are possible: either the 750 microcode makes a<br>
> real longword reference (all byte mask bits set), in contravention of<br>
> the SRM; or the RH750 doesn't check operand lengths. I incline to the<br>
> latter hypothesis, but we need either the RH750 spec to be sure.<br>
><br>
</span>Since it's a *memory* read (and as you note), the byte masks need not be<br>
passed to the cache. What matters to the SRM is whether the programmer<br>
can detect a reference beyond the selected byte. Assuming the ucode<br>
doesn't do something stupid (like reference beyond the end of a page and<br>
report an undeserved exception), reading a byte, a word, a longword or<br>
an octaword doesn't contravene the SRM. Internally, the memory<br>
subsystem is almost certain to read more than a byte due to ECC. As<br>
long as the instruction selects the correct bit to branch on, the<br>
reference type doesn't matter. (If the BB were a BBx{S,C}, then the<br>
write would have to obey the atomicity rules. But that doesn't apply to<br>
the reported case.) So I don't agree with your "in contravention of the<br>
SRM."<br>
<br>
If a programmer can't distinguish an implementation from the SRM<br>
description, it's legal. Just like SRM 2.6 which says that the<br>
architecture assumes a sequential model where "no instruction is<br>
processed, (even partially) until the one before it completes." If<br>
implementations adhered literally to that, there could be no instruction<br>
or data prefetch, branch prediction, or speculation. And every VAX<br>
would be non-conformant. The SRM is interpreted to mean that an<br>
implementation must work from a programmers point of view "as if" it<br>
literally follows the text. But what's under the covers is fodder for<br>
creativity.<br>
<br>
Now if it's a reference to I/O space, this does become important. But<br>
that's what is in contravention of the SRM. This instruction is not<br>
allowed to have an operand in I/O space. To correctly support I/O<br>
space, including registers that have read side-effects, byte masks need<br>
to be supplied and obeyed. I guess the good news is that if this is<br>
only being done with MBA registers, offhand I can't think of a Massbus<br>
device that has registers with read side-effects.<br>
<br>
I don't know whether the 750 spec says that the machine will support all<br>
types of references to I/O space, even those disallowed by the SRM. If<br>
it does, no software engineer should have relied on the statement.<br>
Except, perhaps a platform-specific diagnostic coder in some corner<br>
case. Specs weren't required to list what happens in all the UNDEFINED<br>
cases.<br>
<br>
You're probably right that the the RH750 doesn't check lengths. I hope<br>
that the RH or CPU spec clarifies this for you, but as it's an<br>
UNDEFINED, I wouldn't bet on whether there's enough information in the<br>
specs to tell.<br>
<br>
What *is* clear is that this particular bit of code worked on the real<br>
750 hardware & that SRM issues aside, SimH will have to make it work<br>
too. Exactly how painful that must be depends on how pervasive this<br>
non-compliant coding is...and the SimH 750 code, which I haven't<br>
examined. From your description, the RH shouldn't be throwing an error...<br>
<div class="HOEnZb"><div class="h5"><br>
> /Bob<br>
><br>
> On 8/11/2015 12:00 PM, <a href="mailto:simh-request@trailing-edge.com">simh-request@trailing-edge.com</a> wrote:<br>
>> Message: 3 Date: Mon, 10 Aug 2015 15:02:48 -0400 From: Timothe Litt<br>
>> <<a href="mailto:litt@ieee.org">litt@ieee.org</a>> To: <a href="mailto:simh@trailing-edge.com">simh@trailing-edge.com</a> Subject: Re: [Simh]<br>
>> Needed: RH750 specification Message-ID: <<a href="mailto:55C8F558.1060508@ieee.org">55C8F558.1060508@ieee.org</a>><br>
>> Content-Type: text/plain; charset="utf-8" On 10-Aug-15 14:13, Bob<br>
>> Supnik wrote:<br>
>>> >Mark Pizzolato sent me a note about a code sequence in the original<br>
>>> >VAX750 bootstrap that fails on the 750 simulator. The code is doing a<br>
>>> ><br>
>>> >BBC #7,address,10$<br>
>>> ><br>
>>> >where the address is in the RH750 Massbus adapter. The sequence fails<br>
>>> >because the simulated RH750 throws an error - the operand access is<br>
>>> >not an aligned longword.<br>
>>> ><br>
>>> >BBC and the other bit branches use a byte access operand. The SRM says<br>
>>> >that VAX implementations must access the precise byte specified by the<br>
>>> >base address and the byte part of the bit offset. There's no leeway in<br>
>>> >the wording, and the VAX chips (and the 780) do precisely that.<br>
>>> ><br>
>> This is not exactly correct. BB uses a FIELD access, not a pure byte<br>
>> access. SRM 3.5 (p. 3-56 "BB") "opcode pos.rl, base.vb, <a href="http://displ.bb" rel="noreferrer" target="_blank">displ.bb</a>,<br>
>> {<a href="http://field.mv" rel="noreferrer" target="_blank">field.mv</a>}" Note the "v".<br>
>><br>
>> Fields are 1-5 bytes, and "access the minimum number of aligned<br>
>> longwords necessary to to contain the field". (SRM 1.2.10) (Rev. J<br>
>> added a reference to INSV in 3.4, but this postdates the 750 and isn't<br>
>> relevant here.)<br>
>><br>
>> The SRM also says that BBC is not legal in I/O space. See 7.5.5 (3) --<br>
>> BBC is a control instruction with a field operand. Operand types of<br>
>> field are not legal in I/O space.<br>
>><br>
>> As a practical matter, BB is problematic in I/O space. For example,<br>
>> Aquarius fetches a quadword around the base address, which can have side<br>
>> effects reading the unwanted register... (And yes, the implementation<br>
>> conforms to 1.2.10 from the programmer's perspective when the field is<br>
>> in memory.) I remember finding and removing a number of OS/driver bugs<br>
>> where I/O space was used...<br>
>><br>
>> That said, programmers do things that are unspecified & when they "seem<br>
>> to work" on the hardware they're using, move on.<br>
>><br>
>> Apparently the 750 hardware deals with whatever access the CPU generates<br>
>> for BBC - which architecturally can be anything from a byte read to a<br>
>> longword.<br>
>><br>
>> I don't have the RH750 specification - but this is unspecified<br>
>> behavior. I would be mildly surprised if the spec bothered to<br>
>> mention it.<br>
>><br>
>> The spirit of SimH, of course, is to make the software work despite<br>
>> implementation bugs. I'd say this is an unspecified behavior in the<br>
>> RH750 simulator that SimH needs to fix there... Removing the check is<br>
>> probably the right hack - with a suitable comment.<br>
>><br>
>>> >If the 750 microcode is correctly implemented, then the best<br>
>>> >explanation is that the RH750, unlike the RH780, does not in fact<br>
>>> >check the length (and possibly not the alignment) of register<br>
>>> >accesses. This is true of the respective Unibus adapters: the 780's<br>
>>> >does lots of checking, the 750's does none.<br>
>>> ><br>
>> Either the 780 driver doesn't do this, or this particular case isn't<br>
>> checked for in the 780 hardware. The hardware is not obliged to check<br>
>> for UNSPECIFIED behavior (FIELD in I/O space). If the 780 ucode happens<br>
>> to make a longword reference to fetch the byte for BB (which is valid<br>
>> for memory, so long as it's aligned & won't pagefault), things would<br>
>> "appear to work". Without looking at the hardware, that would be my<br>
>> guess.<br>
>><br>
>>> >The 750 simulator is not mine, but I'd like to track this problem<br>
>>> >down. The RH750 schematics don't help, because the critical logic is<br>
>>> >inside gate arrays. What's needed is an RH750 specification. Does<br>
>>> >anyone have it?<br>
>>> ><br>
>>> >Thanks,<br>
>>> ><br>
>>> >/Bob Supnik<br>
>>> ><br>
><br>
> _______________________________________________<br>
> Simh mailing list<br>
> <a href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
> <a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" rel="noreferrer" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br>
<br>
<br>
</div></div><br>_______________________________________________<br>
Simh mailing list<br>
<a href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
<a href="http://mailman.trailing-edge.com/mailman/listinfo/simh" rel="noreferrer" target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br></blockquote></div><br></div>