1. Front End? (Was: Re: async problem)
- Posted by EUPHORiCK <euphoric at cklester.com> Dec 29, 2003
- 431 views
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)
- Posted by Robert Craig <rds at RapidEuphoria.com> Dec 29, 2003
- 414 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
3. Re: Front End? (Was: Re: async problem)
- Posted by EUPHORiCK <euphoric at cklester.com> Dec 29, 2003
- 446 views
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)
- Posted by "Kat" <gertie at visionsix.com> Dec 29, 2003
- 431 views
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)
- Posted by Robert Craig <rds at RapidEuphoria.com> Dec 30, 2003
- 428 views
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)
- Posted by "Hayden McKay" <hmck1 at dodo.com.au> Dec 31, 2003
- 430 views
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)
- Posted by Robert Craig <rds at RapidEuphoria.com> Dec 31, 2003
- 415 views
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