In 1981, Intel released the iAPX 432
oldbytes.space
oldbytes.space
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
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.
If 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>
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
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 nowhttp://www.bitsavers.org/components/intel/iAPX_432/Organick_...
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.
"iAPX432: Gordon Moore, Risk and Intel’s Super-CISC Failure"
https://thechipletter.substack.com/p/iapx432-gordon-moore-ri...
In general, Intel's history of failed architectures is almost more interesting than its history of winning architectures.
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.
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.
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
EDIT: I think it was Karl (Carl?) something.
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.
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.
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.