Re: Use of ';' in Forth Compiler
- From: "Elizabeth D Rather" <eratherXXX@xxxxxxxxx>
- Date: Mon, 27 Jun 2005 11:43:57 -0700
"Albert van der Horst" <albert@xxxxxxxxxxxxxxxxxx> wrote in message news:iiqtlz.c9r@xxxxxxxxxxxxxxxxxxxxx
In article <11bu00vs04obc67@xxxxxxxxxxxxxxxxxx>, Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote: <SNIP>
Languages that use more conventional parameter passing strategies have
overhead on entering and leaving subroutines consisting of the code to
manage the parameters being passed, setting up stack frames and taking them
down, etc. All of this goes away in Forth. In our implementations, for
example, the cost of calling a word is limited to the call/return
instructions only -- no register saving/restoring, no fiddling with
parameter passing, etc.
All of this becomes nowadays irrelevant, because both approaches use optimising compilers. The effort in optimising makes the resulting program converge between Forth and c, as well as the amount of effort. Of course there is an advantage in parameter passing for debugging. But please note that this means extra effort in providing a separate interpreter that may (or may not) behave exactly as the compiler.
I sometimes can't explain why I like Forth so much.
I don't think it's at all irrelevant, because not all Forths use optimizing compilers, and of those that do, not all optimize parameter passing in the same way. Particularly on devices without a large register bank, there can definitely be extra overhead in managing parameter passing in other languages, and in managing local variables in Forth.
Although timings in optimized Forths are certainly becoming comparable to C in straight execution-type benchmarks (where C used to have a very clear advantage in the past), I think highly modular Forth still has a measurable advantage over equally modular C (although C is rarely used with the level of modularity that's common in Forth).
I can't speak for you, of course, but the major reason I like it is because its level of interactivity (including as its modularity) makes it much, much quicker to develop and test applications. And that's all connected to the interpreter as well as the way the stack is used for parameter passing.
As Alex notes, the WikiPedia is a wildly unreliable and misleading source of
information on Forth. There are some good books on Forth and code supplied
with the better implementations, all of which will help you see how "a
'forther' would think".
You must read this is as: "the Forth community has failed miserably in providing reliable information on Forth. The great Forth experts tolerate that misleading information prevails on Wikipedia." (Note: I don't necessarily agree with this. It is what Elizabeth implies.) This is because Wikipedia is as good a medium as the community that provide the information.
You see information you don't like? You change it. It is as simple as that.
Not quite. You have to get approved to make changes. The first time I really read what WikiPedia said about Forth I was so appalled I tried to make some changes. I was told I had to apply for permission. I did so, and never heard from them again. I don't even know who "they" are. It contained some outdated links to our old web site, and I tried for over a year to get them changed, without success. Currently it's "locked for a software upgrade".
Unlike the Forth community the python communicaty has build a source library that dwarfs the Forth libraries by a large margin. Now check out the Wikipedia python information.
The Forth community has failed for years to contribute useful library material. The FSL is the only such body of code. For whatever reason, people would rather write Yet Another Forth than produce useful library code.
That wasn't really my point. Knowing several languages can be an asset, but
Forth is sufficiently different that you really need to understand some
fundamental things about it in order to either use it effectively or
implement it in an efficient way. An architectural analogy would be, if
you're skilled in building with wood and brick, that may not translate
directly into building with aluminum and steel; some new techniques will
have to be learned.
Wel of course you must understand steel before you design a building around reinforced concrete. So how could someone not working with Forth make a good decision whether to have ?DUP in the kernel, to pick on a controversial word? I'd say that a great deal of conversancy is needed.
Yes, I agree. That is precisely what I'm trying to convey.
-- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310-491-3356 5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454 Hawthorne, CA 90250 http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."