[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rtl vp->sp handling

From: Stefan Israelsson Tampe
Subject: rtl vp->sp handling
Date: Tue, 6 Nov 2012 18:00:26 +0100


I've been thinking a lot about the managing of vp->sp in such a way that we guard the stack with it as a top mark of the stack meaning everything below that mark should be scanned for gc protection.  My hypothesis now is that we can keep changing this stack mark quite seldom but at right places and use a special system to make sure that we keep protecting the stack in the right way.

The ordinary logic for a instruction with a dst is to check the dst against vp->sp, if it's below vp->sp we use vp->sp as the upper mark and if it's above it we use dst as the upper mark. The idea is that the only time. This is then used to temporary cahnge e.g. vp->sp = dst over a c-call that may start the gc. The other sources of of gc'ing is when we jump back up the stack I solved that by adding a sp field in the branch instruction relating to if's, a pure br will not use a sp field but for those we will model when needed by an instruction sp.set!. Also return and call semantics also can go into gc and they are handed specially.


scheme@(guile-user)> (define f ((c (lambda (x) (let loop ((i 0) (s 0) (t (+ x 2))) (if (eq? i x) s (loop (+ i 1) (+ s i t) (+ t 1))))))))
((begin-program program97574)
 (assert-nargs-ee/locals 0 1)
 (label :LCASE97569)
 (make-empty-closure 0 program97573 0)
 (return 1)
 (begin-program program97573)
 (assert-nargs-ee/locals 1 5)
 (label :LCASE97568)
 (br :L97570)
 (label :LCASE97567)
 (br-if-eq 4 1 0 1 :L97571)
 (mov 0 2)
 (return 1)
 (label :L97571)
 (mov 4 1)
 (add1 1 1)
 (add 5 4 3)
 (add 2 2 5)
 (add1 3 3)
 (br :LCASE97567)
 (label :L97570)
 (clear 1 3)
 (sp-set! 4)
 (load-constant 1 0)
 (load-constant 2 0)
 (load-constant 4 2)
 (add 3 0 4)
 (br :LCASE97567)

Note that we only need to protect and setup the sp-set! level at the start of the loop, typically the inner loops will be free of this instruction and therefore I expect the overhead to be minimal. Also when we translate to native code the overhead will be minimal. To note with is that with this tool we do not need to cleat fields after a let (we use sp-set!) in stead and also at the initial start we do not need to clear the frame.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]