1. int.exe
I recently noticed that whenever I run the imakew script, I get an emake.bat
file which creates a file called int.exe
I don't see it in the bin folder, and searching Google, the archive, and
listfilter reveals nothing. When I click it, it pops up pretty much the same
thing that the standard exw.exe pops up.
However, the problem comes up when I try to run a Euphoria file. To which I
get
Fatal run-time error:
machine_proc/func(65,...) not supported
which makes the program crash. The only other error I can get it to make
mentions an 'ASCII 0 found'.
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?
2. Re: int.exe
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.
Matt
3. 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
4. Re: int.exe
Oh, wow. That sounds awesome, Robert!
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
5. Re: int.exe
Robert Craig wrote:
> 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.
<snip>
>
> then the back-end will be called
> via machine_proc(65,...) and will run the IL at *full speed*.
<snip>
>
> Only the parsing will be a bit slower.
>
> Before the change
> to complete open source, this would have been bad for business.
LOL!!! Erm, actually, I don't know whether to laugh or cry at that...
Anyway, against all my better judgement 
I've decided to launch an Eu Design
Central, which will no doubt take some time to get going and may well be
completely ignored, but anyone interested the tiny starter is:
http://palacebuilders.pwp.blueyonder.co.uk/dc.htm
Not sure how best to gather votes yet, and when I do I'll rank things
accordingly. Not my job to rip say OEspecs into digestable parts, or cover any
blatent bugs which crop up, they belong on sorceforge, which maybe this does too,
just I don't see it delivering [a consensus].
Pete
6. Re: int.exe
- Posted by don cole <doncole at pacbell.net>
Mar 17, 2007
-
Last edited Mar 18, 2007
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
7. Re: int.exe
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Mar 17, 2007
-
Last edited Mar 18, 2007
don cole wrote:
>
> Robert Craig wrote:
> >
> >
> > 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.
>
Look in your euphoria\source directory.
Matt
8. Re: int.exe
Matt Lewis wrote:
>
> don cole wrote:
> >
> > Robert Craig wrote:
> > >
> > >
> > > 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.
> >
>
> Look in your euphoria\source directory.
>
> Matt
Thank you Matt,
Yes, I do see backend.ex but I don't see any front-end anywhere.
Don Cole
9. Re: int.exe
don cole wrote:
>
> Matt Lewis wrote:
> >
> > Look in your euphoria\source directory.
> >
>
> Thank you Matt,
>
> Yes, I do see backend.ex but I don't see any front-end anywhere.
>
All of the euphoria files in that directory are the "front end" (except
for execute.e, which is the euphoria back-end).
Matt
