Juergen Boemmels wrote:
>
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > Further:
> > The C<setline> and C<setfile> opcodes are suboptimal, they impose
> > runtime penalty on each run core, so they will go finally. The
> > C<getline> and C<getfile> can map to the functionality used in
> > warnings.c.
>
> Normal processors also don't have setline and setfile operations. They
> use an extra segment in the *.o file, which is only used by the
> debugger. This could also be done in parrot.
In other words, setline and setfile ops in source don't translate to
actual ops in the bytecode, but instead translate to additions/changes
to the debugging segment?
> We just need to settle on a format for the line-info bytecode segement.
> The only question is reinvent the wheel, or use an already establiched
> format (stabs or DWARF).
>
> > And finally: Parrot will (again[2]) track HLL source line info like:
> >
> > #line 17 "sourcefile.p6"
> >
> > So that warnings and errors can be located in HLL source too.
I don't like this syntax -- it sounds too easy for someone to write a
comment like:
#When this was in the original foobar language, it was on
#line 17
And have it interpreted as a directive, when the author meant for it to
be just a comment.
There's no reason not to have the directives look like ops (setline,
setfile).
Oh, and you could have get{line,file} directives, which end up
translated as being simple "set" ops, using the info generated by the
set{line,file} directives.
> It might be nice to have column information to. This would make
> debugging of Befunge programs a lot more easy. Also it would be nice
> to have blocks of code (many pasm-lines) with just one linenumber, and
> otherwise have a possiblity to increase the source-line with each line
> of pasmcode.
I like the ideas of a range of characters, and of variable amount of
information. So, how about multiple setline variants?
setline Ix # all code from here to the next set{line,file} op is line
x
setline Ix, Iy # set line,col number from here to next set* op.
setline_i Ix # the next line is x, each succeeding line increases.
setlinerange Ix, Iy # the following represents lines x..y of hll
code.
setlinerange Ix, Iy, Iz, Iw # line x, col y .. line z, col w.
setfile Sx # sets filename from here to next setfile op.
There'd be a corresponding get* function for each of these except for
setline_i (for which it wouldn't make sense), which would get translated
at compile time to "set Ix, 12" or whatever. There should be a C-code
level interface to go (at runtime) from a pointer to bytecode (or from a
bytecode offset) to a file, line, or range of lines, or ... with
columns; this would be useful for debuggers.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}