[Simh] Needed: RH750 specification

[Timothe Litt]

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...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150812/1e465bcc/attachment.html>
-------------- 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/1e465bcc/attachment.bin>