Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #50554 > unrolled thread

Implementing lisp in Forth. Chapter 4.

Back to article view | Back to comp.lang.forth

Contents

  Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-29 18:41 +0200
    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-08-29 09:39 -0700
      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-30 10:49 +0200
    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-08-29 09:46 -0700
      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-08-30 11:07 +0200
        Re: Implementing lisp in Forth. Chapter 4. Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-08-30 08:00 -0400
          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-02 12:34 +0200
        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-08-31 14:23 -0700
          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-01 02:15 +0200
            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-01 19:49 -0700
              Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-02 11:49 +0200
                Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-04 11:28 -0700
                  Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-05 03:31 +0200
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-04 21:03 -0700
                    Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-05 07:47 +0000
                      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-05 12:05 +0200
                        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-05 12:04 -0700
                          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 11:48 +0200
                            Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-06 15:32 +0000
                              Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 21:27 +0200
                                Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-06 19:50 +0000
                                  Re: Implementing lisp in Forth. Chapter 4. Stefan Monnier <monnier@iro.umontreal.ca> - 2016-09-08 12:15 -0400
                                    Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-08 20:09 +0200
                                      Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-08 12:34 -0700
                                      Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 10:17 +0000
                                        Re: Implementing lisp in Forth. Chapter 4. Stefan Monnier <monnier@iro.umontreal.ca> - 2016-09-12 11:50 -0400
                                          Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 16:48 +0000
                                            Re: Implementing lisp in Forth. Chapter 4. Stefan Monnier <monnier@iro.umontreal.ca> - 2016-09-12 13:41 -0400
                                Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-06 22:03 -0700
                                Re: Implementing lisp in Forth. Chapter 4. George Neuner <gneuner2@comcast.net> - 2016-09-08 16:50 -0400
                                  Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-08 16:34 -0700
                                    Re: Implementing lisp in Forth. Chapter 4. George Neuner <gneuner2@comcast.net> - 2016-09-09 00:12 -0400
                                      Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-08 22:22 -0700
                                Re: Implementing lisp in Forth. Chapter 4. Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-27 08:51 +0200
                                  Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-27 00:47 -0700
                        Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-06 13:18 +0000
                          Re: Implementing lisp in Forth. Chapter 4. "WJ" <w_a_x_man@yahoo.com> - 2016-09-06 20:52 +0000
                          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-02 19:15 +0100
                        Re: Implementing lisp in Forth. Chapter 4. Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-09 10:05 +0200
                          Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 10:11 +0000
                            Re: Implementing lisp in Forth. Chapter 4. Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-12 13:15 +0200
                              Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 17:25 +0000
                  Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-09 16:19 +0200
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-09 10:55 -0700
                      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-09 21:39 +0200
                        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-09 13:06 -0700
                          Re: Implementing lisp in Forth. Chapter 4. franck.bensusan@gmail.com - 2016-09-10 07:23 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-11 01:28 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Spiros Bousbouras <spibou@gmail.com> - 2016-09-13 21:37 +0000
                              Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-14 09:55 +0200
                              Re: Implementing lisp in Forth. Chapter 4. franck.bensusan@gmail.com - 2016-09-14 01:04 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-13 14:40 -0700
                              Re: Implementing lisp in Forth. Chapter 4. franck.bensusan@gmail.com - 2016-09-14 03:37 -0700
                  Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-10 01:17 -0700
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 12:01 -0700
                      Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-10 21:57 -0700
                        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 22:12 -0700
                          Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-10 23:30 -0700
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 23:48 -0700
                              Re: Implementing lisp in Forth. Chapter 4. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-11 02:59 -0500
                                Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-11 01:16 -0700
                                  Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-11 19:02 -0700
                              Re: Implementing lisp in Forth. Chapter 4. lawrencedo99@gmail.com - 2016-09-11 19:00 -0700
                    Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-10 12:08 -0700
                    Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 09:43 +0000
                      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 13:42 +0200
                        Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 17:26 +0000
                          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 20:56 +0200
                            Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-12 13:08 -0700
                            Re: Implementing lisp in Forth. Chapter 4. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-14 07:38 +0000
      Re: Implementing lisp in Forth. Chapter 4. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-30 07:48 +0100
        Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-30 11:22 +0200
        Re: Implementing lisp in Forth. Chapter 4. Paul Rubin <no.email@nospam.invalid> - 2016-09-30 18:36 -0700
          Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-01 11:19 +0200
            Re: Implementing lisp in Forth. Chapter 4. luser droog <mijoryx@yahoo.com> - 2016-10-01 19:34 -0700
    Implementing lisp in Forth. Garbage collection. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 12:30 +0200
      Re: Implementing lisp in Forth. Garbage collection. Spiros Bousbouras <spibou@gmail.com> - 2016-09-06 15:34 +0000
        Re: Implementing lisp in Forth. Garbage collection. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-06 21:12 +0200
      Re: Implementing lisp in Forth. Garbage collection. Paul Rubin <no.email@nospam.invalid> - 2016-09-06 14:52 -0700
        Re: Implementing lisp in Forth. Garbage collection. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-07 01:50 +0200
          Re: Implementing lisp in Forth. Garbage collection. Paul Rubin <no.email@nospam.invalid> - 2016-09-06 17:49 -0700
    Re: Implementing lisp in Forth. Chapter 4. luser droog <mijoryx@yahoo.com> - 2016-10-21 17:02 -0700
      Re: Implementing lisp in Forth. Chapter 4. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-22 02:43 +0200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#50840

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> You're exactly right, and it's simple to see why.  With multi-core
> systems and reference counting you need an atomic compare-and-
> increment operation every time that you change a pointer.

