Talk:Intel iAPX 432

iAPX 432, not i432

This page should be renamed. Intel NEVER offically referred to it as the i432. It was always the iAPX 432. --Brouhaha 02:55, 10 Oct 2004 (UTC)

Seems reasonable. Perhaps the acronym expansion should be included as well? (is it actually intel Advanced Processor ArChitecture? -- a wild guess on my behalf is that the X stands for the Greek letter Chi...) --Wernher 14:41, 10 Oct 2004 (UTC)

So there; fixed it. I also did some editing incl sectioning to (hopefully) make the article more readable. --Wernher 23:37, 10 Oct 2004 (UTC)

I've never seen any explanation of "iAPX" from Intel; there may not have been an official one. Your conjecture that it stands for Intel Advanced Processor arCHitecture seems reasonable, but I don't think it should be stated as fact unless a reasonably authoritative source can be found. --Brouhaha 16:26, 11 Oct 2004 (UTC)

• iAPX means Intel Advanced Performance Architecture (rather than Processor) according to dvorak.org and according to the same source the X refers to architecture. The iAPX designation was also used for the 8086 (iAPX 86), 8088 (iAPX 88), 80186 (iAPX 186) and 80286 (iAPX 286) chips according to Intel's programmer's manuals (see the iAPX article), and according to iAPX 286 (80286) programmer's manual Intel refers to the x86 architecture as iAPX 86 series after the first processor, iAPX 86 (8086). The iAPX designation, which seems to be a marketing term, is not used anymore. Sofia Koutsouveli (talk) 18:45, 19 March 2014 (UTC)

I have done some searching around on the net, and me neither can find an acronym expansion of "iAPX" from Intel. The "best" I've found is Aad Offerman's CHIPLIST. Note, however, that I used the term "reportedly" when citing the expansion; one might perhaps find another term to specify the lack of authority in this minor(?) matter. Of course, nothing should be related in such a way that it might be wrongly interpreted as a fact -- I'm with you on that. --Wernher 20:42, 11 Oct 2004 (UTC)

Speaking of which, I'm a little dubious of the cited slogan "mainframe on a chip". Where did that come from? Did Intel actually use that phrase anywhere? --Brouhaha 16:33, 11 Oct 2004 (UTC)

Again, no clear evidence. I have amended the intro paragraph to reflect this. Thanks for mentioning it; I should've been a little more careful in my initial wording. The term "slogan" was used in a more general context, as the "mainframe on a chip" phrase has been an (official and unofficial) advertising slogan of several high-end µP projects. --Wernher 20:42, 11 Oct 2004 (UTC)

I seem to remember Intel gave a book, updated each year of product dscrtiption sheets. This had the phrase micromainframe. Maybe the Computer History Museum has one of these in their library. — Preceding unsigned comment added by 67.20.170.4 (talk) 18:04, 10 September 2012 (UTC)

I just saw "micromainframe" somewehere, I'll check when I get a chance. Peter Flass (talk) 18:26, 10 September 2012 (UTC)

Here's a reference to "Micromainfrane" from Intel: http://bitsavers.org/pdf/intel/iAPX_432/172283-001_Reference_Manual_for_the_Intel_432_Extensions_to_Ada_Dec81.pdf Peter Flass (talk) 23:20, 11 September 2012 (UTC)

BiiN µP correction; i960 Mx information

The BiiN processor was not the i960MC; it predated all of the i960 family. When BiiN flopped, Intel redesigned the processor to remove the tag bit and the microcode support for objects, and introduced the result as the i960. The i960MC, i960MM, and i960MX were later designs that added back the tag bit (and perhaps the microcode?), and were targetted at military designs. It is unclear whether any i960Mx customers actually made effective use of the tag bit. --Brouhaha 00:57, 11 Oct 2004 (UTC)

This is close but not quite right. The BiiN processor was known internally at the time simply as the "P7" -- it's code name according to the system at the time (the i386 had been the P3, the intervening numbers were for future 386s, and the i860 was the N10 because it started life a a numeric co-processor). The i960KA, KB, LC, MM, and (essentially non-existant) MX were all the same chip -- the exact same die, with some packaging differences. The tagged memory support was never removed from the design until the i960C-series, and it was certainly never added back. See my page on the i960. -- gnetwerker 1/1/05

