Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth,comp.lang.lisp Subject: Re: Implementing lisp in Forth. Chapter 4. Date: Mon, 05 Sep 2016 12:04:11 -0700 Organization: A noiseless patient Spider Lines: 75 Message-ID: <87zinmmams.fsf@jester.gateway.pace.com> References: <87fupfo6xl.fsf@jester.gateway.pace.com> <_p9zz.1142663$OC.48142@fx39.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="7bfc8f5b1c0c0e2e29d3a5c3abe51644"; logging-data="18618"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/oA+v7l6IojTnsBfGZ2v+f" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:r2CZxgkyEKICw9aIqw5PM41dEOg= sha1:EaVuzkbc7iPZE+X0Oiw/oeu3qVQ= Xref: csiph.com comp.lang.forth:50699 comp.lang.lisp:27920 albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > With a toy Lisp and a 16 gByte heap, I can do a lot of testing before > the GC needs to kick in. I suppose that's a reasonable way to start. >> 354224848179261915075 may create garbage > That is interesting. The Forth REPL can interpret the line .( aap) > and it will print aap. The string aap is a temporary object and > disappears automatically. It will not be allocated anywhere, What happens if you enter the line "123" to leave the number 123 on the stack? It goes into a stack cell (machine word) that's reclaimed automatically when you pop the stack--that's how Forth works. But what if the number is 354224848179261915075? It won't fit in a cell. It's a bignum that must occupy multiple cells, so you'd use something like ALLOCATE to get those cells, put the number in them, and leave just a pointer on the stack. Later once the number is no longer in use, you'll want to reclaim the memory. That's why we say entering 354224848179261915075 in a Lisp REPL might create garbage. > Normally in Forth this garbage is collected using FORGET/MARKER > a very primitive mechanism that basically only restores a previous > memory situation. Having GC frees you from having to think about stuff like that. Edsger W. Dijkstra in his 1972 Turing Award lecture said, "With a few very basic principles at its foundation, it [LISP] has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts." Part of the way it did that was by handling stuff like memory management for you behind the scenes, in a manner mostly unknown in other languages of that era. These days, of course, everybody does it. > BDW is a c-package? I'm disappointed, because people told me that > Lisp can be implemented using 5 basic operations. That's too vague to be meaningful. Lisp code is written with the illusion of infinite memory, and the GC reclaims the actual underlying memory behind the scenes, invisibly to the program. GC has to munge on actual raw memory which Lisp doesn't have a way to do. BDW is one approach to GC but there are others, all of which need machine-level primitives. Some Lisps include memory-access primitives so the GC can itself be written in Lisp, but that stuff has to be done very carefully to avoid creating garbage while the GC is running. I believe that Scheme-48 (s48.org) works that way. > If you would program a LISP machine like I have a Forth machine (just > a tower that has Forth in the boot sector), would it then contain a > couple of giant binary blobs being the GNU multiprecision lib, the > compiled readline lib and maybe even a compiled BDW library written in > C? Eech! BDW is a nice simple way to get GC for a small Lisp, but the higher performance ones tend to use other methods. And of course Lisp is much older than the GNU project. Traditionally bignums would have been implemented in assembly language. The historical Lisp machines had hardware-assisted GC, I believe. There's a bare-metal Scheme for the Raspberry Pi but I don't know if anyone actually uses it. Big Lisp systems usually run under OS's rather than on bare metal. Although control systems have been done in Lisp, Lisp usually hasn't been in the same niche as Forth. It's more for computation than for control, so it usually doesn't care much about low level hardware access.