Re: int.exe
- Posted by don cole <doncole at pacbell.net> Mar 17, 2007
- 532 views
Robert Craig wrote: > > 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), Where is that? This might seem a stupid question but I have Euphoria lastest addition. But I can't find that anywhere. > 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 > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> Don Cole