Unclear connection to 432

The following two sections were included in the article, but has now been moved here for discussion of their relevance to the 432 CPU—as no characteristics of the 432 pertaining to the sections' material are mentioned in their text. There are, however, some references to an/the operating system, but if this information is to be interpreted as being of relevance to the processor, one would expect the combination of processor and OS to be specified (not just the OS). Please 'preciseify'; I may have missed something (happens now and then). :-) --Wernher 10:23, 11 Oct 2004 (UTC)

==Garbage collection==

Software does not need to explicitly deallocate objects that are no longer needed, and in fact no method is provided to do so. Instead, the operating system provides garbage collection using Edsger Dijkstra's on-the-fly parallel garbage collection algorithm. It is a mark-sweep style collector, but through the use of the system object table and a three-state indicator (white, black, grey) associated with each memory segment, it can operate fully concurrently with user processes.

==Virtual memory==

An attempt to access a segment that does not reside in physical memory will result in a Fault (software interrupt), and the operating system will bring the segment into memory, possibly swapping out another segment to make room for it.

Both are features supported by microcode interpretation of fields in the system object table. Without all accesses to objects being indirected through the object table, and the microcode support for the three-state marking of the object status, Dijkstra's parallel garbage collection algorithm couldn't be used. How many other systems have you ever seen that support parallel, on-the-fly garbage collection? Most systems have to pause their normal activity to run a garbage collector.

The Virtual memory section is less important, but does explain how the 2^40/2^41 byte virtual address space is provided. Virtual memory is commonplace now, but is almost always implemented by paging, and rarely if ever by swapping variable-length segments. There were plenty of other systems that swapped variable-length segments, but did not provide virtual memory thereby. The iAPX 432 architecture cannot support paging.

The operating system is iMAX 432. It's the only operating system that was available for the iAPX 432, so specifically mentioning it by name in descriptions of the features of the hardware architecture didn't seem necessary. If there had been another operating system available, presumably it would have used the architectural features of the object table for the same purposes. There should be a description of iMAX 432 elsewhere in the page, or maybe it should have its own page, but describing it adequately is a large task and I'm not yet sure where to start.

--Brouhaha 16:14, 11 Oct 2004 (UTC)

The iMAX 432 OS should be mentioned, I think, as it was the only available OS for the processor -- an important fact in its own right, and a clear qualifier for the treatment of garbage collection & virtual memory. One could just put in a short description of the OS, and include an empty link to be made into an article later on. Very 'wikipedish', BTW :) --Wernher 20:09, 11 Oct 2004 (UTC)

Added garbage collection section back into article, reworded to indicate role of hardware/microcode. --Brouhaha 08:23, 7 June 2006 (UTC)

Efficacy of OO, etc?

Can someone explain to me why this line isn't totally POV:

Sadly the market appears to have taken away the wrong lesson from the iAPX 432 failure. Generally the market has concluded that object support in the chip leads to a complex design that will invariably run slowly. However it appears that the OO support was not the problem at all, the problems were much more general and would have made any chip design slow.

Sadly -- wrong lesson -- there is much contrary opinion. I would reword: "Chip designers seems to have learned from the 432 that object support leads to .... -- the 432 was a favorite (bad) example in discussions of RISC designs. Whether this is the right lesson is still being debated, etc, etc. -- gnetwerker 1/1/05 -- DONE - Gnetwerker 18:40, 6 Jun 2005 (UTC)

External link suggestion

There's currently a link to a paper by King et al. Perhaps a link to the parent web page about the iAPX 432 would be reasonable? I haven't added that since it's my own web page.

I guess I'll see to it. Lots of 432 info there, no doubt. --Wernher 20:45, 11 Oct 2004 (UTC)

250,000 transistors, not 250,000 logic gates ?

> Together the three-chip system used about 250,000 logic gates, making it one of the largest designs of its era;
> the contemporary Motorola 68000 contained about 68,000 for instance, about 1/3 of that for its microcode.

I do not have any data to verify it, but I would think that this should probably mean "250,000 transistors" instead of "250,000 logic gates". I think I remember I once found an old iAPX432 preliminary datasheet dated 1978, and if we assume 4 transistors per gate, then 1M Transistors would seem somewhat overambitious even for a three-chip set for the late seventies. Also, I think the 68K was suggested to have 68K transistors, not gates - though this was surely incidental and probably anecdotal, as the M68K should have been named after the successful 6800 series of 8 bit microprocessors.

