Slashdot

Linkage: Extreme example [wikipedia.org]. Cool example [vcalc.net].

Sometimes, pictures are needed. :)

I have worked on the Datapoint 2200, when I was just starting out. A magnificent machine for it's time! It was multi-tasking two dual card reader punches, two daisy wheel printers, was master of a 16 node TTY local network and an SNA controller to boot! This was with a CPU that was, IIRC, mostly 8008 compatible ( plus a second register set al la Z80 ). a maximum load of 16Kb of RAM,
two true digital cassette decks and a 12 x 80 screen. This was circa 1975 . All one had to do was keep the the dust off the chips and change the tape drive belts once a year and it ran for at least the 7 years I was around.

It was Intel's clear intention to allow simple, fully automatic translation of assembly code between one generation and the next. So the fact that the transition from each generation to the next is expressed in large steps does not make it a mighty tenuous connection. To exemplify:

(1) The slow speed of the 8008 required hardware acceleration for parity computation, so the 8008 ALU provided a parity bit in the flags register. That bit lasted all the way through the Pentium line. (Could it remain in X86_64? I no longer work in the assembly language world and do not know.)

(2) The original A,B,C,D,E,H/L register configuration with its byte/word weirdness in the 8008 was still plainly visible in the 16-bit X86 line, and hints of those structures lasted right through IA32, though IA32 does have significant improvements in orthogonality. (This is the genesis of the non-orthogonal register sets that compiler writers complained about all the way through IA32, which are fully rectified only with X86_64.)

The connection is not only not tenuous, but (I claim, having worked with every CPU they built from the 8008 to my current Core2duo) clearly connected by an intentional, nearly unblemished record of source-level backward compatibility for the 40 years of its history.

You do have a good point with respect to the way Intel scheduled its generational developments. When my group at AT&T was debating a project based on i486 DX2/66 and i960CA/CF, the Intel FAEs were exceptionally forthcoming with us about the way Intel developed their processor families. One of the more interesting things I learned was that Intel's X86 families were developed using dual teams, each team leapfrogging the other with successive generations. There was constant discussion among the teams, so often ideas from one would slip into the other.

There is no question that each generation was intended to be as large a leap as possible beyond the last, so you do have a good point about the internal architecture of the processor families.

Upwardly compatible opcodes was the overarching reason why, in that era, the 8086 was considered a true descendant of the 8080, and the 8080 was considered the true descendant of the 8008.

Remember we are talking about an era when Assembly Language was the highest level of programming abstraction available on the early micro computers. The compilers that converted AL to binary machine language ran on minicomputers, were state of the art, expensive, hard to acquire, and difficult to use. Developing under these conditions, and attempting to fit working programs into 4, 8, or even a glorious 16 kilobytes of RAM, was an art form that no one has had to practice in more than 30 years.

There was a tremendous advantage in developing a chip that allowed extension of the existing AL compilers without total rewriting, and allowed the AL programmers of the day to build upon their old skills. That some of the routines developed for the 8008 would also run on the 8086 / 8088 was a fringe benefit.

Disclaimer: while I was writing my first "HELLO WORLD" programs in Fortran on punch cards at the time the 8008 was put on the market, my first PC was an Apple II+ (about 8 years later) and I learned 6502 Assembly rather than 8086 code. I have since managed to forget all those old skills. Good riddance! It is much better to scratch out new ideas in Perl, and then if there is some reason to optimize, get a code monkey or two to do the low level work.

You're basically correct, but the transition wasn't as abrupt as all that. A 16-bit register can be designed so it looks like an 8-bit register to 8-bit code. And one reason the 808x has memory segments instead of a simple flat memory space is to provide a memory model that works with old 8-bit code; you pointers just refer to an address within a 64K segment instead of a flat 64K address space. I seem to recall that it was possible to run a lot of 8080 assembly code on the 808x simply by reassembling it. You could not, however, use your old binaries because the op codes were different. That lack of binary compatibility is more to the point, transitionwise, than add-on (but backward compatible) features like bigger registers and memory segments.

The 8080/808x transition was certainly more abrupt than subsequent transitions to 80186, 80286, etc., where there was binary compatibility. But it was less abrupt than, say, Motorola's transition from the 6800 to the 68000.

In the 1970s and early 1980s, before general-purpose personal computers, there was a whole industry for "word processors". These were special-purpose machines which offered text editing, printing, and storage for documents. They replaced typewriters. For the first time, people could edit documents without retyping. Word processors were not intended to be user-programmable; they ran a built-in application. Wang was a big name in that area, as were Datapoint and IBM. The original IBM PC reused the display from the IBM Displaywriter, IBM's family of word processors.

The next step was "shared-logic word processors", where several terminals connected to a central unit, with the central unit having a disk and printer. This was a low-end version of time-sharing. Datapoint introduced ArcNet, so the word processors could send documents to each other. But none of this stuff was user-programmable, although the hardware underneath was a general purpose CPU. It wasn't considered reasonable that users in a typical office could program something as complex as a computer. Also, these machines barely had an operating system; they were usually running the application on the bare machine.

After the IBM PC came out, Wang tried to enter that business. They weren't very successful. I used one of their early 8086 machines, the Wang PIC, which had a scanner. It ran a variant of DOS, which, interestingly, allowed about 800K of user space instead of 640K, because they did the split between RAM and device space at a higher address than IBM did. (The real 8086 limit isn't 640K; it's 1024K minus whatever address space is needed for devices.) It used a completely different (and more rugged) plug-in card design than the IBM PC, and wasn't software-compatible. A nice machine, it just lost out for being incompatible.

So really, PCs are descended from these word processors.