This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: guile-vm-0.0


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> > Debugging support is the concern I have about my VM.  Since bytecodes
> > loose information about source code, I'm not sure if I can provide a
> > good debugging interface. (Nobody want to trace assemble code)
> 
> It is probably possible to supplement the byte code of each closure
> with a separate package of debugging information (much the same way
> that object files contains extra debugging information)?  This could
> be used to achieve source-level debugging.

Probably.  Each closure may have its own properties, so adding some
information there is certainly possible.  Closure-level backtrace is
not so hard.  One tricky part is, for example,

  (define (multiply a b)
    (let loop ((result 0) (multiplier b))
      (if (<= multiplier 0)
          result
          (loop (+ result a) (1- multiplier)))))

This function doesn't call any closure, so if one want to execute it
in step, the debugger must emulate execution instead of having the VM
execute one step.  VM's one step is different from that of Scheme.

And emulating execution is exactly what an interpreter does.  If I want
to add a source level debugging feature, I have to write another Scheme
interpreter on the top of the VM, don't I?  Hmm, no, maybe I can add
such information that tells the VM that which expression corresponds to
which sequence of bytecodes, and then let the VM continue execution
until the end of a Scheme expression one want to step...

So it is like what GDB does, right?  Maybe we'll have it after three
years :)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]