On Sat, 17 Jul 2004, Chris Lattner wrote:> > http://www.ida.liu.se/~tobnu/scheme2llvm/ > > Looks great! > > > (what's a blurb? :) > > Just a summary, so that I can add an entry to this page: > http://llvm.cs.uiuc.edu/ProjectsWithLLVM/Maybe this for now: "This is a small self applicable scheme compiler for LLVM. The code is quite similar to the code in the book SICP (Structure and Interpretation of Computer Programs), chapter five, with the difference that it implements the extra functionality that SICP assumes that the explicit control evaluator (virtual machine) already have. Much functionality of the compiler is implemented in a subset of scheme, llvm-defines, which are compiled to llvm functions." modulo my mistakes in English :). Or, write whatever you like.> > > > As you continue development on it, would you be interested in integrating > > > this into the LLVM tree? > > > > Sure, it could probably at least be used as an example of how to use the > > GC support. Maybe smaller and easier to understand compared to a complete > > JVM. :) > > That is what I was thinking. :)Good. , Tobias
On Sun, 18 Jul 2004, Tobias Nurmiranta wrote:> > Just a summary, so that I can add an entry to this page: > > Maybe this for now: > > "This is a small self applicable scheme compiler for LLVM.Great, I added it here: http://llvm.cs.uiuc.edu/ProjectsWithLLVM/ Thanks! Also, please let us know how the front-end is going :) -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/
Hi,
Regarding llvm.gcroot, do I have to allocate stack-space for all pointers
in a function? Right now I mostly use SSA-variables, and let llvm's
register allocation allocate stack-space when needed. Also, what happens
when I run the mem2reg pass, does it handle llvm.gcroot's that are moved
from stack to registers?
I'm thinking along the lines, that should one not use llvm.gcroot on all
SSA-variables that contains pointers to objects, and then depending on if
the variables end up on the stack, or in registers, the compiler will use
llvm.gcroot?
All my objects are currently typetagged uint's. My llvm scheme code in
the compiler explains this I think:
(llvm-define (make-number x) (bit-shl x 2))
(llvm-define (raw-number x) (bit-shr x 2))
(llvm-define (clear-tag x) (bit-shl (bit-shr x 2) 2))
(llvm-define (get-tag x) (bit-and x 3))
(llvm-define (make-pointer x) (bit-or (clear-tag x) 1))
(llvm-define (make-function-pointer x) (bit-or (clear-tag x) 3))
(llvm-define (points-to x) (clear-tag x))
(llvm-define (number? x) (seteq (get-tag x) 0))
(llvm-define (vector? x) (seteq (get-tag x) 1))
(llvm-define (procedure? x) (seteq (get-tag x) 3))
(llvm-define (make-vector raw-size)
(make-pointer
(cast "uint*" (store raw-size (malloc (add raw-size
1))) "uint")))
, Tobias
On Mon, 19 Jul 2004, Tobias Nurmiranta wrote:> Regarding llvm.gcroot, do I have to allocate stack-space for all > pointers in a function? Right now I mostly use SSA-variables, and let > llvm's register allocation allocate stack-space when needed.Yes. This reflects the fact that the GC can move objects (to compact the heap) at unpredictable times.> Also, what happens when I run the mem2reg pass, does it handle > llvm.gcroot's that are moved from stack to registers?Not currently. In the future this will definitely be improved. In particular, when the code generators are enhanced to provide more accurate mapping information for GC pointers (e.g. which registers contain pointers), we can do this. This is in the long term plans, but I suspect that performance will be fine without it for many applications.> I'm thinking along the lines, that should one not use llvm.gcroot on all > SSA-variables that contains pointers to objects, and then depending on > if the variables end up on the stack, or in registers, the compiler will > use llvm.gcroot?llvm.gcroot is an abstraction. Your front-end is telling the code generator and optimizer what locations can be modified unpredictably at runtime by the GC system. Right now we do not have many clients of the gc interfaces, so they do not produce wonderful code, but this will change in time. :)> All my objects are currently typetagged uint's. My llvm scheme code in > the compiler explains this I think:I think that this should be fine. The GC interfaces are explicitly designed to be able to support list/scheme style type tagging like this, thought the current garbage collector is not fully implemented. -Chris> (llvm-define (make-number x) (bit-shl x 2)) > (llvm-define (raw-number x) (bit-shr x 2)) > (llvm-define (clear-tag x) (bit-shl (bit-shr x 2) 2)) > (llvm-define (get-tag x) (bit-and x 3)) > (llvm-define (make-pointer x) (bit-or (clear-tag x) 1)) > (llvm-define (make-function-pointer x) (bit-or (clear-tag x) 3)) > (llvm-define (points-to x) (clear-tag x)) > (llvm-define (number? x) (seteq (get-tag x) 0)) > (llvm-define (vector? x) (seteq (get-tag x) 1)) > (llvm-define (procedure? x) (seteq (get-tag x) 3)) > > (llvm-define (make-vector raw-size) > (make-pointer > (cast "uint*" (store raw-size (malloc (add raw-size 1))) "uint"))) > > , Tobias > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/