Comment by kens | Hacker News Reader

Comment by kens | Hacker News Reader

The article describes how Apple included support for the x86 parity flag which comes from the 8080. Parity is relatively expensive to compute, requiring XOR of all the bits, so it's not an obvious thing to include in a processor. So why did early Intel processors have it? The reason is older than the 8080.

The Datapoint 2200 was a programmable computer terminal announced in 1970 with an 8-bit serial processor implemented in TTL chips. Because it was used as a terminal, they included parity for ASCII communication. Because it was a serial processor, it was little-endian, starting with the lowest bit. The makers talked to Intel and Texas Instruments to see if the board of TTL chips could be replaced with a single-chip processor. Both manufacturers cloned the existing Datapoint architecture. Texas Instruments produced the TMX 1795 microprocessor chip and slightly later, Intel produced the 8008 chip. Datapoint rejected both chips and stayed with TTL, which was considerably faster. (A good decision in the short term but very bad in the long term.) Texas Instruments couldn't find another buyer for the TMX 1795 so it vanished into obscurity. Intel, however, decided to sell the 8008 as a general-purpose processor, changing computing forever.

Intel improved the 8008 to create the 8080. Intel planned to change the world with the 32-bit iAPX 432 processor which implemented object-oriented programming and garbage collection in hardware. However, the 432 was delayed, so they introduced the 8086 as a temporary stop-gap, a 16-bit chip that supported translated 8080 assembly code. Necessarily, the 8086 included the parity flag and little endian order for compatibility. Of course, the 8086 was hugely popular and the iAPX 432 was a failure. The 8086 led to the x86 architecture that is so popular today.

So that's the history of why x86 has a parity bit and little-endian order, features that don't make a lot of sense now but completely made sense for the Datapoint 2200. Essentially, Apple is putting features into their processor for compatibility with a terminal from 1971.

Thanks, I wasn't aware of the iAPX 432! Funny that history repeated itself almost exactly 20 years later, when Intel introduced the 64 bit Itanium architecture, but eventually had to copy AMD's 64 bit extension of the x86 architecture because x86 just refused to die. And today, 40 years later, it's still around - although maybe Apple's efforts will finally manage to put a stake through its shriveled heart...

Heh, refused to die seems like a weird way to state it.

Intel tried to force a split in desktop/server design with a significant price premium and shipped a very complicated CPU that moved significant complexity/work into the compiler. It managed to scare Alpha, Mips, and PA-risc out of the market, and generally shipped years late and hit performance milestones even later.

AMD on the other hand doubled the x86's registers, added 64 bit support, improved performance and did so with basically zero increase in cost. So suddenly a random x86-64, even a desktop, could gasp make full use of over 4GB ram at zero cost.

So Itanium retreated from servers, to HPC, to enterprise, and HA enterprise then of course died.

Compatibility with a terminal from 1971 yet I can't run a copy of Logic Pro 9 I bought 10 years ago - and haven't been able to for years - because Apple.

Do you find Apple's contempt for backward compatibility surprising?

I'm still displeased with macOS Catalina and iOS 11 dropping support for 32-bit apps (including many games) but Apple has a long history of old apps not running on newer OS versions and newer hardware.

Over time macOS dropped support for 68K, PowerPC, Classic, Carbon, and 32-bit apps. We'll undoubtedly get a macOS that won't run on x86, and I will be unhappy, but not surprised, if/when Apple removes Rosetta 2 and x86 app support. I can even imagine an unpleasant time when they remove the Objective-C runtime and frameworks.

I'm sure there were some Apple 1 users who were unhappy that their software didn't work well on an Apple 2, even if the Apple 2 had much better hardware and software.

Parity is one of the cheapest thing you can compute in hardware

By itself, sure, but fidelity to x86 requires the PF calculation be made alongside a wide range of common instructions, which is a significant cost either for the microarchitecture or for an emulator.

Yes the problem is that instructions such as CMP, that are often at the end of a basic block, will leave around PF for later use in other basic blocks (which likely will never happen but you cannot know!).

Compared to what? The sign flag has zero cost since it's just the top bit of the result. The zero flag is one NOR gate to compute. You get the carry flag for free with addition. (Although processors usually throw a lot of other functionality into carry (such as shifting) so the carry flag often ends up complicated.) A signed overflow flag is confusing but one gate to implement. In comparison, parity is difficult. You'll note that other early microprocessors such as the 6800, 6502, and 68000 did not have a parity flag. Same with early computers such as the System/360 and PDP-11.

Parity is expensive to compute with 1970s hardware. If you look at the die of the TMX 1795, the parity flag computation is a substantial part of the die, about half the size of the register file or the ALU. The first problem is that XOR is an inconvenient gate to implement, especially if you use standard MOS logic. Processors usually have special pass-transistor tricks to make XOR more compact. The second problem is that parity needs to XOR all the bits together, so you don't get parallelism.

How is the zero flag one NOR gate? Don't you have to NOR all the bits?

One biiiig NOR gate.

Yes, one 8-bit wide NOR gate. This is easy to implement in NMOS, basically you have a wire the width of the ALU and attach a transistor driven by each bit to pull it low.

One very large NOR gate. But unlike XOR, an n-bit NOR or NAND is just 2n transistors in CMOS (at least in theory).

While I know you already know this, technically all of the flags have large prop. delay and nothing is for free. :D

Computing any of them is equal amounts of delay if you want to mux/select any of them to output, and then on top of that you have to sequentially NOR-chain (and/or some hierarchical manner) the result for zero, and waiting on the adder carry chain for the carry flag. If you were sequentially (and/or some hierarchical manner) XOR-chaining for parity in parallel, is it really that much more delay? Especially if XOR uses domino logic etc.

I see a parity in the same realm as the adder carry chain as far as prop. delay goes (for computing sign/carry at the end.) Of course carry chains can be made more efficiently than a direct sequential chain, but you could be hierarchical about xor-chains for parity too..

Yes, addition is annoyingly slow due to carry propagation. But a problem with the parity flag is that it is computed on the result of your arithmetic operation, so it add another big delay to every operation. The other problem is that it adds a lot of circuitry (by 1970s standards).

Yeah agreed -- though that's what I meant about the zero flag: NOR instead of XOR combinatorial complexity, but same prop. delay critical path, only simpler circuits per bit if purely NMOS or PMOS! :) I think the 1970s Intel were doing MOSFETs then?

Technically parity could become a stable value before the zero flag could! ;)

Oh but I did forget that a single multiple input NOR could be large but without exponential amounts of gates

Obviously compared to any other ALU operation, except the most basic binary ops. It is just a parity of 8 bits, so even in a straightforward implementation you only have three levels of XOR, it is not completely serial, you do get to parallelize some. I do agree that it is not free on an 8080, but it is still a lot cheaper than add or sub.

Reply on news.ycombinator.com