develooper Front page | perl.perl6.internals | Postings from September 2005

Re: [RFC] Debug Segment, HLL Debug Segment And Source Segment

Thread Previous | Thread Next
Roger Browne
September 21, 2005 04:02
Re: [RFC] Debug Segment, HLL Debug Segment And Source Segment
Message ID:
Jonathan Worthington wrote:


Great! Anything that brings parrot closer to being able to report the
HLL filename and line numbers is a good thing!

> ... the idea would seem to be 
> that this segment can contain source code.  I suspect the intention of it 
> was to store the source code of high level languages rather than PASM or 
> PIR.

I don't think Parrot should care about what languages are in the source
segments. If someone is writing directly in PASM or PIR, that can go in
a source segment. If someone is writing in a high-level langauge, that
can go in a source segment. If someone is writing data from which HLL
code is generated by some utility (e.g. yacc, a UML tool, or a GUI
designer), that data can go in a source segment too.

Any kind of source code for which there exists some kind of debugging
tool is a candidate to go into a source segment. This implies that there
could be more than one source segment per .pbc file, and more than one
source location for each opcode. It also implies that (eventually)
parrot will have a way of knowing how to call all the candidate
debuggers for a particular bytecode location (according to which source
language the programmer wants to debug in).

[Incidentally, source segments may also meet the needs of those who wish
to distribute source with every application, without burdening those who
just want to run the compiled code.]

> 2) Allowing for a reference into the source segment in place of a filename.

Some development tools are still going to want the filename, even if
there is a corresponding source segment in the .pbc file. I think it
should be possible to include both.

> This change is incompatible with the current debug segment format.  But 
> that's OK, we're still in development.

Sure, but if we're going to change it, let's change it to something
general that won't need to be changed again after version 1.0 is

This is something that Dan Sugalski mooted in his "WCB: Full bytecode
metadata" blog entry:

I like the idea that each HLL can store whatever kind of metadata it
wants. In particular, I'd like to have my Amber compiler put column
numbers as well as line numbers into the .pbc file, and perhaps even
information about which optimizations it has applied.

> 3) Still being space-efficient on disk

Source segments should probably be compressed. There's a lot of
repetition and whitespace in most source languages, so they tend to
compress really well. Any reference into the source would be an offset
into the uncompressed source (which would only need to be uncompressed
during debugging runs).

> The opcode stream will contain one line number per
> bytecode instruction.

You are proposing to use a chain of mappings to record the filename; why
not use the same system for recording all kinds of metadata including
line numbers? Sure, there's a small performance penalty - only during
debugging runs - but there's a worthwhile space saving on disk (because
typical HLLs produce a lot of bytecodes per line of source).

Roger Browne

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About