Yep.  You even need that when you only copy a pointer, like if you say
"a = b" you have to adjust two refcounts.  That's painful even on a
single core computer.  CPython got away with it because the interpreter
overhead was so bad that refcounting got lost in the noise, but I don't
think higher performance systems generally work that way.

[toc] | [prev] | [next] | [standalone]

#50868

On Sunday, September 11, 2016 at 8:16:39 PM UTC+12, Paul Rubin wrote:
> You even need that when you only copy a pointer, like if you say
> "a = b" you have to adjust two refcounts.  That's painful even on a
> single core computer.

Could be worse. With GC, you are whacking memory that has long since fallen out of the cache. So you are going to incur a shitload of cache misses. Not good for performance at all.

I remember in the mid to late 1990s, Corel undertook a project to rewrite its office suite in Java. Then it found out how bad the performance was...

[toc] | [prev] | [next] | [standalone]

#50867

On Sunday, September 11, 2016 at 6:48:19 PM UTC+12, Paul Rubin wrote:
>
> Lawrence D’Oliveiro writes:
>
>>> I thought it would just eat all the system memory if you didn't use -Xmx.
>>
>> That’s the big drawback with garbage collection.
> 
> I dunno, if you have the memory then it's reasonable for the server to
> expect that you want to use it.

If your server is only doing one thing, then fine. Otherwise it’s not a very system-friendly thing to do.

On Linux, if you eat up all the RAM, you will arouse the wrath of the dreaded “OOM Killer”.

[toc] | [prev] | [next] | [standalone]

#50821

lawrencedo99@gmail.com writes:
> Why not use reference-counting as a first resort, only falling back to
> GC when you need to, like Perl and Python do?

I forgot to add: refcounting doesn't really work in Forth, since you
don't know what cells have pointers in them.  With conservative GC you
just assume anything that looks like a pointer is one and occasionally
miss reclaiming something, usually no big deal.  With refcounting and
that approach, you could clobber user data thinking you were adjusting a
reference count.

And as Anton mentioned a while back, you'd have to adjust refcounts
every time a program uses DUP (etc.), which would cause a bad slowdown.
Conservative GC on the other hand suits Forth pretty well.

[toc] | [prev] | [next] | [standalone]

#50881

