Translation & Debugging (was: Steps)

[Matthew Tuck]

Hans-Dieter.Dreier@materna.de wrote:

> The mapping isn't all. You also got to find variables (on stack, inside
> objects, in static memory), interpret them (as numbers, pointers, text,
> arrays, structures), set breakpoints, look at registers (eg return values
> are always kept in EAX on '86 machines), interpret the stack for a call
> history. There may be Windows callbacks interspersed. That's a helluva
> lotof work, and mostly lowest level and VERY machine and compiler-dependent.
> Once upon a time I did a debugger for the good old (8-bit) 6800 which was
> much much less complicated than today's CPUs and it took me really long.
> It doesn't pay off if we need to do it ourselves. If we can find an
> extendible expandable source code for that maybe it's a different matter,
> but I won't count on that...

OK, so certainly debugging at the machine-code level within the editor
will be difficult.  But debugging at the HLL level should be our first
debugging goal, although we should endeavour to build as much framework
as possible for this into the editor to make it easier to extend to new
languages and views.

> If it's C-generated assembly code, you'd be in for a really hard time.
> See above and take that to the power of 2. But we are a long way from
> that...

Yes, I would hope we would have better solutions by then.  That doesn't
mean a C debugger wouldn't be worth doing of course.  But I probably
wouldn't be involved.  =)

> Yes. If the next step has less code, it's no problem either.

I would only expect that to occur if something is unneeded, or the
output is optimised.

> ...
>  "there are " + n + " pigs."
> he actually gets
>  "there are " + n.tostring () + " pigs."
> Now the editor could decompile the AST generated by the compiler and display
>  "there are " + n.tostring () + " pigs."
>  ----------------++++++++++++-----------
> ...

Well, assuming there is anything implicit, we could do this.  It would
probably be a nicer way to debug the optimiser than looking at machine
code and writing a machine code debugger too!  I can't see much work
involved.  You have existing deparsing facilities, plus you already have
the optimised AST (which would already have implicit stuff made
implicit).

Perhaps the best way to do this is by having a "language X to language
X" translator, ie an optimiser, in the translational hierachy.  Hence
you can view the source at each stage.  This seems to fit in very nicely
with what we're already planning!

This would make the optimiser a plug-in translation, so it could be
added in later.  Or you could put two there if you desired.

--
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/