Re: Compiler status
From: Robert Craig <rds at ATTCANADA.NET>
> The Euphoria compiler project is moving along well.
> I'm successfully compiling all DOS32 programs in
> euphor22.zip, plus many large user programs
> such as the ee editor (over 10,000 lines of Euphoria).
good job :)
> I even compiled the Cuny/Gayle Euphoria interpreter,
> making it run the sieve benchmark 2.1x faster.
> Sieve, compiled by the new compiler, runs 2.6x faster
> than with ex. Shell sort runs 3.2x faster.
outstanding :)
i'm a little puzzled tho...
is this creation of yours turning EU code -into- C code, which
then needs to be compiled using a C compiler...
or...
is it actually compiling EU code into a stand alone executable
similar to bind, but without the overhead of the interpreter tagged
onto the .exe???
or is it doing both :) parsing the EU code, generating temporary
C code (held in ram or disk as a temp file, invisible to the user) and
then in turn calling a C compiler to act upon that intermediate stage
C code?
how will this affect things like run time error checking, and wont it
significantly affect the (perhaps largest blessing of EU) edit/run cycle
of program development?
will we now have an edit/convert/compile/link/run cycle???
will unintialized variables still be detected?
will gracefull program crashes be a thing of the past, replaced with
those dreaded, mysterious, inexplicable crashes without any sort
of data dump?
in short, we will now be facing many of the reasons not to
use C listed in C.DOC????
don't get me wrong here...i see a rather large need for being able
to port towards C compatibility...would make other OS porting
tasks much easier...and it would make porting programs written
in C already much easier to port into native EU code as well...
and I know i cannot have my cake and eat it too...
once again, kudos rob :)
--Hawke'
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
|
Not Categorized, Please Help
|
|
