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

[Charles Anthony]

On Mon, Mar 14, 2016 at 10:38 AM, Mouse <mouse at rodents-montreal.org> wrote:

>
> Now that 64-bit address space is becoming common, eight megs of RAM is
> ignorably small, and multi-level page tables are common, this looks a
> lot less impossible.  I've been tempted to build something of the
> source, but I never got to use real Multics, and I would probably have
> trouble shaking free of the POSIX mindset.
>
> I desperately want to port Multics to a modern architecture, 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.

I do believe that it is possible (tho not necessarily feasible) to take an
open source architecture (OR1000 for example) and add an additional page
table level to support the segment architecture; then you need to extend
the instruction set to support the clever indirect address exceptions that
allow directed faults and linkage offset tables; tweak the C compiler to
understand segment pointers (something along the line of 'near' and 'far'
pointers.

Then there is subtle issue in the way the Multics does the stack -- the h/w
didn't have actual stacks; a index register was assigned as the stack
pointer, and a pointer register as the stack segment pointer. This means
that stack addresses, heap address and data addresses are all in separate
address spaces, requiring 'far' pointers to access. I think it is possible
to move them all into the same space, but that will require a lot of
tinkering with the way that Multics deals with stack and process space.
(Also, Multics stacks grow upward -- great for protection against buffer
overrun attacks, but a pain in a modern architecture.)

-- Charles