Hacker News Reader

Comment by hisham_hm | Hacker News Reader

Incidentally, I just finished reading "The Mythical Man-Month", which also discusses another old large system, IBM System/360 and its operating system OS/360.

It's really interesting to see how current the discussions on these old machines can be. From the OP:

"For additional security, code and data were distinguished in memory by the use of a "flag bit", and the hardware would not execute data or alter code without first having explicitly changed the flag"

We've been dealing with buffer-overruns and code injection in the stack until very very recently, and there are surely machines out there that still don't have support for the NX bit.

We surely still have a lot to learn from the past.

View on HN

What was it, _South Park_ that did the "Simpsons did it" episode? Thinking about some of the things that came along 20 or 30 years later remind of that. Virtual machines? OS/360 did it. Virtual memory? OS/360 did it. Non-executable data? OS/360 did it. I was a security lead for a product while at Microsoft when the NX was being implemented, and wondered at the time why it took 35 years to get around to that. (I've never worked on a 360, but did some work its successor the 370 and OS/370 some many years ago.)

Even the Burroughs had multitasking before then, in the early 60s. And how can you not like a system with a "HEYU" instruction to interrupt other processors?

Ever get an answer, or come close to one, as to why it took 35 years?

Before the Internet arrived, very few people had a big need for it. It makes some things marginally harder, and it's more work to implement, so it makes sense that it got left off.

By the time the Internet generally arrived, and people generally realized what the Internet meant, we had accumulated enough backwards compatibility burden that sweeping architectural changes were difficult.

Never had access to those that could give an informed answer. As cliffban says, probably not much of a need. But if I had to pick a reason, and it would be a reason based on no inside knowledge, it's that the 8086 was a stop-gap design until the Intel iAPX 432 came out. The 432 had a lot of capabilities that mainframes took for granted, including segregation between data and executable code. Problem was that the 432 was so over-designed (which made it slow, for one problem) that it never saw production. So everyone just kind of settled on x86 and close to forty years later we're stuck with the 8086 legacy.

Microprocessors were one of those "disruptive" innovations, in that their architectures mostly threw out the previous 30 years of good Engineering design ideas in order to give customers something cheap and immediately useful. Oddly, it's taken another 30 years for microprocessors to reabsorb those ideas.

I disagree - I was a B6700 hack, loved the machine - but code for it was just so non-portable because the machine model was just so non-standard - remember this is a machine (B5000 et al) that depended on the compiler creating correct and sane code not just for system security but system integrity - only 'root' could write compilers and one bad instruction would take the entire system down - it was fragile.

Microprocessors when they first came out were also feeling their way into architecture, Intel sort of headed down the Burroughs tagged capability architecture route - 286 segments, the 960, the 432 et al

But in the long term the PDP11/Vax were more the machines that people loved and their simple memory model (a simple array of bytes) and generic identical registers allowed portable languages and operating systems to flourish - prior to this operating systems were designed for particular hardware platforms - Burroughs MCP was never going to run on any other machine. People forget that the idea of a portable operating system in a time where operating systems were written and were the closed property of hardware manufacturers was a pretty radical idea at the time.

RISC, where simple was beautiful, loved the simple memory/execution models, Unix having grown up on PDP11s and Vaxen was the same.

Intel's through this was bit of a weird duck - they tried everything and failed at many of them - the CISCiest thing imaginable (the 432 a true capability machine) and the 960/860 (both kind of RISCy) all appeared at about the same time - but the 'x86 architecture has walked a pretty magically fine line - in a time of VAX derived CISCy architectures (68k 32k etc) they had a relatively simple memory addressing model (no indirect stuff) and a pretty simply instruction set - in retrospect much more RISCY than it's contemporaries, though missing the generic register file, the 386 eventually adopted the simple linear memory model and tried to forget about all that silly segment stuff and the 64-bit instruction set has moved to a RISCy world - I used to really hate the x86, especially when I wrote compilers, but in retrospect it's mellowed

The thing that microprocessors and the architectural trends they adopted have really done is they've taken us from a proprietary world where nothing was portable, where once you'd bought a system you were a captive customer - to a marketplace with competitive manufacturing and happier consumers

> remember this is a machine (B5000 et al) that depended on the compiler creating correct and sane code not just for system security but system integrity - only 'root' could write compilers and one bad instruction would take the entire system down

This doesn't actually sound like such a bad thing, provided enough processing-power to back it up (i.e. if you had an architecture like this in modernity.)

As as I see it, the problem is, at its core, in having a system call to spawn a process given a file full of (unsafe, unchecked) machine-code. You can avoid this: instead, only have a system call to execute a file of bytecode. Everything in userspace would target that bytecode format as if it were the machine's instruction-set. The kernel would then have to have an interpreter and JIT built into it, and do static safety checking--ala Google's NaCl sandboxing--before it ran the results. Both are CPU-costly, but doable, and the results could be cached.

Of course, root would still have to write the compiler... because the true "compiler"--the one targeting the native machine-architecture--would be the kernel.

So you're using your B6700 as the single big mainframe at your university ('big' is relative here your phone is almost a 1000 times faster and has a 5000 times as much memory and 'disk' storage at one 1,000,000th the price - we bought 1.5Mb for ours for a million dollars)

You're a full professor, very important in the world, and you're running a big multi-hour data analysis run and the compsci student at the terminal next to you is writing a compiler (that would have been me) - every time they test their compiler code the system crashes and scribbles garbage over the hard drive a day later they've recovered the disk and that student is sitting there again ..... you go and see the powers that be

Basically if you wanted to write a compiler for this multi-million dollar platform you needed to have one for yourself ..... only one I know of was written outside Burroughs (UCSD Pascal) - my compilers were all interpreted until we got a Vax

That's what's really stands out to me as foreign in the article - the idea of an entire system consisting of hardware, OS and even applications designed as a unit with no regard for portability, and people considering that a good thing or at least as the normal thing to do.

We've come a long way since then, and in retrospective the most interesting thing about the article may be what it does not mention at all: the IBM PC, released in the previous year, which would go on to establish a mass-market platform where software compatibility became such a strong concern that praise of elegant and innovative hardware details that support a custom OS seem quaint or absurd.

exactly, we're still fighting people trying to create closed wall gardens: iOS, windows, macOS's of various flavours, android to a lesser extent, parts of our phones - places where we're allowed to write apps in frameworks that wont run anywhere else but not operating systems.

To be fair it's used to be impossible to bring a hardware product to market without an OS and at least one compiler, and there were no portable compilers or operating systems when Burroughs, IBM, DEC et al were starting out - OS's and early compilers were often written in assembly, they just weren't going to be portable, and those walled gardens kept captured customers in the fold, you couldn't escape.

Reply on news.ycombinator.com