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