You are correct. The three chips together contain about 250,000 transistors.

Of course, it is somewhat silly to add all three together, since a 432 system might have any number of GDPs (43201/43202 pair) and a different number of IPs (43203). It would make more sense to quote the total for the GDP and a separate count for the IP. Reminds me of a road sign for a town that gave the year the town was founded, the population, and the elevation, then a total. --Brouhaha 08:13, 7 June 2006 (UTC)

End Of Life?

Can anyone provide an official "death certificate" for the iAPX 432? Did iNTEL ever officially discontinue the product (perhaps with a press release,) or did it just sort of disappear from the product lineup one year?

The article talks about a "failure", and says that iNTEL was "loath to abandon it entirely" but they must have, at some point, or else I should be able to buy one today.

The brouhaha article gives a 1986 date, but without any formal reference or explanation of why that year was chosen.

--Eliyahu S ^Talk 00:40, 21 November 2007 (UTC)

I/O

The 43203 Interface Processor (IP) allows a more conventional microprocessor to be interfaced as an Attached Processor (AP) to an iAPX 432 system. The AP acts as an intelligent I/O controller. The IP allows the AP to access objects in the iAPX 432 memory through the use of memory-mapped windows, but will enforces the access rights applicable to the objects.

Jamesbootman (talk) 22:09, 24 September 2008 (UTC)

16 bits vs. 32 bits

Dave House in a 2005 interview states that the project started out as a 16-bit processor, known as the 8816. See http://silicongenesis.stanford.edu/transcripts/house.htm M.smotherman (talk) 02:10, 1 June 2010 (UTC)

It was 32-bits, but not completely; segment size was 64k (16 bit), but the capability registers much larger - IIRR it could support a VM space of far more than 4 GB - I seem to recall 40 or 48 bits. So you could have massive programs and data sets, but individual objects were limited to 64k. That made sense back in 1980 :-) ~~dww —Preceding unsigned comment added by 86.9.90.50 (talk) 14:18, 16 July 2010 (UTC)

Instruction Set as P-code

Reading articles about the processor when released I recall that most of the hype was that the instruction set was basically P-code. The idea was that high-level (ie Ada) programs could be as fast as assembler. At the time most Pascal and Ada compilers generated P-code that was then run by an interpreter. —Preceding unsigned comment added by 203.41.222.1 (talk) 02:05, 13 January 2011 (UTC)

P-code is usually defined as code for a virtual machine that is simulated by machine code running on a real processor. The 432 instruction set is not P-code in that sense; it is the native instruction set of the machine, as implemented by the hardware and microcode. The semantic level of the instruction set is somewhat similar to a typical P-code, but that is true of many stack machines. --Brouhaha (talk) 08:41, 13 January 2011 (UTC)

Price ?

Given intel's expectations of a 32-bit "super chip", I'm guessing it wasn't cheap to buy :)
And the need for 32-bit support chips presumably made for motherboards significantly dearer than those for x86...
So, how much ?
86.25.123.52 (talk) 06:22, 16 June 2011 (UTC)

• The only info I'm aware is is this $25,000 rumour but it refers to today's collectors' price (if true) rather than then Intel's price. Sofia Koutsouveli (talk) 18:52, 19 March 2014 (UTC)

• There's some actual component pricing from early 1984 on my web site. At the time, the pricing was somewhat expensive compared to e.g. the Motorola MC68000, but compared to modern x86 processor pricing, even adjusted for inflation, it was not that outrageous. --Brouhaha (talk) 17:12, 21 February 2022 (UTC)

x86 compatible or not?

I think it's not clear from the Intel iAPX 432 article to a non-technical person whether iAPX 432 was x86-compatible or not, so perhaps we should elaborate and explicitly say it was incompatible with x86, what do you think? Sofia Koutsouveli (talk) 18:48, 19 March 2014 (UTC)

So, who exactly?

This article manages to contradict itself within a single paragraph:

...with Justin Rattner as the lead engineer. ... The lead engineer of iAPX 432 was Fred Pollack

Wow. Maury Markowitz (talk) 12:50, 4 May 2020 (UTC)