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;}