Re: What happened to the ex-Guile VM?

[Keisuke Nishida]

At 20 Mar 2001 14:49:52 +0100,
Mikael Djurfeldt wrote:
> 
> > One is for fast execution, and one is for debugging execution.
> 
> One idea could be to drop the conditional compilation in eval.c and
> only keep the debugging evaluator, and replac the "normal" evaluator
> with your VM.  But it would of course be nicer if we could replace the
> current evaluator completely.  At the same time, we wouldn't like to
> downtrade a lot with regard to for example the quality of backtraces.
> The current backtraces are very informative when debugging.  We should
> work on getting a similar quality of source level backtraces when
> using your VM.

A simple backtrace can be implemented very soon, since the VM
creates stack frames already.  However, frames are created
only when closures are called, so you can't backtrace primitive
calls and syntaxes.  For example, there is no backtrace
information in case of the following error:

  (let ((x 1))  ;; No frame due to a syntax
    (car x))    ;; No frame due to a primitive call

I'm going to add extra information to bytecode in order to
support more informative backtrace, error messages, and
source level debugging.

> This is *very* interesting.  Current policy with regard to Guile and
> language translation is to have translators translate into Scheme.
> The reason for this policy is that we don't want translators tied to a
> particular VM.  However, if your language GCIL is in itself generic
> enough, we should consider the possibility of using that instead as a
> target for translators.

Currently, it is just a `@'-prefixed version of Scheme ;)
We can add/remove more features as we proceed.

I'm thinking of two levels of intermediate languages.  Maybe
I should call them GHIL (Guile High Intermediate Language)
and GLIL (Guile Low Intermediate Language).

GHIL is a structured, functional language, just like Scheme.
GLIL is more like an assembly language, a stack-based VM code.

A high-level language is first translated into GHIL.  There is
a standard GHIL compiler, which converts GHIL to GLIL with
optimization (or without it).  GLIL is then assembled into a
platform specific code, like my VM bytecode or machine code.

Since both GHIL and GLIL are intermediate forms, they are
usually represented by internal parsed structures.  For
convenience, it is also possible to write them in a list
form as follows:

  Source: (define (add x y) (+ x y))

  GHIL:   (@define add (@lambda (x y) (@+ x y)))

  GLIL:   (@asm ()
            (@asm (x y)
              (ref x)
              (ref y)
              (add)
              (return))
            (set add)
            (const *unspecified*)
            (return))

GLIL supports local variables as follows:

  (@let ((x 1)) x)  ->

  (@asm ()
    (const 1)
    (@local (x))
    (@bind)
    (ref x)
    (return)
    (@unbind))

  (@letrec ((x 1)) x)  ->

  (@asm ()
    (@local (x))
    (const 1)
    (@bind)
    (ref x)
    (return)
    (@unbind))

Labels and branches:

  (@if x y z)  ->

  (@asm ()
    (ref x)
    (br-if-not :L0)
    (ref y)
    (return)
    (label :L0)
    (ref z)
    (return))

Debug information:

  (@+ 1 2)  ->

  (@asm ()
    (@source 1 5)   ;; line 1 column 5
    (const 1)
    (@source 1 7)
    (const 2)
    (@source 1 1)
    (add)
    (return))

I'm not sure whether this is a good intermediate language, but
I think having two levels of intermediate languages seems good.

> (BTW, have you studied the language translation proposal?
>  guile-core/devel/translation/langtools.text)

Yes, but since I'm doing a transient work right now, I have
chosen an easy interface without thinking.

Kei