[Info-vax] [OT] Portable operating systems, was: Re: PowerX Roadmap - Extended beyond 2020

[Camiel Vanderhoeven]

Op maandag 19 september 2016 13:55:37 UTC+2 schreef John Reagan:
> On Monday, September 19, 2016 at 3:26:12 AM UTC-4, Dirk Munk wrote:
> >  wrote:
> > > On Wednesday, April 20, 2016 at 3:04:34 PM UTC-4, Simon Clubley wrote:
> > >> On 2016-04-20, johnwallace4 wrote:
> > >>>
> > >>> Fortunately for VMS, it's been through enough processors that the
> > >>> next migration after x86 will hopefully be a mere matter of
> > >>> cranking the handle. I jest slightly, but which other non-Linux
> > >>> OS has the same proven portability.
> > >>>
> > >>
> > >> Apart from Linux, NetBSD and OpenBSD are the other two traditional
> > >> operating systems I know of which are highly portable.
> > >>
> > >> In the RTOS market, there's RTEMS and QNX which I know exist on
> > >> multiple architectures. (I've just checked the eCos supported
> > >> architecture list and see that has support for a wide range of
> > >> architectures as well.)
> > >>
> > >>> Many months ago, there was a comment here suggesting that 'if'
> > >>> VMS ever migrated to x86-64, it would be good for that migration
> > >>> to also consider the next one as well. At the time there was no
> > >>> real suggestion that nuVMS on x86 would ever happen. It's not
> > >>> there yet, but it's a lot closer than it was back then.
> > >>>
> > >>
> > >> There's the two-level hardware (User and Kernel only) issue to tackle
> > >> in that case. I know there's a similar issue in the x86-64 but it
> > >> turns out VSI are using x86-64 specific features to work around that
> > >> issue. (I don't remember the fine details, but do remember thinking
> > >> it was a creative approach; however it is one that relies on x86-64
> > >> functionality.)
> > >>
> > >> Simon.
> > >>
> > >
> > > Not quite but you almost remembered it. Yes, we will only be using two of x86's HW access modes and enforcing the other two in the OS. We already do a little of this on Itanium so it is not complete invention this time. However, we are not using anything specific to x86. In fact, we are prototyping this on Itanium to get it debugged before we reach the point of needing it on x86. Note that x86 has four modes but they do not give us the separation that VMS needs.
> > >
> > > Clair
> > >
> > 
> > To your knowledge, is there any OS that actually uses those four modes 
> > in x86?
> > 
> > If not, would it be possible to ask Intel to change the design of x86 is 
> > such a way that the separation VMS requires would be achieved? I can 
> > imagine that another OS could benefit from that too.
> > 
> > Perhaps it's just a fantasy, but a nice one I hope :-)
> 
> Not that I'm aware of.  The CPU still has the four modes, but in 64-bit mode the page table entries only have K/U (the older modes have the extra modes in the PTEs).  Somebody from Apple explained the rationale behind the change to me last year at the LLVM conference.  Apparently there was some way to circumvent those mode checks such that S and E (in VMS terms) could get access to K memory.  Instead of fixing the underlying issue, they just removed the extra modes from the PTEs.

I'm afraid your source has their facts wrong...

Protected mode started on the 286 (16-bit), using segmentation; this is where you have four rings, and a segment is tied to one of the four; this was continued on the 386 (32-bit), but on the 64-bit (AMD64 and later Intel64) architecture, segmentation effectively disappeared (there's a small remnant of it left, but it's not intended to be used for memory protection any more).

On the 286, it turned out that practically no-one used four rings; instead most OS's only used two rings, so when they added paging as a protection mechanism in the 386, they simplified things a bit by treating rings 0, 1, and 2 as identical from a paging perspective. Therefore, for paging, there have never been separate bits for the four rings in the PTE; just one bit: S/U (supervisor = ring 0,1,2 / user = ring3).

In the end, we've decided that we can provide the four modes VMS requires, by doing the mode changes in software; the code that performs these mode changes runs in hardware ring 0 (where VMS's kernel mode runs too), all other VMS modes will run in ring 3. The end result is as good as running on a CPU that does this in hardware, and the code that does this will be portable to a wide variety of platforms.

Camiel.