Multics ran on Honeywell 6180 and DPS8/M machines. They had 36 bit words like the PDP-10. They also had instructions that would operate o in 6 or 9 bit characters in the word
The VAX had byte addressable memory, the DPS8/M word 36 bit word addressable, so I suspect that byte oriented instructions might have an edge on the VAX. Contrawise, the DPS8/M memory bus width was 72 bits, so it might have had an edge in double wide operations. I suspect the dominate factor would be that the DPS8/M was core memory at 1 us access time; I don't know the memory bandwidth of the VAX but I would assume it was faster.
According to wikipedia, the 6000s ran about 1 MIP and the DPS8/Ms topped out about 1.7 MIPS. Talking with people that worked on Multics, they generally say the 6000s were about 1 MIP.
Multics achieved security by building it into the h/w. That caused the h/w to be more expensive and slower. The system market these days is all about price/performance ratio and the collective decision not to include security as a performance metric.
These days all the security is already in the hardware, that's what MMUs are supposed to do, virtualize memory, plus protect the OS from everything else. There's not really any penalty to be had for security... plus, think of all the stuff like Virus scanners you can get rid of along the way.
I'd settle for a hardware enforced write protect on a microSD port that I could boot from... at least then I could get back to 1982 levels of security.
IIRC,Primos was written in FORTRAN (with language extensions including the ability to pass a statement number as a parameter, allowing longjmp() like behavior).
Non-single level stores are copy-on-demand. Typically, a process runs a program by starting with an empty address space and mapping the executable code into that space. The program is started, the first instruction fetched; the address space is empty a page fault occurs and the page is copied in. If the page is modified, that is local to the process and the disk image is unchanged. Each process has its own copy of writable pages.
With single level store, the program pages are mapped in, not copied. Writing to the page alters the disk image. All processes running the same program share the memory pages.
> With single level store, the program pages are mapped in, not copied. Writing to the page alters the disk image. All processes running the same program share the memory pages.
MAP_SHARED
Share this mapping. Updates to the mapping are visible to
other processes mapping the same region, and (in the case
of file-backed mappings) are carried through to the
underlying file. (To precisely control when updates are
carried through to the underlying file requires the use of
msync(2).)
MAP_PRIVATE
Create a private copy-on-write mapping. Updates to the
mapping are not visible to other processes mapping the
same file, and are not carried through to the underlying
file. It is unspecified whether changes made to the file
after the mmap() call are visible in the mapped region.
I've had it running in an emulator for a while, but not natively sadly.
It would be fun to have an FPGA implementation of the hardware, and/or a port of the system to modern (or relatively modern) processors that are generally available (perhaps some x86 processors that support segmentation.)
