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 <[email protected]>: > 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, [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 > > > > _______________________________________________ > Simh mailing list > [email protected] > http://mailman.trailing-edge.com/mailman/listinfo/simh >
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
