Sorry to belabor the point, but this whole business of what is a compiler or
an interpreter does not seem to be well understood on this list.

An interpreter reads source code, translates it into executable form one
line at a time, executes a line, and throws away the translated code. Each
time a line of source code needs to be executed, it is translated all over
again.

A compiler translates source code into executable code and saves the
translated code. Each time a line of source code needs to be executed, the
already translated code is executed.

The executable code is of course executed on a processor. "Machine language"
means that the executable code consists of instructions in the instruction
set of the host processor, for example a Pentium chip. "Pseudo code" means
that the executable code consists of instructions in the instruction set of
a virtual machine. Examples of such virtual machines are the Pascal p-code
machine, the Java Virtual Machine, or (loosely speaking) the Csound program.

This discussion has become confused for several reasons.

Csound is a true compiler, because it translates source code into executable
code all at once, and does not have to translate it again during execution.
But the orchestra language syntax is simple, like that of assembly language.
Is an assembler a compiler? Yes.

Csound does not produce executable code for the host processor, but rather
for musmon, which is (loosely speaking) a virtual machine. A virtual machine
is sometimes called an interpreter, but this not accurate. Unlike
interpreted code, all the symbols (function addresses, variable addresses)
in pseudo-code are resolved at the time of original translation. It is more
accurate to say that the "actions" in the pseudo-code are carried out by a
virtual machine, which is emulated by a program running on the host
processor.

In modern Java virtual machines, when the compiled pseudo-code (the .class
code) is first executed, another level of compilation takes place, from
instructions for the virtual machine to instructions that are directly
executable on the host processor. This is called "just-in-time compilation".
It produces a whole new order of magnitude of efficiency because Java
pseudo-code is complex and is not completely resolved during execution. With
Csound, because the Csound pseudo-code is simple, like assembly language,
and completely resolved at translation except for copying instrument
templates into new instances and filling in their pfields and gens for new
notes in the score, there would probably not be a large gain in efficiency
from compiling directly to machine language. After all, the opcodes
themselves, where most of the action happens, are already compiled and
optimized machine language. In other words, the Csound virtual machine, due
to its simplicity, is highly efficient and probably would not benefit as
much as Java from just-in-time compilation.

In my opinion, Csound represents a pretty good compromise between a number
of sharply conflicting goals in music synthesis. Increasing the power of the
language would either slow Csound down, or make the orchestra compiler much
more complicated, and also make it take longer to translate orchestras.
Keeping the language simple also makes it conceptually easier to add new
opcodes. As it happens, some quite complex instruments can be written in
Csound. If more is desired, it is always possible to code away in C or C++
and link the result in as a new opcode.


-----Original Message-----
From: Richard Dobson 
To: Larry Troxler 
Cc: Csound List 
Date: Saturday, February 27, 1999 6:16 AM
Subject: Re: if.../ Common Lisp Music / compilers / interpreters


>The trouble is that if we use the term 'compiler' too librerally, it
>ends up meaning everything and nothing. In my mind, Csound is really  a
>scripting language. It doesn't 'compile into code', nor is it an
>interpreter (there is no 'executable output'), it links
>~already-compiled~ routines according to the users requirements. Output
>is either a sounfile, or an audio stream. Even if we call Csound's
>syntax 'assembler-like', there is still no machine-like code it compiles
>into, as such, just linked lists of routines. Thus Csound was able to be
>adapted to link SHARC dsp modules (pre-built), for XTCsound. Perhaps
>this is a case where Csound ~is~ more of a compiler; though surely the
>SHARC executable it produces requires a lot of support from the XTCsound
>OS - and the ADI linker.
>
>
>Conversely, I understand CLM to be (according to the given descriptions)
>a language ~translator~ - it translates it's native language into C.
>Presumably in the days when it produced 56K dsp code, it was linking
>existing modules, rather than compiling directly into machine code.
>
>If we call Csound ~or~ CLM 'compliers', then we really have to call web
>browsers compilers too, simply because they take HTML and turn it into
>pictures and text on a screen.
>
>CLM looks like an attractive package; but it is from these descriptions
>very much less self-sufficient than Csound. Nobody even needs to own a C
>compiler to use Csound. For many users, that must be a major part of its
>attraction, and hence its success. Composers can get into it step by
>step, without having to have a full-scale computer-science-like
>environment, with commandline c-compilers and the rest. If MIDI
>sequencers depended on the availablility of a C compiler on everyone's
>machine, I don't think they would be the commercial and musical
>phenomenon they are!
>
>Richard Dobson
>
>
>--
>Test your DAW with my Soundcard Attrition Page!
>http://wkweb5.cableinet.co.uk/rwd
>CDP homepage: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm