1. Re: Interpret() & More suggestions

Anders and others have been wondering:
> Is Euphoria a compiled or interpreted language? From what I understand =
it is
> compiled... (Sources are compiled before actually run) But if the compi=
ler is
> left in memory after the compilation is complete, what prevents us from=
 using
> it again? I think that an interpret-function would really kick ass... (=
as I've
> seen it do elsewhere)

Euphoria, like almost every other interpreter ever constructed,
does some "compiling" or translating of the source code
that you type in, before it starts to execute your program.

Most interpreters, such as Basic interpreters, will at least
"tokenize" the source statements. This means that keywords
such as "while",  "if", etc. are converted to numeric codes or "tokens"
like 17, 123 or whatever. It would be very slow if the interpreter
had to read  'w' 'h' 'i' 'l' 'e'  every time and check if the spelling wa=
s
correct. By checking the syntax beforehand and generating single-byte =

numeric codes, the interpreter can operate much faster, especially =

when it executes statements many times in a loop.

Euphoria goes further than just tokenizing your source into
byte codes. Euphoria actually assigns 32-bit memory addresses to your
variables, and replaces byte codes by the 32-bit memory address of
a chunk of code that performs that operation.

So a Euphoria statement like:
    a =3D b + c

Would be converted to:

Euphoria instruction pointer --> - address of code to perform ADD
                                 - address of b
                                 - address of c
                                 - address of a

                                 - address of the next operation

When the program is executed, the machine code that
performs the ADD operation knows that the 2 input
variable addresses and the output variable address
follow in memory from where the instruction pointer
is pointing. The Euphoria instruction pointer always
keeps track of the next operation to perform, and is
used in accessing the operands.
The instruction pointer is kept in a register since
it is critical for speed.
The ADD operation will calculate b+c and store it in a, =

then will increment the instruction pointer
to point at the next operation, and then jumps to that
operation using a machine instruction that jumps =

to the address stored in a register.

A language called "Forth" also works a bit like this,
but Euphoria avoids some inefficiencies that Forth has.

The beauty of this system is that there is hardly any
interpretive overhead. Compared to compiled machine code, =

there's a bit of waste in having to do the indirect jump instruction =

so often. There's also a bit of waste because the code for =

the ADD operation has to be fairly general code, not =

as fast as a compiler might produce in a specific case. =


Many other interpreters generate single-byte codes and then
have a big case statement that jumps to the code for the
various operations. Euphoria's method is much faster.

Euphoria has a lot of other tricks that make it fast, but
I'm not going to reveal everything.  smile

As for dynamically creating and executing strings of Euphoria
code with an interpret function, yes it could be done, but it =

would require a lot of painful restructuring of the interpreter =

that might slow down all programs by a few percent. =

In my APL days long ago I found the APL interpreter's "execute"
function, which does exactly what you are asking, to
be very much a solution looking for a problem.
I've got higher priority things to look at.

Regards,
  Rob Craig
  Rapid Deployment Software

new topic     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu