back to article Multics resurrected: Proto-Unix now runs on Raspberry Pi or x86

Seminal time-sharing OS Multics - the Multiplexed Information and Computing Service - has been resurrected in a new simulator. As The Register reported in 2011, Multics' sprang from MIT's decision to eschew an IBM mainframe, buy one from GE instead and write an OS for the machine. The operating system's source code was …

Boffin

Re: Anything we should steal ? - Definitely

"Like OS/400 and AIX?"

OS/400 (now "IBM i") is the other commonly cited OS that provides a single level store, and AFAIK the only one still in active commercial use today. (Aegis and KeyKOS are two other, now defunct, examples that I remember OTTOMH.)

AIX OTOH is IBM's homegrown (SysV-based) implementation of Unix and while certainly providing mmap(2) & friends I am not aware that it has a single level store. Not that it would be impossible to implement a POSIX-ish OS on top of an OS based on a SLS (it has, in fact, been done: Domain/OS), but to my knowledge AIX is basically SysV with the usual set of BSD extensions as well as IBM's very own bells and whistles added.

Note that a "single level store" means more than just the ability to mmap files (I had mentioned mmap only as a /very loose/ Unix-analogy); in fact such a system does not have a "file system" in the usual sense of the word at all - just a large, usually segmented, address space or object store that is transparently being made persistent by the OS through writing out dirty pages to permanent background storage as needed.

No need for file I/O to keep data persistent, /that/ is the key point.

FWIW, the concept appears not to be entirely "dead"; while searching Multics references I stumbled on this paper

http://repository.cmu.edu/ece/370/

but I have not yet had time to really digest it. And then there is of course "The Machine", or rather, with quite a bit of luck there will be one day... although "memory centric computing" - while also being built around a persistent main memory is a different and more far-reaching concept altoghether.

BTW, another Multics nicety that I had forgotten in my original post is the fact that Multics segements containing executable code could (being mapped into the address space all the time anyway) be directly invoked and the interface for doing so was IIRC provided and standardized by the OS, thus leading to implicit cross-language compatibility of executable code. No need for FFIs and stuff.

1
0
swm

Re: Anything we should steal ? - Definitely

I thought that the compiler was (eventually) written in PL/1. (It used to be called NPL for New Programming Language until the National Physics Labs complained.) Wherever the compiler was slow they optimized the compiler so things got better and better. There was a compiler switch for generating optimized code but they discovered that compilation times were faster with optimization enables so they removed the compiler switch and made all compilations optimized. The only code not in PL/1 were device drivers and bootstraps etc.

There was an early decision to do all of the code in PL/1. They figured that they would lose a factor of 2 by not being in assembly but gain an order of magnitude by being able to manage the code base. Best decision - every time someone complained about slow generated code they fixed the compiler and everyone benefited.

We stole the hierarchical file system for the Dartmouth Time Sharing System. We didn't have hardware for paging so we couldn't steal their memory system.

MULTICS was a great system before its time.

1
0
Anonymous Coward

Re: Anything we should steal ?

Most of the ideas Multics implemented were carried over to our more modern OS's especially anything Unix like.

Basically Multics was the foundation for much of what we expect a modern OS to do. Anything we can steal would be the left overs :D

0
0
Anonymous Coward

Re: Anything we should steal ?

The original ransomware?

0
0

Re: Anything we should steal ?

Stability.

0
0

Cut my teeth on Multics

I got a job as a student programmer at my university shortly after they replaced their aging Burroughs B5500 (affectionately known as "Bertha") with a Multics system. It felt like the future had arrived. Exotic OS features! CRT terminals! Lowercase characters! No more punchcards! PL/1!

I actually took some heat for one thing I did -- ported a multiplayer "Space Wars" game to work on our Teleray 1061 terminals. The load from people playing the game during prime hours was having a significant impact on system performance. (I had to assure my management that the development had been done on my own time, not on the job).

3
0

Re: Cut my teeth on Multics

My similar history involved IBM's VM/CMS. We were able to convince management that by transitioning a Star Trek game from Basic in to REXX, that would give us experience with the new language. On work hours.

And it worked, both ways. The game was functional, and we did learn the language.

