Re: int.exe

new topic     » goto parent     » topic index » view thread      » older message » newer message

Matt Lewis wrote:
> Jesse Adkins wrote:
> > I recently noticed that whenever I run the imakew script, I get an emake.bat
> > 
> > file which creates a file called int.exe
> > 
> <snip>
> > 
> > I tried putting it in a clean bin repository but it still crashes. Upon 
> > examing the emake.bat file, I notice that it's not compiling any .c files 
> > with a be_ prefix to them.
> > 
> > Anyone know what the int.exe file is for?
> 
> If you examine the imakew file, Rob is using int.ex as the input to ecw
> to translate the front end.  If you run emake.bat, it will try to build
> that using the euphoria back end, which isn't what you want.  The trick
> is that Rob is mixing the translated front end with the hand coded back
> end (the be_*.c files).
> 
> Without looking, I believe that machine proc 65 is how the backend is
> initialized by the front end.  Take a look at backend.e, which basically
> puts the symbol table into a big C structure that the back end can use.
> 
> In short, don't bother with the emake.bat created, and ignore int.exe if
> you do.  Also, the batch file doesn't work with open watcom.  You need to
> use the makefile.

The above is all true, but it reminded me that a long time ago, 
in the pre-open-source days, I inserted "return ATOM_1;"
in case M_BACKEND (case 65), in the situation where the Euphoria 
front-end was being interpreted. I did this to help ensure
that no one could run the fast (C-coded) back-end by calling
machine_proc(65,...) from the new open-source Euphoria-coded
front-end. (You would also have needed to know the IL 
format, by looking at backend.e, which was available in the Source
Code product).

Anyway, I took that limitation out just now, 
and checked in be_machine.c. The code now reads:
    #ifndef ERUNTIME
            case M_BACKEND:
                return start_backend(x);
                break;
    #endif

It means you can now run things like:
   ex int.ex myprog.ex
or
   exw int.ex myprog.exw
or
   exu int.ex myprog.exu

to run the official Euphoria interpreter, where the front-end
will be interpreted, and then the back-end will be called
via machine_proc(65,...) and will run the IL at *full speed*. 
You can even bind int.ex to get a (more convenient) int.exe 

You can't translate/compile int.ex though, because the
Translator library does not include the IL executor code
from be_execute.c. (translated programs normally would
never need that code). 

This means, that any Euphoria programmer can now modify 
the Euphoria front-end, (which is written in pure Euphoria code), 
and create a modified interpreter that will run programs 
at full speed (much faster than using the Euphoria-coded execute.e). 
Only the parsing will be a bit slower. Before the change 
to complete open source, this would have been bad for business.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu