iAPX The first time Intel tried to kill x86 

5:23 Ada was designed for writing highly reliable code that could be used in safety-critical applications. Fun fact: the life-support system on the International Space Station is written in Ada, and runs on ancient Intel 80386 processors. So human lives depend on the reliability of all that.

4:42 Ada didn't program the difference engine, which was built after her death, because that wasn't programmable. The difference engines works by repeatedly calculating using finite differences. Ada wrote a program for the analytical engine, a more advanced Babbage design that would've been the first programmable computing machine.

Actually, Microsoft didn't write DOS. They bought QDOS from Seattle Computer Products after they had told IBM they had an OS for the 8088.

The 68000 was a nice chip! It has hardware multiply and divide. An assembly programmer's dream. I know, because I coded in Z-80 and 8080 Assembly. Good reporting!

It wasn't just that the processor returned by value. Values were literally wrapped in system objects, each with all sorts of context wrapped around it. You put all this together, and you'd have a subroutine exit take hundreds of nanoseconds. This is when all the system designers who WERE interested in this, tell the Intel Rep, "This is garbage." and leave the room.

Ha, great video. I love the hilarious background footage... that tape drive at 2 mins in looks like it's creasing the hell out of the tape. And lots of Pet and TRS-80 footage too!

Intel would use the term iAPX286 to refer to the 80286, along with the 432 in sales literature. Intel had intended the 286 for small to medium time sharing systems (think the ALTOS systems), and did not have personal computer use anywhere on the radar. It was IBM's use in the AT that changed this strategy.

One more thing that really hurt the 432's performance was the 16 bit packet bus. This was a 32 bit processor, but used only 16 lines for everything. Reading a word from memory meant sending the command and part of the address, then the rest of the address, then getting half of the data and finally getting the rest of the data. There were no user visible registers so each instruction meant 3 or 4 memory accesses, all over these highly multiplexed lines.

That programming reminds me very much like a "professional" I used to know ; he worked on a Navy base, and wrote his own code. Professional, in this case, meant he received a paycheck.. The dataset came from COBOL - very structured, each column with a specific set of codes/data meaning something.. He wrote some interpreted Basic code to break down the dataset. It went like this: He would first convert the ascii character into a number. There's 26 lower case characters, and 26 uppercase characters, and 10 digits ( zero thru nine ). So first he converted the single ascii character into a number. Then he used 62 If ... then statements to make his comparison. Mind you, it had to go thru ALL 62 if then statements. This was done for several columns of data PER line, so this really stacked up on instructions carried out. Then based upon the output, he'd reconvert the ascii code back to a character or digit, using another 62 if then statements. And there was like 160 columns of data for each line of the report he was processing.. With a single report consisting of a few thousand lines all the way up to a few hundred thousand rows. Needless to say, with all of the if then statements ( not if -then - else ) it was painstakingly slow. A small report might take 2 to 3 hours to process; larger reports- well, we're talking an all day affair; with ZERO output till it was completed; so for most that ran it, they thought that the code had crashed. In comparison, I wrote a separate routine using Quick Basic, from scratch, not even knowing his code existed, using on...gosub and on .. goto statements, with complete report taking about 1 1/2 minutes, with the every tenth line output to screen so one knew that it was actually working. Only later did I find out his code already existed, but no one used due to how long it took to run. Prior to this, the office in question had 8 to 10 people fully engaged, 5 to 6 days a week, 8 to 10 hours a day, manually processing these reports, reading the computer printouts, and transferring the needed rows to another report, by hand, on electric typewriters. Yes, this is what they did... as stupid as that seems...

The 8086/8088 was a stopgap stretch of the 8 bit 8080, started as a student project in the middle of iAPX development. iAPX was taking too long, and interesting 16 bit devices were being developed by their competitors. They badly needed that stopgap. A lot of the most successful CPU designs were only intended as stopgap measures, while the grand plan took shape. The video doesn't mention the other, and more interesting, Intel design that went nowhere - the i860. Conceptually, that had good potential for HPC type applications, but the cost structure never really worked.

Have you ever heard the tragedy of iAPX the Slow? I thought not, it's not a story Intel would tell. Very great video, loved it.

