Do Microprocessors Love Cee

Discussion moved from SufficientlySmartCompiler

On the one hand it is argued that CeeLanguage earns its reputation of speed (AsFastAsCee) from its closeness to assembly and to its maturity, allowing refinement of compiler optimizations. Therefore, it would be hard for any other language to achieve the same level of performance without matching general hardware better. For the purposes this discussion we are talking about "real" compiled C, not DotNet C or CeeSharp.

On the other hand it is argued that the above is a self-fulfilling prophecy: CeeLanguage is fast because processors are tuned to execute C efficiently. It is noted that "the Intel 8086 line of CPUs are optimized for accessing local variables on the stack, as is common in Algol-derivative languages, like C." and that "Much of the design philosophy behind RISC is geared towards executing the output of C compilers efficiently. Many addressing modes that assembly-programmers loved but weren't used in compilers got axed. ".

It is even speculated that C syntax is "so close to the PDP-11 instruction set, it's scary", which implies a relation between the two. However, as told by DennisRitchie (http://cm.bell-labs.com/cm/cs/who/dmr/chist.html):

: "People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed."

Even the alleged similarity between PDP-11 assembly and C is apparently "a folk myth, pure and simple, which continues propagating because its a handy sound bite, not because there is any truth to it whatsoever."

There is the assumption that LispMachines or processors tuned to AplLanguage probably would execute these languages FasterThanCee. From the previous discussion:

: That said, the low-level nature of C (and not just "processors being tuned to execute C") is what makes it fast. Executing C code on a LispMachine (or any other architecture designed to efficiently execute code written in a HighLevelLanguage) would suck; as emulating C in a HLL is an AbstractionInversion and an inefficient one at that. Emulating a HLL on a low-level language like C, on the other hand, is commonplace and well-known.

But "These CPUs are designed to provide direct hardware support for programs written in high-level languages such as Pascal-86 and Intel's PL/M-86" APX 86/88, 186/188 User's Manual, Programmers's Reference, 2-1. Perhaps the 8088 really did not love C? And the jump instructions for the 8x86 family favour -1 for true instead of +1...

x86 jumps favor checking either for -1 or for 0, so C's use of +1 and 0 for BooleanRepresentation doesn't impact performance of branches. I really do wish that they'd used -1 for true though, so that you can use bitwise-AND to compute various things based on a set of booleans. For example, in ForthLanguage, which does use -1 for true, you can do this:

 : handleKey ( ch -- )
   inInsertMode? ['] insertCharacter and inCommandMode? ['] executeCommand and or execute ;

The 80286 and earlier CPUs did have some complex instructions to facilitate block-structured, Algol-ish languages. However, they had no particularly-obvious-made-for-C instructions like the 80386 and later has.

original contributors included JeffGrigg and others.

See AlternativeMicroprocessorDesign

CategoryCee