1. Is there an Euphoria compiler?
- Posted by Alan Tu <ATU5713 at COMPUSERVE.COM>
May 22, 1998
-
Last edited May 23, 1998
Is there, and if not, will there ever be, an Euphoria compiler? It seems=
to me that tacking on the whole interpreter to a program is not efficient=
=2E
--Alan
=
2. Re: Is there an Euphoria compiler?
- Posted by Terry Constant <constant at FLASH.NET>
May 22, 1998
-
Last edited May 23, 1998
Alan Tu wrote:
>
> Is there, and if not, will there ever be, an Euphoria compiler? It seems
> to me that tacking on the whole interpreter to a program is not efficient.
>
> --Alan
>
Alan,
What is good or efficient depends on your goal. For example, if you want
to move your belongings to another address, a large truck is efficient.
If you want to drive from the east coast to the west coast, a large
luxury car is efficient. Neither one is efficient for the task that the
other one was built for.
Euphoria follows a common practice of binding. A few other such programs
that pop into my head are REXX, Cenvi, O'Basic, some other basics I have
toyed with. Euphoria is very efficient for the task it is designed for.
If you want compiled programs and their much more cumbersome process,
then get Pascal, C, Visual Basic, etc. By the way, Visual Basic (I don't
know about the current version), tokenizes its code, interprets it, and
calls it compiled. But then look how cumbersome it is.
Euphoria qualifies as what programmers once referred to as elegant. It
is, a program that I can quickly and easily develop solid programs.
Euphoria is very eficient for such tasks. If I want to spend 10 times
more time writing programs that are more buggy, but that produce small
and lightning fast executables, then I will use Pascal or an optimize C
compiler.
I guess it all depends on what your goal is, what you mean by efficient.
--
Terry Constant
constant at flash.net
3. Re: Is there an Euphoria compiler?
- Posted by Irv <irv at ELLIJAY.COM>
May 22, 1998
-
Last edited May 23, 1998
At 08:39 PM 5/22/98 -0500, Terry Constant wrote:
>Alan Tu wrote:
>> Is there, and if not, will there ever be, an Euphoria compiler? It seems
>> to me that tacking on the whole interpreter to a program is not efficient.
>>
>> --Alan
>>
>
>Alan,
>What is good or efficient depends on your goal. For example, if you want
>to move your belongings to another address, a large truck is efficient.
>If you want to drive from the east coast to the west coast, a large
>luxury car is efficient. Neither one is efficient for the task that the
>other one was built for.
>
>Euphoria follows a common practice of binding. A few other such programs
>that pop into my head are REXX, Cenvi, O'Basic, some other basics I have
>toyed with. Euphoria is very efficient for the task it is designed for.
>If you want compiled programs and their much more cumbersome process,
>then get Pascal, C, Visual Basic, etc. By the way, Visual Basic (I don't
>know about the current version), tokenizes its code, interprets it, and
>calls it compiled. But then look how cumbersome it is.
>
>Euphoria qualifies as what programmers once referred to as elegant. It
>is, a program that I can quickly and easily develop solid programs.
>Euphoria is very eficient for such tasks. If I want to spend 10 times
>more time writing programs that are more buggy, but that produce small
>and lightning fast executables, then I will use Pascal or an optimize C
>compiler.
>
>I guess it all depends on what your goal is, what you mean by efficient.
>--
Well said. I can only add: Euphoria -- interpreted -- is faster
than compiled Pascal in many instances. See, for example,
my windoz GUI on my web site. It runs in SVGA mode
faster than a compiled Turbo Pascal version could.
Why?
Because Euphoria has a set of well-written low level graphics
routines. Euphoria is also nearly as fast as some C compiled
programs. So there's little to be gained by compiling.
Plus, with many programs, speed and compact code
are not nearly as important as a program that *works*
every time.
Irv
4. Re: Is there an Euphoria compiler?
Irv wrote:
<snipage>
> Plus, with many programs, speed and compact code
> are not nearly as important as a program that *works*
> every time.
>
> Irv
Such as programs in medical computers, Air-trafic controll, the
shuttle, etc.
I read somewhere (on one of c-nets sites, in an article about
really bad bugs) that once during the gulf war a scud got past a patriot
battery because bug in the software (some kind of cumulative error that
built up until it crossed some kinda threshold) and people died as a
result!
Kasey
-- WIN 95 a.k.a. WIN98 beta (early beta at that)
5. Re: Is there an Euphoria compiler?
At 01:03 AM 5/23/98 -0500, you wrote:
> Kasey
>
>-- WIN 95 a.k.a. WIN98 beta (early beta at that)
I have one of the win98 betas. It's kinda
like netscape meets XTGold and I think I
don't like it.
Oh yes and it crashes, of course.
Graeme.
----------------------------------------------------
6. Re: Is there an Euphoria compiler?
>Is there, and if not, will there ever be, an Euphoria compiler? It seems
>to me that tacking on the whole interpreter to a program is not efficient.
Not efficient ??
Wanne bet, a binded version of TextGUI is smaller than the MSDOS Editor.
which is an com file that launches qbasic /ascii_mode or something like
that).. so not the com file that comes wiht DOS, but the qbasic.exe or the
editor found with Win95.
My point is, an quake clone in Euphoria, would be slow, but so much more
smaller than the real quake.
Euphoria programs have binded a minimum about 160 kb, but from that point on
it increases almost nothing. Even the biggest programs only a few Kb. Big
programs, were size *does* count (unlike small programs) are still
relatively small and easy to distribute. Plus, remember, most of the 160 kb
is put in the extended memory thanks to the memory extender.
And last, but not least, it could be compiled much.
As an interpreter, Euphoria can do certain stuff, that compiled would be a
call to a piece of code, just like now.
Example, a decleration as object, you can't compile *anything* since you do
not know which data type it is gonna hold. You would create a mixture of
the interpreters code and a bit of code to call the interpreters code. What
exactly is the difference with a binded version ?? NONE
Yes, the code is now seperated and we needed to compile. Plus, compiling
would mean, Euphoria's safety would be gone.
Nope, from an Euphoria source code, there is no way to compile it into
anything significantly faster, since the compiler wouldn't have enough
information, that Euphoria does not need to have.
It would only need a lot more memory, and would run a lot less stable.
Compiled languages are fast, not because they compile (they wish), but
because they can optimize by asking the right questions. Asking such
question would eliminate Euphoria elegance.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
7. Re: Is there an Euphoria compiler?
If you have to drag your obscene wars into this, please do not blame the
programs/programmers for the mayhem. jiri
-----Original Message-----
From: Kasey <kaeyb at GEOCITIES.COM>
To: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Date: Saturday, 23 May 1998 18:14
Subject: Re: Is there an Euphoria compiler?
>Irv wrote:
>
><snipage>
>
>> Plus, with many programs, speed and compact code
>> are not nearly as important as a program that *works*
>> every time.
>>
>> Irv
>
> Such as programs in medical computers, Air-trafic controll, the
>shuttle, etc.
> I read somewhere (on one of c-nets sites, in an article about
>really bad bugs) that once during the gulf war a scud got past a patriot
>battery because bug in the software (some kind of cumulative error that
>built up until it crossed some kinda threshold) and people died as a
>result!
>
>
>
> Kasey
>
>-- WIN 95 a.k.a. WIN98 beta (early beta at that)
>
8. Re: Is there an Euphoria compiler?
At 12:07 AM 5/24/98 +1200, Jiri wrote:
>
>If you have to drag your obscene wars into this,
>please do not blame the programs/programmers
>for the mayhem. jiri
>
Ok. Instead let's blame the programs which run the
brakes on several million new (US) cars now being
recalled.
Personally, I would get a little nervous zipping
down the road at 70 mph with brakes as dependable
as Win95+++.....
Speaking of what we find "obscene" -- can anyone
explain why:
If an airliner crashes, and 200 people die, it is
major news. If one crashed every day, there would
be an uproar, and probably the airlines would be
shut down. Every day at least twice that many
people die in cars, and no one mentions it?
Where are the protest marches?
Just a thought for US readers: this Memorial Day
weekend; 2,000 people are expected to die in traffic.
Try not to be one.
Irv
9. Re: Is there an Euphoria compiler?
Irv wrote:
> At 12:07 AM 5/24/98 +1200, Jiri wrote:
> >
> >If you have to drag your obscene wars into this,
> >please do not blame the programs/programmers
> >for the mayhem. jiri
> >
> Ok. Instead let's blame the programs which run the
> brakes on several million new (US) cars now being
> recalled.
> Personally, I would get a little nervous zipping
> down the road at 70 mph with brakes as dependable
> as Win95+++.....
> Speaking of what we find "obscene" -- can anyone
> explain why:
> If an airliner crashes, and 200 people die, it is
> major news. If one crashed every day, there would
> be an uproar, and probably the airlines would be
> shut down. Every day at least twice that many
> people die in cars, and no one mentions it?
> Where are the protest marches?
> Just a thought for US readers: this Memorial Day
> weekend; 2,000 people are expected to die in traffic.
> Try not to be one.
>
> Irv
Hey, you haven't made a Public... err... what's the word? anyway, good
message.
Just to see: is there an #euphoria on EFnet?
BTW, I can't re-upload my file because it is already there... could you
delete it so I may resend it? (MTG Card Database.zip)
10. Re: Is there an Euphoria compiler?
Hi
I've just started using Euphoria and I like it quite a bit. I've
been programming for years on an Atari 1040 using a language called
GFA Basic and I've been looking for a good language on a PC that was
powerful, cheap, and easy to use. I didn't like pointers in C, and I
don't care for object oriented programming - the kind of programs I
write don't seem to fit the object paradigm very well.
Euphoria is different from other interpreters that I've used. In
them, the text editor is integrated to the interpreter so that you
can run the program without ever leaving the editting environment.
This is very convenient. With Euphoria, the process of running the
interpreter is almost exactly the same as running a compiler. This is
not convenient, but it's not a problem.
With GFA, I can write my program in the interpreter, which provides a
very convenient development environment, and then once the source
code is debugged I can just run it through a compiler that produces
code that will run as a stand-alone program. This stand-alone program
is -not- just the source code bundled with the interpreter - GFA
provides a run only interpreter that serves that function. The
compiled code is actual machine code, and the compiled program runs 2
or 3 times faster than the interpreted source code.
So, it seems to me that the main advantage of a compiler is that it
provides faster execution of the same source code, presumably because
the interpreter overhead is eliminated. A doubling of execution speed
is a major advantage.
Is it really impossible to provide a package that provides this
compiler function? I'd be interested in the details. It seems to me
that the engine that produces the code for the interpreter to send to
the CPU could be easily modified to send the code to a file instead.
Wouldn't that be a compiler?
Bye
Martin
11. Re: Is there an Euphoria compiler?
- Posted by Irv <irv at ELLIJAY.COM>
May 24, 1998
-
Last edited May 25, 1998
At 05:20 PM 5/24/98 +0000, Martin wrote:
>Euphoria is different from other interpreters that I've used. In
>them, the text editor is integrated to the interpreter so that you
>can run the program without ever leaving the editting environment.
You could get a copy of Dave Cuny's EE editor, which
can run or bind a program from the menu. It's in the package
text-gui (which is worth getting for other reasons as well).
>With GFA, I can write my program in the interpreter, which provides a
>very convenient development environment, and then once the source
>code is debugged I can just run it through a compiler that produces
>code that will run as a stand-alone program.
>Is it really impossible to provide a package that provides this
>compiler function?
Impossible? For me, yes. For you .. I don't know.
Will it happen? My best guess is *highly unlikely*,
from what Robt. Craig has said about this in the past.
You would lose several really neat features and
a lot of protection, is my understanding.
I'd be interested in the details. It seems to me
>that the engine that produces the code for the interpreter to send to
>the CPU could be easily modified to send the code to a file instead.
>Wouldn't that be a compiler?
Not exactly. (Any further explanation will require someone
smarter than me. Ralf?)
Regards,
Irv
Hundreds of Euphoria files - zero ads!
http://www.mindspring.com/~mountains
ftp.mindspring.com/users/mountains
12. Re: Is there an Euphoria compiler?
- Posted by lithex <lithex at POP.INTERGATE.BC.CA>
May 24, 1998
-
Last edited May 25, 1998
Hi
Thanks to Irv and Alan for recommending EE.Ex.
Thanks to Dave Cuny for writing it, it seems like a fine program, and
it will make my work easier.
I'll look up Robt Craig's comments in the archive - I'm not trying to
criticize a fine program, I'm just exploring a topic. I'd always
thought that an interpreter was kind of like a shell for a compiler,
or that an interpreter had a compiler living inside it. I didn't
think that they were so incompatible. Live and learn
Bye
Martin
13. Re: Is there an Euphoria compiler?
> I'd be interested in the details. It seems to me
>>that the engine that produces the code for the interpreter to send to
>>the CPU could be easily modified to send the code to a file instead.
>>Wouldn't that be a compiler?
>
>Not exactly.
Even if it was possible, would it be any faster? No
Would it require more memory? Yes for large programs.
Again, compiled languages are faster because they have demand more
information. That's why you have to specify a data type instead of a scaled
value like this.
Lets go back to your perspective, sending the code we execute to a file
instead..
One of the ways a program can make a computer seem to think, is by having it
made decisions and then choose which code to execute based upon that
decision. That is the whole idea of a computer.
Since we do not want to execute the same code again and again, we would like
some interaction.
Which means some decisions have to be made in run-time (when you run your
program)
Euphoria's elegance, provided because its language definition is based upon
the flexibilities of an interpreter, exist because it makes all decisions at
run time. (actually, those decisions he can make at forehand are done by a
quick preproccesor that prepares the execution stack).
You could see it like this:
The interpeter reads your program and makes a stack.
At this point, we have all the code the most memory efficient compiler would
produce only in a different order.
We have a stack full of machine addreses of the machine code to be executed
and their arguments, are on the stack also. All variables are replaces by
machine addreses.
So, at this point the overhead is *one* "jmp" per statement. ( foo = bar +
5 --> 2 statements: addition and a store )
About 0,0001 % of the execution time.
No reason to create such a brilliant compiler. 1) It takes a lot of time 2)
More chances on bugs
On the other hand, a much simpeler compiler, a real compiler approuch would
produce a program with _no_ run-time checking of anything. Make a mistake..
BOOM. and it still wouldn't be much faster for sequences anyway.
The problem is not the compiler/interpreter as you have now seen the small
overhead actually caused by that difference. The problem is that interpreter
has to check and do a lot of things at run-time. Both could be optimized
with more specific information. A fixed-length sequence subscripts way
faster. Thats is also why types would speed up a program. They know the
*fixed* position of eveyr element.
And fixed is off course the oposite of flexibile.
Like some one else said.. if you want small don't use Euphoria.. if you
wanne be big .. eh.. :)
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
Maybe Robert could explain the stack-interpreter method Euphoria uses a bit
better than I just did, so people have a better understanding of the
internals of Euphoria and its behaviour.
14. Re: Is there an Euphoria compiler?
Thanks to Ralf for his explanation about compilers vs interpreters.
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.
So the way I thought it would work is that if you had bug free source
code that the compiler would do all of the checking that the
interpreter does for each run at the compile time. Then when the
compiled code was run, all of that run time checking would not have
to be done. This is what I meant by reducing the overhead.
I gather, from what Ralf is saying that a compiled program still
does all of those run time checks and so the overhead is basically
the same. Is this what's going on?
Thanks for the feedback about this.
My compliments to the creators of Euphoria. I really like the
sequences. I really like the flexible variable types. I really like
the debugging tools. I've been porting a program from my Atari into
Euphoria and it's only taken me a day to do almost 200 lines of code.
Bye
Martin
15. Re: Is there an Euphoria compiler?
Ralf Nieuwenhuijsen wrote:
>
> Even if it was possible, would it be any faster? No
> Would it require more memory? Yes for large programs.
>
> Euphoria's elegance, provided because its language definition is based upon
> the flexibilities of an interpreter, exist because it makes all decisions at
> run time. (actually, those decisions he can make at forehand are done by a
> quick preproccesor that prepares the execution stack).
>
>
> And fixed is off course the oposite of flexibile.
> Like some one else said.. if you want small don't use Euphoria.. if you
> wanne be big .. eh.. :)
>
A couple of thoughts.
I like the fact that, with Euphoria, I can run a source file, a shrouded
file, or a bound file. They all run EXACTLY the same. That is not true
of any other language I have used that allows interpreted running and
compiling. The compiled version always has a few limitations that are
not in the interpreted version.
Now as to size. I am experimenting with running shrouded programs. For
example, I shroud Test.ex to Test.exs. During development I run Test.ex.
For actual use I run Text.exs. The shrouded program is small. Since
Ex.ex or Exw.ex is in my disk cached, the load time for multiple
programs is as fast as loading very small .exe files. Overall, by using
shrouded files, I have small and fast "compiled" programs. There is no
way I would replace Euphoria's way of doing things with the more
cumbersome ways of existing compiled languages. Plus, I get to use my
favorite text editor during development with no loss of ability. For me
using that very powerful editor that I know so well, makes my
development time much faster than using the editors that come with
various IDEs of popular compiled languages.
The short statement of all this. I LIKE the way Euphoria handles the
interpreted/compiled issue. I don't desire a change in this issue.
--
Terry Constant
constant at flash.net
16. Re: Is there an Euphoria compiler?
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
17. Re: Is there an Euphoria compiler?
Thanks to Robert Craig for his posting about compilers.
I think I understand the issues now and I appreciate the explanation.
Bye
Martin
18. Re: Is there an Euphoria compiler?
Robert Craig wrote:
<snipage about how full compile would be a pain for way to
little if any speedup>
>
> 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
Of course if your feeling masochistic could try compiling as much as
possible/makes sense then rewriting the interpreter for whats left in
assembly, you'll probably get some speedup and a smaller ex(w).ex.
Kasey