Funny, though, how the game development and additions didn't stop once we were declared to have graduated from that particular learning activity . . .

(Nostalgia: I got through the whole post without mentioning Creative Computing and David H Ahl. Until now.)

1
0
Gold badge
Unhappy

"It felt like the future had arrived. "

The Burroughs architecture was pretty advanced for its time, being designed directly to support a high level language and tight access security to variables. I didn't know about the upper case restriction. That sounds a bit austere, even for business use.

Edward Dijkstra wanted one when he watched it compile his program as fast as it was being read in (single pass compiler. Apparently not at ll standard at the time).

1
0
RW

Those fast Burroughs card readers

Yes, indeedy!

[I worked for Burroughs for a couple of years in the early 1970s.]

1
0
Coat

Opportunities

"A few tweaks have been made to Multics, notably support for dates in the 21st century."

Let's hope this revival takes off so we can restart a Y2K consultancy.

2
0
Devil

There were five in the UK..

There were five Multics systems in UK Universities as I recall, Birmingham, Bath/Bristol (AUCC), Brunel, Cardiff and Loughborough. Typically these were hooked up to Lear-Siegler ADM3a or similar terminals, ours used British-built Insight VDT-1s (who were eventually bought our by Sanderson Electronics).

Of course, as with probably most 1980s computing students we tried to hack it, but unlike other boxes the security was very solid. Social engineering attacks worked the best. Yes, I got into a lot of trouble in those days..

As an aside, Paul Smee was one of the leading Multicians of the time IMO. Sadly he passed away back in 2006 - http://www.bristol.ac.uk/news/2006/5138.html

2
0

Re: There were five in the UK..

There were also two non-academic systems: STC (Standard Telephones and Cables) and the RAE (Royal Aircraft Establishment).

The RAE site was the first MLS (Multi-Level Secure) computer system in the UK, as Multics had just been certified to Orange Book B2 level. I constructed the security trials which we conducted for the RAE as part of the acceptance testing.

If I told you any more, I'd have to kill you...

4
0
RW

Re: There were five in the UK..

Since you mentioned a name now lost, let me mention another, also an OS wizard: Jim Oma, who was one of the tiny team (about six people) that maintained Burroughs's large systems MCP.

Jim died around 1973; he's long gone and most people have never heard of him. Clever guy!

1
0

Re: There were five in the UK..

One of its main functions was to front end the cray - I installed the coloured book network protocols on that one. AUCC wrote the protocols

1
0

Unix was meant not so much an anti-Multics as a mini-Multics. Unix had to run on a PDP-7, after all, and then a PDP-11, vs. a mainframe that could have a whole megabyte of memory. In other words, by today's standards, big fat Multics was small.

But it had features still missed. Security was central. It had rings of protection, enforced by the hardware (unlike Unix, it was not meant to be portable). The zillions of Unix exploits that plague today's descendants would not be likely to work in Multics. Frankly reviving it for modern hardware might be a useful exercise in security.

1
0
Bronze badge

Multics Hardware security

Funny you should mention Multics on Modern Hardware. When I first got the docs on the 80286, I said to myself: "looks like they want to run Multics on this beast". Rings, real segments, etc. Then I started using it and found that the segments were not quite as lovely as they were described (loading a descriptor was slow, and no caches for them). Intel could have fixed this for the 386, but it seems that the Great Unwashed _really_ wanted a memory model just like whatever Vax or SunOs machine they had in school, so they added fairly conventional page-maps as well. The death knell was probably when the folks who thought it was the bee's knees to execute code on the stack led the march to "forget segments" and map them all to one flat (page mapped) address space.

I also recall fighting with a gcc re-target over which of the configuration stuff to control things like stack layout would actually do so, or was "more like guidelines, really". Had to wonder WTF they would do with something like the IBM360 ABI that allowed "bushy stacks" (ala Burroughs) or the Power or Natsemi16032 that supported function pointers that were more than an index of octets in the one undifferentiated memory space.

In summary, Modern Hardware (for some values of "Modern") has at least vestigial support for Multics-worthy security and isolation. Modern Software developers for the most part seem more willing to eat a live toad than accept the constraints (and re-training) that might involve.

8
0
LDS
Silver badge

Re: Multics Hardware security

