3 ms·
A number of claims here and in the original article are inaccurate interpretations of the almost random walk that we have made to get to our modern processor de
by todd8 7y ago
A number of claims here and in the original article are inaccurate interpretations of the almost random walk that we have made to get to our modern processor designs and the C programming language.
Instruction level parallelism and out of order execution were done by the seminal CDC 6600 as early as 1964–at the time one of the worlds fastest computers. (I remember a conversation with Seymour Cray about the difficulty of handling machine state during an interrupt on such an architecture.) The C programming language didn’t come along until almost 10 years later.
As the article says, C is a good fit to the architecture of the PDP-11, mini-computer very different that the mainframes of the time. There were many competing visions for what a “high-level” programming language ought to look like back then, Pascal (1970), LISP (pre-1960), Prolog (1972), FORTRAN (pre-1960), COBOL (pre-1960), Smalltalk (1972), Forth (1970), APL (1966), Algol (pre-1960), Jovial (pre-1960), PL/1 (1964), CLU (1974). As a professional developer and CS grad student during this period we were well aware of these alternatives. Many of these had escape hatches to gain low level access to the machines that they ran on and libraries were customarily written in assembly language. C came along during this period. It wasn’t my favorite—the whole pointer/array punning seemed unnecessary to me.
Why did C prevail? Was it because it was low-level? No, there were other well established languages capable of low level work. I recall, a few reasons: Unix, DEC’s PDP-11, and Yourdon.
First Unix was amazing and C was the favored language on Unix. Just being able to type man on a TTY or VDT and see the man page for a command was so novel. Unix OS and commands were written in C.
Second, the PDP-11 was a very popular good machine and Unix ran on the PDP-11. Unix on a PDP-11 was a lot more fun than dropping off decks of punch cards to run on an IBM 360 or CDC mainframe.
Edward Yourdon was an influential American software consultant, author and lecturer. He had picked C over Pascal and other languages as a “practical” general purpose high level language to recommend.
Meanwhile, hardware was was not at all a monoculture; even though the PDP-11 was a comercial success, it was a simple machine and just a mini-computer. There were many attempts at alternative architectures. Harvard memory architecture machines, capability based addressing, programmable wide-microcode, LISP machines, RISC systems. I’ve programmed or designed systems for most of these.
So why did the x86 become one of the dominant architectures?
It was because of the power of mass production of integrated circuits. Computers using other architectures can be built, but like the LISP machines, they will be slower and more expensive than mass produced processors.
- cryptonector 7y agoAll those languages are very serial and branch-happy too. What would the alternatives be? SIMD, basically, and some sort of language layered on that -- array languages most likely -- and a complete retraining of programmers. TFA also talks about the UltraSPARC CMT architecture and says it's a bad fit for C because most C programs don't use a lot of threads. That's nonsense though, since in fact there are many C10K-style, NPROC threads/processes applications out there. Sure, many applications remain that are thread-per-client, but those were obsolete in the 90s, and most such apps I run into are Java apps because Java didn't tackle async I/O way back when. I suppose Java is also C's fault since Java resembles C. C is a scapegoat here, but TFA still has a point if we ignore that part of it: our programming languages (not just C) are serial and branch-happy, even when they have well-developed threading and parallelism features, and this translates to pressure on CPUs to do a lot of branch prediction. But we do have less-radical ways out. For example, the CMT architecture results in pretty lousy per hardware thread performance, but pretty good overall performance with minimal or no Spectre/Meltdown trouble (because the architecture can elide most or all branch prediction) -- this won't do for laptops, but there's no reason it shouldn't do for cloud given server applications written in C10K/CPS/await styles. My bet would be on a hybrid world with a mix of CMT and SIMD, and maybe also some deeply pipelines cores. CMT CPUs for services, SIMD for relevant applications, and deeply-pipelined CPUs for control purposes.
- Merrill 7y agoThe evolution of minicomputers recapitulated the evolution of mainframes. The evolution of microprocessors recapitulated the evolution of minicomputers.