[perl #45857] [IMCC][RFC] #line vs .line

[Patrick R. Michaud via RT]

A few months ago, the "#line" directive was implemented.
I'm wondering what the reason was why it looks like a comment (as # will
start a comment).
Is there any reason to not replace this by ".line"? A directive typically
tells the assembler/compiler something, and in this case it updates

the line

number.

As this gets addressed we should also address the handling of the
'setline' opcode (RT #43269).

Pm

[Jonathan Worthington]

Post by Patrick R. Michaud via RT

A few months ago, the "#line" directive was implemented.
I'm wondering what the reason was why it looks like a comment (as #

will

Post by Patrick R. Michaud via RT

start a comment).
Is there any reason to not replace this by ".line"? A directive

typically

Post by Patrick R. Michaud via RT

tells the assembler/compiler something, and in this case it updates

the line

number.

As this gets addressed we should also address the handling of the
'setline' opcode (RT #43269).
Pm

.line directive is implemented per r33084. #line still works.
I'm not sure what Pm meant by addressing the handling of 'setline'
opcode, so leaving this ticket open.

I'm planning to work on bytecode annotations Real Soon Now...my thoughts
on these issues are:

* I think .line and .file will remain for setting the PIR-level line and
file (#line and #file maybe too, or we could deprecate those)

* .annotate "key" value / .annotate "key" "value" will be added for
setting annotations, which will form high level language debug info
(.line and .file may be converted to also store data using the new
annotations segment rather than keeping a separate PIR debug segment in
the future; not sure how soon that will happen, will leave the current
debug seg intact for now though)

* setline and setfile opcodes can probably go away; I can't think of a
use case where we'd want to set these dynamically, since we know the
line number/file number/column/whatever else we wish to store at compile
time. Doing an op dispatch rather than making an annotation we can look
up only when we need it seems odd to me.

Thoughts?

Jonathan

[Klaas-Jan Stol]

On Sun, Nov 23, 2008 at 10:08 PM, Jonathan Worthington

A few months ago, the "#line" directive was implemented.
I'm wondering what the reason was why it looks like a comment (as #

will
start a comment).

Is there any reason to not replace this by ".line"? A directive

typically
tells the assembler/compiler something, and in this case it updates
the line

number.

As this gets addressed we should also address the handling of the
'setline' opcode (RT #43269).
Pm

.line directive is implemented per r33084. #line still works.
I'm not sure what Pm meant by addressing the handling of 'setline' opcode,
so leaving this ticket open.

I'm planning to work on bytecode annotations Real Soon Now...my thoughts on
* I think .line and .file will remain for setting the PIR-level line and
file (#line and #file maybe too, or we could deprecate those)

Minor detail:
.file does not actually exist, except in PIRC. I do not have a strong
preference for adding it. Pro: it's a bit clearer than .line, as .line
indicates, ehm, the "line" :-) Specifying a filename by .line is a bit
weird. Con: generating 2 directives instead of 1 each time you want to
update the location makes the generated code string a bit longer/more
verbose, which might not be desirable. Anyway, I'm open to anything :-)
(possibly renaming even to .location (or .loc, but that's another well-known
abbreviation)

* .annotate "key" value / .annotate "key" "value" will be added for setting
annotations, which will form high level language debug info (.line and .file
may be converted to also store data using the new annotations segment rather
than keeping a separate PIR debug segment in the future; not sure how soon
that will happen, will leave the current debug seg intact for now though)
* setline and setfile opcodes can probably go away; I can't think of a use
case where we'd want to set these dynamically, since we know the line
number/file number/column/whatever else we wish to store at compile time.
Doing an op dispatch rather than making an annotation we can look up only
when we need it seems odd to me.

I agree.

Thoughts?
Jonathan

[Jonathan Worthington]

Post by Klaas-Jan Stol
.file does not actually exist, except in PIRC.

Well, I guess we can add it...

Post by Klaas-Jan Stol
I do not have a strong preference for adding it. Pro: it's a bit clearer than .line, as .line indicates, ehm, the "line" :-) Specifying a filename by .line is a bit weird. Con: generating 2 directives instead of 1 each time you want to update the location makes the generated code string a bit longer/more verbose, which might not be desirable. Anyway, I'm open to anything :-) (possibly renaming even to .location (or .loc, but that's another well-known abbreviation)

Oh, argh, so .line now carries the file *and* the line number?.I wanted
it to just carry the line number (the clue's in the name... ;-)) and
have .file carry the filename. Then the source you compiled from one
file has one ".file 'foo.pir'" directive, and then you just have ".line
42" style things for lines.

Wonder how much of a pain it'd be to change that. Since you only just
added .line it, we can probably take this opportunity to make it mean
what we want (just a line number), add .file, then deprecate #line and
#file and we're done...perhaps for the next release.

Sound sane?

Jonathan

[Patrick R. Michaud]

Post by Jonathan Worthington
Oh, argh, so .line now carries the file *and* the line number?.I wanted
it to just carry the line number (the clue's in the name... ;-)) and
have .file carry the filename. Then the source you compiled from one
file has one ".file 'foo.pir'" directive, and then you just have ".line
42" style things for lines.

Either way works for me -- PCT can generate either without much
difficulty. It probably makes more sense to have separate .file
and .line directives. In particular, I wouldn't want to be
repeating the .file annotation information throughout the bytecode! :-)

Just a reminder that the central issue for PCT and other HLL's
is that the current #line, setline, setfile, etc. instructions
are currently intimately tied to lines of PIR source (RT #43269),
and they probably shouldn't be.

I agree that I don't see a strong need for setting file and
line number dynamically -- at least not at this stage.

Thanks!

Pm

[Jonathan Worthington]

Post by Patrick R. Michaud
Either way works for me -- PCT can generate either without much
difficulty. It probably makes more sense to have separate .file
and .line directives. In particular, I wouldn't want to be
repeating the .file annotation information throughout the bytecode! :-)
Just a reminder that the central issue for PCT and other HLL's
is that the current #line, setline, setfile, etc. instructions
are currently intimately tied to lines of PIR source (RT #43269),
and they probably shouldn't be.
I agree that I don't see a strong need for setting file and
line number dynamically -- at least not at this stage.

Let me clarify a little. The current ".file" and ".line" directives are
tied to PIR lines. That's fine, and I'm planning we can keep things that
way. We could use such a feature now, e.g. in gen_builtins.pir, for
example. It's useful when you're building PIR from other bits of PIR.
But I don't expect PCT will be emitting these two directives.

Instead, I expect PCT will emit .annotate. This allows you to emit
whatever annotations you wish. So you can do file and line annotations,
but you can also choose to do column too if needed. We can use it to
stash away the source code for a sub so we can do .perl for subs, or for
stashing away the compiler version or OS we compiled under for the
various $?FOO variables. When an exception is thrown, we already capture
the location it was thrown from, and thus there will be a way to get
which of these settings were in effect at the point that the exception
was thrown. As an upshot of this, .annotate is not at all tied to PIR
lines - the latest annotation under a given key takes precedence. So you
can emit at the start maybe:

.annotate "file" "foo.pl"
.annotate "compiler" "rakudo-0.1"

And then per line:

.annotate "line" 42

When a new source code line starts.

And yes, I need to get this all into the PIR docs, though the storage
scheme for all of this is in the bytecode PDD already. But it should
give us plenty of flexibility.

Sound good?

Thanks,

Jonathan

[Patrick R. Michaud]

Post by Jonathan Worthington

Post by Patrick R. Michaud
Just a reminder that the central issue for PCT and other HLL's
is that the current #line, setline, setfile, etc. instructions
are currently intimately tied to lines of PIR source (RT #43269),
and they probably shouldn't be.

Instead, I expect PCT will emit .annotate. This allows you to emit
whatever annotations you wish.
[...]
And yes, I need to get this all into the PIR docs, though the storage
scheme for all of this is in the bytecode PDD already. But it should
give us plenty of flexibility.
Sound good?

Sounds fantastic! I can hardly wait!

Pm

[Klaas-Jan Stol]

Post by Patrick R. Michaud

Post by Jonathan Worthington
Oh, argh, so .line now carries the file *and* the line number?.I wanted
it to just carry the line number (the clue's in the name... ;-)) and
have .file carry the filename. Then the source you compiled from one
file has one ".file 'foo.pir'" directive, and then you just have ".line
42" style things for lines.

Either way works for me -- PCT can generate either without much
difficulty. It probably makes more sense to have separate .file
and .line directives. In particular, I wouldn't want to be
repeating the .file annotation information throughout the bytecode! :-)

well, I guess that's two +1's for the proposal in RT#59830 :-)

kjs