Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.forth    |    Forth programmers eat a lot of Bratwurst    |    117,927 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 117,922 of 117,927    |
|    Hans Bezemer to dxf    |
|    Re: Evolution of Forths was Re: Recogniz    |
|    21 Feb 26 16:35:33    |
      From: the.beez.speaks@gmail.com              On 20-02-2026 02:33, 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.       >              You're hitting the nail on the head: if making a Forth compiler is the       only goal, then what use is it to make it "standards compatible". A       Forth compiler is no different from any other program: if the goal is       "just making it work" then essentially the purpose is fulfilled once       it's done.              But useful programs (if only in the eye of the beholder) are USED. They       live. They fail. They develop (as you stated - often beyond standards).              IMHO opinion standards are only useful if they have to be transferred -       from person to person or from platform to platform. I can't say I       haven't benefited from that idea in one way or another. But like you       said - let's keep its true value realistic and pragmatic.              Hans Bezemer              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca