Re: Front End? (Was: Re: async problem)
- Posted by Robert Craig <rds at RapidEuphoria.com> Dec 29, 2003
- 413 views
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