7 ms·

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

by kabdib 3y ago

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.

jandrese 3y ago
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.
- Taniwha 3y ago
  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!
  - jandrese 3y ago
    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.
    - twoodfin 3y ago
      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.
  - chx 3y ago
    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. Memorial page with photos: http://hampage.hu/nosztalgia/netto/ursus/index.html 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.
  - aidenn0 3y ago
    The 68k was so much simpler than the 432 that it came out about over a year earlier, despite starting two years later.
    - Taniwha 3y ago
      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 ....
  - cduzz 3y ago
    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.
- WorldMaker 3y ago
  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).
  - jandrese 3y ago
    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.
    - ajxs 3y ago
      > ...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.
- rwmj 3y ago
  The first IBM POWER was also split over several chips (Wikipedia says up to 10! - https://en.wikipedia.org/wiki/POWER1#Physical_description https://en.wikipedia.org/wiki/POWER1#Physical_description)
  - aidenn0 3y ago
    POWER2 was originally multiple chips as well.
- DonHopkins 3y ago
  They should have listened to Ian Dury. https://www.youtube.com/watch?v=Z90nKW8VhhI 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 now
- paul_f 3y ago
  The Fairchild Clipper, released in 1986, was also a 3-chip solution https://en.wikipedia.org/wiki/Clipper_architecture https://en.wikipedia.org/wiki/Clipper_architecture
pkaye 3y ago
I found the book on Bitsavers. http://www.bitsavers.org/components/intel/iAPX_432/Organick_A_Programmers_View_of_the_Intel_432_System_1983.pdf http://www.bitsavers.org/components/intel/iAPX_432/Organick_...

by kabdib 3y ago

jandrese 3y ago

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.

Taniwha 3y ago
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!
- jandrese 3y ago
  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.
  - twoodfin 3y ago
    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.
- chx 3y ago
  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. Memorial page with photos: http://hampage.hu/nosztalgia/netto/ursus/index.html 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.
- aidenn0 3y ago
  The 68k was so much simpler than the 432 that it came out about over a year earlier, despite starting two years later.
  - Taniwha 3y ago
    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 ....
- cduzz 3y ago
  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.
WorldMaker 3y ago
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).
- jandrese 3y ago
  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.
  - ajxs 3y ago
    > ...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.
rwmj 3y ago
The first IBM POWER was also split over several chips (Wikipedia says up to 10! - https://en.wikipedia.org/wiki/POWER1#Physical_description https://en.wikipedia.org/wiki/POWER1#Physical_description)
- aidenn0 3y ago
  POWER2 was originally multiple chips as well.
DonHopkins 3y ago
They should have listened to Ian Dury. https://www.youtube.com/watch?v=Z90nKW8VhhI 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 now
paul_f 3y ago
The Fairchild Clipper, released in 1986, was also a 3-chip solution https://en.wikipedia.org/wiki/Clipper_architecture https://en.wikipedia.org/wiki/Clipper_architecture

pkaye 3y ago

I found the book on Bitsavers. http://www.bitsavers.org/components/intel/iAPX_432/Organick_A_Programmers_View_of_the_Intel_432_System_1983.pdf http://www.bitsavers.org/components/intel/iAPX_432/Organick_...