I have been researching lisp internals and last night found what
seems to be an interesting discussion about a GC implementation.
This implementation seems to be from the perspective of a
C application not knowing/caring about memory allocation.
With a lisp system, the lisp does not care what objects are in
or not in use, but the underlying internals (C) have a better
idea of what's going on, yes?
What's a typical implementation? Anyone have some links?
http://www.hpl.hp.com/personal/Hans_Boehm/gc
Mike
Mike <·····@mikee.ath.cx> writes:
> With a lisp system, the lisp does not care what objects are in or
> not in use, but the underlying internals (C) have a better idea of
> what's going on, yes?
I don't know that there has to be any underlying internals that has to
do with C or are otherwise somehow outside the scope of the lisp as
such.
> What's a typical implementation? Anyone have some links?
Here's one GC implementation I've written (the essential function is
named stop-and-copy):
<URL:http://common-lisp.net/cgi-bin/viewcvs.cgi/movitz/losp/los0-gc.lisp?rev=HEAD&cvsroot=movitz&content-type=text/vnd.viewcvs-markup>
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
> Mike <·····@mikee.ath.cx> writes:
>
>> With a lisp system, the lisp does not care what objects are in or
>> not in use, but the underlying internals (C) have a better idea of
>> what's going on, yes?
>
> I don't know that there has to be any underlying internals that has to
> do with C or are otherwise somehow outside the scope of the lisp as
> such.
>
>> What's a typical implementation? Anyone have some links?
>
> Here's one GC implementation I've written (the essential function is
> named stop-and-copy):
>
><URL:http://common-lisp.net/cgi-bin/viewcvs.cgi/movitz/losp/los0-gc.lisp?rev=HEAD&cvsroot=movitz&content-type=text/vnd.viewcvs-markup>
>
I'm scanning it now, thanks.
At first glance what I find fascinating is the embedded assembler.
Hadn't thought of that application.
Mike
Mike <·····@mikee.ath.cx> writes:
> At first glance what I find fascinating is the embedded assembler.
> Hadn't thought of that application.
Hm.. well, yes, the embedded assembler is used for the allocation
primitives, which is sort of the flip side of the GC implementation,
and are in assembly mostly because they need to be atomical (in a
particular fashion) with respect to (hardware) interrupts. (OK, they
need to be "efficient", too.) But if GC is what you're interested in,
you'd probably be better off ignoring the assembly stuff there.
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
> Mike <·····@mikee.ath.cx> writes:
>
>> At first glance what I find fascinating is the embedded assembler.
>> Hadn't thought of that application.
>
> Hm.. well, yes, the embedded assembler is used for the allocation
> primitives, which is sort of the flip side of the GC implementation,
> and are in assembly mostly because they need to be atomical (in a
> particular fashion) with respect to (hardware) interrupts. (OK, they
> need to be "efficient", too.) But if GC is what you're interested in,
> you'd probably be better off ignoring the assembly stuff there.
>
Oh, I agree with the ignore part, I was simply suprised to see it
there. I hadn't thought of embedding assembly into lisp. It's the
idea that I find fascinating.
Mike
In article <···············@corp.supernews.com>,
Mike <·····@mikee.ath.cx> wrote:
> In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
> > Mike <·····@mikee.ath.cx> writes:
> >
> >> At first glance what I find fascinating is the embedded assembler.
> >> Hadn't thought of that application.
> >
> > Hm.. well, yes, the embedded assembler is used for the allocation
> > primitives, which is sort of the flip side of the GC implementation,
> > and are in assembly mostly because they need to be atomical (in a
> > particular fashion) with respect to (hardware) interrupts. (OK, they
> > need to be "efficient", too.) But if GC is what you're interested in,
> > you'd probably be better off ignoring the assembly stuff there.
> >
>
> Oh, I agree with the ignore part, I was simply suprised to see it
> there. I hadn't thought of embedding assembly into lisp. It's the
> idea that I find fascinating.
>
> Mike
It is not 'that' unusual. Macintosh Common Lisp (and so OpenMCL)
has this feature since ... well, since ... hmm ... I guess,
say, 15 years maybe. At that time it was 68k assembler.
Nowadays it is PowerPC assembler...
In article <····························@news-50.dca.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> In article <···············@corp.supernews.com>,
> Mike <·····@mikee.ath.cx> wrote:
>
> > In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
> > > Mike <·····@mikee.ath.cx> writes:
> > >
> > >> At first glance what I find fascinating is the embedded assembler.
> > >> Hadn't thought of that application.
> > >
> > > Hm.. well, yes, the embedded assembler is used for the allocation
> > > primitives, which is sort of the flip side of the GC implementation,
> > > and are in assembly mostly because they need to be atomical (in a
> > > particular fashion) with respect to (hardware) interrupts. (OK, they
> > > need to be "efficient", too.) But if GC is what you're interested in,
> > > you'd probably be better off ignoring the assembly stuff there.
> > >
> >
> > Oh, I agree with the ignore part, I was simply suprised to see it
> > there. I hadn't thought of embedding assembly into lisp. It's the
> > idea that I find fascinating.
> >
> > Mike
>
> It is not 'that' unusual. Macintosh Common Lisp (and so OpenMCL)
> has this feature since ... well, since ... hmm ... I guess,
> say, 15 years maybe. At that time it was 68k assembler.
> Nowadays it is PowerPC assembler...
Maclisp had LAP (Lisp Assembly Program) back in the 70's.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <····························@news-50.dca.giganews.com>,
> Rainer Joswig <······@lisp.de> wrote:
>
>
>>In article <···············@corp.supernews.com>,
>> Mike <·····@mikee.ath.cx> wrote:
>>
>>
>>>In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
>>>
>>>>Mike <·····@mikee.ath.cx> writes:
>>>>
>>>>
>>>>>At first glance what I find fascinating is the embedded assembler.
>>>>>Hadn't thought of that application.
>>>>
>>>>Hm.. well, yes, the embedded assembler is used for the allocation
>>>>primitives, which is sort of the flip side of the GC implementation,
>>>>and are in assembly mostly because they need to be atomical (in a
>>>>particular fashion) with respect to (hardware) interrupts. (OK, they
>>>>need to be "efficient", too.) But if GC is what you're interested in,
>>>>you'd probably be better off ignoring the assembly stuff there.
>>>>
>>>
>>>Oh, I agree with the ignore part, I was simply suprised to see it
>>>there. I hadn't thought of embedding assembly into lisp. It's the
>>>idea that I find fascinating.
>>>
>>>Mike
>>
>>It is not 'that' unusual. Macintosh Common Lisp (and so OpenMCL)
>>has this feature since ... well, since ... hmm ... I guess,
>>say, 15 years maybe. At that time it was 68k assembler.
>>Nowadays it is PowerPC assembler...
>
>
> Maclisp had LAP (Lisp Assembly Program) back in the 70's.
MCL and OpenMCL also call it LAP, presumably by reference to its heritage.
mikel <·····@evins.net> writes:
> Barry Margolin wrote:
> > In article <····························@news-50.dca.giganews.com>,
> > Rainer Joswig <······@lisp.de> wrote:
> >
>
> >>In article <···············@corp.supernews.com>,
> >> Mike <·····@mikee.ath.cx> wrote:
> >>
> >>
> >>>In article <··············@vserver.cs.uit.no>, Frode Vatvedt Fjeld wrote:
> >>>
> >>>>Mike <·····@mikee.ath.cx> writes:
> >>>>
> >>>>
> >>>>>At first glance what I find fascinating is the embedded assembler.
> >>>>>Hadn't thought of that application.
> >>>>
> >>>>Hm.. well, yes, the embedded assembler is used for the allocation
> >>>>primitives, which is sort of the flip side of the GC implementation,
> >>>>and are in assembly mostly because they need to be atomical (in a
> >>>>particular fashion) with respect to (hardware) interrupts. (OK, they
> >>>>need to be "efficient", too.) But if GC is what you're interested in,
> >>>>you'd probably be better off ignoring the assembly stuff there.
> >>>>
> >>>
> >>>Oh, I agree with the ignore part, I was simply suprised to see it
> >>>there. I hadn't thought of embedding assembly into lisp. It's the
> >>>idea that I find fascinating.
> >>>
> >>>Mike
> >>
> >>It is not 'that' unusual. Macintosh Common Lisp (and so OpenMCL)
> >>has this feature since ... well, since ... hmm ... I guess,
> >>say, 15 years maybe. At that time it was 68k assembler.
> >>Nowadays it is PowerPC assembler...
> > Maclisp had LAP (Lisp Assembly Program) back in the 70's.
>
>
> MCL and OpenMCL also call it LAP, presumably by reference to its heritage.
Hmm, it seems we've drifted away from embedded assembler discussion and
have started discussing LAP. Well, I suppose it depends on what you
mean by "embedded assembler". Any native-compiling Lisp that doesn't
generate output to another langauge (say, C, or assembler source) is
going to have its own assembler for each architecture. I think many
still call the instruction formats LAP.
CL-USER(1): (defun foo (x y) (if x (bar y)))
FOO
CL-USER(2): (setq comp::*hack-compiler-output* '(foo))
(FOO)
CL-USER(3): (compile 'foo)
Break: type :cont when you're done editing "hackit.s"
Restart actions (select using :continue):
0: return from break.
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this process.
[changing package from "COMMON-LISP-USER" to "COMPILER"]
[1c] COMP(4): (shell "cat hackit.s")
(LABEL GARBAGE::L2)
(PUSH.L (:REG 5 :EBP :BP))
(MOVE.L (:REG 4 :ESP :SP) (:REG 5 :EBP :BP))
(PUSH.L (:REG 6 :ESI :SI))
(SUB.L (IM (:FINAL-FRAME-SIZE 32 -4)) (:REG 4 :ESP :SP))
(CMP.L (IM 2) (:REG 1 :ECX :CX :CL))
(BCC :EQ GARBAGE::L5)
(INT.B (IM 97))
(LABEL GARBAGE::L5)
(LABEL GARBAGE::L1)
(CMP.B (IM 0) (D -105 (:REG 7 :EDI :DI)))
(BCC.S :EQ GARBAGE::L6)
(INT.B (IM 100))
(LABEL GARBAGE::L6)
(CMP.L (:REG 0 :EAX :AX :AL) (:REG 7 :EDI :DI))
(BCC :EQ GARBAGE::L4)
(MOVE.L (:REG 2 :EDX :DX :DL) (:REG 0 :EAX :AX :AL))
(MOVE.L (D 18 (:REG 6 :ESI :SI)) (:REG 3 :EBX :BX :BL))
(MOVE.B (IM 1) (:REG 1 :ECX :CX :CL))
(BCC :T (PC (:REG 7 :EDI :DI)) :LINK)
(LABEL GARBAGE::L3)
(LEAVE)
(MOVE.L (D -4 (:REG 5 :EBP :BP)) (:REG 6 :ESI :SI))
(RETURN)
(LABEL GARBAGE::L4)
(MOVE.L (:REG 7 :EDI :DI) (:REG 0 :EAX :AX :AL))
(CLC)
(BCC :T GARBAGE::L3)
0
[1c] COMP(5): :cont
Warning: While compiling these undefined functions were referenced: BAR.
FOO
NIL
NIL
CL-USER(6):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@franz.com>, Duane Rettig <·····@franz.com>
wrote:
> Any native-compiling Lisp that doesn't
> generate output to another langauge (say, C, or assembler source) is
> going to have its own assembler for each architecture.
Not necessarily. It could have its own code generator -- that's what
Maclisp did, both the ITS and Multics versions. They both had LAP, but
it was just for users, it wasn't used as an intermediate step by the
Lisp compilers.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Mike wrote:
> .... I hadn't thought of embedding assembly into lisp. It's the
> idea that I find fascinating.
It is the only thing faster enough to justify the effort.
:)
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<····················@twister.nyc.rr.com>...
> Mike wrote:
> > .... I hadn't thought of embedding assembly into lisp. It's the
> > idea that I find fascinating.
>
> It is the only thing faster enough to justify the effort.
>
> :)
>
> kt
And even then not in all cases.
Mike <·····@mikee.ath.cx> writes:
> Oh, I agree with the ignore part, I was simply suprised to see it
> there. I hadn't thought of embedding assembly into lisp. It's the
> idea that I find fascinating.
You might also be interested in SBCL/CMUCL's VOPs, which are another
approach to integrating Lisp and assembly language. Dan Barlow gave a
nice how-to here:
http://sourceforge.net/mailarchive/message.php?msg_id=426631