I'm guessing one of the subsequent attempts at intel shooting itself in the foot would be the 1989 release of the i860 processor. For this one they decided that the 432 was such a disaster that what they needed to do was the exact opposite - to implement a RISC that would make any other RISC chip look like a VAX. So we ended up with a processor where the pipelines and delays were all visible to the programmer. If you issued an instruction the result would only appear in the result register a couple of instructions later and for a jump you had to remember that the following sequential instructions were still in the pipeline and would get executed anyway. Plus context switch state saves were again the responsibility of the programmer. This state also included the pipelines (yes there were several) and saving and restoring them were your job. All this meant that the code to do a context switch to handle an interrupt ran into several hundred instructions. Not great when one of the use cases touted was real time systems. Again intel expected compiler writers to save the day with the same results as before. On paper, and for some carefully chosen and crafted assembly code examples, the processor performance was blistering. For everyday use less so, and debugging was a nightmare.

Back in 1980 I was off to University to do a Computer Science degree, and was also building a computer at the same time - I]d been mucking about with digital electronics for a number of years and with the confidence of a teenager that didn't know if he had the ability to do so, I had designed several processor cards based on the TMS9900, 6809 and others (all on paper, untested!) and had read about the iAPX 432 in several trade magazines, and was quite excited by the information I was seeing, although that was marketing mostly. I tried getting more technical data through the Universiity (because Intel wouldn't talk to hobbyists!) but found information thin on the ground, and then six months or so later all the news was basically saying what a lemon the architecture was, so I lost interest as it appears the rest of the world did. About a decade later my homebrew computer booted up with its 6809 processor, I played with it for a few weeks, then it sat in storage 20 years, because "real" computers didn't require me to write operating systems, compilers etc :D

Intel building the iAPX: Oh no this massively complicated large-die CPU with lots of high-level language support that relies on the compiler to be good *sucks* Intel 20 years later: What if we built a massively complicated large-die CPU with lots of high-level language support that relies on the compiler to be good?

Allegedly the "X" stood for arCHItecture, as in the Greek letter. Feels like it's grasping for straws though.

IBM ultimately chose the 8088 because it meant that the I/O work that had been done on the Datamaster/23 could be lifted and brought over. (No joke, this was the tie-breaker)

Someone I knew in my area had a type ofAXP development machine. And he remarked its performance was very under rated, and that it had IPC higher than a 386 when coded properly. And estimated a single chip derivative with tweaks could out perform a 486 or 68040 in IPC. Sadly he developed dementia and passed away about 10 years ago. And I have never been able to track the hardware down or what happened to it. He had one of the most exotic collections I had ever seen. And he was a very brilliant man before mental illness overtook him. I only got to meet him at the tale end of his lucidity which was such a shame.

You forgot the 80186 processor! Not used in a PC. But it was a huge failure couldn’t jump back out of protected mode. This needs a reboot!

Burroughs was the first to feature compiler friendly hardware architecture in the B5000 model. it also was the first to feature virtual memory architecture. As a result, huge teams of software developer were not needed to implement Algol-60 and other major compilers with great reliability and efficiency. Eventually, Burroughs was able to implement the architecture in IC chips.

You should do an episode on the Intel 860 and 960. I’m remember them being interesting processors but never saw anything use them

I've seen a bunch of videos on itanium. But this is the first time I've ever even heard of iAPX. There's not a lot of videos on these lesser known topics from the early days of home computing so I appreciate the history videos you've done.

Yet again a super interesting video. Thank you. I had no idea that this processor existed.

Intel did do another O/S called RMX (stood for Real-time Muti-tasking Executive ) was used extensively with their range of multibus boards. It was powerful and popular in control systems ( like factory automation ) There was also ISIS which was used on the Intel development systems. I use to service these and were a major tool for BT, Marconi’s, IBM, and anyone wanting to develop a system to use a microprocessor as they had In Circuit Emulators ( ICE ) units that enabled developers to test their code before they had proper hardware or to test their hardware as you could remove the processor and run and debug your code instruction by instruction. During the early 80’s there was a massive rush to replacement legacy analogue systems with digital equipment controlled by a microprocessor and intel had development systems, their ICE units and various compilers ( machine code level, PL/M, Pascal, C, to name a few ) so a hardware engineer could develop his code and test it quicker than most of the competitors. Fond memories going to factories where they were putting their first microprocessor in vending machines, petrol pumps, cars, etc. One guy developing his coke dispensing machine wanted a way of networking all the machines ( no internet then ) and have them as a super-computer calculating Pi as they would be spending most of their life doing nothing.

