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
|
Not Categorized, Please Help
|
|
