17

A computer scientist will correctly explain that all programs are interpreted and that the only question is at what level. --perlfaq

How are all programs interpreted?

Community
  • 1
  • 1
Chankey Pathak
  • 21,187
  • 12
  • 85
  • 133
  • 11
    +1. Why so many close votes ? This actually is a good question. – user703016 Jul 16 '11 at 19:02
  • In addition to the good answers here, you should consider http://stackoverflow.com/questions/871833/what-does-data-is-just-dumb-code-and-code-is-just-smart-data-mean . – darch Jul 20 '11 at 00:03

5 Answers5

21

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
unpythonic
  • 4,020
  • 19
  • 20
  • 2
    +1 However, Java HotSpot and similar might JIT to machinecode so to be complete... and not sure how Perl on parrot would be classified, etc ... (also, for what it's worth, .NET offers a way of "pre-JIT"ing). –  Jul 16 '11 at 17:42
  • to add to it compilers can also produce assembler code if so desired which can later be assembled.. So no compilation to machine code level in that case but eventually every thing does get converted :) – Osama Javed Jul 16 '11 at 22:38
  • 2
    There did not exists "Compiled languages" or "Interpreted languages". A language is a language, and you can write a compiler or an interpreter or both for it. A language itself does not restrict to one of them. There also exists C Interpreter for example, and a lot of languages have both Interpreter and Compiler. And by the way. A Compiler is just something that just converts to another language. If you have a program that converts JavaScript to Perl, that's also a compiler. And by the way, `perl` compiles Perl code before execution to a byte-code and then execute that, just like java does. – David Raab Jul 17 '11 at 01:01
  • 1
    @Sid Burn, Nit: Perl sources aren't compiled to byte code, but to a tree of OP structures. Loosely speaking, it gets compiled into opcodes. – ikegami Jul 17 '11 at 05:36
  • @Mark Mann, wrt your addition, the quote to explain is "all programs are interpreted", not "all programs could be interpreted" – ikegami Jul 17 '11 at 05:37
6

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.

Louis
  • 2,442
  • 1
  • 18
  • 15
  • 1
    Also see [microcode](http://en.wikipedia.org/wiki/Microcode), which is present in many modern CPUs: "...it resides in a special high-speed memory and **translates machine instructions into sequences of detailed circuit-level operations**..." :-) –  Jul 16 '11 at 17:40
  • I was going to bring up microcode, but then I realized that below ASM, I don't really have a clue what I'm talking about :P – Louis Jul 16 '11 at 17:43
  • ...also, [Transmeta](http://en.wikipedia.org/wiki/Transmeta), while no longer around, had an interesting approach of translating x86 to the native VLIW instruction set "on the fly"... I always found it interesting. –  Jul 16 '11 at 17:46
  • And even with processors that *hard-wire all instructions* (i.e. not really any microcode in between - some RISC processors do this AFAIK), the instruction is being interpreted by those circuits. –  Jul 16 '11 at 17:48
  • ... and it's about that point that we go into electronics and then physics and then existential philosophy and then the meaning of life and then... and then... well... sigh. – Louis Jul 16 '11 at 17:52
  • It's turtles all the way down – Davos Apr 06 '18 at 13:16
5

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.

ikegami
  • 367,544
  • 15
  • 269
  • 518
0

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. :-)

Nils Jonsson
  • 21
  • 1
  • 6
  • FYI: Those "scripting languagues" are actually interpreted on the same level as most Java and CLR bytecode most of the time: As bytecode. (And before you bring up the JIT compiler of those VMs: Many - including at least the one in Sun's HotSpot - JITs only code that executed frequently, which is usually only a small part). –  Jul 16 '11 at 17:52
  • What is the difference between a "runtime" language and a "scripting" language from the point of view of compilers and interpreters? – Schwern Jul 16 '11 at 18:30
  • Javacompiler --> Javaruntime | C#, C, C++, J++ und VB --> CLR. That means a Runtimelanguage is the result by a compiler. A Scriptlanguage is a language, where you can interpret a text directly. Of course, you can compile Python or Ruby to a Runtimelanguage. But that doesn't make sense. – Nils Jonsson Jul 16 '11 at 18:50
  • In the Bad Old Days, languages were sometimes ran line-by-line from the text file. Command shells (like Bash) are probably the only ones left that do that. You could call those scripting languages. These days, almost everything is compiled into an intermediate form, be it bytecode or internal parse trees. In fact, Python and Ruby have their own runtimes, as does Perl6. No reason, in theory, why Perl5 couldn't be that way, either. – frezik Jul 16 '11 at 22:53
  • "C --> CLR?" Why on earth would anyone want to do that? – Kevin Stricker Jul 16 '11 at 23:48
  • @mootinator, Two reasons come to mind. CLR bytecode supports the idea of "Managed Code". That is code that by virtue of running on the CLR can have more fine grained security applied to it. Compiling a C library as CLR bytecode allows it to be accessed by .NET code that must be run as Manage Code. – Ven'Tatsu Jul 18 '11 at 19:59
0

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 C1, 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.

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

frezik
  • 2,316
  • 15
  • 13