I attended a presentation in Portland Oregon where Intel engineers were extolling features of iAPX 432. I remember they discussed how its hardware supported garbage collection addressed a key aspect of running programs written in high level languages. During the Q&A afterwards, someone asked about its reported disappointing performance numbers. Their response didn't refute or address that issue.

Having done ASM for a 286 and a 68000 at university, I have to say, at the time I preferred the 68000.

An expensive arch with an inordinate dependency on an a magic compiler that never worked? It's the Itanium's granddaddy. x86 was never intended to do what it ended up doing, which is why Intel kept trying to replace it. Too bad the bandaids were so effective as to render most attempts futile. The i860 was Intel's next attempt after the iAPX, a pure RISC design this time, but this also failed for a variety of reasons. The APX wasn't unique in using multi-chip CPUs (multi-chip and discrete logic-based CPU modules were common in mainframes such as the System/360) but in minis and micros they weren't ideal and they certainly would've needed to consolidate to single-chip implementations ASAP to keep up with chips (in both performance and price) such as the 68k and especially the RISC designs that were less than a decade off. Also, this wasn't the only arch that tried to run a high-level language directly: AT&T's CRISP-based Hobbit chips ran C (or they did until development was canceled).

i really enjoy these videos i have a bit of knowledge, problem solving repairs and builds but these vids do make a nice introduction to some more complex topics, thank you.

Seems like they didn’t learn their lessons of “letting the compiler do the thing” when they did Itanium.

The iAPX was actually one of the first commercial capability architectures. See contemporary efforts such as CHERI. You might consider a future video on that aspect of the architecture. While it failed, it was ahead of its time in other respects.

My first job was programming Ada for Ready System’s VRTX operating system, targeting Motorola 68000 VME boards. That’s is some retro tech soup. Killing the x86 would have done us a favour really, the fact we are stuck on it in 2022 is a bit of tech failure IMO. I’m glad there is real competition now from ARM-based CPUs.

love the channel.these deep dives on obscure cpus are great. any chance you could do a deep dive on the i860 and the ncube hypercube?

The X in "Architecture" is both silent and invisible.

Love your content and presentation style.

This channel is awesome, so much history I even didn’t know about.

Woo hoo! Thanks for these videos, they're great! You're my favorite retro-computing youtuber.

You deserve more subs! Great informative video.

Correction: the IBM 5100 Basic Computer already existed and used an i8085 chip which uses the same bus as i8088. It was not a random choice to pick the 8088.

Thank you for making these :)

I love your architecture videos

It's hard to get across how bonkers iAPX is unless you read the programming documentation, which I did a few years ago. No only are instructions variable length in true CISC fashion, but they don't have to align to byte boundaries and can be arbitrary bit lengths. That's just nuts. Even the high-level theory of operation is hard to understand. All of that so they could keep the addressing paths limited to 16-bit (because all that 64K segmentation stuff in x86 worked out so well, didn't it?) I'm not a fan of RISC, as I feel more compromise between the RISC and CISC world might be pretty effective, but iAPX really takes the cake in terms of complexity, and it's no wonder why RISC got so much attention in the mid 80's. It's a shame the video didn't mention i860 and i960, which were Intel's attempts at making RISC designs which were a bit quirky and complicated in their own rights. Of course, those processors saw some success in military and embedded applications, and I don't believe they were meant to compete with x86, let alone replace it. One thing worth mentioning: the 68000 processor used about 40K transistors for the logic, but also used about 35K more for the microcode. The transistor density of microcode is much higher than logic, but it's misleading to just chop the microcode out of the transistor count. That said, the 68000 was also a very complex processor, and in the long term probably would not have been able to outperform x86. That's a shame, as I liked programming 68K.

