14 Mar
2016
14 Mar
'16
9:56 a.m.
From: Charles Anthony
I get bloody impressed just watching it on the
emulator; doing it in a
production environment must have been spectacular.
Even though I never did do any programming on Multics myself (I had an
account on the MIT system, and logged in a bit), I still feel that _as an
environment for system programming_, it's _still_ far ahead of almost all the
available competition. Unix V6 at least had the grace of simplicity and
incredibly small size; its descendants have lost that, and so to me Linux,
for example, is entirely inferior to Multics.
Which to me is a pretty awesome accomplishment, in a field as fast-moving as
computers - the only thing that even vaguely compares is the A-12/SR-71,
which today, 17 years after it retired in 1998 (it first flew in 1962),
_still_ holds the record for the fastest air-breathing aircraft.
There is one axis along which I concede that things have advanced since
Multics, which is away from monolithic kernels - Multics is pretty much one
big lump in ring 0, except a few things in ring 1.
But the complete structing of the system around a segmented, single-level
memory system (at least, in terms of the environment the user sees) is such a
fantastic idea that I simply don't understand why that hasn't become the
standard. (The ability to map files in, and DLL's, do get a lot of that
power, but in an ad hoc, inelegant, and less powerful way.)
A few now-defunct system (e.g Apollo) picked up on it, but the only OS today
I know of based around the concept is the IBM i, the descendant of the
Control Program Facility OS on the System/38.
Sigh. (And apologies for the rant, it's one of my hot buttons.. :-)
Noel
14 Mar
14 Mar
1:38 p.m.
There is one axis along which I concede that things
have advanced
since Multics, which is away from monolithic kernels -
Whether that is an advance or a regression depends on your priorities.
I see good arguments each way.
But the complete structing of the system around a
segmented,
single-level memory system (at least, in terms of the environment the
user sees) is such a fantastic idea that I simply don't understand
why that hasn't become the standard.
Well, what was the largest virtual memory space available on various
machines? On the VAX, it was either one gig or two gig, depending on
whether you count just P0 space or both P0 and P1. When you're mapping
objects of uncertain size, that seems awfully constraining - and,
depending on the page table architecture in use, it can cost a lot of
RAM to get even that much; the VAX, for example, needs eight megs of
RAM to map one gig of space, and that doesn't even account for any
memory used to back any of that space. And, back in the heyday of the
VAX, eight megs was a lot of RAM.
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 should dig up some 64-bit machines and try to find enough
documentation to build OSes for them....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
1:59 p.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
15 Mar
15 Mar
10:23 a.m.
m?n 2016-03-14 klockan 13:38 -0400 skrev Mouse:
Which is one of the reason why the POWER architecture was done the way
it was done.
How much table space is needed is directly decided by the machine's
amount of RAM (in POWER 1 at least.)
There is one
axis along which I concede that things have advanced
since Multics, which is away from monolithic kernels -
Whether that is an advance or a regression depends on your priorities.
I see good arguments each way.
But the complete structing of the system around a
segmented,
single-level memory system (at least, in terms of the environment the
user sees) is such a fantastic idea that I simply don't understand
why that hasn't become the standard.
Well, what was the largest virtual memory space available on various
machines? On the VAX, it was either one gig or two gig, depending on
whether you count just P0 space or both P0 and P1. When you're mapping
objects of uncertain size, that seems awfully constraining - and,
depending on the page table architecture in use, it can cost a lot of
RAM to get even that much; the VAX, for example, needs eight megs of
RAM to map one gig of space, and that doesn't even account for any
memory used to back any of that space. And, back in the heyday of the
VAX, eight megs was a lot of RAM.
3085
days inactive
3086
days old
3 comments
4 participants
participants (4)
-
charles.unix.pro＠gmail.com -
jnc＠mercury.lcs.mit.edu -
mouse＠Rodents-Montreal.ORG -
stefan.skoglund＠agj.net