lawrencedo99@gmail.com writes:
>On Monday, September 5, 2016 at 6:28:59 AM UTC+12, Paul Rubin wrote:
>> ... ALLOC notices if you're running low on memory, and performs a GC if y=
>ou
>> are.
>
>How does it decide when you are =E2=80=9Crunning low on memory=E2=80=9D?

This is actually documented pretty exhaustively in the manual:

|Tuning
|
|gc.fs generally uses only a part of the memory it manages. This policy
|allows you to give it a huge amount of memory to manage, as
|preparation for the worst case, without consuming that much real (and,
|for good OSes, even virtual) memory before it is necessary.
|
|The amount of memory actually used is determined in the following way:
|
|memory= (a * livemem / b) + c
|
|Where livemem is the amount of memory in live objects after the last
|garbage collection, and a, b, and c are tunable parameters. By
|default, a/b is 3, and c is 256KB.
|
|You can tune these parameters for your application: You can reduce the
|memory, at the cost of a higher number of garbage collections, or you
|can increase it to reduce the number of garbage collections. Note that
|if you reduce memory too much (to less than about 2*livemem), the
|number of garbage collections rises extremely. And if a
|garbage-collection does not free an appropriate memory chunk, alloc
|will grab more memory regardless of the limit.
|
|The following code sequence demonstrates the adjustment of parameters
|by resetting them to their default values:
|
|also garbage-collector
|3 1 ( a b ) size-factor 2!
|256 1024 * ( c ) grain/ size-offset !
|set-current-limit
|previous

You also have to tell gc.fs how much maximum memory it should use; it
will allocate that much (plus 1/32 of that) from the start, but will
write to only the part of it that the "memory" above specifies; so
only that much physical memory (and, with overcommit, that much
virtual memory) is really consumed; in other words, if you have an OS
with overcommit, you can make the maximum memory big, e.g., the RAM
size, and if the amount of live memory stays small, the amount of used
memory will also stay relatively small.

> Do=
>es it limit your heap size, like Java does?

I have no idea how Java does it.

>Why not use reference-counting as a first resort, only falling back to GC w=
>hen you need to, like Perl and Python do?

As others have mentioned, that would be inefficient.  Moreover, having
both reference counting and GC is more complex than necessary.  Most
importantly, you would have to prefix all operations that deal with
references in order to add the reference counting; e.g., RDUP ROVER R@
R!; if the programmer forgets this once, the invariant of reference
counting is broken, and such bugs are not easy to find.  For Python
and Perl, that's no problem, because there the system keeps track of
references (by tagging).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#50886

In article <2016Sep12.114311@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>lawrencedo99@gmail.com writes:
>>On Monday, September 5, 2016 at 6:28:59 AM UTC+12, Paul Rubin wrote:
>>> ... ALLOC notices if you're running low on memory, and performs a GC if y=
>>ou
>>> are.
>>
>>How does it decide when you are =E2=80=9Crunning low on memory=E2=80=9D?
>
>This is actually documented pretty exhaustively in the manual:
>
<SNIP memory allocation strategy >

I believe that the package behaves reasonably with the defaults.

What I don't understand is where the information enters that
something is no longer needed. (I only do allocs, I'm not supposed
to free's, but the garbage collection must have *something* to
work with.)

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50903

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>What I don't understand is where the information enters that
>something is no longer needed. (I only do allocs, I'm not supposed
>to free's, but the garbage collection must have *something* to
>work with.)

What happens is that, starting with the root set, the garbage
collector recursively scans for live memory.  Anything that is not
found is no longer needed.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#50906

In article <2016Sep12.192638@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>What I don't understand is where the information enters that
>>something is no longer needed. (I only do allocs, I'm not supposed
>>to free's, but the garbage collection must have *something* to
>>work with.)
>
>What happens is that, starting with the root set, the garbage
>collector recursively scans for live memory.  Anything that is not
>found is no longer needed.

In the context I find this non-sensical. The root-set is part of
the application. The garbage collector only knows what has been
alloced, so as far as the garbage collector is concerned there
is no such thing as a "root set".

So please explain.

>
>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50910

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> so as far as the garbage collector is concerned there
> is no such thing as a "root set". So please explain.

