OpenEuphoria

Re: Is there an Euphoria compiler?

• Posted by Robert Craig <rds at EMAIL.MSN.COM> May 25, 1998
• 751 views

Martin writes:
> There are a couple of things I don't understand.
> If the"interpreter has to check and do a lot of things at run-time"
> it seems that a compiler would be automatically faster because it
> could do that checking during compilation, and then not have to
> do it when the code runs.

Writing a compiler for Euphoria would be an interesting
project. However, because of the highly dynamic nature
of Euphoria, a compiler would be more difficult to write
and would have fewer benefits than with other languages.

In most compiled languages, such as C, or even Basic,
the compiler knows the data type of all variables in each
statement at compile-time, and the types can't change.
Furthermore, these data types correspond exactly to types
supported by the hardware, such as 8-bit char, 32-bit int,
64-bit double (f.p.) etc. It's possible to generate short,
fast machine code for any source language statement.

Suppose you wanted to compile the Euphoria statement:

         a = b + c

If b or c were declared as "object", you would have to
generate machine code to test the actual type of
b and c at run-time, and then branch to one of several
chunks of code for adding:
    integer + integer
    double + double
    integer + double
    double + integer
    integer + sequence
    sequence + integer
    etc.

Obviously you would have to generate a huge amount of code
for an apparently simple statement, because you don't
know the type of b or c at compile-time. So then you
say, let's not generate all that code for every addition
statement. Let's put it in a subroutine and call it when
we need it. That's fine, but you are now introducing
a subroutine call overhead, and you are losing
much of the speed advantage of compiling.

So then you say, let's generate in-line code (no call) only when
we know that a and b are both integers (because the
programmer declared them that way). We'll just emit
an ADD machine instruction. That's fine, but what if
you overflow 32-bits? Euphoria is supposed to automatically
convert to floating-point in this case. More code to emit.

It gets worse. Suppose you have:
    a = b[i] + c[j]

Although a, b and c might be declared as sequence, and
i and j are declared as integer, you have no idea what
type of object might be stored in b[i] or c[j]. To get some idea
you would have to examine all assignments to b and c
throughout the whole program. Even then you still might
not know.

I could go on, but I just wanted to give you a feel
for some of the issues. Some form of additional
"compiler technology" is likely to be added to
Euphoria to speed it up, but a traditional compiler
is not necessarily the way to go.

Regards,
     Rob Craig
     Rapid Deployment Software