From: Chris Scheers [asi@airmail.net] Sent: Thursday, December 09, 1999 6:17 AM To: Info-VAX@Mvb.Saic.Com Subject: Re: Hardware requirements for porting VMS (was: VMS must be port ed to Intel or die with Alpha) or die with Alpha) Intel or die with Alpha) or die with Alpha) "Gotfryd Smolik, VMS lists" wrote: > > On Fri, 10 Sep 1999, Wyer, Brett wrote: > > [...some parts of Chris message...] > +> The big bugaboo that I keep hearing is the "four modes" issue. > +> > +> VMS does NOT use four processing modes. > +> > +> It only has three modes: interrupt, kernel, and non-kernel > +> > +> (If you want to be pendantic, you can add compatibility mode to this > +> list, but I think we can ignore that for any port.) > +> > +> What VMS does have four of is per process memory management spaces. > +> These are commonly called KESU (KERNEL, EXECUTIVE, SUPERVISOR, USER). > +> These are NOT the same as the processing modes. > + > +Hmm... I think this is just a matter of semantics. Every page in a given > +process has a PTE protection code for Kernel, Executive, Supervisory and > +User mode. These protections are handled at the hardware level by the MMU > +(if I remember correctly), not by VMS. You switch between protection levels > +with the CHMx instruction, also at the hardware level. On each access, the > +MMU verifies the page accessibility against the current processor mode, etc. > +You can ask the MMU about page accessibility based on your current mode with > +the PROBEx instruction. It is more than semantics. You are confusing implementation with functionality. I am suggesting that there are different implementations which can achieve the same functionality. > Agree. I am will ask Chris: what *you* will mean "mode" ?? > > The processors I know all have *only* for kernel mode differrent > intruction set (enhanced), and the same for all other modes. > The rest of differrence in in the concept described by Brett: > the processor have internal "mode flag" (1 bit in a crippled > implementation, register or part of register elsewhere), the > memory (*not* neccessary pages !) are marked also with "mode > protection" and allows limited access, differrent for differrent > modes... > The interrupt mechanism is only in limited way *related to* > (but separated, as a control-flow part) the mode mechanism: > roughly can say, it switches processor to kernel mode as part > of the interrupt. > Both mode and interrupt mechanism require hardware support. > Then again: Chris, what *you* mean as "mode" ? > Kernel and non-kernel (you words !) modes differs with instruc- > tion set and something else. IMHO the "something else" is memory > access management, that make the differrence both for KERNEL vs. EXEC > and EXEC vs. USER. The VAX has three processor modes: interrupt, kernel, and non-kernel. The VAX has four per-process memory maps: kernel, executive, supervisor, and user. Some confusion occurs because the memory map is often equated with a processor mode. They are distinct functionalities. The VAX hardware defines these legal mode/map combinations: Name Processor Mode Memory Map interrupt interrupt kernel kernel kernel kernel executive non-kernel executive supervisor non-kernel supervisor user non-kernel user This architecture was carried over to the Alpha. (sorta) Further confusion results because the architecture of the VAX MMU hardware wraps all four memory maps into a single set of PTEs, making it look like there is a single memory map. The set of PTEs actually define four (possibly) different memory maps. When considering porting VMS to another platform, the question is how to generalize this architecture so that VMS may be ported. For the Alpha, performance was a prime consideration, so additional MMU hardware was added to the Alpha to implement the KESU memory map in hardware. This is not the only way to go. They key is realizing that as far as memory management is concerned (ignoring PROBEx for now), there is only one map: The current map. If we assume that the target processor has memory based memory maps (Pretty much a requirement for VMS.), you can design a memory management system that builds separate per-process memory maps for executive, supervisor, and user. REI can be implemented as a privileged routine that does the appropriate setup to select memory map and stack for the new mode (ESU), and then goes non-privileged in the new mode. (I know I am speaking very genericly here, but the details are highly implementation specific.) Basically, we implement the REI microcode as host processor macro code. This is not as efficient as direct hardware support, but it does work. For porting to an Intel platform (the original point of this discussion), I think that this solution would be adequate. If you want the ultimate in performance, get an Alpha. If you want to run VMS on your existing desktop, you accept the performance hit. (Actually, in the PC world, this isn't a bad solution. Have you ever looked at how Windows goes from protected back to real mode on an 80286?) This leaves the issue of PROBEx. PROBEx requires read access to the memory map. Assuming that the memory map is not left globally readable, this would require that PROBEx be implemented as a privileged trap. > +Additionally, you have stacks for each of the various modes. I assume that > +this is handled in hardware when a CHMx is executed... > > ...with some addition: AFAIR b.ex. VAX have separate stack for > interrupt as part of architecture, I am right ? > (but Alpha not, and that forces large reserve to *any* process > kernel mode stack) > > [...agree, that VAX archit. and VMS must be separated...] > +> The key to making VMS work is the REI instruction. This is where mode > +> changes, stack changes, memory management changes, AST dispatching, > +> pending interrupt recognition, etc. all happen. > + > +With the exception of the CHMx instruction... :) Also, interrupt > +dispatching is a function of IPL, which is also a hardware function. > + > +An additional note on that one. The only way you can adjust the IPL is in > +Kernel mode with a MTPR src,#PR$_IPL. For that matter, You can't even > +adjust any of the processor private registers without being in Kernel mode. > +It generates a Reserved Instruction Fault. > + > +> > +> The ONLY processor to have the REI instruction required by VMS is the > +> VAX, where it is implemented in microcode. > +> > +> The Alpha doesn't have it. (The Alpha emulates REI in PALcode.) Yet > 1). ************** > > +> VMS runs on the Alpha. > +> > + > +Whether it is in microcode or in PALcode really doesn't make any difference > +(IMO)... It's still a processor instruction. PALcode is a trap to Alpha code with performs the required function. Think of it as a special type of subroutine call. Don't get hung up on the distinction between hardware instructions and software traps. The whole concept of RISC is that specialized hardware is replaced by a sequence of instructions. > +> To port VMS to another architecture, you need to write code to emulate > +> REI. If necessary, this REI code can emulate KESU by switching memory > +> maps. (This happens anyways when switching processes.) > > But does not ! Chris, AFAIR Alpha have *real* KESU access mode > support in the processor, and have *one* 3-level page table > for all modes, *not* four page sets (for every level separate, > as you suggest). The page does *not* switch while CMxx is > enforced. I am tired, but (have hope) not too much to talk > nonsense -;) (23.35 local time...) Again, this is a performance/implementation issue, not a functionality issue. > +> The ability to switch memory based memory maps is all that is > +> required. > > You will create a emulator of multi-mode processor with > one-mode one -:) Not really. If you want to think of it that way, we are emulating the VAX implementation of mode transitions. Only the transitions are an issue. Yes, I suspect that context changes will be significantly slower than on the Alpha, but once the transition completes, code runs at full speed. > +> As far as I know, all modern processes support this. KESU support > > AFAIK the multi-mode processors (including the I86 architecture !) > *doesn't* change memory map while mode switching. > The processorrs *does* memory map change, but while *process > context* changes - when you switch to another process !! > And *that* makes the step "time costly" - you must clear > the TBL cache register etc. While you switch in one process > to another mode you *not* must do it. > And in 1) or rest of the stuff you suggest that ESU control > is done in PAL-code: I am schocked that all are agree with > you ! Including Brett !! -;) > Think a moment: you will do a PAL-code check of internal register > (the page table entry, where includes page protection) with > other internal register (processor mode) for *EVERY* memory > load & store ??! You will the force *any* LOAD, STORE and > other memory-manipulating intstruction to be PAL-based ! > That looks like be best implemented with little number of > transistor... ! > AFAIK what in PAL *must* be done is some switching, required > for b.ex. calling standard: to prevent access for data in one > mode from other mode *may* be required atomic instruction > (probably a REI where you mention, can think for some ENTER > and LEAVE of stack frame etc.) where are not implemented > in the RISC. The actual per access processing is done in hardware. I am not suggesting that it be done any other way! On the VAX, the setting of the bits which tell the memory management hardware about the current KESU setting was done in the hardware / microcode which implemented REI, CHMx, and interrupt handling. On the Alpha, these bits are set by the PALcode which implements REI and CHMx. I am not sure about interrupt handling. All I am suggesting is that if the memory management hardware does not support the two bit KESU signal, you can get equivalent functionality by setting the memory management hardware to look at different memory maps. > +> hardware makes things more efficient, but it is not necessary. > > Sure. But the efficiency differrence probably is bigger, than > you will admit... > > +Hmm... Your "switching memory maps" doesn't make sense to me--it almost > +sounds like you're talking about P0/P1/S0 space. It really doesn't matter > +which mode you're executing in, you still have the exact same memory map > +(from a process perspective). The only time your memory map changes is if > +you change process context (from a VMS system/processor perspective). A > +user-mode process can elevate itself to Kernel mode, execute a few > +instructions in the same page (assuming it is locked in memory), then drop > +back to user mode. > > Ach, yes, the description was already here -:) > > +> Comments anyone? > > -:) > > [...] > +In any case, I BELIEVE (anyone correct me on this one) that the Intel x86 > +architecture does have KESU (or KSU at least) > > Yes. KESU. > > + as well as page protections > +based on these levels. > > Unfortunatelly - NO... :( > I86 have two-level memory mapping: segments (where are a differrent- > size, [16-byte multiplied]) where are mandatory on all modes, and > paging (4kB page size) where are optional (!). > Segmentation was introduced in 286, paging in 386. > Segment memory mapping precedes paging. > Segmentation does 4-mode access control (named as in VMS) > or none: I86 have roughly 5 memory modes (KESU and Real - linear, > non-mapped) with some unsupported fiddling; I am not sure if > in Alpha switching from virtual memory mapping to real is > ever possible or supported: on i86 (starting from 386) the > switching *is* supported (that is, what [except other work] > does HIMEM.SYS+EMM386.EXE). > That the reason I write "5 modes" ! -:) > > Paging does only two modes access control: Kernel vs. rest > with the addition of linear (paging off, regardless of real > or virtual memory addressing). > > Not all mixes of the segment+page mode setting are supported, > but most possible (even if not supported): see www.x86.org The paging mode is what I envision using. I don't think the segmented mapping is appropriate. (Of course, someone with more imagination than me may see a perfectly good way to make it work.) > + I don't think it has the concept of IPL--at least > +not in hardware. > > WRONG ! (only, if you say what you say... -;)!) > Was there: I86 has equivalent of hardware IPL in the *archi- > tecture* description, but not neccessary embeded in the micro- > processor chip. > Even 8086 has the ablity to do hierarchical interrupt with > "interrupt while in interrupt" allowed. But the functionality > of architecture *and the chips* (not only the processor, but > *also* the separate interrupt controller !) allows more mode > interrupt control: > - flat, two level interrupts (interrupt and NMI) > - limited hierarchical interrupt control > - limited round-robin (!) interrupt control > - mixing of the above > - hierarchical 64-interrupt source > (all are + NMI - NonMaskableInterrupt). > Additionally I86 have some parts, where can help software > IPL control (INT instruction, where roughly emulate a hardware > interrupt !). Some INT are reserved by Inter (and used) for > internal processor usage (b.ex. "invalid instruction" etc. > exception handlers). > > Unfortunately the *IMB-PC* architecture is limited here ! > IBM-XT have one controller, -AT two (cascaded). > BIOS uses some INT, badly near the area of hardware INT > and (ugh !) some was at start incompatible with Intel > description of "reserved for future use"... > Finding "where is the real interrupt" looks like nightmare > (some are re-aranged and renumbered to restore some consis- > tency and fit Intel specification - b.ex. of FPU [when FPU > was implemented] etc.). > Even that - *some* IPL functionality is possible (with > low number of hardware IPL-equivalents) on existing > hardware. > > At end - even, if I86 *has* not-so-bad IPL support, *MOST* > of I86 computers in the world (IBM-PC compatible) are have > build-in parts where prevents usage of that... -:> > And here you are right... I have never said that it would be easy or trivial. I am contending that it can be done and with adequate (if not optimal) performance. (But isn't that a description of most PC software? ) The reality is that there is so much horsepower available in a PC now that even inefficient code can perform adequately. (Note that I am omitting the obvious comments about MS software.) I am not trying to make it sound like this solution would be a dog. I think it would have very good performance. VMS does a much better job of interleaving I/O and CPU time than most PC OSes. If you aren't CPU bound, the extra overhead would probably be almost unnoticable.