|[2 earlier articles]|
|Re: How long does it take to build a compiler? firstname.lastname@example.org (1993-10-30)|
|Re: How long does it take to build a compiler? email@example.com (Youngwhan Lee) (1993-11-01)|
|Re: How long does it take to build a compiler? firstname.lastname@example.org (1993-11-01)|
|Re: How long does it take to build a compiler? email@example.com (1993-11-04)|
|Re: How long does it take to build a compiler? firstname.lastname@example.org (1993-11-05)|
|Re: How long does it take to build a compiler? xjam@ginkgo.CS.Berkeley.EDU (1993-11-09)|
|Re: How long does it take to build a compiler? email@example.com (1993-11-09)|
|Re: How long does it take to build a compiler? firstname.lastname@example.org (1993-11-10)|
|From:||email@example.com (David Keppel)|
|Organization:||Computer Science & Engineering, U. of Washington, Seattle|
|Date:||Tue, 9 Nov 1993 21:49:04 GMT|
xjam@ginkgo.CS.Berkeley.EDU (Crossjammer) writes:
>[I suspect debugging virtual machine code is easier than debugging
> generated assembly.]
Rarely, however, are there symbolic debuggers for the machine code of the
virtual machine; that makes it harder to debug the VM code. Also, note
that one *could* write a VM for real hardware and use that to debug the
compiler output, but rarely is that done, and usually it's done when the
hardware doesn't yet exist, so there is little choice.
I suspect that in general it is *harder* to debug using a VM, but that in
particular cases where the VM has "high level" operations it is much
easier to write the code generator (both ease of translation and that
optimizations are redundant since most time is spent in the VM anyway).
A big problem with VM's is that they add an extra level of translation and
thus another level of mappping: "OK, I found bad machine state in the VM,
I have to map that back to the generated VM code, then map *that* back to
the source constructs."
;-D on ( Translation is virtually mechanical ) Pardo
Return to the
Search the comp.compilers archives again.