# 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)

[ compile.pir < 1K ]
.sub main @MAIN
  register_compiler()

  .local pmc compiler, invokable
  compiler = compreg "PUTS"

  invokable = compile compiler, "ok 1"
  invokable()

.end

.sub register_compiler
  $P0 = find_global "puts"
  compreg "PUTS", $P0
.end

.sub puts
  .param string printme

  .local pmc pasm_compiler, retval
  pasm_compiler = compreg "PASM"

  .local string code

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

  retval = compile pasm_compiler, code

  .return (retval)
.end

Will Coleda (via RT) wrote:

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

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

leo

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

Nick

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

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

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.))

compile2.pir < 1K Download