1. Indepth Analyses Of Euphoria Translator
- Posted by Mike The Spike <mtsreborn at yahoo.com>
Mar 29, 2001
-
Last edited Mar 30, 2001
I didn't find a single bug in the new translator...
BUT, (and there's always a butt...)
I did see many insufficiencies...
For one, code size is still way too big...
For two, execution speeds are still not as fast as
they should be...
It's jsut *slightly* improved performance, and
sometimes the interpreter beats the translator...
Maybe Rob should start all over again and design a new
translation sheme...
Aslong as it's faster...
For two, the code is still unreadable, mainly because
it's so big...
If the code size was reduced, you could hand-edit
stuff much easier, and it would pass as hand-written
code aswell...
For three, the runtime library is still in compiled
form...
It is my idea that there shouldn't even be one!
Code for runtime routines should be spewn out if
invoked, in a fil ecalled routines.c or something..
Aslong as we can port our programs to other platforms,
it'll be cool...
Rob, what's the latest story on this all?
Mike The Spike
2. Re: Indepth Analyses Of Euphoria Translator
MTS wrote:
> For one, code size is still way too big...
Well, the code is obviously always going to be larger than interpreted code,
and considerably larger than 'equivalent' C code. That's primarily because
of the overhead of the garbage collection, which has to be made explicit.
You can't just add two objects:
a = b + c
You have to dereference the prior values, hold and release temporary
expressions, and so on. Instead of nice, space efficient bytecodes, you're
at the mercy of whatever compiler you happen to be using.
Additionally, there's usually a tradeoff of speed versus size. For example,
instead of calling small, common routines (and incurring the associated
overhead), the compiled version inlines a lot of code with macros, making
the source code even larger.
> For two, execution speeds are still not
> as fast as they should be...
Relative to what? The interpreter? I'm not suprised that the interpreter
remains faster in many cases. For one thing, you have better control over
the optimization of the bytecodes, and deciding what needs to be inlined.
Garbage collection can be made implicit within the instructions, instead of
having to spell them out with seperate instructions.
If you were talking about low-level stuff (like adding integers), C code
might run faster. But when you start working with high-level constructs with
complex datatypes, bytecodes start coming into their own.
> For two, the code is still unreadable,
> mainly because it's so big...
And optimized. Integer code, for example, creates 'empty' blocks because the
compiler knows that it will never be reached.
> If the code size was reduced, you could
> hand-edit stuff much easier,
Or you could just use dummy routines at the high level, and then write a
routine that would seek out these dummy routines, and replace them with
appropriate calls.
> and it would pass as hand-written
> code as well...
Given that the code is worthless on it's own, I can't imagine why you would
want that.
> For three, the runtime library is still
> in compiled form...
I don't think that Robert is going to give away 'the keys to the kingdom',
so to speak.
-- David Cuny
3. Re: Indepth Analyses Of Euphoria Translator
Mike The Spike writes:
> I didn't find a single bug in the new translator...
I've fixed a couple of bugs since beta-1,
but it's getting pretty stable now.
> For one, code size is still way too big...
> For two, execution speeds are still not as
> fast as they should be...
I've reduced the code size slightly since beta-1,
and improved the speed slightly, but my main
goal now is to make it stable so I can get
an official release out. I'm also adding support
so you can make a .dll (or .so) from Euphoria source.
> the code is still unreadable, mainly because
> it's so big...
Readability of the code is of secondary importance
to me. Most people will just translate/compile/run
without looking at the code.
(At least I indent the C code nicely for you, and
if you have the registered version I include
the Euphoria statements as a comments.)
> For three, the runtime library is still in compiled
> form...
> It is my idea that there shouldn't even be one!
> Code for runtime routines should be spewn out if
> invoked, in a fil ecalled routines.c or something..
> Aslong as we can port our programs to other platforms,
> it'll be cool...
It's not as simple as you suggest.
I can't just output the source to
individual small run-time routines.
There's a lot of inter-connected "machinery"
beneath the surface of the runtime library.
I'd end up outputting most of it each time.
However I'd like to work out a scheme where people can
buy the source.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Indepth Analyses Of Euphoria Translator
> MTS wrote:
>
> > For one, code size is still way too big...
>
> Well, the code is obviously always going to be
> larger than interpreted code,
> and considerably larger than 'equivalent' C code.
> That's primarily because
> of the overhead of the garbage collection, which has
> to be made explicit.
> You can't just add two objects:
>
> a = b + c
>
> You have to dereference the prior values, hold and
> release temporary
> expressions, and so on. Instead of nice, space
> efficient bytecodes, you're
> at the mercy of whatever compiler you happen to be
> using.
Yeah, but still, there must be a way to simplify
garbage collection...
The speed penalty is way too big...
You have a routine wich is called 5 million times,
then there can be hundreds of millions of Refs and
DeRefs that have to be performed...
> Additionally, there's usually a tradeoff of speed
> versus size. For example,
> instead of calling small, common routines (and
> incurring the associated
> overhead), the compiled version inlines a lot of
> code with macros, making
> the source code even larger.
Well, not realy...
Calling a macro or calling a function requires the
same space, ie one labeled call...
The produced executable is bigger, though, but that's
not that bad realy...
> > For two, execution speeds are still not
> > as fast as they should be...
>
> Relative to what? The interpreter? I'm not suprised
> that the interpreter
> remains faster in many cases. For one thing, you
> have better control over
> the optimization of the bytecodes, and deciding what
> needs to be inlined.
That's not the case, as any inlining or bytecode
optimisations can be directly performed on the C
source aswell, wich I'm betting the translator is
allready doing...
> Garbage collection can be made implicit within the
> instructions, instead of
> having to spell them out with seperate instructions.
>
> If you were talking about low-level stuff (like
> adding integers), C code
> might run faster. But when you start working with
> high-level constructs with
> complex datatypes, bytecodes start coming into their
> own.
The speed gain is just not worth the trouble writing a
translator for, especially if things like DLL
compilation and interfacing with C code isn't
utilised...
The translated code could be a max of only 10% slower
than equivalent hand-written C code, but obviously
it's not.
> > For two, the code is still unreadable,
> > mainly because it's so big...
>
> And optimized. Integer code, for example, creates
> 'empty' blocks because the
> compiler knows that it will never be reached.
>
> > If the code size was reduced, you could
> > hand-edit stuff much easier,
>
> Or you could just use dummy routines at the high
> level, and then write a
> routine that would seek out these dummy routines,
> and replace them with
> appropriate calls.
Did that, it was called MTSECW...
> > and it would pass as hand-written
> > code as well...
>
> Given that the code is worthless on it's own, I
> can't imagine why you would
> want that.
Well, it'd make a damned good resume don't ya think?
Anyone that can code a C app in the complex fashion as
the translater emits, is a coding genius...
:P
> > For three, the runtime library is still
> > in compiled form...
>
> I don't think that Robert is going to give away 'the
> keys to the kingdom',
> so to speak.
Rob said he would do it, but *when* is the key...
> -- David Cuny
Mike The Spike
>
5. Re: Indepth Analyses Of Euphoria Translator
Rob,
> I'm also adding support so you can make
> a .dll (or .so) from Euphoria source.
Isn't a .dll the same as an executable, basically, in that it can be a
trojan horse for virulent or merely destructive code if you don't know
what's inside or you're not confident in its distributor?
IOW, would it be possible for someone to create a euphoria program that
deletes all data from your hard drive, turn it into a dll, then provide the
function of "scanHarddriveForViruses?"
Ouch!
<\<
6. Re: Indepth Analyses Of Euphoria Translator
MTS wrote:
>>I don't think that Robert is going to give away 'the
>>keys to the kingdom',
>>so to speak.
>
>Rob said he would do it, but *when* is the key...
He said he'd 'license' the code... A slightly different ball of wax.
-- David Cuny
7. Re: Indepth Analyses Of Euphoria Translator
>
> Mike The Spike writes:
> > I didn't find a single bug in the new
> translator...
>
> I've fixed a couple of bugs since beta-1,
> but it's getting pretty stable now.
>
> > For one, code size is still way too big...
> > For two, execution speeds are still not as
> > fast as they should be...
>
> I've reduced the code size slightly since beta-1,
> and improved the speed slightly, but my main
> goal now is to make it stable so I can get
> an official release out. I'm also adding support
> so you can make a .dll (or .so) from Euphoria
> source.
>
> > the code is still unreadable, mainly because
> > it's so big...
>
> Readability of the code is of secondary importance
> to me. Most people will just translate/compile/run
> without looking at the code.
> (At least I indent the C code nicely for you, and
> if you have the registered version I include
> the Euphoria statements as a comments.)
>
> > For three, the runtime library is still in
> compiled
> > form...
> > It is my idea that there shouldn't even be one!
> > Code for runtime routines should be spewn out if
> > invoked, in a fil ecalled routines.c or
> something..
> > Aslong as we can port our programs to other
> platforms,
> > it'll be cool...
>
> It's not as simple as you suggest.
> I can't just output the source to
> individual small run-time routines.
> There's a lot of inter-connected "machinery"
> beneath the surface of the runtime library.
> I'd end up outputting most of it each time.
> However I'd like to work out a scheme where people
> can
> buy the source.
I understand.
But if you'd sell the source, I know *I*'d buy it!
And I'm sure people like David Cuny would too.
Being able to port the runtime library, and using ECW
to compile, (and by declaring a fake WinMain,
offcourse), would allow our Euphoria programs to run
on whatever platform we ported the runtime library to.
Imagine coding a Hello World app like this:
puts(1,"Hello world")
Translating it to C, burning the executable to a CD-R,
plugging it into your Playstation or Dreamcast, and
seeing it run!
Since consoles have small amounts of RAM, Eu's
excellent garbage collection would let our games be
bigger than most out there, and it would be easy to
code our console games, as we code it, and test it by
running it with Ex*.exe!
Wanna port it to the PC? No problem!
With good coding style, all you have to do is
recompile with another C compiler!
Wanna see a Dos32lib app on your Playstation?
You can!
Since I am a PSX/DC 'hobby' coder, I will do the port
of the runtime library to PSX and DC.
DC not being that hard, as it runs on Windows CE and
uses MSVC to compile programs.
PSX uses GCC, so that won't be that hard eighter...
I'd hardware-accelerate pixel(), and set up
draw_polygon() to read at a given memory address to
find a texture to map.
Imagine the possibilities...
Mike The Spike
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>
> >
> >
> >
>
8. Re: Indepth Analyses Of Euphoria Translator
Wha?
No, wait....
..
Wha?
Yeah, but so what?
You are saying that not having the source to a
Euphoria library, can mean that it could be a virus
and you wouldn't know it, therefore, let us forget
about DLL compilation and stay in thiss little
200-people community with no one knowing we exist, am
I correct?
Think of customers, people that want to buy plugins
for apps or games, should they first go to
www.rapideuphoria.com, download Euphoria To C, visit
the archive, download the source to your library,
register Euphoria To C, download a C compiler,
translate your library to C, link it into a DLL, and
then use it, just because it *might* contain a virus
otherwise?
Why are people on this list so afraid of viruses?
It's not even healthy anymore!
Just get a Virus Scanner and scan your HD, most email
clients do that for you automatically anyways, and
stop worrying!
Did you know I can code a Euphoria app that deletes
your hard drive and you wouldn't even know it?
No scanner would nottice it as it is in source-code
form.
Therefore, my analogy is: Eu source is even more
likely to contain viruses than an executable!
I'd mask the inner workings of the code by doing
something crazy like this:
sequence c
c = "ABBADDAAAADBBAAA"
for i = 1 to length(c) do
if c[i] != -1 do
c[i] = unmask(c[i])
end if
end for
atom a
a = allocate(length(c))
poke(a,c)
call(a)
Would you know that 'c' contained masked Machine Code
that performes a format of your hard-drive?
Exactly...
In a 1000-line app, you wouldn't even nottice the
above code!
Mike The Spike
--- CK Lester <cklester at yahoo.com> wrote:
> >
>
> >
> >
> >
> Rob,
>
> > I'm also adding support so you can make
> > a .dll (or .so) from Euphoria source.
>
> Isn't a .dll the same as an executable, basically,
> in that it can be a
> trojan horse for virulent or merely destructive code
> if you don't know
> what's inside or you're not confident in its
> distributor?
>
> IOW, would it be possible for someone to create a
> euphoria program that
> deletes all data from your hard drive, turn it into
> a dll, then provide the
> function of "scanHarddriveForViruses?"
>
> Ouch!
>
> <\<
>
>
>
>
>
>
>
> >
> >
> >
>
9. Re: Indepth Analyses Of Euphoria Translator
Mike,
> Yeah, but so what?
I've NEVER had a virus infection on any machine for which I was responsible.
> You are saying that not having the source to a
> Euphoria library, can mean that it could be a virus
> and you wouldn't know it, therefore, let us forget
> about DLL compilation and stay in thiss little
> 200-people community with no one knowing we exist, am
> I correct?
No no no. I'm simply saying, should I take the same precautions with DLLs
that I do with EXEs... in regards to their potential use for "bad things."
> Think of customers, people that want to buy plugins
> for apps or games, should they first go to
> www.rapideuphoria.com, download Euphoria To C, visit
> the archive, download the source to your library,
> register Euphoria To C, download a C compiler,
> translate your library to C, link it into a DLL, and
> then use it, just because it *might* contain a virus
> otherwise?
In this case, the DLL would be well-tested and general users could be
reasonably confident that the DLL would perform as specified.
> Just get a Virus Scanner and scan your HD, most email
> clients do that for you automatically anyways, and
> stop worrying!
If I wrote a EUPHORIA program called "FunnyVideo.exe," that actually deleted
all contents off your hard drive, no virus checker is going to be able to
determine what my program does... In this case, it's not a virus, but the
enemy in a trojan horse.
<\<
10. Re: Indepth Analyses Of Euphoria Translator
Hmm, allright then, so you are *for* the idea of DLL
compilation...
*sigh*
I allmost thought panic was about to break out about
this whole DLL compilation thing possibly deleting
your hard drive, and Rob might change his mind...
I can see many benefits to DLL compilation,
for one, I'd be able to provide my Euphoria libraries,
wich use Eu's excellent features, to C++ and VB
programmers.
I could create a DLL called win32lib.dll, and I'm
betting people will use that instead of MFC.
And for example, I can now create MODs and plug-ins
for various programs out there.
A WinAmp plug-in? A 3DSMAX plug-in? etc...
What would be nice would be to have the source to the
DLLs you download, though.
Not because of the whole virus thing, but because it
would be educational to see how it all works.
I wouldn't want to see all future Euphoria libraries
to be precompiled DLLs without source, know what I
mean?
Also, your Eu apps can now be extended by plugin DLLs
written by other Eu coders...
Maybe something cool for David's llama library?
Create a new control by coding a DLL?
Mike The Spike
--- CK Lester <cklester at yahoo.com> wrote:
> >
>
> >
> >
> >
> Mike,
>
> > Yeah, but so what?
>
> I've NEVER had a virus infection on any machine for
> which I was responsible.
>
> > You are saying that not having the source to a
> > Euphoria library, can mean that it could be a
> virus
> > and you wouldn't know it, therefore, let us forget
> > about DLL compilation and stay in thiss little
> > 200-people community with no one knowing we exist,
> am
> > I correct?
>
> No no no. I'm simply saying, should I take the same
> precautions with DLLs
> that I do with EXEs... in regards to their potential
> use for "bad things."
>
> > Think of customers, people that want to buy
> plugins
> > for apps or games, should they first go to
> > www.rapideuphoria.com, download Euphoria To C,
> visit
> > the archive, download the source to your library,
> > register Euphoria To C, download a C compiler,
> > translate your library to C, link it into a DLL,
> and
> > then use it, just because it *might* contain a
> virus
> > otherwise?
>
> In this case, the DLL would be well-tested and
> general users could be
> reasonably confident that the DLL would perform as
> specified.
>
> > Just get a Virus Scanner and scan your HD, most
> email
> > clients do that for you automatically anyways, and
> > stop worrying!
>
> If I wrote a EUPHORIA program called
> "FunnyVideo.exe," that actually deleted
> all contents off your hard drive, no virus checker
> is going to be able to
> determine what my program does... In this case, it's
> not a virus, but the
> enemy in a trojan horse.
>
> <\<
>
>
>
>
>
>
>
> >
> >
> >
>
11. Re: Indepth Analyses Of Euphoria Translator
- Posted by David Cuny <dcuny at LANSET.COM>
Mar 30, 2001
-
Last edited Mar 31, 2001
MTS wrote:
> But if you'd sell the source, I know *I*'d buy it!
> And I'm sure people like David Cuny would too.
The engine would be great for a commercial language if I wanted to support
sequences. But I don't really want to write a commercial product. Just ask
Robert how much of his time goes to coding, relative to supporting the
product. It's much easier to release stuff as Open Source - more eyes
looking at the code, and more people able to contribute.
I doubt that Robert would allow the source code to be released in an Open
Source project.
I'd also probably want to support more than data types than Euphoria does.
But because of the way that Euphoria encodes pointers, it's restricted as to
the number of complex data types it can represent in an integer.
Don't get me wrong - Robert's created a great sequence engine. It just
wouldn't be that useful for my purposes.
-- David Cuny
