Awesome, I was really hoping that kens would take a look at the 432 chipset given his experience reversing the 8086 and the fact that the 432 is on a similar Intel HMOS process. Particularly because the 432 has a lot of commentary on why it failed, but unfortunately lacks a lot of hard details on what all it actually was.
If people want to read more, some of the best docs I've found are the academic literature on the chips.
Intel and Microsoft thought so much of the i860's future, it was the architecture Microsoft started developing Windows NT on. Obviously...didn't work out.
The full Intel i960 implementation (i960MX & i960MC variants) was particularly interesting, supporting a capabilities based arch and a lot of built in fault tolerance features. Unfortunately, it got squeezed by the BiiN project going nowwhere in the end, and both the i386 & i860 competing for mindshare within Intel. In the end, they stripped out most/all of the nifty stuff and made a lot of money from i960 as a high-end but pedestrian embedded processor.
The i860 failed for entirely different reasons though. It was really a vector engine that could manage some general compute with some grumbling whereas the 432 was built for general purpose applications written in Ada.
But I guess they did both fail for the same reason: they were more expensive and slower than x86 when running regular applications. Itanium would follow this trend. Come to think of it i860 and Itanium are far more closely related, both suffering greatly from the Intel hardware engineers punting on the difficult instruction scheduling issues with the architecture and the compiler writers not being able to pull the rabbit out of the hat and magically fix those issues. So you have chips that only ever perform properly on trivially parallelizeable tasks and are slow on the vast majority of code.
At the time I worked for a small compiler company (primarily C and secondarily Fortran) that did a port for the i860, but decided not to polish and market it. It was a while ago, but my memory matches what jandrese (parent comment) says.
It's not that it was particularly hard to compile for — it did have specific multiple-issue rules, but we were used to worse from microcode and VLIW targets — but that, outside of a very few arithmetic kernels, real-world code simply did not have enough parallelism for the chip to get anywhere near its paper performance claims. Entering and leaving the multi-flop mode had high latency, and there was so much internal state that interrupts/task-switching were ridiculously expensive. It was predictable that it was not going to be succeed as a general-purpose processor.
The i960 embedded CPU series (that came out at about the same time as the i860) has been called the successor to the iAPX432. It had the same lead designer, and was also intended to run Ada, but except for its use of tagged memory it was a relatively conventional RISC architecture: <https://en.wikipedia.org/wiki/Intel_i960>
I quite liked the i960 at the time. The later implementation, the i960CA, dropped all the capability features but was one of the first, if not the first, commercial microprocessor to offer superscalar execution. This required correct instruction placement, which was fun, but also fun. My vague memory is that real-world code could get something like 25% speedup from automatic scheduling alone, which was a lot better than the internally-competing i860.
I was taking a VLSI design course around that time; our instructor came into class with a fist-size block of plexiglass, with an iAPX 432 chipset embedded in it. A gift from Intel. The chips were HUGE.
I have Elliot Organick's book on the 432. It is not fun reading.
Only one chip wasn't even enough, the amount of die needed and the limited lithography at the time meant Intel had to split it into three huge and expensive chips.
One of the crazier aspects of the design was that the chip design basically required the Ada computer language to take over the world. As far as predictions of the future go that has to be one of the most expensive misses of all time.
Remember that at the time no one put a main-frame class chip on a single die - the 68ks/32ks, and much later 386s were the first generation who managed to pull off putting a large architecture on a chip (I'm trying to make a distinction here between architecture and what particular implementations could do) - in the early 70s mainframes were the size of basketball courts, in the late 70s/early 80s they were the size of a large fridge (and disk drives the size of a washing machine).
So splitting it all in 3 wasn't necessarily the crazy idea we might think it is today - it still all fitted on one circuit board!
It depends on your perspective. From a mainframe/minicomputer standpoint it was pretty good. From the microcomputer perspective it was nuts. Unfortunately for Intel they've always been closely associated with microcomputers so that is the standard by which they were judged.
At the time it wasn’t at all clear that microcomputers and their architecture would graduate from being toys for hobbyists to ruling the computing world. It was assumed in many circles (including Intel, apparently) that minis and mainframes—really, more “modular” less “integrated” architectures—would own the enterprise.
(The dependence on Ada makes a lot more sense in this context: Your mainframe vendor telling you what language you could use wasn’t odd at all in that space.)
DEC also essentially fell victim to this misapprehension, and unlike Intel didn’t have a Plan B.
One of my favorite crazy facts: in 1991 a Hungarian university got an IBM 3090 mainframe as a gift, while outdated it was still insanely more advanced than anything else available in the country. They found a spot on the top floor for it but it was impossible to get it up there so they removed the roof and used a crane.
In 1995, when another university got a VAX 9000 cluster for the bargain basement price of 50 000 CHF (~130 000 USD equivalent today) -- the Swiss basically discarded it as outdated, this truly was cheap -- and they tried to switch it on, it blew the fuse ... of the district. They needed to run a new power line from the nearest substation.
and yet it was a 32-bit core, vax class architecture, so unix was a relatively easy port.
I think the really big problem with the 432 was all that hard wired microcode - rumor has it that it was buggy enough that subroutine calls could take over a millisecond (because they effectively called malloc() which in turn could trigger garbage collection) - stuff that's simply on say a 68k (push the next PC on the stack and jump) becomes a nightmare on a 432 if to fix a bug you need to spin the chip to change the microcode (to be fair at the time rammable microcode was all the rage, but it did take more area and you had to solve the booting problem).
Anyway turning off the interrupts for a millisecond is a non starter for so many microcomputer applications ....
A mainframe style system is a couple of things that the x86 ecosystem is only recently started to get. Some of these (not every "mainframe" had every feature in this list)
* nested virtualization -- anything can run inside anything inception style (IBM; maybe others)
* smart peripherals -- hey storage get me this record! hey terminal send me the whole message when the user's done typing it out! (most of them)
* binary abstraction -- your code is compiled by a bytecode of some sort that's dragged along to abstract decades of underlying hardware changes (IBM, burroughs, probably others)
I think there's a bunch of stuff that's unique to unix that people just presume "this is the way" but since I'm mostly stuck in that universe I can't give a quick overview of all the wonky things that are totally alien to unix but totally normal to other systems.
From my understanding, that wasn't necessarily a bad prediction at the time. Ada was one of the most advanced languages at the time and was built for a lot of things that wouldn't become standard in other languages for decades later in some cases. From that perspective even in hindsight it was very much "the future".
It was built for the US Department of Defense and it is easy to believe that something with US government backing might have massive staying power, even if only just for (sometimes lucrative) defense contracts.
The biggest problem with Ada at the time was how expensive it was to purchase compilers, which is obviously par for the course for something built for defense contracts on a defense budget but would have been a lot harder to swallow for general software companies. Even then there was room to imagine that competitor compilers might be built (especially if you think you've got a chipset designed to make that in theory easy to do by moving many of the language intrinsics/underlying virtual machine directly into hardware as a physical machine).
Ada had a lot of companies that missed the boat on earlier languages seeing their opportunity to really get the monetization right this time. It helped that Ada was so complex that some rando in his basement couldn't write a good compiler for it like they could with C, BASIC, Pascal, Fortran, LISP, etc... It was expensive to develop so it was expensive to purchase. Even better, such a huge compiler for a new language is doomed to be buggy, especially at first, so they can make even more money on expensive support contracts.
The only thing missing was a reason for programmers to switch to it. There were promises that the code would be safe, and that if it compiled it should just work, but the buggy nature of the compilers undercut these promises. Actually, it sounds a lot like Rust minus the buggy compiler part.
The idea that the defense contractors would drive the industry over-estimates just how much code they write. Sure it's millions of lines every year, but compared to worldwide C development it is a drop in the bucket.
> ...some rando in his basement couldn't write a good compiler for it like they could with C, BASIC, Pascal, Fortran, LISP...
I see Ada as having a fundamentally different philosophy from languages like C and BASIC. Ada compilers were allowed to not implement all of the standard library features, and many didn't.
> ...such a huge compiler for a new language is doomed to be buggy, especially at first...
Was this actually what happened though? There was always the Ada Conformity Assessment Test Suite (ACATS), which tested a compiler's implementation. If compilers ever hindered Ada's adoption, it wasn't because they were buggy, it was how expensive and resource intensive they were.
> There were promises that the code would be safe, and that if it compiled it should just work, but the buggy nature of the compilers undercut these promises...
...except that it did kind of work in the end though, didn't it? Ada is still very widely used in a lot of places, and has been for a long time. Lots of new code is still being written in Ada too. There's lots of literature available about how well Ada integrates in environments where code is audited against safety regulations.
> The idea that the defense contractors would drive the industry over-estimates just how much code they write.
This is certainly true now, but was this true when Ada was being designed in the late-70s/early-80s? My understanding is that C didn't become the dominant embedded-systems language until much later. I wasn't there, mind you. I could have some historic details wrong.
Edit: It's worth adding that of the languages the parent poster mentioned above, the only language which still sees mainstream use is C. I know Fortran and LISP have very healthy communities and enjoy a lot of use in niche industries, of course. I don't think this is what the parent poster meant exactly, however it's very common to hear people talk about Ada as a failure on the basis that it didn't completely overtake the software industry. You don't really hear people condemn BASIC, or Pascal in the same way though, even though Ada enjoys much more modern usage.
Even the defense industry is migrating away from Ada. The F-22 Raptor software was mostly written in Ada. The F-35 Lighting II (JSF) software is mostly written in C++. While the JSF program has had some major software delays, overall the choice of C++ seems to have worked out.
This is true. Ironically, when we're talking about an area as heavily regulated as aerospace, I don't think language choice matters as much as it does elsewhere. My understanding is that if you're aiming for certification with a standard like DO-178C and have to demonstrate compliance on a line-by-line basis, ultimately only compliance matters, not what language it's written in. Some languages will achieve that result more easily than others though. Someone please correct me if I'm off track here.
While I never programmed Ada myself (there were no compilers I could afford), the people I knew who did complained bitterly that the compiler was always tripping over itself and making their life difficult. Well, even more difficult since they were stuck writing Ada. This was the late 90s though, so the situation hopefully improved over time.
> The idea that the defense contractors would drive the industry over-estimates just how much code they write. Sure it's millions of lines every year, but compared to worldwide C development it is a drop in the bucket.
The implication I was making, in case it wasn't overt enough, had a lot more to do with money/budget/revenue than lines of code. The US DOD has massive budgets and over-spends those budgets on all kinds of wild things (so long as they can pass Congressional oversight, at least). The amount of money the US DOD spends on defense contractors will always attract a lot of attention, even if the amount of code that the US DOD gets back from all that spending will always be a drop in the bucket to the overall software industry.
A different, unrelated, implication that is often used is that the DOD has increased requirements for safety, security, and oversight and that "defense-grade" or "defense-level" signifies something stronger than consumer-grade. You can see some of that in the 432's attempted marketing: imagine having access to "defense-grade" Ada-capable hardware in the microcomputer form factor at a fraction of then-current mainframe costs. Of course, in reality, not everyone needs "defense-grade" and the "dream" of using the same language and similar tools to the US DOD never had quite the appeal that Intel marketers must have hoped for. But you can certainly see why Intel marketers might have thought there some advantage in "defense grade".
The US DOD and its defense contractors have never exactly "led" the industry, but they've certainly had a large shadow over of it for most of computing history. (Says the person sending this little collection of thoughts and opinions over a vast and incredible inter-network of networks that began as a Defense advanced research project.)
The history had shown that the industry would produce a great number of programming language and a great number of different OSs. The idea that one language would dominate everything is really questionable, specially because things like Unix and VMS were already now written in Ada. And there was no real OS for Ada as far as I know.
Adding some special instructions for Ada might be reasonable, but betting your future on a single programing language dominating everything is beyond bold.
Moments of sadness, moments of guilt
Stains on the memory, stains on the quilt
Chapter of incident, chapter and verse
Sub-heading chronic, paragraph worse
Lost in the limelight, backed in the blaze
Did it for nine pence, those were the days
Give me my acre and give me my plough
Tell me tomorrow, don't bother me now
That was the starting point of my undergraduate independent seminar topic.
Back then the complexity was even more mind-boggling, as I had barely any appreciation of the object-oriented world, and the idea of pushing all that into the micro-architecture was really hard to get my mind around, let alone talking about it to a class full of fellow students.
Author here if there are any questions. Also, if anyone happens to have other iAPX 432 chips sitting around, I'd be happy to take high-resolution die photos. There aren't good 432 die photos around, so I was happy to get access to the 43201 chip.
Just wanted to say that I love your content and look forward to new stuff. Thanks so much for putting the effort forward that you do! I’ve learned tons of the years following you :) greatly appreciate it.
Favorite bit: "What if the 432 had won? Computing would be very different. Many security problems wouldn't exist. You can't have a buffer overflow because every data structure is a separate object with memory segment size enforced in hardware. You can't smash the stack or make bad pointers."
In the early 80s, speed was everything and security a non-issue. LANs hadn't even taken off yet, let alone the internet. But that's almost flip-flopped today.
I'm really curious at this point what would happen if someone tried to resurrect a design like the 432. Maybe not the 432 exactly because things like bit-aligned instructions are still awkward/weird and didn't turn out to be as useful as the designers hoped. (It seems like an obvious compromise because object-tagging taking so much RAM in an era where RAM was so expensive it is an easy bet that they felt a need to nickel and dime/golf program code size, if they could.)
But even just reusing the architecture as-was, it would certainly be cheaper and need fewer chips today. It might be fun to have a cheap Raspberry Pi-like board with a 432 to experiment coding against.
The ironic thing is that the performance analysis paper [*] found that the weird bit-aligned instructions iAPX 432 didn't actually help code size.
"Although the 432 has bit-variable length instructions, it requires more space than either the 68000 in Pascal or the VAX in C. Reasons include the lack of immediates and the inability to refer to a local variable or constant using fewer than 16 bits of address."
(From a modern perspective, the test programs are absurdly small: 120-2900 bytes. Nowadays, you probably couldn't even create a program that small.)
Well, I can make a guess: the experience of porting existing C code to it would be a horrible experience so it would never take off the ground because, you know, nobody ain't got time to rewrite the whole world from scratch.
My curiosity has nothing to do with running existing C code. The reference to Raspberry Pi should have made that obvious, I think. The idea would be to have something to play with as a hobbyist. Something to develop new compilers for to see what you can build and if what you can build is fun/interesting, even if it doesn't have commercial aspirations or "productive" uses and is only ever a "toy". You know, hobbyist fun.
That is something that I know. That is why I suggested it might be cheap to explore the concept (at the bottom of my post) and part of why I'm curious to see others try. I personally have college experience in FPGA prototyping but primarily have focused my efforts on software development then and since, I wouldn't have much fun myself building an FPGA prototype of something like the 432 by myself. But if someone sent me a cute RPi-like board and an okay (doesn't have to be great) assembler/debugger for it, I'd certainly give it a try seeing if I could assemble something interesting like a compiler for a next higher-level language. If that same someone were to build enough of the boards to build an entire community of hobbyist developers more than just me, that would be even better and really interesting and the biggest reason to mention it as a curiosity on a site like this, not to do a one-off thing to scratch a personal itch but to wonder what a community of hobbyists could do together as a group.
I have wondered the same thing. I would adore to have the knowledge to resurrect stuff like this. Something I’ve always wanted to do is revamp ISAs like the 432 or DEC J-11 etc. on modern process nodes and see what kind of performance could be eked out.
What would have actually happened is once the first programmer realised you could get a speed bump by putting all your objects inside a single segment, we'd have been back to where we are now. Which is roughly what happened to the 286 which borrowed some of the 432 concepts -- every practical OS ignored the call gates, segments, and all but two of the rings.
The state of liability for insecure software in America is woefully bad.
You’re not going to be able to apply breach of warranty under UCC. As a threshold matter, software might not even be considered a “good” and so it might not even governed by UCC. But if you did manage to apply UCC to software, the contract or license under which software is provided would have to be incompetently drafted if it were to be found that it did not effectively disclaim liability or if it was found unconscionable. There are some additional procedural hurdles concerning probity of contract but let’s leave it there
Under basic tort law, a software provider would need to be found to have a duty of care in order to be found negligent, but surprisingly, this is seldom found to exist. There is also no clear standard to measure whether a software provider may have breached that duty. Intervening or superseding cause exists in almost every breach, although for security-specific software, this might not be the case (e.g., a firewall fails open might be reasonably foreseeable to cause damage by means of a hacker, against whom the firewall is meant to protect).
Finally even if you get to this point, recovery may be barred or limited by the economic loss doctrine.
Defective product law is even worse, due to the (inscrutable) fact that while most courts would call software a good for UCC purposes, they would not call it a product for the purposes of product defect law. There are some additional wrinkles here concerning design of software versus manufacture of software in the context of defective product design law, but we’re starting to wander out of HN post territory and into CLE territory here.
Frankly if Joe Biden wanted to change every thing I just red it would be superb but I think we have to be realistic about how much influence the federal government can apply here without causing massive terrible second and third order effects. For example look back to 43 and Obama’s heavy reliance on cybersecurity insurance to advance national security interests and how quickly that turned into free payouts for everyone who could manage to get a random reared out to work.
"A consequence of this principle is that every occurrence of
every subscript of every subscripted variable was on every
occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they
urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have
long been against the law."
On a side note, my dad observed that when he was getting his Master's degree in CS, they had to read Hoare's CSP paper. He said the class was divided into two groups: those who didn't understand it, and those who thought the problems with mutable-by-default multithreading could be solved with proper programmer discipline.
I might argue that those who thought the problems with mutable-by-default multithreading could be solved with proper programmer discipline also didn't understand it.
But it can be solved trivially with proper discipline. ‘Mutable by default’ implies there’s a way to make things immutable, and proper discipline can make everything immutable.
The problem is that no human can maintain proper discipline at all times, and it takes only one slip to create a bug.
And yes, programmers doing that would soon realize that ‘immutable by default’ leads to a better UX of a programming language. It’s way easier to be alerted by a warning ‘mutable’ keyword than by a missing ‘immutable’ one)
That’s why we should have linters that flag all missing ‘immutable’ annotations or incorrect usage of ‘mutable’ ones. Rust even adds something like that to the language.
My brother worked there at the time. He wanted in on the project, but Intel mgmt had already begun to pull back from it, controlling costs.
I recall him saying at the time, "A JMP . instruction takes 500 machine cycles". This was apparently because it was largely an interpreter - the 'assembly' wasn't run in hardware but some kind of firmware. I suppose the OP covered all that.
Implementing a CPU by writing an interpreter in lower level microcode is a obvious implementation strategy for CISC ISAs. But the mechanism how modern OoO x86 CPUs (and even many notionally RISC CPUs) works is different: The incoming instruction stream is converted into internal “more RISC” uOps and these are then executed by the OoO pipeline, this happens almost entirely in hardware (and on current x86 implementations with somewhat incredible amount of parallelism) and can in fact even combine multiple instructions into one uOp (or even completely discard an instruction). There is usually some microcode, but this is there to handle instructions that cannot be efficiently mapped to block of the uOps (too much work done in one instruction, interestingly ARM has bunch of such cases) and to handle interrupt and exception handling.
Someone observed to me once that the dominance of ARM has proven both the CISC and RISC sides wrong as ARM has fairly intermediate complexity instructions.
Actually I've previously made the same claim about the x86 ....
I'd argue that of all its generation of CISCS (vax/68k/32K/etc) it was the most RISCy (apart from the microcoded segment crud) almost all it's instructions make at most a single memory reference (push/pop are the exceptions) and so are trivially restartable if there's a TLB fault (look at the CRUD! a 68020 throws on the stack, a vax could touch something like 20 pages in one poly instruction) - x86 has no indirect addressing modes, few side effects (no auto increment/decrement except for push/pop)
I think that this is one of the reasons why x86 is still with us, it's relatively easy to decompose an x86 instruction into RISCy uops and do OoO/etc
There is usually some microcode, but this is there to handle instructions that cannot be efficiently mapped to block of the uOps
I believe the microcode is actually used to generate uops which go into the OoO pipeline too, for when there's too many uops for the decoder to generate directly.
When I was at UCB I was roommates with a grad student working on/with (not sure which) the 432. I was learning CS at the time and what he described did seem like a wild alternate universe of computing.
Not one of those people... honestly, having trouble remembering his name now, but I would recognize it if I saw it. And, I know Dave Patterson wasn't my roommate. :) His office was just down the hall, though, when I was at UCB.
well sort of, similar stuff ... though it's worth remembering that Burroughs security depends on only specially blessed programs called 'compilers' being able to make code - because the underlying architecture has no real protection, it depends on compiled code playing well with the hardware.
There are all these special hardware descriptors and stuff so that you can't step out of arrays, but there's also an instruction you can execute that will blindly make one (and there's one available to every process that describes all of memory ....).
As I said system integrity and system security depends on people not being able to make arbitrary code, only a privileged user can make code a compiler, and only a compiler can make a code file ....
The 432 had a lot of similar data structures but genuinely did have the security and integrity one would expect from a capability system
Sounds like Midori/Singularity. Or like any of Per Brinch Hansen's OSes, written in concurrent dialects of Pascal and depending on the language-level constructs for memory protection and process separation (they could and did run on machines without MMUs).
The old Burroughs systems (up to at least the B7700) didn't really have MMUs in the traditional sense - their descriptors only reserved 20 bits for (word addresses) so they were limited to ~6Mb of addressing - not a big deal when we had paid over a US$ million for 1.5Mb of B6700 core, no one could have afforded more - they paged segments (much as a 432 would have) and also supported segments chunked into 256 word chunks for large arrays (at the cost of an extra memory access per lookup).
The days of Byte Magazine where people and esp venture capitalists funded and the market had space for all sorts of new ideas like the Amiga.
My favourite one was a 3 chip Object Oriented system called Objekt,Numerik and something else by Hifi manufacturer Linn - the owner at the time loved the Vaxen running his factory and funded a new architecture.
The fixation with the letter "k" I found rather intriguing.
The four chip system you are thinking of was the Logik, Objekt, Numerik, and Klock chips that made up Rekursiv [1]. There was some crazy backstory to it that I read up on a few years ago, which I no longer remember, but I do remember it was outlandish.
Yeah the owner of Linn at the time wanted something to replace the Vaxen in his factories and he did not like the direction DEC was going (Alpha) and funded two Comp Sci professors to do a new bespoke full OO design.
From reading it only reached a prototype state in software on a Sun 3 Workstation and some logic boards but then Linn ran into some financial difficulties and it was cancelled.
If you can get your hands on the book they published about it (titled "Rekursiv") you should give it a read. It's written in a fun style and is actually quite interesting
Yeah, that's where I got this stuff from. I'm debating re-reading it now that I know something about this stuff: I originally looked at it as a clueless undergrad.
Any discussion of the iAPX 432 should mention IBM's earlier stab at building a minicomputer around a single-level object store hardware architecture - the System 38. It too struggled in the market, although being a sibling of the system 3X -> AS/400 line, didn't die quite as ignominiously as the iAPX 432.
The 97,000 transistor count number is from Wikipedia. The number appears to be fictional and doesn't match other sources so I marked it as [citation needed].
103 comments
[ 1.6 ms ] story [ 255 ms ] threadIf people want to read more, some of the best docs I've found are the academic literature on the chips.
Instruction Decoder: https://doi.org/10.1109/JSSC.1981.1051633
Execution Unit: https://doi.org/10.1109/JSSC.1981.1051631
Interface Processor: https://doi.org/10.1109/JSSC.1981.1051632
<https://homes.cs.washington.edu/~levy/capabook/Chapter9.pdf>
0: https://en.wikipedia.org/wiki/Intel_i860
In general, Intel's history of failed architectures is almost more interesting than its history of winning architectures.
[1] https://en.wikipedia.org/wiki/IA-64
But I guess they did both fail for the same reason: they were more expensive and slower than x86 when running regular applications. Itanium would follow this trend. Come to think of it i860 and Itanium are far more closely related, both suffering greatly from the Intel hardware engineers punting on the difficult instruction scheduling issues with the architecture and the compiler writers not being able to pull the rabbit out of the hat and magically fix those issues. So you have chips that only ever perform properly on trivially parallelizeable tasks and are slow on the vast majority of code.
https://thechipletter.substack.com/p/iapx432-gordon-moore-ri...
https://news.ycombinator.com/item?id=35412342
I have Elliot Organick's book on the 432. It is not fun reading.
One of the crazier aspects of the design was that the chip design basically required the Ada computer language to take over the world. As far as predictions of the future go that has to be one of the most expensive misses of all time.
So splitting it all in 3 wasn't necessarily the crazy idea we might think it is today - it still all fitted on one circuit board!
(The dependence on Ada makes a lot more sense in this context: Your mainframe vendor telling you what language you could use wasn’t odd at all in that space.)
DEC also essentially fell victim to this misapprehension, and unlike Intel didn’t have a Plan B.
Memorial page with photos: http://hampage.hu/nosztalgia/netto/ursus/index.html
In 1995, when another university got a VAX 9000 cluster for the bargain basement price of 50 000 CHF (~130 000 USD equivalent today) -- the Swiss basically discarded it as outdated, this truly was cheap -- and they tried to switch it on, it blew the fuse ... of the district. They needed to run a new power line from the nearest substation.
I think the really big problem with the 432 was all that hard wired microcode - rumor has it that it was buggy enough that subroutine calls could take over a millisecond (because they effectively called malloc() which in turn could trigger garbage collection) - stuff that's simply on say a 68k (push the next PC on the stack and jump) becomes a nightmare on a 432 if to fix a bug you need to spin the chip to change the microcode (to be fair at the time rammable microcode was all the rage, but it did take more area and you had to solve the booting problem).
Anyway turning off the interrupts for a millisecond is a non starter for so many microcomputer applications ....
* nested virtualization -- anything can run inside anything inception style (IBM; maybe others)
* smart peripherals -- hey storage get me this record! hey terminal send me the whole message when the user's done typing it out! (most of them)
* binary abstraction -- your code is compiled by a bytecode of some sort that's dragged along to abstract decades of underlying hardware changes (IBM, burroughs, probably others)
I think there's a bunch of stuff that's unique to unix that people just presume "this is the way" but since I'm mostly stuck in that universe I can't give a quick overview of all the wonky things that are totally alien to unix but totally normal to other systems.
It was built for the US Department of Defense and it is easy to believe that something with US government backing might have massive staying power, even if only just for (sometimes lucrative) defense contracts.
The biggest problem with Ada at the time was how expensive it was to purchase compilers, which is obviously par for the course for something built for defense contracts on a defense budget but would have been a lot harder to swallow for general software companies. Even then there was room to imagine that competitor compilers might be built (especially if you think you've got a chipset designed to make that in theory easy to do by moving many of the language intrinsics/underlying virtual machine directly into hardware as a physical machine).
The only thing missing was a reason for programmers to switch to it. There were promises that the code would be safe, and that if it compiled it should just work, but the buggy nature of the compilers undercut these promises. Actually, it sounds a lot like Rust minus the buggy compiler part.
The idea that the defense contractors would drive the industry over-estimates just how much code they write. Sure it's millions of lines every year, but compared to worldwide C development it is a drop in the bucket.
I see Ada as having a fundamentally different philosophy from languages like C and BASIC. Ada compilers were allowed to not implement all of the standard library features, and many didn't.
> ...such a huge compiler for a new language is doomed to be buggy, especially at first...
Was this actually what happened though? There was always the Ada Conformity Assessment Test Suite (ACATS), which tested a compiler's implementation. If compilers ever hindered Ada's adoption, it wasn't because they were buggy, it was how expensive and resource intensive they were.
> There were promises that the code would be safe, and that if it compiled it should just work, but the buggy nature of the compilers undercut these promises...
...except that it did kind of work in the end though, didn't it? Ada is still very widely used in a lot of places, and has been for a long time. Lots of new code is still being written in Ada too. There's lots of literature available about how well Ada integrates in environments where code is audited against safety regulations.
> The idea that the defense contractors would drive the industry over-estimates just how much code they write.
This is certainly true now, but was this true when Ada was being designed in the late-70s/early-80s? My understanding is that C didn't become the dominant embedded-systems language until much later. I wasn't there, mind you. I could have some historic details wrong.
Edit: It's worth adding that of the languages the parent poster mentioned above, the only language which still sees mainstream use is C. I know Fortran and LISP have very healthy communities and enjoy a lot of use in niche industries, of course. I don't think this is what the parent poster meant exactly, however it's very common to hear people talk about Ada as a failure on the basis that it didn't completely overtake the software industry. You don't really hear people condemn BASIC, or Pascal in the same way though, even though Ada enjoys much more modern usage.
The implication I was making, in case it wasn't overt enough, had a lot more to do with money/budget/revenue than lines of code. The US DOD has massive budgets and over-spends those budgets on all kinds of wild things (so long as they can pass Congressional oversight, at least). The amount of money the US DOD spends on defense contractors will always attract a lot of attention, even if the amount of code that the US DOD gets back from all that spending will always be a drop in the bucket to the overall software industry.
A different, unrelated, implication that is often used is that the DOD has increased requirements for safety, security, and oversight and that "defense-grade" or "defense-level" signifies something stronger than consumer-grade. You can see some of that in the 432's attempted marketing: imagine having access to "defense-grade" Ada-capable hardware in the microcomputer form factor at a fraction of then-current mainframe costs. Of course, in reality, not everyone needs "defense-grade" and the "dream" of using the same language and similar tools to the US DOD never had quite the appeal that Intel marketers must have hoped for. But you can certainly see why Intel marketers might have thought there some advantage in "defense grade".
The US DOD and its defense contractors have never exactly "led" the industry, but they've certainly had a large shadow over of it for most of computing history. (Says the person sending this little collection of thoughts and opinions over a vast and incredible inter-network of networks that began as a Defense advanced research project.)
Adding some special instructions for Ada might be reasonable, but betting your future on a single programing language dominating everything is beyond bold.
https://www.youtube.com/watch?v=Z90nKW8VhhI
http://www.bitsavers.org/components/intel/iAPX_432/Organick_...
Back then the complexity was even more mind-boggling, as I had barely any appreciation of the object-oriented world, and the idea of pushing all that into the micro-architecture was really hard to get my mind around, let alone talking about it to a class full of fellow students.
"iAPX432: Gordon Moore, Risk and Intel’s Super-CISC Failure"
The thread is also on Twitter: https://twitter.com/kenshirriff/status/1649075486008524801
I think it was Oxide and Friends episode on SPARC but not sure.
In the early 80s, speed was everything and security a non-issue. LANs hadn't even taken off yet, let alone the internet. But that's almost flip-flopped today.
But even just reusing the architecture as-was, it would certainly be cheaper and need fewer chips today. It might be fun to have a cheap Raspberry Pi-like board with a 432 to experiment coding against.
"Although the 432 has bit-variable length instructions, it requires more space than either the 68000 in Pascal or the VAX in C. Reasons include the lack of immediates and the inability to refer to a local variable or constant using fewer than 16 bits of address."
(From a modern perspective, the test programs are absurdly small: 120-2900 bytes. Nowadays, you probably couldn't even create a program that small.)
[*] https://archive.org/details/PerformanceEvaluationOfTheIntelA...
I know it's not what you are looking for since it's not making nearly enough bounds checks. I thought I'd drop a mention since it's widely available.
https://www.sonatype.com/national-cybersecurity-strategy-wha...
https://digital-strategy.ec.europa.eu/en/library/cyber-resil...
The rest will follow.
> Shifting liability for software products and services to promote secure development practices; and,
You’re not going to be able to apply breach of warranty under UCC. As a threshold matter, software might not even be considered a “good” and so it might not even governed by UCC. But if you did manage to apply UCC to software, the contract or license under which software is provided would have to be incompetently drafted if it were to be found that it did not effectively disclaim liability or if it was found unconscionable. There are some additional procedural hurdles concerning probity of contract but let’s leave it there
Under basic tort law, a software provider would need to be found to have a duty of care in order to be found negligent, but surprisingly, this is seldom found to exist. There is also no clear standard to measure whether a software provider may have breached that duty. Intervening or superseding cause exists in almost every breach, although for security-specific software, this might not be the case (e.g., a firewall fails open might be reasonably foreseeable to cause damage by means of a hacker, against whom the firewall is meant to protect).
Finally even if you get to this point, recovery may be barred or limited by the economic loss doctrine.
Defective product law is even worse, due to the (inscrutable) fact that while most courts would call software a good for UCC purposes, they would not call it a product for the purposes of product defect law. There are some additional wrinkles here concerning design of software versus manufacture of software in the context of defective product design law, but we’re starting to wander out of HN post territory and into CLE territory here.
Frankly if Joe Biden wanted to change every thing I just red it would be superb but I think we have to be realistic about how much influence the federal government can apply here without causing massive terrible second and third order effects. For example look back to 43 and Obama’s heavy reliance on cybersecurity insurance to advance national security interests and how quickly that turned into free payouts for everyone who could manage to get a random reared out to work.
"If you outlaw freedom, only outlaws will have freedom."
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
C.A.R. Hoare in his 1980's Turing Award speech.
In 1988, Morris Worm takes over UNIX
https://en.m.wikipedia.org/wiki/Morris_worm
The problem is that no human can maintain proper discipline at all times, and it takes only one slip to create a bug.
And yes, programmers doing that would soon realize that ‘immutable by default’ leads to a better UX of a programming language. It’s way easier to be alerted by a warning ‘mutable’ keyword than by a missing ‘immutable’ one)
That’s why we should have linters that flag all missing ‘immutable’ annotations or incorrect usage of ‘mutable’ ones. Rust even adds something like that to the language.
I agree, those programmers should be properly flogged.
I recall him saying at the time, "A JMP . instruction takes 500 machine cycles". This was apparently because it was largely an interpreter - the 'assembly' wasn't run in hardware but some kind of firmware. I suppose the OP covered all that.
I'd argue that of all its generation of CISCS (vax/68k/32K/etc) it was the most RISCy (apart from the microcoded segment crud) almost all it's instructions make at most a single memory reference (push/pop are the exceptions) and so are trivially restartable if there's a TLB fault (look at the CRUD! a 68020 throws on the stack, a vax could touch something like 20 pages in one poly instruction) - x86 has no indirect addressing modes, few side effects (no auto increment/decrement except for push/pop)
I think that this is one of the reasons why x86 is still with us, it's relatively easy to decompose an x86 instruction into RISCy uops and do OoO/etc
I believe the microcode is actually used to generate uops which go into the OoO pipeline too, for when there's too many uops for the decoder to generate directly.
EDIT: I think it was Karl (Carl?) something.
Well, two chips actually, but the idea is the important thing.
But yeah I can see the resemblance, what Algol was to the Burroughs Ada was to the Intel 432
There is a fun web based Burroughs B5500 emulator. Totally worth it to spend an evening running through the boot procedure.
http://phkimpel.us/B5500/webUI/B5500Console.html
There are all these special hardware descriptors and stuff so that you can't step out of arrays, but there's also an instruction you can execute that will blindly make one (and there's one available to every process that describes all of memory ....).
As I said system integrity and system security depends on people not being able to make arbitrary code, only a privileged user can make code a compiler, and only a compiler can make a code file ....
The 432 had a lot of similar data structures but genuinely did have the security and integrity one would expect from a capability system
My favourite one was a 3 chip Object Oriented system called Objekt,Numerik and something else by Hifi manufacturer Linn - the owner at the time loved the Vaxen running his factory and funded a new architecture.
The fixation with the letter "k" I found rather intriguing.
[1] https://en.wikipedia.org/wiki/Rekursiv
From reading it only reached a prototype state in software on a Sun 3 Workstation and some logic boards but then Linn ran into some financial difficulties and it was cancelled.