> From: Charles Anthony > Slightly at cross purposes here; I was speaking of porting Multics; you > are speaking of writing a Multics like OS. I was opining that I don't > think that porting would work due to Multics reliance on very specific > VM features.
Yes; my un-stated assumption was that the existing Multics code was so tied to the peculiar Multics hardware (how many instances of "fixed bin(18)" do you think there are in the Multics source :-) that it would be impossible to run on any modern hardware except via (as you have so wonderfully done) emulation. Hence the re-implementation route... >> I think the x86 has more or less what one needs Intesting note here: I was just reading Schell's oral history (a _fascintating_ document), and it turns out he was a consultant to Intel on the 286 (which architecture the later machines more or less copied exactly, extending it to 32 bits). So I'm no longer surprised that the x86 has more or less what one needs! :-) >> Well, Multics had (IIRC) 4 segment registers, one for the code, one >> for the stack, one for the linkage segment, and I don't remember >> what the 4th one was used for. I pulled down one of my many copies of Organick, and I had misremembered the details (and of course Organick describes the 645, not the 6180, which was subtly different). The code has its own set of registers; the PBR/IC (I was probably thinking of the x86's CS here). Of the four pointer-register pairs (which are effectively pointers to any segment, i.e. 'far' pointers, in a sense), two are indeed to the stack and linkage segments, and the others can be used for other things - one is typically a pointer to subroutine arguments. > 8 pointer registers .. > PL1 calling conventions reseverved certain regsiters for frame pointer, > etc. Yes, I got the 6180 processor manual, and a bunch of other things, and there had been significant changes since the 645 (which is the version I was somewhat familiar with, from Organick). Of the 8 pointer registers in the 6180, I was only able to find the usage of several: 0 - arguments 4 - linkage 6 - stack frame 7 - stack/linkage header I assume the others (most?/all?) were available for use by the compiler, as temporaries. One apparent big change in Multics since Organick was that the stack and linkage segments had been combined into one (not sure why, as I don't think having one less segment in the KST made much difference, and it didn't save any pointer registers); the header in the combined stack/linkage segment contained pointers to each in the combined segment. >> You wouldn't want to put them all in the same segment - that's the >> whole point of the single-level-store architecture! :-) Or perhaps I'm >> misunderstanding your point, here? > It's been a long time since I look at the x86 segment model, but my > recollection is that segments were mapped into the address space of the > process; that is not how the Multics memory model worked. Each segment > is in it's own address space; any memory reference was, per force, a > segment number and offset. In this last sentence, is that referring to Multics? If so, that is exactly how the x86 _hardware_ works, but most x86 OS's (in particular, all the Unix derivatives) don't really use segments, they just stick everything in a limited number of segments (one for code, one for all data - maybe one more for the stack, although perhaps they map those two to the same memory). > I am unconvinced that Multics could be ported to that architecture No disagreement there - "fixed bin (18)"! > an interesting Multics like operating system should be possible Exactly. > with he caveat that some things are going to have be done differently > due to incompatibilities in the memory model. I'm not so sure - I think you may be thinking that the x86 model is something other than what it is. It does indeed not have the infinite inter-segment pointer chaining possible on Multics hardware (where a pointer in memory points to another pointer which points to another pointer), but other than that, it does seem to have most of what is needed. In particular, it has local and global segment tables (indexed by segment number), and the ability to load pointer registers out of those tables, and the ability to have most (all?) instructions use particular pointer registers (including segment selection), e.g. if the linkage segment was pointed to by the ES register, there is an optional (per-instruction instance) modifier which causes most (all?) of the normal x86 instruction set to operate on that segment, instead of the primary data segment (pointed to by the DS register). Of course, until we get into the details, we can't say positively, but after reading the manuals, it seemed like it was doable. Noel