Honneywell multics? from panels. the inline phots in this message folks -smecc

[Noel Chiappa]

    > From: Charles Anthony

    > I desperately want to port Multics to a modern architecture

Funny you should mention this! Dave Bridgham and my 'other' project (other
than the QSIC) is something called iMucs, which is a Multics-like OS for
Intel x86 machines.

The reason for the x86 machines is that i) they have decent segmentation
support (well, not the very latest model, which dropped it since nobody was
using it), and ii) they are common and cheap.

The concept is to pretty much redo Multics, in C, on the x86. The x86's
segmentation support is adequate, not great. The Multics hardware had all
those indirect addressing modes that the compiler will have to simulate, but
the machines are now so freakin' fast (see simulated PDP-11's running at 100
times the speed of the fastest real ones - on antique PC's), that shouldn't
be a huge problem. We did identify some minor lossage (e.g. I think the
maximum real memory you can support is only a couple of GB), but other than
that, it's a pretty good match.

The x86 even has rings, and the description sounds like it came out of the
Multics hardware manual! Although I have to say, I'm not sure rings sare what
I would pick for a protection model - I think something like protection
domains, with SUID, are better.

(So that e.g. a cross-process callable subsystem with 'private' data could
have that data marked R/W only to that user ID. In 'pure' Multics, one can
move the subsystem/data into a lower ring to give it _some_ protection - but
it still has to be marked R/W 'world', albeit only in that lower ring, for
other processes to be able to call the subsystem.)

It will need specialized compiler support for cross-segment routine calls,
pointers, etc, but I have a mostly-written C compiler that I did (CNU CC is
large pile, I wouldn't touch it with a barge-pole) that I can re-purpose. And
we'll start with XV6 to get a running start.

There would be Standard I/O, and hopefully also something of a Unix emulation,
so we could take advantage of a lot of existing software.

Anyway, we've been focused on the QSIC (and for me, getting my 11's running),
but we hope to start on iMucs in the late spring, when Dave heads off to
Alaska, and QSIC work goes into a hiatus. Getting the compiler finished is
step 1.


    > but there is a profound road-block: the way that Multics does virtual
    > memory is very, very different, and just does not map onto current
    > virtual memory architecture.

You refer here, I assume, to the segmentation stuff?

    > then you need to extend the instruction set to support the clever
    > indirect address exceptions that allow directed faults and linkage
    > offset tables

I think the x86 has more or less what one needs (although, as I say, some of
the more arcane indirect modes would have to be simulated). Although my
memory of the details of the x86 is a bit old, and I've only ever studied the
details of how Multics did inter-segment stuff (in Organick, which doesn't
quite correspond to Multics as later actually implemented).

    > Then there is subtle issue in the way the Multics does the stack ..
    > This means that stack addresses, heap address and data addresses are
    > all in separate address spaces

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 don't think Multics had 'heap' and 'data' segments as somone
might read those terms; a Multics process would have had, in its address
space, many segments to which it had R/W access and in which it kept data.)
But the x86 has that many, and more, so it should be workable, and reasonably
efficient.

    > I think it is possible to move them all into the same space

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?

    > Also, Multics stacks grow upward -- great for protection against buffer
    > overrun attacks, but a pain in a modern architecture.

Sorry, I don't follow that? Why does the stack growth direction make a
difference? It's just a convention, isn't it, which direction is 'push'
and which is 'pop'?

	Noel