Great video once again, I enjoyed it. I never knew about this though I had heard of ADA. Never really knew what it was, just heard of it in passing.

iAPX was the sort of CISC that RISC was created to combat and that makes modern cisc vs risc arguments look kind of silly

Loved the video, never got my hands on one, but brought back some fond memories about the NEC v20, I had a Hyundai xt clone and a friend that had an original ibm 5150, who was convinced that because it originally cost more and was ibm that it was faster than my Hyundai, until the day we got a copy of Norton si. (May have been something similar) The friendship dynamic changed that day.

1:23 that tape unit looks wrong. There doesn't seem to be any devices to soften the pull of the tape up reel. On full height units there are suction channels that descend either side of the head and capstans. The capstans can rapidly shuttle the tape across the head and you'd see the the loop in the channels go up and down. When the tape on either channel would shorten to the top of the channel then the reels would spin and equalize the length of tape in the channels. So the only tension on the tape was from the suction of air and not a mechanical pull from the reels that at high speed would stretch the tape. Slower units might have a simple idler? whigh was on a spring suspension. You'd see the idler bouncing back an forward and the reels intermittently spinning. Looking at the unit shown either its really old and slow or its a movie/TV prop.

One fact that drove the decision on using the 8088 in the 5150 PC was that they had experience with using Intel's 8085 CPU in the Datamaster and the 8086 in the Displaywriter.

The main takeaway I got from this video was that for all the faults of the CPU, the compiler itself was much much worse; using hugely inefficient CPU instructions to do simple things when the CPU had far better ways of doing it built in. Much like the Itanium how much more kindly would we be looking back at it had the compiler writers actually done a really good job? Hell, the "compiler had to organise the instructions" idea is in use today and has been since the Pentium. How much different really is that to the Itanium's model? I just think that Intel has a history of hiring the "right" people but putting them with the "wrong" teams. They have engineers who come up with really interesting concepts, but then when it comes to implementation it seems like they just fall over and pair it with some really stupid management. Meanwhile on the x86 side they add something that sounds suspiciously like a nerfed version of what the other team was doing and then they kill the interesting project or allow it to fail and then put billions of dollars into assuring that the x86 line doesn't even when faced with arguably superior competition from other CPUs. I just remember that when RISC came about it was considered slow and dreadfully inefficient and it was some time before the advantages of simpler CPUs started to make sense. If the money and backing had been behind language specific CISC instead of assembly focused CISC would we be looking back at x86/68k and even ARM and thinking "boy, what a weird idea that compilers would always have had to turn complex statements into many cpu instructions instead of the CPU just doing it itself. CPUs would have to run at 4GHz just to have enough instruction throughput to resolve all these virtual function calls! LOL!"

The point of the iAPX 432 was to design a clean, safe, reliable architecture. Had it happened a decade later without the need for backward compatibility, it would have been a superb architecture. Its problem was that it was too advanced for the time and its day never came. The same was true for their Ada compiler. It was, again, designed to be clean and safe at the cost of speed.

Very interesting stuff. I'm glad I skipped this chapter in Intel's life! When I used to repair Ontel terminals, I came across one CPU board that had 8008s on it! That was their oldest product I came across. The others were based around 8080 and and 8085 CPUs not counting their Amiga CP/M 2.0 computer which had the requisite Z80.

Btw, the 'X' from APX stems from the "chi" in "Ar*chi*tecture" interpreted as Greek letter "X" ("chi").

Someone at IBM should have tried harder to contact Gary Killdall. The z80 or the Motorola 68000 would have made a better PC.

Loving the tape drives from the Italian Job

@RetroBytes - when you run out of topics, here is one: MMUs . Early microprocessors had some registers and some physical adress-width. Then they found out, that they might do something like 'virtual memory' and/or memory-protection. The processor families Z8000 and 60000 had separate chips, which acted as Memory Management Units. They did translation of some logical adress to a physical adress. when the requested data was not in physical memory, they aborted the instruction, called a trap-handler, which loaded the memory page from disk and restarted/continued the trapped instruction. some architectures could just restart/redo the instruction, but some required to flush and reload a lot of internal state. Maybe you can make a video about the various variants, which were the easy ones, which were the tricky ones, how is it done today (nobody has a separate MMU).

