Re: int.exe
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
|
Not Categorized, Please Help
|
|