gc.fs has some words where you tell the gc what the root set is.
The data stack contents are also in the root set.  The return stack
contents are not, since there's no standard way to get at them,
but it seems worth doing that if your Forth has a way.

If you look at small Lisp implementations, their gc's also scan a
predefined root set.  I've been looking at uLisp (ulisp.com) lately
and you might find it educational.  It's about 3 kloc about 1/3 of
which is Arduino specific.

[toc] | [prev] | [next] | [standalone]

#50959

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Sep12.192638@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>What I don't understand is where the information enters that
>>>something is no longer needed. (I only do allocs, I'm not supposed
>>>to free's, but the garbage collection must have *something* to
>>>work with.)
>>
>>What happens is that, starting with the root set, the garbage
>>collector recursively scans for live memory.  Anything that is not
>>found is no longer needed.
>
>In the context I find this non-sensical. The root-set is part of
>the application. The garbage collector only knows what has been
>alloced, so as far as the garbage collector is concerned there
>is no such thing as a "root set".

Every garbage collector uses a root set, so there obviously is such a
thing.

One automatic approach is to treat all memory that is not allocated
through the collector as roots; I think Boehm-Weiser does something
like this.

For a Lisp garbage collector, typically the root of the Lisp symbol
table, the stack, and possibly registers are used as roots.

For my Forth garbage collector, the data stack and explicitly
registered memory locations are the root set.  There is no standard
way to access the return stack or locals, nor all of the dictionary,
and I wanted the garbage collector to be a standard library, so that's
how I arrived at that decision.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#51469

On 29/08/2016 17:46, Paul Rubin wrote:
> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>> The following is inspired by the website
>>    http://www.buildyourownlisp.com
>> This site is beyond brilliant. A comparison with the lisp's in
>> Forth I've seen is ... well let's not compare.
>
> You might also like:
>
> https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours
>
> Or just look at source code of many of the Lisps out there that are
> written in C or in Lisp itself.
>
> You should probably also read SICP at some point:
>
>    https://mitpress.mit.edu/sicp/
>
> It looks like the Lisp from buildyourownlisp.com is very limited.
>

Has anybody mentioned Lispkit which seems to have been implemented in a 
few languages.

https://en.wikipedia.org/wiki/Lispkit_Lisp

It is built on the SECD virtual machine and includes garbage collection. 
Not being a Lisper I have no idea how good, bad or indifferent it is.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#51472

In article <nsl1qf$ip2$1@dont-email.me>,
Gerry Jackson  <gerry@jackson9000.fsnet.co.uk> wrote:
>On 29/08/2016 17:46, Paul Rubin wrote:
>> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>> The following is inspired by the website
>>>    http://www.buildyourownlisp.com
>>> This site is beyond brilliant. A comparison with the lisp's in
>>> Forth I've seen is ... well let's not compare.
>>
>> You might also like:
>>
>> https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours
>>
>> Or just look at source code of many of the Lisps out there that are
>> written in C or in Lisp itself.
>>
>> You should probably also read SICP at some point:
>>
>>    https://mitpress.mit.edu/sicp/
>>
>> It looks like the Lisp from buildyourownlisp.com is very limited.
>>
>
>Has anybody mentioned Lispkit which seems to have been implemented in a
>few languages.
>
>https://en.wikipedia.org/wiki/Lispkit_Lisp
>
>It is built on the SECD virtual machine and includes garbage collection.
>Not being a Lisper I have no idea how good, bad or indifferent it is.

The lexicon is very helpful, because it's so concise.
This lisp is for experimenting with advanced functions, purely
functional. Not what I intend to try.

>
>--
>Gerry

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#51499

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> https://en.wikipedia.org/wiki/Lispkit_Lisp
> It is built on the SECD virtual machine and includes garbage
> collection. Not being a Lisper I have no idea how good, bad or
> indifferent it is.

I hadn't seen that before, but it looks like a research platform from
quite a long time ago, maybe of some interest to study but not for
actual use.

