From: dxforth@gmail.com   
      
   On 20/02/2026 9:58 pm, albert@spenarnc.xs4all.nl wrote:   
   > In article <6997b9e1$1@news.ausics.net>, dxf   wrote:   
   >> On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:   
   >>> ...   
   >>> Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)   
   >>> This was done with a so called metacompiler. Once you get used to   
   >>> this tool, it is comparitively easy to port to new microprocessors.   
   >>> In this development path, the first thing you do is to write a   
   >>> Forth assembler for the new processor, then insert the uP-dependant   
   >>> stuff into the metacompiler tool.   
   >>> In this way the meta sources determine what is present, possibly   
   >>> a bit idiosyncratic.   
   >>>   
   >>> I consider my assembler sources more valuable than an open source   
   >>> metacompiler system, so I choose that route.   
   >>   
   >> Not only was native assembler easier for me as I mentioned, it was   
   >> considerably faster.  Running the F83 metacompiler on a 4MHz Z80 was   
   >> painfully slow.  On top of this I'd have needed to modify it to do   
   >> dictionary segmenting - my prime motivation in creating a forth.   
   >> Even the ubiquitous M80 CP/M assembler proved too slow and I invested   
   >> in an SLR Systems assembler.  Given the number of compiles I did in   
   >> development it was easily the best money I ever spent on software.   
   >> Not that I wasn't forced to learn new stuff.  Macros, code segmentation,   
   >> etc gave me enough headaches.  Looking back it seems crazy.  No regrets   
   >> however as I began to realize this was more my niche than writing   
   >> applications.  That said, if one doesn't write apps there's no way to   
   >> evaluate the effectiveness of a given forth.  How many forths never got   
   >> past creation because the author's interest waned.  For these the list   
   >> of words in ANS etc suffices.  But the forth one uses is something else.   
   >> It's the difference between a living tree and what comprises trees.   
   >> Standards are an obsession with the latter and kind of misses the point.   
   >>   
   >   
   > All tools running on windows/linux are fast,   
   > The metacompilers do not run on the sbc and take at most seconds.   
   >   
   > Especially assemblers, building ciforth is in the milliseconds.   
   > (What they say in a blink of an eye).   
      
   Metacompilers have an air of cleverness but come with so many hurdles that   
   frankly if there's an alternate tool I'll use that.  I don't blame William   
   Payne (8051 FigForth) in the least for hiring Nautilus Systems to write his   
   metacompilers, or C.H. Ting for translating Bill Muench's metacompiler-based   
   eForth to MASM.  I figure there's enough masochism in Forth already without   
   looking for more ;-)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)