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.
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.
Multics was co-developed with the hardware; that hardware contains Multics specific features that are needed to implement Multics. Segment tables, Rings, Gates and more. enable the memory mapping and protection that that is the basis of Multics.
These hardware features are not found in the current gamut of architectures due to the dominance of the marketing value of being the fasted CPU; these features lower the CPU throughput and also cost valuable silicon space, and the economic value of a secure OS is less then the value of being faster or shinier.
segment
User-visible subdivision of a process's address space, mapped onto a storage system file. Each segment is 1MB long, and has a zero address. The term "segment" is used interchangeably with "file" -- except not really: the things that are files in other systems are implemented as segments; also, the term "file" includes multi-segment files, and when talking in terms of COBOL, PL/I, or FORTRAN language runtime objects, one speaks of files. Programs are spoken of as stored in (procedure) segments. Correct use of the terms "file" and "segment" is a sure sign of a Multician.
Porting is unfeasible; Multics relies on hardware features not available. An emulator for the original hardware can be found at: http://ringzero.wikidot.com/ Information about Multics at: https://multicians.org/
I would argue that Multics security was due more to the ring and gate hardware architecture, that security was designed into the software from day 0 (rather then being grafted in afterwards), and code review practices.
Reading the Multics B2 security analysis reveals that the review team did find security holes in Multics which were fixed as part of the review process.
Recently, a buffer overflow vulnerability was found in the Multics CKermit implementation, despite it's being written in PL/I.
Security is hard, and is achieved through good programming, not by (just) trusting tools.
PL/I doesn't prevent memory access bugs, but it makes it easier to do good programming. For example, parameters are passed by descriptor, so the allocated size is passed allowing run-time bounds checking. On the other hand, there is an equivalent of C type-casting, so it is still possible for the programmer to shoot themselves in foot while simultaneously hoisting themselves on their on petard.