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 …

  1. Uberseehandel

    Primos

    Some years ago, when there was a plethora of super-minicomputer company manufacturers, one of the leading lights was Prime Computers. Their operating system, Primos, was based upon Honeywell's development of Multics for super-minis.

    Primos was a class act and well ahead of its time in many respects.

    I wouldn't dismiss Multics out of hand.

    1. Nick Ryan Silver badge

      Re: Primos

      Wow - PrimOS. That brings back some memories. Interesting systems, and like many they had some good points and some really infuriating ones as well. Certainly easy enough to use but at the time I used them there were already lots of grumbles about lack of software support with vendors abandoning PrimOS ports in favour of pretty much anything else.

    2. Anonymous Coward
      Anonymous Coward

      Re: Primos

      In the late 80s, early 90s, the company I was with was moving offices. It ran on a PR1MOS-based COBOL suite, and we needed new hardware to cover the move - I can't recall the model. No bother, said Prime, it's all yours for a mere £2million. My boss at the time, who knew full well the writing on the wall for Prime said "Think again." He ended up getting two systems and paying £900k. It took another 10 years to port the COBOL to another platform. Unfortunately that platform was Dynix/ptx....

    3. jeffdyer

      Re: Primos

      We had a Pr1me at Sheffield when I was there, I used it mostly for online chat with the female person at the terminal directly opposite IIRC.

      1. Grouchy Bloke
        Thumb Up

        Re: Primos

        Ahh, the days of boot 14114...

        A pr1me 750, the first computer that I got paid to use..

    4. John Smith 19 Gold badge
      Unhappy

      "Their operating system, Primos, was based upon Honeywell's development of Multics"

      I did not know this.

      The impression from reading the literature of the time was any startup looking to side step an OS would get a copy of Unix off Bell Labs and hack it.

      1. swm

        Re: "Their operating system, Primos, was based upon Honeywell's development of Multics"

        My memory is that it was originally on a GE-645 computer on the top floor of tech square at MIT. I remember seeing the machine there. We used to log on to this machine remotely. I still have the instruction manual for this machine.

        Then Honeywell bought out the GE computer department - many stories about the early development times.

    5. Arthur the cat Silver badge

      "Primos, was based upon Honeywell's development of Multics for super-minis."

      I don't think so. Take a look at the comp.sys.prime FAQ entry on Primos.

      TL;DR version: written at a NASA research centre because they needed a time sharing system; originally called DOS(*); in the public domain because it was done with US government money; the company was set up to sell hardware running the OS; finally called Primos when V mode came along.

      (*) As were most OSes in those days.

      1. Uberseehandel

        Re: "Primos, was based upon Honeywell's development of Multics for super-minis."

        I was there at the time, I was the initial customer for a distributed Prime WAN deployment in my country, that went global; subsequently I was processed through Prime's internal SE course, as a "reward", and worked as part of the benchmarking team on a number of US government tenders, including classified ones.

        The Honeywell origins were freely acknowledged if anybody asked, mostly, they didn't.

        Quite a lot of OSes were called OS.

        1. Weiss_von_Nichts

          Re: "Primos, was based upon Honeywell's development of Multics for super-minis."

          Bendix, AFAIK, are still a major player in aviation. I think, there's a famous series of auto pilots manufactured by them.

      2. John Smith 19 Gold badge
        Unhappy

        "TL;DR written at a NASA research centre because they needed a time sharing system; "

        Thanks for the correction.

        The thing that struck me about reading the post was how organized Prime seemed, possibly as a result of having its core group all from the same originating company (I wouldn't call Honeywell a parent as I don't think they had any involvement in Prime).

        But the game changed and they made some wrong moves and they were out evolved by Intel and MS.

        Of course what has happened once can happen again.....

      3. DaiyuHurst

        Re: "Primos, was based upon Honeywell's development of Multics for super-minis."

        Prime's first OS was called RTOS, for Real-Time Operating System. It was written by Prime's founder, Bill Poduska, who wrote the first assembler for Multics. DOS came next, and then later, DOS was used as the bootloder for PRIMOS. Beginning with Revision 17 of PRIMOS, most of the OS was re-written in a subset of PL/I, and the Primos Analyst Training Class notes included pages photocopied from the Multics Systems Programmers Manual.

        RTOS is lost to time. I have the DOS source code, the source code for PRIMOS Rev 18.1 and Rev 19.2. As Bill Poduska himself described, it's "Multics in a Matchbox".

    6. GidaBrasti

      Re: Primos

      Thank you for bringing back fond memories

    7. RW

      Re: Primos

      There have been any number of very good computer manufacturers. Philco and Bendix, names perhaps better known for household appliances, had extremely innovative designs for their mainframes, but eventually went under as far as computers were concerned.

      1. Anonymous Coward
        Windows

        Re: Primos

        One of my earliest memories from the late 1970s is my dad driving along the M4 from Heathrow and seeing the elevated neon signs for Data General and Trico. I knew even then that windshield wipers were not my calling, but sadly, by the time I was ready for Data General, they had long since disappeared. But I credit that sign with laying a seed of interest in computers.

    8. Doctor Syntax Silver badge

      Re: Primos

      We had access to a Prime run by the Home Office. Its main use was to run a Lockheed bibliography database. It was possible to write well tuned queries for that, a characteristic which Google, Amazon and eBay seem to remorselessly root out of their query engines. The responses were in the form of references to microfilms of the original papers which were supplied to the labs which used it. Elsevier would have a blue fit if that were done today. The database was written in FORTRAN; for some reason a query managed to get it to start regurgitating the source code but I never managed to get it to repeat that trick.

      We also had Pascal available. I can't remember what use I made of that but I must have done. We got our Onyx Unix box a little later and I sacrificed one of the TTY ports to connect to the link to the Prime (we must have had some sort of multiplexer on the Prime link). We didn't have tip, cu or the like on the Onyx so I explored the possibilities of fork() (and, indeed C which was new to me at the time) to write a simple equivalent so I could get on to the Prime from my lab instead of having to go down to the library. If I'd just been wanting to use the Prime for a literature search I'd have had to go to the library anyway to use the microfilm.

      Again, thanks for a reminder of times gone by.

    9. sawatts

      Re: Primos

      As I was told at the time, the MOD spent an unfortunate amount of time deciding on a minicomputer to standardise on. This being a Prime model which promptly went out of production.

      I missed out on the Primes. When I started work (1990) they had just been removed and the ground floor of our building was a dark warren with unexpected holes in the floor. There were still people who bemoaned losing a "real" computer - even though the 386PC desktop was quicker, not shared, and cost less than a years maintanance.

      This is the same realm that built a big new building to house a new Cray. Had to be big because the new computer was a hundred times more powerful than the old one, and that was quite big enough. Last time I saw the place the new computer was installed in the lobby, and the cavern was used as a super-chilled typing pool...

  2. Chris Miller

    The first commercial mainframes I worked on (in the 70s) were Honeywell 36-bit machines running GCOS (originally GECOS for General Electric). They also had the ability to run Multics (and we had the manuals), but there was no commercial software (such as COBOL compilers) available for it.

    All customers got the source code for the OS - it was on microfiche. This enabled you to write and implement your own patches, which we did. I think some universities ran Multics, but whether they got the source code, I can't say.

    1. Anonymous Coward
      Anonymous Coward

      Often, mainframes came with source code. It was sold with the hardware, was very tied to the hardware, there were no mainframe clones on sale, and very few could build one (and have the space to host and run it). Licensee were well known, and giving access to code could wasn't a big issue, and customer may have needed to personalize it. Also, big money was made selling the hardware, not the software.

      Illegal copies of software and IP became a much bigger issue later, with the advent of minis and personal PCs, ISV (software only companies), more competition, and off-the-shelf software. Now money was made selling software, not the hardware.

      It's no surprise the FOSS movement was born in universities among people used to have access to the OS and application code on mainframes.

      1. Chris Parsons

        Indeed they did. I made a living modifying George 3 for quite a few years, and great fun it was, too.

    2. BenDwire Silver badge
      Pint

      Certainly my Uni ran it (Brunel, west London, c1980) and I used to spend hours in the computer centre trying to learn how to program. Now, finding out that I could recreate the experience with a Raspberry Pi seems to illustrate just how far we've advanced in such a relatively small length of time.

      I'm just kicking myself for throwing out my original "Multics Pocket Guide" at the last house move ...

      1. Neil Davies 1

        Manuals

        I've still got a bunch of them - Multics Programmers Manuals - got to dig them out

      2. DaiyuHurst

        You can get yourself another one here:

        http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AW17_multicsPocketRef_Apr76.pdf

    3. Doctor Huh?

      "I think some universities ran Multics, but whether they got the source code, I can't say."

      MIT certainly ran Multics. Yeah, they had THE source.

      1. Deryk Barker

        All Multics sites had the source code.

        As somebody has pointed out, it was common for mainframes to come with source: I also worked on a Honeywell GOCS-3 system for some years and we had the source to that, too.

        1. RW

          More mainframe OS code

          IN 1974-75 IBM provided the source code for their mainframe OS to some customers. A university I worked at then had it on microfiche. Somewhat later, a large insurance company in Vancouver had it, too.

          And Burroughs provided source code for the MCP in that era, as well.

    4. Deryk Barker

      In fact the hardware story is somewhat more complex.

      GE originally produced the 635 and its OS GECOS-3 in the early 1960s. When MIT were looking to create their new OS they looked around for hardware and GE were prepared to custom-build a processor with segmentation and paging hardware as required; IBM were not.

      Hence the GE-645, which was the first Multics CPU.

      Later, GE developed the 6000 series to run GECOS: several models including 6050, 6060, 6070 and 6080 AIR; the "even numbered" ones having an extended instruction set - EIS - for commercial programming: it had instructions like MVNE (Move Numeric Edited) which could take a binary value and format as ASCII, complete with currency symbol, commas for thousands, decimal places and check suppression characters - RISC it was not.

      But the 6000 series did not have the segmentation and paging hardware necessary for Multics; moreoever, among other recommendations of the USAF Tiger Team looking at Multics security, was that the rings should be implemented in hardware, rather than in software as on the 645.

      Enter the 6180, which had the segmentation and paging hardware AND hardware rings (8 as opposed to the 64 on the 645) and fixed-size pages.

      GE sold their computer business to Honeywell around 1971, later Multics processors were the Level 68 and DPS-8/70M.

      It was only internal politics within Honeywell which killed Multics; by 1984 they had also acquired Xerox's computer business, so now found themselves with 3 mainframe OS's: GCOS (the E was dropped as part of the agreement with GE, although much of the documentation kept it for some time), Multics and CP-6 (originally CP-V when owned by Xerox).

      I'm not sure about the 70s, but by 1980, when I began working on Multics there certainly was a COBOL compiler (I wrote an emacs programming mode for it for a UK customer) and quite a bit of commercial software, including one of the first relational database systems, MRDS.

      I still miss Multics.

      1. unused0

        Yes, it has COBOL.

        r 19:24 0.172 65

        edm hello.cobol

        Segment not found.

        Input.

        000100 IDENTIFICATION DIVISION.

        000200 PROGRAM-ID. HELLOWORLD.

        000300

        000400*

        000500 ENVIRONMENT DIVISION.

        000600 CONFIGURATION SECTION.

        000700 SOURCE-COMPUTER. RM-COBOL.

        000800 OBJECT-COMPUTER. RM-COBOL.

        000900

        001000 DATA DIVISION.

        001100 FILE SECTION.

        001200

        100000 PROCEDURE DIVISION.

        100100

        100200 MAIN-LOGIC SECTION.

        100300 BEGIN.

        100500 DISPLAY "Multics rulez, UNIX droolz".

        100600 STOP RUN.

        100700 MAIN-LOGIC-EXIT.

        100800 EXIT.

        .

        Edit.

        w

        q

        r 19:24 0.128 4

        cobol hello

        COBOL, Version 5.4

        r 19:24 0.477 206

        hello$HELLOWORLD

        Multics rulez, UNIX droolz

        hello$HELLOWORLD: Run-unit hello$HELLOWORLD terminated (line 18).

        r 19:24 0.036 6

      2. elDog

        Good encapsulation of the history of Multics - from my perspective

        I was around during the GECOS-III and HW and then Bull lines. I did a bit of C work on Multics and I think it had a functioning nroff system for doing typesetting - this back in the late 70s.

        Since my little company was somewhat deeply involved with the GCOS (Honeywell) transition I do remember the angst about the neglect for the leading edge features of Multics:

        - all files were memory mapped

        - ring security enforced at the hardware level

        - virtual associative memory

        Of course all of this had a lot of overhead and didn't sell well into the corporate suites.

        Maybe it will actually rise from the ashes in the world of IoT!

      3. DaiyuHurst

        We still have the COBOL compiler, but honestly, I haven't tried it yet.

    5. Doctor Syntax Silver badge

      "Honeywell 36-bit machines running GCOS (originally GECOS for General Electric)."

      That also had at least a small influence on Unix: https://en.wikipedia.org/wiki/Gecos_field

    6. Neil Davies 1

      Source code

      Yes - we did microfiche and tape, we could mount the source on a separate logical volume

  3. Anonymous Coward
    Anonymous Coward

    Anything we should steal ?

    Does Multics have any useful features that are not present in modern OSes ?

    1. Pete 2 Silver badge

      Re: Anything we should steal ?

      > Does Multics have any useful features that are not present in modern OSes

      There was the "cookie" program. It would seize control of your terminal and type write I wanna cookie and wouldn't let you continue with your work (or play) until you typed "cookie".

      The original virus?

      1. Anonymous Coward
        Anonymous Coward

        Re: Anything we should steal ?

        The original ransomware?

    2. Flywheel

      Re: Anything we should steal ?

      It probably doesn't have a GCHQ/NSA/Five Eyes module...

      1. Anonymous Coward
        Anonymous Coward

        Re: Anything we should steal ?

        Yes, because computer weren't born at GCHQ predecessor, right? <G> And most universities refused military and government funds for their researches, right? Guess the various agencies knew exactly what was going on the relatively few mainframes working back then....

      2. Anonymous Coward
        Anonymous Coward

        Re: Anything we should steal ?

        "It probably doesn't have a GCHQ/NSA/Five Eyes module"

        Given access to the source code and the ability to modify it, you could in principle be very sure of that.

        1. Allan George Dyer

          Re: Anything we should steal ?

          @Voyna i Mor: "Given access to the source code and the ability to modify it, you could in principle be very sure of that."

          Have you read Ken Thompson's classic paper "Reflections on Trusting Trust"?

      3. Uberseehandel

        Re: Anything we should steal ?

        Funny as it is that you say that . . .

        better not to open that particular can of worms.

    3. Cem Ayin

      Re: Anything we should steal ? - Definitely

      "Does Multics have any useful features that are not present in modern OSes ?"

      Its virtual memory implementation comes to mind: in Multics, "files" were really persistent memory segments, i.e. all files were "memory-mapped" in Unix-parlance.

      https://nbonvin.wordpress.com/2008/02/05/review_the_multics_virtual_mem/

      The concept was not without problems of its own (see the linked article above and the articles linked therein); but given today's availablity of reasonably fast, persistent mass memory technologies I think that exploring direct mass memory access while doing away with traditional file I/O might well be worth exploring once more.

      1. Christian Berger

        Re: Anything we should steal ? - Definitely

        "I think that exploring direct mass memory access while doing away with traditional file I/O might well be worth exploring once more."

        That's why some popular architectures like Geneva on the LISP machines do it that way even today.

      2. Robert Carnegie Silver badge

        Memory mapped files

        I'm vague on what this feature is. I hope it wouldn't make it 1000 times easier to write really lethal ransomware??

      3. John Smith 19 Gold badge
        Coat

        Re: Anything we should steal ? - Definitely

        Multics was written in a high level language (PL/M IIRC, IE "Programming Language/Multics") but the compiler was hand written.

        In hindsight it might have been better for the team if they developed V1 of the compiler using one of the "compiler compiler" tools of the time, then fed a copy of the compiler through itself with the optimize flag on.

        The virtual memory system was impressive. IIRC it kind of did execute in place, not needing a lot of address fixing during the load process. It also made code sharing very simple.

        Mines the one with a copy of "RW Watson, Timesharing System Design Concepts" in the pocket.

        1. Deryk Barker

          Re: Anything we should steal ? - Definitely

          Multics was 98% PL/1, although there was a cut-down version used early on before the full-blown called EPL (Early PL/1). The remaining 2% was in ALM (Assembler Language for Multics).

          1. StheD

            Re: Anything we should steal ? - Definitely

            When I arrived at MIT in 1969 the decision to use a high level language to design Multics was still controversial. I went to grad school in a place that ran a Multics system (it was Honeywell by then) and it was still mostly PL/1. The Pascal "compiler" used for classes worked by translating Pascal to PL/1 - I was the first person to get the Jensen/Wirth Zurich compiler to compile itself. (Sets were done assuming a 60 bit word.)

            It is hazy now, but I recall that file protection was a lot more flexible than on UNIX, with access control lists implemented a lot more cleanly than anything else I've seen.

        2. 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.

      4. William K Kelley

        Re: Anything we should steal ? - Definitely

        The much under appreciated IBM TSS/360 operating system also had memory-mapped files, decades before the FS-inspired System/38 (iSeries these days). Basic problem with TSS was that it was well before its time, and the S/360 model 67 hardware was never adequate to run it. While it was possible to get a 32-bit addressing version of the model 67, no S/370 models offered it, so customers such as General Motors who had built their early automobile CAD system on TSS were unable to migrate TSS to S/370 and had to rewrite/restructure their CAD software to run on the 24-bit virtual of S/370, and also lost the ability to have memory-mapped files.

      5. uppland2

        Re: Anything we should steal ? - Definitely

        Like OS/400 and AIX?

      6. uppland2

        Re: Anything we should steal ? - Definitely

        "Its virtual memory implementation comes to mind: in Multics, "files" were really persistent memory segments, i.e. all files were "memory-mapped" in Unix-parlance."

        Like OS/400 and AIX?

        1. Cem Ayin
          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.

    4. Smoking Man

      Re: Anything we should steal ?

      It runs without systemd. Imagine that.

    5. Daggerchild Silver badge

      Re: Anything we should steal ?

      From what I remember about it, its APIs had versioning built into the interfaces. It was designed for live-upgrade.

      The components would fall back to the latest version each understood, and as the opportunity arose they would fall-forward to newer versions. I think it's one of those things that is theoretically a good idea, until you start involving humans.

      I mentally filed all this under the image of a kitten tangled in string.

    6. Anonymous Coward
      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

    7. DaiyuHurst

      Re: Anything we should steal ?

      Stability.

  4. Hero Protagonist

    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).

    1. Steve Aubrey

      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.)

    2. John Smith 19 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. RW

        Those fast Burroughs card readers

        Yes, indeedy!

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

  5. Paul Roff
    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.

  6. Conrad Longmore
    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

    1. Deryk Barker

      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...

      1. Neil Davies 1

        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

    2. 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!

  7. Fred Goldstein

    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. Mike 16

      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.

      1. Anonymous Coward
        Anonymous Coward

        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.

        1. Ramazan

          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.

      2. RyszrdG

        Re: Multics Hardware security

        What next - the resurrection of SCOMP?

  8. John Smith 19 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.

    1. Deryk Barker

      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.

      1. John Smith 19 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. KenH

        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

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