[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Oct 7 09:41:54 1993 
Subject:Re: Threaded Interpretive Languages 
From:Robin Popplestone 
Volume-ID:931008.03 

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.