Re: guile-vm 0.3

[Marius Vollmer]

Keisuke Nishida <address@hidden> writes:

> Certainly, we can change the format and add more information.  What
> kind of information should be included?  I just can't decide what is
> the best intermediate representation right now.

What about something along these lines (this is from guile-lightning,
and in flux):

;; The language:
;;
;; Fully parenthesized prefix syntax with nothing but special forms.
;;
;; Special forms are
;;
;; - (lambda-template (ARGS... :rest REST :env ENV) BODY...)
;;
;;   ARGS, REST and ENV are symbols and BODY is a list of expressions.
;;   Both `:rest' and `:env' are optional.
;;
;;   Makes a closure template, argument ENV refers to the
;;   environment given to MAKE_CLOSURE, below.  Closure templates
;;   can not be invoked.  Rest argument denoted by `:rest'.
;;
;;   [ This is not the most expressive way to handle arguments.  Maybe
;;     have explicit (ref-arg N) and (args-list N) etc forms? ]
;;
;; - (make-closure TEMPLATE ENV)
;;
;;   Make a closure from a closure template and an environment.  A
;;   closure can be invoked.  ENV can be anything.
;;
;; - (if TEST THEN ELSE)
;;
;;   The usual conditional.  Else clause is mandatory.
;;
;; - (quote OBJ)
;;
;;   Refers to the Scheme object OBJ, which can be anything.
;;
;; - (local SYMBOL)
;;
;;   Retrieve the value of the local variable SYMBOL, as established
;;   by LABELS, FUNCTIONS or LAMBDA-TEMPLATE.
;;
;; - (set-local SYMBOL VAL)
;;
;;   Set the value of the local variable SYMBOL, as established
;;   by LABELS, FUNCTIONS or LAMBDA-TEMPLATE.
;;
;;   Note that SET-LOCAL does not interact correctly with call/cc.
;;   The values of locals are copied by call/cc and any changes to
;;   them between the call to call/cc and when the continuation is
;;   invoked are lost.
;;  
;; - (global SYMBOL)
;;
;;   Retrieve the value of the global variable that is named by SYMBOL
;;   in the current module.  (Current at the time of linking.)
;;
;; - (invoke PROC ARGS...)
;;
;;   Invokes PROC with ARGS.  PROC can evaluate to any Scheme object.
;;   However, when PROC is of the form `(global VAR)', we cooperate
;;   with the module system to generate a more efficient calling
;;   sequence.
;;
;; - (inline OP ARGS...)
;;
;;   Generate inline code for OP and ARGS.  OP must have been
;;   registered with the compiler previously as an inline-operator.
;;   Typical OPs are `+', `car', etc.
;;
;; - (labels ((LABEL (ARGS...) BODY) ...) BODY)
;;
;;   Establish labels that can be jumped to with GOTO, which see.  The
;;   labels are visible within all of the BODYs in the labels form.
;;   The continuation of each BODY is the continuation of the LABELS
;;   form.
;;
;;   ARGS can be of the form (SYMBOL :reg N) to indicate a register
;;   preference level.  Just SYMBOL is equivalent to (SYMBOL :reg 0).
;;
;; - (goto LABEL ARGS...)
;;
;;   Transfer control to LABEL, passing it ARGS.
;;
;; - (functions ((FUNC (ARGS...) BODY) ...) BODY)
;;
;;   Like `labels', but you need to use `call' instead of `goto'.
;;
;; - (call FUNC args...)
;;
;;   Invoke FUNC, passing it ARGS.
;;
;;
;; Example:
;;
;;   (lambda-template (n)
;;     (if (inline < (local n) (quote 2))
;;         (quote 1)
;;         (inline + (invoke (global fib) (inline - (local n) (quote 2)))
;;                   (invoke (global fib) (inline - (local n) (quote 1))))))
;;
;;
;; Note that there is no `let' equivalent.  Use `labels' instead.
;;
;; A `functions' form where all `calls' appear in tail positions is
;; semantically equivalent to a `labels' form, but the compiler
;; doesn't detect this.  It still emits code to handle the general
;; case.  You have to help it by explicitely using a `labels' form
;; when possible.  This might change in the future, but right now,
;; `functions' isn't even implemented at all.
;;
;; In general, this compiler does no optimizations that could have
;; been performed on its input source.  The expertise of this compiler
;; should be argument shuffling to implement tail calls and
;; parameter-passing gotos, branch optimizations, (simple) register
;; allocation, and inlining of certain operations like fixnum
;; arithmetic and cons cell walking.
;;
;; Things like closure-conversion, removal of explicit lambdas etc are
;; left to the upper layers.

I think I'd prefer to work with such a language (compared to a stack
based language like GLIL).  The stack is already too explicit, and
probably interferes with register allocation.  On the other hand
generating stack-code from this should be very easy.

I think this language is easy to target for Scheme.  `functions' is
intended for known functions that need no heap closure, and `labels'
is for known functions that only tail call each other, i.e., which
don't need a closure at all.

I'm not convinced that this is all that is needed, but it feels like a
good start.  I want to play a bit (or two) with the Larceny compiler
as a front end for the guile-lightning compiler.