[toc] | [prev] | [next] | [standalone]

#51505

In article <87intc3l6d.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> https://en.wikipedia.org/wiki/Lispkit_Lisp
>> It is built on the SECD virtual machine and includes garbage
>> collection. Not being a Lisper I have no idea how good, bad or
>> indifferent it is.
>
>I hadn't seen that before, but it looks like a research platform from
>quite a long time ago, maybe of some interest to study but not for
>actual use.

The first wikipedia reference
http://www.cs.ox.ac.uk/files/3299/PRG32%20vol%201.pdf
is valuable to me because it is a description that doesn't assume
prior knowledge.

It is an interesting read for all Forthers who want to get an
impression of how lisp is implemented without spending an undue amount
of time.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#51529

On Saturday, October 1, 2016 at 4:11:08 AM UTC-5, Albert van der Horst wrote:
> In article <87intc3l6d.fsf@jester.gateway.pace.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
> >Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> >> https://en.wikipedia.org/wiki/Lispkit_Lisp
> >> It is built on the SECD virtual machine and includes garbage
> >> collection. Not being a Lisper I have no idea how good, bad or
> >> indifferent it is.
> >
> >I hadn't seen that before, but it looks like a research platform from
> >quite a long time ago, maybe of some interest to study but not for
> >actual use.
> 
> The first wikipedia reference
> http://www.cs.ox.ac.uk/files/3299/PRG32%20vol%201.pdf
> is valuable to me because it is a description that doesn't assume
> prior knowledge.
> 
> It is an interesting read for all Forthers who want to get an
> impression of how lisp is implemented without spending an undue amount
> of time.
> 

Excellent link. And excellent series of threads!

In writing my own attempt at a very low-level lisp,
https://github.com/luser-dr00g/sexp.c
I found "tinylisp" to be a very usefully documented project,
almost "literate" in its explanation of the representations.

It (my own code) doesn't address the gc issue at all.
tinylisp iirc does.

[toc] | [prev] | [next] | [standalone]

#50705 — Implementing lisp in Forth. Garbage collection.

Has the following API sufficient functionality to base the garbage
collection of a LISP on?

I've a dynamix allocation package with the following API
Forth style  (exceptions are thrown and not shown)

n ALLOCATE addr  : Addr point to an area of size n,
                    subsequently under control of the caller.
addr FREE        : Area at addr is no longer under control.
addr n RESIZE    : Make the area previously ALLOCATEd a different size.
                   Content may have to be copied.
addr SIZE size   : Size is the length passed to ALLOCATE or RESIZE
addr mask MASK!  : Add 10 bits of information related to addr
addr MASK@ mask  : Get back 10 bits of information related to addr

There are two allocation areas, only one is in use at any one time.
SWITCH          : Use the other allocation area
mask lambda BOTH : Perform lambda with data mask on all area's
mask lambda BACKGROUND : Perform lambda with data mask on all
                area's in the allocation area not in use.

RATIONALE:
An action to be done in BOTH would be : store 1 in mask.

An action to be done in BOTH would be store 0 in mask.

An action passed to be BACKGROUND would be
"if mask contains 1, free the allocated area."

This hints to a garbage collector that can work undisturbed,
while an other area is in use.
[I hope that the trivial idea of using two area's is not
patented/patentable. If so I hereby declare prior art.]

(The LISP can be adapted to the API, it doesn;t exist yet.)
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50709 — Re: Implementing lisp in Forth. Garbage collection.

On Tue, 6 Sep 2016 12:30:46 +0200 (CEST)
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
> Has the following API sufficient functionality to base the garbage
> collection of a LISP on?
> 
> I've a dynamix allocation package with the following API
> Forth style  (exceptions are thrown and not shown)
> 
> n ALLOCATE addr  : Addr point to an area of size n,
>                     subsequently under control of the caller.
> addr FREE        : Area at addr is no longer under control.
> addr n RESIZE    : Make the area previously ALLOCATEd a different size.
>                    Content may have to be copied.
> addr SIZE size   : Size is the length passed to ALLOCATE or RESIZE
> addr mask MASK!  : Add 10 bits of information related to addr
> addr MASK@ mask  : Get back 10 bits of information related to addr
> 
> There are two allocation areas, only one is in use at any one time.
> SWITCH          : Use the other allocation area
> mask lambda BOTH : Perform lambda with data mask on all area's
> mask lambda BACKGROUND : Perform lambda with data mask on all
>                 area's in the allocation area not in use.