Intel actually did offer up another operating system during that era. It was called iRMX and was a real-time OS that used lots of those x86 hardware multitasking features.

I've been toying with the idea of building an iAPX 432 emulator for a few years - if only to get my head around how weird the architecture was - but I hadn't known that it was broadly untouched in the emulator space! Perhaps it's time to revisit that project with some more motivation.

So completely different from Itanium, which basically went for "well the compilers will sort it out eventually"?

At Imperial College we bought an iAPX432 and SBC86-12 with a Matrox 512K multibus system. Managed to run OPL432 the Smalltalk style language. When I left Imperial, they sold me the system and I eventually put the iAPX432 on ebay.

Enjoyed that. Thank you

Interactive UNIX file /bin/ls /bin/ls: iAPX 386 executable Thanks for explanation...

Thanks for this video. Another thing people often forget these days; back then Intel was heavily involved in the manufacturer of commodity DRAM chips

do a video on the evolution of Cyrix . . . I'm diggin' this techy stuff . . .

The Ada language was a safe bet back then because it was being bushed by the US Department of Defense, which was the origin of a lot of software back then. IBM's decision to go with the Intel processor architecture was because Intel let AMD second source the processor. IBM's standard was that no part could have a single source. Some of the rumors around the 432 was that Intel was pushing it to freeze AMD out of the processor market.

Rekursiv might be worth a look at, too. Though I don't advise dredging the Forth and Clyde canal to try and find it, that's a retro-acquisition too far.

Remember that most all those early X86's came up in the 8088 mode and had to be prepared and switched to the processor configuration.

I had read some Intel Manuals about iAPX432 back in 1985 during my work time as a hardware development engineer. I couldn't find any value argument for the management to invest in that Intel product line.

You should do a video on the intel i860 Risc processor. It was a worthy effort for a high end 3D workstation but it kind of fell on its face because the compilers sucked.

I had Ada class in college circa 2008, it was mainly about teaching parallel computing concepts.

I remember i286 I believe from an old coco type magazine I got at a yardsale in the 90's(US Ca.)

Love looking back at those crazy times.

7:58 I don’t think the splitting into multiple chips was really a performance or reliability problem back then. Remember that the “big” computers used quite large circuit boards with lots of ECL chips, each with quite a low transistor count. And they still had the performance edge on the little micros back then. Of course, chip counts and pin counts would have added to the cost.

40 OR in the US Military as a systems developer, we still use ADA new libraries are written in ADA and some of the best security libraries are in ADA.

As a collector of weird old cpus, a 432 would be the jewel of my collection - of course I'm never going to see one. For 'failed intel x86 killers' I have to settle for the i860 (and maybe an i960) which is still plenty weird, but which sold enough to actually turn up on ebay every once in a while.

Isn't returning values from procedures the norm? Like how would you return a pointer to your stack, since the stack will be cleaned during the return from procedure

@RetroBytes amusing video. I'd almost forgotten about the i432. The culture of the times was very much high level languages of the Pascal/Algol kind driving design, ADA being the most prominent/newest kid on the block and as I recall there were *no* efficient implementations of ADA and it took forever to compile. Because the ADA language specification was very complex and the validation of it highly rigorous it just took too long to qualify the compilers and my guess is, Intel ran out of *time* to do a decent compiler. Also, ADA was designed to support stringent operating scenarios in the military space. Ultimately the server market was driven by business scenarios which didn't need such stringency, paving the way for C. So wrong hardware for wrong language for what the rest of world wanted...

Okay you joke but if PCBWay could get into producing custom cable knit sweaters I would 100% buy.

Memory (price and speed) and storage ( the same ) always fu**ed semiconductor evolution

8:01 propagation delay doesn't become relevant before you reach the order of magnitude of 1 GHz (at 1 GHz a signal at lightspeed travels 30 cm during 1 clock cycle, in a copper wire still at least 20 cm). The iAPX 432 ran at a maximum clockspeed of 8 MHz.