Memory pages were required in the 386 because you can't really believe to implement virtual memory at the segment level when segment maximum size went from 64K to 4G (and physical memory was quite limited back then).

That said, segments and pages can work together - just manage virtual memory using pages, and manage software security with segments, but OS designers were still unaware of the security implications, and threw away segments because of the performance issues (exactly because of the security checks performed).

Then came AMD and removed segment support altogether.

0
0

Re: Multics Hardware security

What next - the resurrection of SCOMP?

0
0

Re: OS designers were still unaware of the security implications,

"and threw away segments because of the performance issues"

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options:

PAX_SEGMEXEC

This implementation is based on the segmentation feature of the CPU and has a very small performance impact, however applications will be limited to a 1.5 GB address space instead of the normal 3 GB.

1
0
Gold badge

Now I wonder when someone will port the ICL 2900 architecture and George 3

This also used rings but had a very small register set, several of which acted as stack bases.

That mean they could be "slaved" with multiple (hidden) registers in the CPU.

ICL reckoned this would give those registers a cache hit rate 10x that of random data, while being quite simple to engineer. It also meant they could (in theory) provide different price//performance points. Base line has no slaving, more expensive designs have 1 or more slaves. Interestingly the supported data types were part of the ISA but the actual instruction set was not. It was expected to be flexible, with the OS (like the Burroughs 5500) programmed in an in house HLL.

Unlike the 5500 the goal was good support of any major HLL, not just one tweaked to the specific architecture, which raises question of what are the core capabilities you should have in the hardware?

So accumulator based (like an x86) but with the what we would call very strong orthogonality, like the M68K.

For anyone interested

One of the things that's really changed since these machines were built is the massive improvements in chip design and layout software.

What was a bet-the-company project in the late 60's could be an EE class project.

2
0

Re: Now I wonder when someoen will port the ICL 2900 architecture and George 3

Which?

George 3 ran on 1900 machine, the 2900s ran VME/B (and wasn't there a smaller VME/K?)

The ICL people visited the Multics people during the design phase, but IIRC the Multics people couldn't understand why the ICL people felt that 32 rings were needed. Multics had originally had 64 on the GE-645, but this was reduced to 8 on the 6180 - and only rings 0,1, 4 and 5 were actually used initially although later on something (was it forum?) ran in ring 2 and some of the UK Rainbow book networking software ran in ring 3 (I know this for certain, as I wrote a call gate for the latter). Rings 6 and 7 were sometimes referred to as "outer darkness" as the standard software was not accessible in those rings.

Of course, the 2900 could emulate the 1900. Indeed, in the early 1980s my wife encountered, at BT in South Wales, the "orange Leos" which were ICL 2900s running the 1900 emulator running the System-4 emulator running the LEO emulator running LEO programs for which they no longer had source code.

4
0
Gold badge
Unhappy

"the 2900s ran VME/B (and wasn't there a smaller VME/K?)"

Oooops.

Yes it would indeed be one of the Virtual Machine Environments that would be the appropriate OS for them.

"the "orange Leos" which were ICL 2900s running the 1900 emulator running the System-4 emulator running the LEO emulator running LEO programs for which they no longer had source code."

OMG It's been ages since I saw an emulation stack like that. I thought they only existed in the financial sector.

2
0

Re: Now I wonder when someoen will port the ICL 2900 architecture and George 3

Used both Multics at STC and VME when STC bought out ICL.

There is already a G3 emulator and the current VME - still in use by some customers actually runs under emulation on Intel hardware - whether this will ever by generally released is another matter.

ICL seemed to by very good at emulation - with ICL1900 and System4 being ones I saw - there were rumours of a 370 emulator but denied.

What was interesting about the emulation was the fact you had multiple instruction decoder boards to allow the different instruction sets to run as well as some intelligence in the various peripheral controllers to allow the newer hardware to work with older OS.

From memory there were several variants - DME which allowed the new hardware to pretend to be the old hardware - just running a lot faster, CME which allowed concurrent emulation with the hardware effectively time slicing between the two instruction sets - useful when moving a workload from the old platform to the new one and I have some bitter memories of using BMEEP which allowed one VM to run under a different instruction set

0
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018