below On Wed, Aug 12, 2015 at 9:03 AM, Timothe Litt <[email protected]> wrote:
> What SimH does now is SRM-compliant. It's just not useful in that the > hardware does something different. > +1 > 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. ;-) > > ... > > > 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. Clem
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
