Michal Wallace:
# On Sun, 24 Aug 2003, Leopold Toetsch wrote:
# > We have two kinds of file/line information: Parrot source and HLL
# > source. So the C<.currentline> macro needs duplication or an
argument
# > specifying, which source it should denote.
#
# And when parrot throws an error and comp
Gordon Henriksen:
# p6.pl 1: my $var is int;
# p6.pl 2: $var = ($var * $var + 1) * 2 + 3;
#
# p6.imc 1: .local int var
# p6.imc 2: setfile "p6.pl"
# p6.imc 3: setline 1
# p6.imc 4: var = 0 # So far, so good.
# p6.imc 5: var = var *
On Sun, 24 Aug 2003, Leopold Toetsch wrote:
> We have two kinds of file/line information: Parrot source and HLL
> source. So the C<.currentline> macro needs duplication or an argument
> specifying, which source it should denote.
And when parrot throws an error and complains about line 5,
which o
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Do macros have their own line number context, or do they get the context
> from the code they're being called from?
Macros have their own line numbers. Tracking filenames (from .include)
isn't done yet.
Debugging PASM with JIT/i386 inside ddd[1] foll
Robert Spier <[EMAIL PROTECTED]> wrote:
>> > The HLL doesn't know, how many ops one source line will need.
>>
>> Not *normally*, but if it's including code which is already literal
>> assembler, it does: Imagine a version of lex/yacc wherein the the blocks
>> of code you give are imcc or pasm (inst
On Saturday, August 23, 2003, at 08:22 , Benjamin Goldberg wrote:
Leopold Toetsch wrote:
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
setline_i Ix # the next line is x, each succeeding line increases.
The HLL doesn't know, how many ops one source line will need.
Not *normally*, but if it's in
> For that matter, won't the optomizer wreak havoc with other all of the
> various other uses of .setline?
One would hope.
> Anyway, how about this semantic: .setline_i would associate an
> ...
Before making up semantics, it might be useful to look at what other
systems do, like STABS and DWARF
Robert Spier wrote:
>
> > > The HLL doesn't know, how many ops one source line will need.
> >
> > Not *normally*, but if it's including code which is already literal
> > assembler, it does: Imagine a version of lex/yacc wherein the the
> > blocks of code you give are imcc or pasm (instead of C).
> > The HLL doesn't know, how many ops one source line will need.
>
> Not *normally*, but if it's including code which is already literal
> assembler, it does: Imagine a version of lex/yacc wherein the the blocks
> of code you give are imcc or pasm (instead of C). Clearly, there's one
> op per li
Juergen Boemmels wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
>
> > > 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 word
Leopold Toetsch wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
> > 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?
>
> Exactly. (+ C, which isn't done yet)
>
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> > 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
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> 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?
Exactly. (+ C, which isn't done yet)
> I like the ideas of a range of character
Leopold Toetsch:
# And finally: Parrot will (again[2]) track HLL source line info like:
#
##line 17 "sourcefile.p6"
Why create a new directive syntax when we already have one?
.line 17 "sourcefile.p6"
--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
"Yeah, and my underwear i
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> 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 fr
According to Benjamin Goldberg:
> > >#line 17 "sourcefile.p6"
>
> 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
Do you worry about Perl too? Because Perl already has this.
Funny
Juergen Boemmels wrote:
>
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > Further:
> > The C and C opcodes are suboptimal, they impose
> > runtime penalty on each run core, so they will go finally. The
> > C and C can map to the functionality used in
> > warnings.c.
>
> Normal processors a
[EMAIL PROTECTED] writes:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
>
> > I think that it has practical uses for other, dimensionally inferior
> > languages. It would often be nice to know which bit of this line:
> >
> > } elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~
> /([^.]{4,}\.[^.]{2}
Nicholas Clark <[EMAIL PROTECTED]> writes:
> On Fri, Aug 22, 2003 at 02:30:13PM +0200, Juergen Boemmels wrote:
>
> > a format for the line-info bytecode segement. The only question is
> > reinvent the wheel, or use an already established format (stabs or
> > DWARF).
>
> can they do the things be
On Fri, Aug 22, 2003 at 02:30:13PM +0200, Juergen Boemmels wrote:
> a format for the line-info bytecode segement. The only question is
> reinvent the wheel, or use an already establiched format (stabs or
> DWARF).
can they do the things below?
> It might be nice to have column information to. Th
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Further:
> The C and C opcodes are suboptimal, they impose
> runtime penalty on each run core, so they will go finally. The
> C and C can map to the functionality used in
> warnings.c.
Normal processors also don't have setline and setfile operations.
21 matches
Mail list logo