if you told me ARM would be what ate x86 finally back in 2000 i would have said i need to go potty

Ada is still in regular use, or at least in the form of VHDL, used to describe electronic hardware. Ada is a really cool language that lends some great features to later languages.

A bit of precision is required concerning the meaning of “RISC”. It means “Reduced [Complexity] Instruction Set Chip”. Ie, each operations are simpler to decode and execute-more often than not, in a single CPU cycle. Whereas CISC might require multiple CPU cycles to treat a single “complex” instruction. This simplicity generally meant that RISC processors has more instructions than CISC to compensate.

You commented (mocked) Intel for using iAPX on the 286 chip name. Most CISC machines are implemented using microcode. What if they used the APX technology to implement the x286 by simply replacing the microcode with one that implemented the x86 instruction set plus some enhanced instructions. I don't know that this happened, but it wouldn't have surprised me.

also dude. Intel wrote several operating systems: * ISIS - for 8008's and paper tape * ISIS-II for 8080/8085's and floppy disk (hard disk added later) * ISIS-III for 8086's with floppy and or hard disk * ISIS-IV a networked operating system for iMDX-430 Networked Development Systems AND * iRMX a preemptively multitasking operating system used in all sorts of embedded applications (and was also the kernel for the GRiD Compass)

And there were a few CPU chip manufacturers back then. I was there where the dinosaurs ruled and the Processor Wars were happening. My grandkids will be thinking I'm crazy talking about languages having line numbers :)

PS: I find it amusing that the only line of CPUs Intel has had any real success with was based in a contract for a terminal chipset they botched so badly the client was forced implement what they wanted in TTL... which Intel then used as the basis of the CPU they were supposed to design!

Man, I had one of those space bunny soft toy from the original Pentium II release promotion. I chucked it when I moved house in 2021. Now I'm regretting it.

Seems like a lot of similarities between the APX and Itanium from what I heard of the Itanium. Itanium brought about my first look at EFI boot process and that turned out useful for me. I had Windows 2000, HPUX and linux running on the Itanium. The Itanium was faster at some operations. I had an SGI server with Itaniums that I stuck linux on and had it as a camera server running motion on around 2006 or so.

I would love that ada lovelace video at some point too 😁

Ada was mandated by U.S. Dept. of Defense for mission-critical applications, as well as safety-critical.

The really big reason why ADA was invented was as a standard language for defence applications, as specified by the American DoD. The theory was that it was supposed to be provable (in a CompSci sense), & thus less buggy / more reliable. Hence, there was a *lot* of money behind it.

Yup, even Intel saw 8086 and it's decendents as something periodic. From iAPX432, to i960, i860 and IA-64

are you using Cool-retro-term for the terminal overlay??? well playted sir

the Fiesta reference comparing it's alternate naming to Intel's iAPX 286 would be better compared by renaming the Ford Fiesta to the Ford Fiesta Edsel, as the Ford Edsel was essentially Ford's version of the iAPX back in the 1960s.

Just to note, Intel didn't jump straight to 80286. For a brief period there was an 80186. I believe it only went into 2 or 3 offerings of PC's but it was a thing at one point.

Kinda. the 8088 was a special modified 8086 because Intel had the 8086 16-bit CPU but it didn't yet have a 16-bit support chipset for the 8086. Intel modified the 8086 to the 8088 to work with the 8-bit support chips for the 8080.

At 1:11 and on - that tape unit clip is from a scene in the 1969 movie "The Italian Job". Is it PD now, or what?

Having just watched your Itanium video, seems like a similar mindset between the two...pushing the performance onto the compiler instead of silicon

I've only heard of iAPX. But you mentioned Ford Fiesta, the original model is rare to see here in the states. But I used to own one, but sold it on 1992 when I inhereted a newer bigger car. But still see that same Fiesta I once owned zipping around the small town I'm in.

Look at the current IBM "z series" mainframe. It has a lot of "conditional" instructions. Equivalent to "load if" instruction.

Looking forward to hearing about BiiN and i960!

Ada was adopted by the Department of Defense (U.S.).

Recall the failure that was IA64 architecture, the Itanium processors, had no idea iAPX existed.