Should C be regarded as an intermediate language on a virtual machine named PDP-11 Architecture (which have a plain memory space and stacks), like opcode to jvm, msil to dotnet, asm.js to v8, which has to be translated and optimized for real machines of different architectures? (therefore C is the Java before Java)

Or if not, should PDP-11 assembly do?

  • 5
    What is your definition of "Intermediate Language"? – Jörg W Mittag Sep 12 at 13:28
  • 1
    The C standards describe "the behavior of an abstract machine". A PDP-11 virtual machine would be an improvement in regards to eliminating undefined/implementation defined behavior. – Kelvin Sherlock Sep 12 at 15:30

It's not really clear in what context the question is asked, so I'll try to go along.

Should C be regarded as an intermediate language on a virtual machine named PDP-11 Architecture (which have a plain memory space and stacks), like opcode to jvm, msil to dotnet, asm.js to v8, which has to be translated and optimized for real machines of different architectures?

Yes and no.

C is clearly not an intermediate code - the mentioned bytecodes aren't languages at all, but either instruction sets or halfway compiled source. C is a language of it's own, and while it can be used to crank out some bytecode (which may reassemble structures found on a DEC CPU), this isn't C but a layer for a virtual machine. C itself is still a HLL.

Your assumption may come from the fact that, C, as a language, is very much targeted on a specific class of CPU architectures, less fitting for others. It isn't as abstract as other High Level Languages like BASIC, COBOL or Pascal. But on the other hand, it doesn't carry too specific constructs, thus compilation can be done for next to any CPU.

(therefore C is the Java before Java)

Not really. If you're looking for "Java before Java", then UCSD Pascal with its p-code machine is what you're looking for.

Over the years it got everything JAVA claims but about two decades before:

  • Binary portability
  • Virtual machine
  • Bytecode
  • Bytecode to native translation
  • IDE
  • etc.

... all the way to ...

| improve this answer | |
  • 1
    Yep, myself and my coworkers used an intermediate language styled after UCSD p-code to implement Modula-2, C, and Java for the IBM iSeries engines. (The first two were for internal use, but Java was a successful product.) – Hot Licks Sep 12 at 23:07
  • @HotLicks Now, that's cool. – Raffzahn Sep 13 at 15:07

This appears to be triggered by my answer to another question, in which I asserted that C was originally conceived as a "portable assembly language" with the PDP-11 in mind. This does not at all mean that C should be thought of as targetting a virtual PDP-11. Rather, the PDP-11 had a relatively complete feature set, which was used as a model for what operations C should directly support.

By the time C came along, several other high-level compiled and interpreted languages were already well established. Some, like FORTRAN and BASIC, were relatively simple; others, like Algol, were extremely complex and correspondingly difficult to implement. C had, as its primary goal, the capability to write large parts of an operating system's kernel and utilities, a goal which was not met by these high-level languages, and demanded a language which did not abstract the underlying machine too much.

Hence C was designed to be easy to write an efficient compiler for, initially targeting the PDP-11 but also applicable to many other machines, and so that the code expressed in it would have a similar structure to competent assembly language.

There is no built-in memory management except for the CPU's stack, with malloc() and free() being library routines that are themselves written in C. Native string types require built-in memory management, so in C strings are just arrays of char, and arrays in turn are just pointers to some known element within them (usually the first). This closely matches how strings and memory are handled in assembler.

Today's CPUs have grown many capabilities that the PDP-11 did not have. To some extent the C language has not kept up with these developments. But I have never heard of a C compiler which actually generated PDP-11 code as an intermediate product before translating it to its actual target; indeed that would be absurd.

| improve this answer | |
  • One of the design goals of the PDP-11 was to easily support compilers for structured high-level languages, particularly the ones that were "cutting edge" in the late 60s. Algol was surely on their minds, and C is, arguably, an Algol-family language with some simplifications for easy compilation (and different syntax). So was C designed for the PDP-11? Or was the PDP-11 designed for something vaguely like C (albeit before C was actually invented)? – RETRAC Sep 12 at 12:51

No, by definition an intermediate language would be just that -- intermediate; a step in translation. C was designed, and in practice, actually used, as a high-level systems programming language. Unix (and other operating systems), compilers, user applications and all other kinds of software were, and still are, written directly in C.

C only became a common target for automatic translation once C compilers were ubiquitous.

Compare with how, back in the 1970s, it wasn't uncommon to see Fortran used in this role, since FORTRAN once held the exalted position of having a compiler available on nearly every platform. Also compare with Javascript, which now holds a similar position. Javascript is very poorly suited as a general purpose intermediate language, far more so than C (or even Fortran, arguably!) but, again, it is ubiquitous, so it will be used as an intermediate language in practice.

| improve this answer | |
  • 1
    It's not clear to me whether the OP means intermediate in the sense of a step in the compiler tool-chain, or intermediate in the sense of some supposed hierarchy of programing languages: high-level <-> low-level, with C being in between. – another-dave Sep 12 at 15:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.