1. Front End? (Was: Re: async problem)
Robert Craig wrote:
> Now that the front-end is going to be a distinct
> module written entirely in Euphoria, I'm more inspired to
> dump all sorts of information. The full path names
> of include files would certainly be useful. There's lots of
> other info from the symbol table that might also be useful.
Could I get more info on this "front-end" thingie? I still don't know
what that's all about.
2. Re: Front End? (Was: Re: async problem)
C. K. Lester wrote:
> Could I get more info on this "front-end" thingie? I still don't know
> what that's all about.
By "front-end", I mean Euphoria's scanner, parser
and Intermediate Language (IL) emitter. I'm rewriting
all that in Euphoria itself. It's currently all written in C.
By "back_end", I mean the engine that executes the IL,
or, in the case of the Translator, the code that translates
the IL into C. The translator back-end will also be rewritten
from C into Euphoria. Only the interpreter back-end
and Translator libraries will remain in C.
The main advantage to all this will be easier maintainability.
Euphoria code is much easier to write, and debug than C,
and it's easier to convince yourself that it's correct.
The split into front and back ends will, by itself,
promote maintainability, since it's easier to understand and
maintain two small distinct programs (or modules) than one big
interconnected one.
I've already translated several thousand lines, and I like
the result. I've got much of the front-end working in less
time than I expected. The parsing speed is very good.
In the new scheme of things the binder will become trivial.
Right now I have to perform dual maintenance on the binder
whenever there's an enhancement to the language.
I wrote a big blurb about this on December 5...
==========================================================
Here's the plan:
- Make a clear distinction between the Euphoria
"front-end" and the Euphoria "back-end".
- The front-end handles scanning, parsing, and emission of
low-level Euphoria intermediate language code (IL).
The front-end would be written in Euphoria.
- A back-end processes the IL.
- The interpreter back-end, written in C, executes the IL.
- The Translator back-end, written in Euphoria,
converts IL to C source, to be linked with the
run-time library portion of the back-end.
- What we call today "shrouded code" will in the future be IL.
(Some extra encryption may be applied as well).
- The binder will tack this IL onto the Interpreter back-end.
The Interpreter back-end will obviously be smaller than
the current Interpreter.
- When you bind you'll be able to choose whether debugging info
will be included or not in the bound file. It will be possible
to get a full ex.err dump even when your program's source code
is not included in the bound file (just symbol table,
line table info).
I would still release a single interpreter .exe file formed
by fusing the Euphoria-written front-end with the C-written
back-end, and keeping the IL in memory.
Advantages:
- Translator will be 100% Euphoria code
- Interpreter will be 30% Euphoria code
- binder (has always been written 100% in Euphoria)
becomes radically simpler, smaller (reduced to 1/10 the size?,
plus shared copy of front-end to produce the IL),
easier to maintain in the future
- bound files are bound with a smaller "back-end" only, though
the IL (even without debug info) might turn out to be a bit
larger, so this might not be an advantage overall
Disadvantages:
- The Interpreter front-end will be slower. Translator-generated
C won't be as fast as the current hand-coded C.
I tested "include win32lib.ew"
on my P4, with time() calls before and after the include.
It took less than 1/10 of a second to parse. So if it rises to
a few tenths of a second, who cares? On my old P2, purchased
4 1/2 years ago, it took several tenths of a second.
So I guess that might rise to a couple of seconds (on
a Win32Lib-based program, with windows popping up etc.
it will barely be noticed.)
When you bind or shroud a program, this extra parse time
will go away completely, and will be less than now,
since you are running the IL directly without any parsing.
Currently, bound programs are parsed.
Since we will no longer be binding with the full interpreter,
there will be no need to compress it. Not decompressing will
improve the start-up time slightly.
The size of programs that we write has not kept up with
the increases in CPU speed. At best, programs can only
grow linearly in size over time, whereas CPU speeds
keep increasing geometrically.
- The Translator will be slower. I don't care. It's currently
surprisingly fast, and the subsequent C compiles take
most of the time anyway. (The Translator could be run
by the interpreter, or it could translate itself into
a faster .exe for a given platform.)
I've already started converting front-end C code to Euphoria,
and I'm happy with the result so far. The code is
often simpler, cleaner, easier to understand, fewer lines, etc.
The whole mess involving malloc/free and growing
and shrinking countless data structures has been eliminated.
Strings are nicer to work with.
And of course I have subscript checking, etc. etc.
Also, there are places in the C code where I used a
complicated, ugly algorithm to gain a few cycles
or save a few bytes (on a 8 Mb RAM, 50 Mhz 486),
and it's no longer needed.
==========================================================
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Front End? (Was: Re: async problem)
Robert Craig wrote:
>
> C. K. Lester wrote:
>
>> Could I get more info on this "front-end" thingie? I still don't know
>> what that's all about.
>
> By "front-end", I mean Euphoria's scanner, parser
> and Intermediate Language (IL) emitter. I'm rewriting
> all that in Euphoria itself. It's currently all written in C.
> By "back_end", I mean the engine that executes the IL,
> or, in the case of the Translator, the code that translates
> the IL into C. The translator back-end will also be rewritten
> from C into Euphoria. Only the interpreter back-end
> and Translator libraries will remain in C.
What I really want to know is, "What does it mean for the end user?"
Will I notice any difference in how I currently develop programs, or is
all this going to be changes behind the scenes?
I read that prior blurb of Dec. 5th, but didn't quite understand all of
it except to determine that there's a-changes a-comin'!!! :)
4. Re: Front End? (Was: Re: async problem)
On 29 Dec 2003, at 15:22, C. K. Lester wrote:
>
>
> Robert Craig wrote:
>
> >
> > C. K. Lester wrote:
> >
> >> Could I get more info on this "front-end" thingie? I still don't know
> >> what that's all about.
> >
> > By "front-end", I mean Euphoria's scanner, parser
> > and Intermediate Language (IL) emitter. I'm rewriting
> > all that in Euphoria itself. It's currently all written in C.
> > By "back_end", I mean the engine that executes the IL,
> > or, in the case of the Translator, the code that translates
> > the IL into C. The translator back-end will also be rewritten
> > from C into Euphoria. Only the interpreter back-end
> > and Translator libraries will remain in C.
>
> What I really want to know is, "What does it mean for the end user?"
> Will I notice any difference in how I currently develop programs, or is
> all this going to be changes behind the scenes?
Specifically, what can we access that we cannot now? The list of variable
names and what they contain? A way to trap when contents of vars change,
instead of a type check now?
Kat
5. Re: Front End? (Was: Re: async problem)
C.K. Lester wrote:
> What I really want to know is, "What does it mean for the end user?"
> Will I notice any difference in how I currently develop programs,
> or is all this going to be changes behind the scenes?
Things will stay pretty much the same for the end user.
My main motivation is to improve the maintainability
and portability of Euphoria.
There will be a few (minor) positive side effects however:
- the interpreter that you bind with will be smaller
and use less memory
- bound programs will start up without any parsing required
- you'll be able to ship a shrouded or bound program and
*also* get a clear traceback with original variable names
if an error happens
- both translated and interpreted code will run a tiny bit faster
in some cases (due to some improvements that are now practical
in various optimization algorithms)
Of course, if someone buys the Interpreter source, they'll
see a parser written in pure Euphoria code, which will be easier
to work with than C, especially if they don't know C very well.
Perhaps they can use that parser to make other
Euphoria-related tools.
I think the main advantages to the user will come in
the long term. I suspect some interesting developments
could flow from this.
Kat wrote:
> Specifically, what can we access that we cannot now? The list of variable
> names and what they contain? A way to trap when contents of vars change,
> instead of a type check now?
No, but I might be more inclined to make symbol
information available, and provide more analysis of the source,
better "folding" of constant expressions etc.
Maybe I can (optionally) tell you when a symbol is declared
as global when it needn't be, when an atom variable could
be declared as integer etc. etc.
The parser (i.e. front-end) is now free to grow without
increasing the size of bound programs, or consuming memory
needed by the Euphoria program at run-time.
There are advanced algorithms I might want to add to
the Translator. It's 100% C now, but will become 100%
Euphoria. In Euphoria it will be easier and safer for me to
add these algorithms.
The run-time system is not changing.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Front End? (Was: Re: async problem)
Being able to insert data into a bound program would be cool.
Here is something I tried.
Mainprog.exe -- A bound header file for data.
data.ew -- data to be operated on.
routines.dat -- defined routines.
Merge.exe -- merges Mainprog.exe & data.ew
procedure merge()
integer fn
sequence executable,database,rtines
executable = read_64("Mainprog.exe")
database = read_64("database.ew")
rtines = read_46("routines.dat")
fn = open("setup.exe")
puts(fn,write_64(executable) & "\r\n"))
puts(fn,write_64(database) & "\r\n"))
puts(fn,write_64(rtines) & "\r\n"))
flush(fn)
end procedure
the data from 'data.ew' and 'routines.dat' was ingnored by
the new progam setup.exe
Only the data from 'Mainprog.exe' would run in the new program.
(I checked setup.exe with an editor and all the data was there.)
Is it possible to do something like this with another method?
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: <EUforum at topica.com>
Sent: Wednesday, December 31, 2003 4:34 AM
Subject: Re: Front End? (Was: Re: async problem)
>
>
> C.K. Lester wrote:
> > What I really want to know is, "What does it mean for the end user?"
> > Will I notice any difference in how I currently develop programs,
> > or is all this going to be changes behind the scenes?
>
> Things will stay pretty much the same for the end user.
> My main motivation is to improve the maintainability
> and portability of Euphoria.
>
> There will be a few (minor) positive side effects however:
> - the interpreter that you bind with will be smaller
> and use less memory
> - bound programs will start up without any parsing required
> - you'll be able to ship a shrouded or bound program and
> *also* get a clear traceback with original variable names
> if an error happens
> - both translated and interpreted code will run a tiny bit faster
> in some cases (due to some improvements that are now practical
> in various optimization algorithms)
>
> Of course, if someone buys the Interpreter source, they'll
> see a parser written in pure Euphoria code, which will be easier
> to work with than C, especially if they don't know C very well.
> Perhaps they can use that parser to make other
> Euphoria-related tools.
>
> I think the main advantages to the user will come in
> the long term. I suspect some interesting developments
> could flow from this.
>
> Kat wrote:
> > Specifically, what can we access that we cannot now? The list of
variable
> > names and what they contain? A way to trap when contents of vars change,
> > instead of a type check now?
>
> No, but I might be more inclined to make symbol
> information available, and provide more analysis of the source,
> better "folding" of constant expressions etc.
> Maybe I can (optionally) tell you when a symbol is declared
> as global when it needn't be, when an atom variable could
> be declared as integer etc. etc.
>
> The parser (i.e. front-end) is now free to grow without
> increasing the size of bound programs, or consuming memory
> needed by the Euphoria program at run-time.
>
> There are advanced algorithms I might want to add to
> the Translator. It's 100% C now, but will become 100%
> Euphoria. In Euphoria it will be easier and safer for me to
> add these algorithms.
>
> The run-time system is not changing.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
> --
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.556 / Virus Database: 348 - Release Date: 26/12/03
>
---
--
7. Re: Front End? (Was: Re: async problem)
Hayden McKay wrote:
> Being able to insert data into a bound program would be cool.
Try David Cuny's resource binder in the Archive.
I think it still works.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
