I can now at will compile two kinds of call's one old style that will be the best for native compilation and one that is more optimal for rtl-code. Consider for example,
(compile-rtl (macroexpand '(lambda (x y) (g y (f (+ x y) (- x y))))) (current-module) `(#:partial-eval? #f)))
with target native we will get, (begin-program 1 () program11440) (std-prelude 2 2) (label :LCASE11438) (toplevel 0 g ref) (tail-move 3 1) (eq-move 1 2) (add 4 (3 2)) (clear 5 6)
(toplevel 7 f ref) (sub 8 (3 2)) (call mem: 2 sp: 4 len: 2) (tail-call 2))
And for byecode we will get, ((begin-program 1 () program16740) (std-prelude 2 2) (label :LCASE16738) (toplevel 0 g ref)
(tail-move 3 1) (eq-move 1 2) (toplevel 4 f ref) (add 5 (3 2)) (sub 6 (3 2)) (rtl-call mem: 2 rsp: 7 f: 4 args: (5 6)) (tail-call 2))
The instruction count is about the same, slightly less for the bytcode target. But this is not the kind of code that
the bytecode instruction is targeted against, it's for cases like,
(define (g) (compile-rtl (macroexpand '(lambda (x y) (g y (f x y x y))))
And compare this with a generation tuned for native code,
((begin-program 1 () program22053) (std-prelude 2 2) (label :LCASE22051) (toplevel 0 g ref) (tail-move 3 1) (eq-move 1 2) (eq-move 4 3) (clear 4 5) (toplevel 6 f ref) (eq-move 7 2)
(eq-move 8 3) (eq-move 9 2) (call mem: 2 sp: 4 len: 4) (tail-call 2))
What is not seen here is that the bytecode targeted version needs to copy that arguments to new slot's and will waste more stackspace. Also it's inferior if we compile this to native code because we must move more data then
nessesary. I'll will keep this option open as a parameter into the compiler, I will then add both versions of call's to the rtl code in order to play with these settings more and understand the tradeoff better.
Anyway I'll store the compile-rtl.scm in the guile directory in the aschm repo if you would like to play with the compiler.