Hello AmForth-ers: I don't think that people look for speed when considering any Forth -- modern optimizing C compilers will do better.
Nevertheless, I think that we need to rid AmForth kernel ASAP of VM instruction calls (those pesky XT_'s) and leave them for compiled code output only. Let's start with a common construct such as the "do ... loop" (words/do.asm). It can be a group effort if Matthias encourages :-) Sincerely, Enoch. Matthias Trute <mtr...@web.de> writes: > Hello, > >> Has there been any thought about optimizer? > > A lot. And a lot of discussions with people who > know a lot more than I do in this specific area > of wisdom. The final judgment is as it is: for > an ITC forth there are only very few possibilities. > > One is a statistical analysis to find code sequences > that are worth combining into one command. e.g. > "dup if" can be combined to a dup-if that avoids > the stack duplication and makes the flag check > non-destructive (does not drop the Top-Of-Stack > element). This will be both faster and smaller in > the resulting code. > > The downside is that you'll need a real large number > of such words, that nobody with his right mind would > ever consider to use. And these words do need code > space. It is possible, to combine this with the > build process of amforth. Here you can include > tailored word sets that perfectly match your other > forth code needs. On the host side, you can have any > amount of ressources to optimize the result ;) > > For a forth with a real code generator (e.g. the > "competitive" flashforth) there are many more > possibilities to optimize the resulting code. This > optimization works on the resulting machine > code, not at the forth level. > > The next difficulty is that an optimizer needs code > space itself. For a host-based forth this should not > be a problem at all, but an already size restrained > system could be troublesome. The optimizer may save > say 200 cells of code space and need 300 cell itself. > > The only solution would be the already mentioned > preprocessor that works on the forth code on the > host and generates other, optimized forth code or > even a specialized amforth system that goes to the > controller. Something the shell already does > with its inline replacements of constants with their > numbers. > > To answer the OP question: > > Arduino Sketches are probably always faster than amforth > code. Depending of the benchmark (synthetic loops that > stupidly count numbers) there may be a factor of 1:100 or > more. > > Amforth has other strengths, IMHO ;) It is probably > the smallest text interpreter (try to write such a > thing in arduino sketch and beat the 8KB code space). > > Number-IO and formatting is another nice thing. I've seen > quite a few sketches that read some data from the analog > ports and try to print them to the serial port. What did > I smile about them. > > Matthias > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
