17 Mar
2016
17 Mar
'16
8:59 a.m.
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