What does "perform lambda" mean ?

[toc] | [prev] | [next] | [standalone]

#50712 — Re: Implementing lisp in Forth. Garbage collection.

In article <YlBzz.1312339$3%1.931391@fx40.am4>,
Spiros Bousbouras  <spibou@gmail.com> wrote:
>On Tue, 6 Sep 2016 12:30:46 +0200 (CEST)
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
>> Has the following API sufficient functionality to base the garbage
>> collection of a LISP on?
>>
>> I've a dynamix allocation package with the following API
>> Forth style  (exceptions are thrown and not shown)
>>
>> n ALLOCATE addr  : Addr point to an area of size n,
>>                     subsequently under control of the caller.
>> addr FREE        : Area at addr is no longer under control.
>> addr n RESIZE    : Make the area previously ALLOCATEd a different size.
>>                    Content may have to be copied.
>> addr SIZE size   : Size is the length passed to ALLOCATE or RESIZE
>> addr mask MASK!  : Add 10 bits of information related to addr
>> addr MASK@ mask  : Get back 10 bits of information related to addr
>>
>> There are two allocation areas, only one is in use at any one time.
>> SWITCH          : Use the other allocation area
>> mask lambda BOTH : Perform lambda with data mask on all area's
>> mask lambda BACKGROUND : Perform lambda with data mask on all
>>                 area's in the allocation area not in use.
>
>What does "perform lambda" mean ?

I try to speak lisp :-) . A lambda is a pointer to a subroutine aka
Forth execution token.
What I mean is that the allocation system follows a linked list of
pointers and execute a procedure that inspects whether it contains
mask, and if so frees the allocated area.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#50718 — Re: Implementing lisp in Forth. Garbage collection.

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> n ALLOCATE addr  : Addr point to an area of size n,
>                     subsequently under control of the caller.

You need that.

> addr FREE        : Area at addr is no longer under control.

Get rid of this--the GC handles it for you.

> addr n RESIZE    : Make the area previously ALLOCATEd a different size.
>                    Content may have to be copied.

This isn't feasible in a non-moving system and I don't understand why
you wouldwant it anyway.

> addr SIZE size   : Size is the length passed to ALLOCATE or RESIZE

The non-gc parts of the program shouldn't care about this either.

> addr mask MASK!  : Add 10 bits of information related to addr
> addr MASK@ mask  : Get back 10 bits of information related to addr

Is that for type tags?  A number of Lisp systems started that way but
ended up going to smaller tags, to have more address bits left.  Typical
is 1 tag bit distinguishing ints from pointers.  If the low bit is the
tag and 0 means integer, then you can add two such integers together and
get another integer without any bit fiddling.  For dereferencing
pointers you can mask off the bit, or use it relative to a base register
that itself contains an address adjusted for the extra 1 bit.

> There are two allocation areas, only one is in use at any one time.

Wait I'm confused, you're writing a semispace gc?  I'd say look at the
one in SIOD and get an idea from that what you need.  SICP also
describes something like that, towards the end of the book.

[toc] | [prev] | [next] | [standalone]

#50720 — Re: Implementing lisp in Forth. Garbage collection.

In article <87r38wn1ag.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>> n ALLOCATE addr  : Addr point to an area of size n,
>>                     subsequently under control of the caller.
>
>You need that.
>
>> addr FREE        : Area at addr is no longer under control.
>
>Get rid of this--the GC handles it for you.

There is some confusion here. I'm describing what is in the GC.
The GC certainly must be able to free space.

<SNIP>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web