"All programs are interpreted". How?

A co开发者_C百科mputer scientist will correctly explain that all programs are interpreted and that the only question is at what level. --perlfaq

How are all programs interpreted?

A Perl program is a text file read by the perl program which causes the perl program to follow a sequence of actions.

A Java program is a text file which has been converted into a series of byte codes which are then interpreted by the java program to follow a sequence of actions.

A C program is a text file which is converted via the C compiler into an assembly program which is converted into machine code by the assembler. The machine code is loaded into memory which causes the CPU to follow a sequence of actions.

The CPU is a jumble of transistors, resistors, and other electrical bits which is laid out by hardware engineers so that when electrical impulses are applied, it will follow a sequence of actions as governed by the laws of physics.

Physicists are currently working out what makes those rules and how they are interpreted.

Essentially, every computer program is interpreted by something else which converts it into something else which eventually gets translated into how the electrons in your local neighborhood fly around.

EDIT/ADDED: I know the above is a bit tongue-in-cheek, so let me add a slightly less goofy addition:

Interpreted languages are where you can go from a text file to something running on your computer in one simple step.

Compiled languages are where you have to take an extra step in the middle to convert the language text into machine- or byte-code.

The latter can easily be easily be converted into the former by a simple transformation:

Make a program called interpreted-c, which can take one or more C files and can run a program which doesn't take any arguments:

#!/bin/sh
MYEXEC=/tmp/myexec.$$
gcc -o $MYEXEC ${1+"$@"} && $MYEXEC
rm -f $MYEXEC

Now which definition does your C program fall into? Compare & contrast:

$ perl foo.pl
$ interpreted-c foo.c

Machine code is interpreted by the processor at runtime, given that the same machine code supplied to a processor of a certain arch (x86, PowerPC etc), should theoretically work the same regardless of the specific model's 'internal wiring'.

EDIT:

I forgot to mention that an arch may add new instructions for things like accessing new registers, in which case code written to use it won't work on older processors in the range. Much like when you try to use an old version of a library and then try to use capabilities only found in newer libraries.

Example: many Linux distros are released as 686 only, despite the fact it's in the 'x86 family'. This is due to the use of new instructions.

My first thought was too look inside the CPU — see below — but that's not right. The answer is much much simpler than that.

A high-level description of a CPU is:

1. execute the current op
2. grab the next op
3. goto 1

Compare it to Perl's interpreter:

while ((PL_op = op = op->op_ppaddr(aTHX))) {
}

(Yeah, that's the whole thing.)

There can be no doubt that the CPU is an interpreter.

It just goes to show how useless it is to classify something is interpreted or not.

Original answer:

Even at the CPU level, programs get rewritten into simpler instructions to allow the CPU to execute more them more quickly. This is done by changing the order in which they are executed and executing them in parallel. For example, Intel's Hyperthreading.

Even deeper, each instruction is considered a program of its own, one that routes electronic signals. See microcode.

The Levels of interpretions are really easy to explain:

2: Runtimelanguage (CLR, Java Runtime...) & Scriptlanguage (Python, Ruby...)

1: Assemblies

0: Binary Code

Edit: I changed the level of Scriptinglanguages to the same level of Runtimelanguages. Thank's for the hint. :-)

I can write a Game Boy interpreter that works similarly to how the Java Virtual Machine works, treating the z80 machine instructions as byte code. Assuming the original was written in C¹, does that mean C suddenly became an interpreted language just because I used it like one?

From another angle, gcc can compile C into machine code for a number of different processors. There's no reason the target machine has to be the same as the machine you're compiling on. In fact, this is a common way to compile C code for AVRs and other microcontrollers.

As a matter of abstraction, the compiler's job is to translate flat text into a structure, then translate that structure into something that can be executed somewhere. Whatever is doing the execution may have its own levels of breaking out the structure before really executing it.

A lot of power becomes available once you start thinking along these lines.

A good book on this is Structure and Interpretation of Computer Programs. Even if you only get through the first chapter (or half of the first chapter), I think you'll learn a lot.

¹ I think most Game Boy stuff was hand coded ASM, but the principle remains.