M. Anton Ertl writes in <28u6ou$mmn@email.tuwien.ac.at>
> Interpreted Forths are 5-10 times slower than assembly language,
> Native code Forths as fast as C. Since there are Forths written in C,
> the availability of Forth is art least as good as that of C. There are
> commercail Forths for all price ranges, and some usable free
> implementations, too. If C is modest-sized, even F-PC is small.
|> > Now, there are various gaps to close. How good can Forth code be made? Is
|> > a built in garbage collector desirable?
|>
|> FORTH generally does not need garbage collection because all
|> memory allocation is under the user's control. That is, FORTH
|> does not often use linked lists (other than the dictionary) and
|> if a user defines a LL, then it is his responsibility to see that
|> the trash is taken out.
> Those numeric guys obviously have never felt the need for garbage
> collection. But for the work I do, having to program storage
> reclamation by hand is a pain in the ass. So, yes, garbage collection
> would be desirable. However, in contrast to Robin Popplestone I don't
> think that conservative garbage collectors don't count. They may have
> their problems, but they are better than nothing. Although having no
> storage reclamation also works for my applications in my environment
> (64MB RAM, 384MB swap space).
Micheal Coughlin writes in <28ui3nINN12f@life.ai.mit.edu>
> If you use Forth to work with symbolic data, manipulate text
> strings, and such stuff, then you'd probably want to incorporate
> the same type of garbage collection as is used by the langauges
> that are usually used to do this work. But this is not a part of
> Forth, it is an extension for a particular application.
Garbage collection involves an intimate knowledge of the implementation of
a language. So, unless a language is very tightly specified, it is not just
an add-on. This was the point I was at pains to make about Algol 60 ---
things have not changed since. Standard, non-conservative, collectors
require to be able to recognise an object unambiguously, which is
constraint on implementation. Language design may also -prevent- the
efficient use of some kinds of garbage collection. For example, the only
way I can see of supporting pointers in a garbage collected C might be to
make them be (base,offset) pairs to a block created by malloc.
The performance of a (non-conservatively) garbage collected language can be
-superior- for applications that significantly fragment store, because the
collector can address issues of locality, compacting the working set of
objects . In doing this it makes use of its freedom to move objects around,
which a conservative collector cannot do, since it only knows that things
may be pointers (to be updated therefore) or may not (e.g. they may be
integers -not- to be changed).
Steve Knight who writes applications for Hewlett Packard reckons that, for
a given effort, he can write a POP-11 program for many applications that
runs twice as fast as the equivalent C. Being able to use appropriate
data-structures for the -problem-, knowing that he does not have to worry
about reclaiming them, a particularly serious problem in an interactive
program that may run ad infinitem, slowly clogging up its virtual memory as
it does.
I don't have enough detailed knowledge of Forth to know whether it would be
easy to garbage-collect. But is there a POPLOG user out there who would
think it a good student project to implement Forth within POPLOG? One might
even get a shrunk-wrapped stand-alone garbage-collected version if one knew
enough about how to relink Poplog with -just- what one needed.
Robin Popplestone.
|