Re: guile-vm 0.3

[Keisuke Nishida]

At 11 Apr 2001 23:49:57 +0200,
Marius Vollmer wrote:
> 
> > 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):

Looks interesting, and this is more like the internal form of my GHIL,
which is a structured language like yours.  After parsing and macro
expansion, GHIL is reduced to a simpler form like this language.
(After then, it is converted into GLIL.)

So, maybe I should stop transformation at the end of the GHIL stage.

> ;; - (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.

How do you use ENV?  Are you adding `env-ref' or something?
Is it dynamic or static? (i.e., when do you look up?)

> ;;   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'.

(By the way, a closure template can be invoked in my VM
when it is known that the closure template does not contain
any environment references.  Actually, I do not distinguish
a closure template from a closure; one is a closure without
an environment, and the other is a closure with an environment.
Closures without environments are constants:

  address@hidden> (define (foo) (lambda () 1))
  address@hidden> ,disassemble foo
  Disassembly of #<program foo>:

     0    object-ref 0                    ;; #<program 80f7e26>
     2    return
)

> ;; - (global SYMBOL)
> ;;
> ;;   Retrieve the value of the global variable that is named by SYMBOL
> ;;   in the current module.  (Current at the time of linking.)

Are you going to look up global variables at loading time?
If so, you can't do global analysis at compile time, can you?
I'd prefer an explicit reference as follows:

  (module-ref MODULE-NAME SYMBOL)
  (module-set MODULE-NAME SYMBOL VALUE)

(But in my current VM, MODULE-NAME is just ignored.)

> ;; 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.

Do you really need the `functions' form?  You distinguish global
function calls (`invoke') from local function calls (`call'),
which complicates the system, I think.  But maybe it's worth
doing.  Hmm, I need to think about it.

> 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 agree with that.  We should be able to combine our efforts
after some experiences.

Keisuke