imcc pasm generation

2003-09-02 Thread Will Coleda
Should I expect:

parrot -o foo.pasm foo.imc
parrot foo.pasm args
to work like:

parrot foo.imc args

? (it doesn't appear to be de-mangling two different outer: labels, 
each of which is in it's own enclosing .sub)

I'm trying to track down a bug where a .local var that's a PerlArray is 
getting replaced with a PerlInt at some point, and I'm trying to figure 
out why. Presuming I'm somehow stepping on that PMC register in a 
subroutine I'm calling, and thought looking at the pasm might help me 
track down where it was occurring.

Better suggestions on how to debug .imc in general appreciated. =-)

--
Will Coke Coledawill at coleda 
dot com



Re: imcc pasm generation

2003-09-02 Thread Luke Palmer
Will Coleda writes:
 Should I expect:
 
 parrot -o foo.pasm foo.imc
 parrot foo.pasm args
 
 to work like:
 
 parrot foo.imc args

No.  imcc doesn't emit local labels properly (as you seem to have
discovered).  

 ? (it doesn't appear to be de-mangling two different outer: labels, 
 each of which is in it's own enclosing .sub)
 
 I'm trying to track down a bug where a .local var that's a PerlArray is 
 getting replaced with a PerlInt at some point, and I'm trying to figure 
 out why. Presuming I'm somehow stepping on that PMC register in a 
 subroutine I'm calling, and thought looking at the pasm might help me 
 track down where it was occurring.

Sounds to me like you're confusing imcc's control flow analysis.  Make
sure you're conforming to the calling conventions and using savetop,
etc. when you should (or using .pcc_*, which does this for you).

 Better suggestions on how to debug .imc in general appreciated. =-)

print?  parrot -t?  Those have usually been sufficient for me.  I've
never been able to use pdb very well...  The 'trace' opcode is pretty
nice, too.

Luke

 --
 Will Coke Coledawill at coleda 
 dot com
 


Re: imcc pasm generation

2003-09-02 Thread Leopold Toetsch
Will Coleda [EMAIL PROTECTED] wrote:
 Should I expect:

[ Luke already did answer it, but some more hints ]

 parrot -o foo.pasm foo.imc
 parrot foo.pasm args

 to work like:

 parrot foo.imc args

No. as mentioned. The most useful thing here probably is:

  $ parrot -o- foo.imc # | less

to have a quick look at PASM output. This output is nor intended for
running any more (label mangling and .pcc_sub handling are not
implemented in PASM mode).

 I'm trying to track down a bug where a .local var that's a PerlArray is
 getting replaced with a PerlInt at some point, and I'm trying to figure
 out why. Presuming I'm somehow stepping on that PMC register in a
 subroutine I'm calling, and thought looking at the pasm might help me
 track down where it was occurring.

Which calling conventions are you using?

 Better suggestions on how to debug .imc in general appreciated. =-)

  $ parrot --help-debug
  $ parrot -d18 foo.imc 21 | less   # or
  $ parrot -d18 foo.imc foo.debug 21

does give you details of life analysis and register allocation.

Also the register allocator isn't yet finished (or totally switched to
Parrot Calling Conventions). If too many variables (16) are used across
a function call, they are not preserved yet.

 Will Coke Coledawill at coleda

leo