[perl #35944] PIR compilers broken?

[Will Coleda]

# New Ticket Created by Will Coleda
# Please include the string: [perl #35944]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35944 >

Leo's recent patches to <compile> seem to have improved the state of affairs, but I'm still having difficulty with tcl's <compile>r. The attached is a simplified version that exhibits the same problems I'm experiencing.

Attached find a test for <compile>rs written in PIR. (very simple compiler. takes a string and prints it out with a trailing newline.)

While I expect it to print "ok 1", it instead prints:

Null PMC access in invoke()
current instr.: 'main' pc 50 (compile.pir:8)

[Leopold Toetsch]

Will Coleda (via RT) wrote:

> While I expect it to print "ok 1", it instead prints:
>
> Null PMC access in invoke()
> current instr.: 'main' pc 50 (compile.pir:8)

W/o testing it I'd say that ...

> code .= "print \""
> code .= printme
> code .= "\\n\"\n"

... a single print statement isn't a subroutine, so it has to fail.

leo

[Nick Glencross]

Will Coleda wrote:

> .local string code

>
> code .= "print \""
> code .= printme
> code .= "\\n\"\n"
>

This may be related, but your first .= is acting upon an uninitialised
variable.

Nick

[Nick Glencross]

Nick Glencross wrote:

Actually, the code dies before this. Worth fixing as you may get hit by
a Heisenbug at some point, as in:

.sub main
S30 = "Garbage"

.local string code
code .= "Hello\n"

print code
.end

(of course this problem may have only been introduced in the example
snippet that you've created)

Cheers,

Nick

[Will Coleda]

Fixed the uninitialized string error Nick pointed out, but as he noted, it
has no effect on the error.

Leopold Toetsch writes:

But this is the PASM compiler, not the PIR compiler - Attached find the
slightly more complicated example using a PIR sub instead of a PASM snippet
which dies in exactly the same fashion. (Which is to say, as the invokable
is invoked with <invokecc>). I even insure that the anonymous sub is not
reused by dynamically creating a .sub name, though for this particular
example it's irrelevant.

(Note: the subject "PIR compilers" was referring to "compilers written in
PIR", as opposed to the compilers written in C. (as opposed to being opposed
to the PASM compiler.))