3 ms·
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 thi
by Taniwha 13y ago
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
- derefr 13y ago> 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.
- Taniwha 13y agoSo 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
- brazzy 13y agoThat'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.
- Taniwha 13y agoexactly, 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.