<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12-Aug-15 10:09, Clem Cole wrote:<br>
</div>
<blockquote
cite="mid:CAC20D2P0Wbwc6X_KbSWAtMo5V=KTPt_h__ndUhrtVpHkx9dh2w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1ah" class="a3s" style="overflow:hidden"><font
color="#ff0000">
The 750 specs may or may not describe what happens in
this UNDEFINED<br>
case. They're not required to.</font><br>
</div>
</blockquote>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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. ;-)</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1ah" class="a3s" style="overflow:hidden">
<font color="#ff0000"><br>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;display:inline">
.</div>
</font></div>
</blockquote>
</div>
</div>
</div>
</blockquote>
Agreed. My point was that searching for the RH750 spec - which is
what started this - may not resolve the question that Bob raised.<br>
<blockquote
cite="mid:CAC20D2P0Wbwc6X_KbSWAtMo5V=KTPt_h__ndUhrtVpHkx9dh2w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1ah" class="a3s" style="overflow:hidden"><font
color="#ff0000">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;display:inline">..</div>
<br>
<br>
To keep the scope of this effort reasonable, one
probably wants to do<br>
the "simple obvious" thing, and deal with the messy
cases if code<br>
surfaces that invokes them. And hope that none
does...</font></div>
</blockquote>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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). </div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">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.</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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... <br>
<br>
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.<br>
<br>
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...<br>
<br>
Once the OS was loaded (and usually after memory management and
interrupts were turned on), the OS-supplied drivers would be used.<br>
<br>
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...<br>
<br>
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'.<br>
<br>
And that's probably more than most people on this list ever wanted
to know...<br>
<br>
</body>
</html>