On 12-Aug-15 10:09, Clem Cole wrote: > > The 750 specs may or may not describe what happens in this UNDEFINED > case. They're not required to. > > Right - but as you point out, that probably does not matter either > since we have a real implementation of 750 and code written for that > implementation. The documentation for the implementation is nice, > the primary target is not the documentation. ;-) > > > . > Agreed. My point was that searching for the RH750 spec - which is what started this - may not resolve the question that Bob raised. > > .. > > > To keep the scope of this effort reasonable, one probably wants to do > the "simple obvious" thing, and deal with the messy cases if code > surfaces that invokes them. And hope that none does... > > I think this is reasonable - certainly for the case of UNIX. IMO: > The good news here is that the danger should be limited to boot level > code. The BSD kernel code itself, tried to be CPU independent so that > the "generic" UNIX could load and run. If people wanted to > customize, their own kernel they could, but they did not have too. > Thus by the time you got to the kernel itself loaded into memory, the > drivers would have had to been agnostic - certainly the ones I wrote > were. The only time I ever got funky/CPU specific was dealing with > boot loader which was needed to be specific to each CPU > implementation. I had 780's only in my lab in Cory Hall, the mass > of 750's were over in Evans in the main CSRG machine room at the > time. IIRC: Leffler and Joy wrote the 750 boot loader for BSD > (although Rob Pike had a 750 in BTL a few months before we got one at > UCB - so it's possible Sam could have gotten the boot loader from him). > > My point is that if there was something really bad in the kernel > drivers itself, I think we would have seen it before now because the > other Vax implementations would have tripped over that code path. > Even boot code should have been platform independent in the sense of SRM-compliant. "A VAX is a VAX is a VAX. period." The only code that legally relied on implementation quirks was the code that implemented the VLSI VAX "console". (Well, and maybe some diagnostic, though that was discouraged.) The VLSI console is the reason for the note in the SRM that allows platform-specific code to fetch i-stream from I/O space (e.g. a [flash] rom) and/or to have the stack or PCB in I/O space. (SRM 7.5.3 before the final implementation note "Notwithstanding the above rules..."). However, this exception carefully does NOT allow fields to live in I/O space. This is always illegal. And as I've noted, in the general case (size > 1) there is no obvious definition of how a field in I/O space should/could work.
I was responsible for all the OS software on Aquarius - VMS (including VMB, which packaged the boot drivers), System V, Ultrix, & VAX/ELN. This involved a lot of SRM lawyering with my friends in the OS groups, in the hardware architecture groups (peripherals tried to take shortcuts too) and in the console and diagnostic groups. I know that I removed (or caused to be removed) a fair bit of non-SRM-compliant code like that discussed in this thread. So this is a very familiar discussion. One problem is that VMB was stuck in ROM or in console code that was only updated by FCO (field service). So fixes to VMB rarely got pushed back to prior implementations, especially for the VLSI VAXen. And new OS releases were pretty much stuck with old VMB bugs. (Though having ROM load VMB load a newer VMB, which then loaded the OS was not unheard of.) For the separate console VAXes, VMS could push a new VMB onto the console media. VMS was pretty clean when it came to SRM compliance. Both because the engineers were regularly educated, and because low-level code is assembler. But the other OSs, often because they used compilers for low-level code and were further from the hardware groups, had more broken code. "But INSV to this register works on <insert platform here>; C (or PASCAL) has always generated it here." Sorry, it's not legal. And even on <foo>, it may not work with the next set of peephole optimizations... VMB is the VAX bootstrap (initially VMS bootstrap, but ALL the OSs use it). It contains the primitive drivers for the boot device, a pointer to the selected one is passed to the first part of the OS, which typically saves that driver for writing crash dumps and for loading the rest of the OS. [In the case of VMS, this would be SYSLOAxxx - the platform dependent module, and for VMS 5+, the loadable execlets.] The OS has no control over these drivers. The BSD boot loader is probably the code loaded by VMB. I haven't looked at it, so don't know whether it used the primitive boot drivers, or ignored them and supplied its own. It could do either, depending on the NIH quotient of those who wrote it. The platform dependencies were not SRM exceptions. They were things like machine check error handling, bus and bus adapter enumeration and error handling (SBI is rather different from XMI), subset instruction emulation. There is a certain amount of cleverness in the way busses layer; a UDA-50 on a unibus on a BI on an XMI can look the same to its driver as one on a unibus on an SBI. If it's properly configured and enumerated, the addresses are mapped and remapped so the driver can be platform-agnostic. But that's a different kind of platform compatibility from the main discussion here. Here we have a problem caused by code which does something that is explicitly forbidden by the SRM. SimH does need to emulate the hardware's behavior. But appeals to what the SRM says do not resolve what the 750 does (or should do). UNDEFINED is a black hole. Other implementations may do what this code expects. Or may not. Did BSD ever run on Aquarius (VAX 9000)? It wasn't on my list. I guarantee that if it did, this particular instruction would fail spectacularly... Once the OS was loaded (and usually after memory management and interrupts were turned on), the OS-supplied drivers would be used. In theory, the OS could use its own drivers for loading itself. But this was rarely convenient as they tend to rely on process structure, memory management and interrupts. All of which usually aren't present until at least 2 pieces of the OS are loaded... So the smart move was to use the VMB-supplied primitive boot driver to continue the load & switch to the OS drivers once the OS core functions were alive. Not only are they there, but someone else wrote and debugged them... Though people with sufficiently large NIH quotients could always find reasons to redefined 'smart'. And that's probably more than most people on this list ever wanted to know...
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
