Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are collectors supposed to rely on the type informations provided by llvm? 2. what about gcreading and gcwriting objects of a different type than i8*? 3. No Intrinsic for allocating gc memory? 4. When passing a gc managed pointer to a c function,how should that function access the pointer? directly? there seem to be functions for that in the runtime/ source directory,but it also seems to be meant for the llvm c frontend? (and not for use in an extra c library) 5. some collectors update pointers upon read/write access, can the llvm gc api provide this? sorry for so many questions (and sorry if some of them may be stupid). thanks in advance for help. thomas
Hi Thomas, On Feb 4, 2008, at 12:20, thomas weidner wrote:> i want to implement a common lisp subset using llvm for fun.Welcome!> This requires the use of a garbage collector. I read the docs, but > many things are still unclear to me.One of the important things to recognize about LLVM's GC support is that it only provides facilities which must be provided by the compiler back end. There are many other necessary facilities which must be provided by a complete language implementation. For the parts of the system where it doesn't need to be involved, LLVM simply gets out of your way.> 1. how are collectors supposed to find all living objects? there is > llvm.gcroot for marking objects on the stack,but how do collectors > crawl heap objects? I did not see a way to provide custom mark > functions. Are collectors supposed to rely on the type informations > provided by llvm?Registering roots (e.g. globals) is a facility your runtime should provide. You could use a module initializer to call into the runtime and accomplish this. Traversing the object graph is also outside of LLVM's scope. Your code would need to emit whatever metadata is necessary for it to correctly traverse the graph at runtime.> 2. what about gcreading and gcwriting objects of a different type > than i8*?Simply bitcast to/from i8*. If you don't need write barriers, you would be advised to ignore gcread and gcwrite entirely, since currently they will only pessimize your code as compared to direct loads and stores.> 3. No Intrinsic for allocating gc memory?Again, that's a feature of the runtime. Simply write a function to do so. For efficiency, your compiler may want to inline part of allocation if you're using a bumpptr allocator.> 4. When passing a gc managed pointer to a c function,how should that > function access the pointer? directly?Generally speaking, yes, directly. If you are using a moving collector and need to pin or copy an object, LLVM neither helps nor hinders your efforts.> there seem to be functions for that in the runtime/ source > directory,but it also seems to be meant for the llvm c frontend? > (and not for use in an extra c library)I'm not sure what you mean here.> 5. some collectors update pointers upon read/write access, can the > llvm gc api provide this?gcread easily allows the pointer loaded from the derived pointer to be updated when it is read. Updating the object pointer from gcread or gcwrite may be possible, but is not straightforward within the framework. Have fun, Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080204/7726e2cc/attachment.html>
thomas weidner wrote:> Hello, > > i want to implement a common lisp subset using llvm for fun.Out of curiousity, for which CL implementation is this targeted? sbcl? Or something you're rolling? The reason why I ask is that I expressed an outrageous opinion at Supercomputing back in November, to wit, that CL is probably the best language suited for today's multicore problems... but I don't have the time to hack one of the current implementations to proove the point. Although, you'll notice that LLVM amply prooves "Greenbaum's hypothesis" (IIRC): inside every sufficiently complex program there is an implmentation of a Lisp interpreter. ;-) -scooter
Scott Michel <scottm <at> rushg.aero.org> writes:> Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling?I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned.> > The reason why I ask is that I expressed an outrageous opinion at > Supercomputing back in November, to wit, that CL is probably the best > language suited for today's multicore problems... but I don't have the > time to hack one of the current implementations to proove the point.interesting, what makes lisp superior in this area over languages with explicit support for parallell computing (like erlang? or Ada) or languages which may be easier auto parallelized (like haskell because of its functional nature).> Although, you'll notice that LLVM amply prooves "Greenbaum's hypothesis" > (IIRC): inside every sufficiently complex program there is an > implmentation of a Lisp interpreter.Nice statement :)