Dan Sugalski wrote:
Your code is fine. It *should* work. That it doesn't is a bug, which needs fixing. For now you're going to have to work around it.

I would have swore the code was wrong. Am I being naive thinking that a
call to a sub is different than what looked like a call to a label. On further investigation I had a look at


operation.pod

and found the following statement

67
68 To determine the life range of variables, the code gets separated
into
69 pieces, called B<basic block>s. A B<basic block> starts at a label,
70 which can get jumped to, and ends at a branch instruction.

This meant my last post was severely flawed. I then decided to try the following code and it seems to work

      1 .sub _main
      2         goto L1
      3 test:
      4         $I1 = 1
      5         branch L2
      6 L1:
      7
      8         $I2 = 2
      9         call test
     10 L2:
     11         print $I2   # prints 2 as expected
     12         end
     13 .end

I have changed "ret" to "branch L2" and added the "L2" label. So for some reason the compiler can now see that we are in a basic block and saves the state acordingly or at least that is what appears.

The pasm is as follows.

      1 _main:
      2         branch L1
      3 test:
      4         set I16, 1
      5         print I16
      6         branch L2
      7 L1:
      8         set I17, 2
      9         bsr test
     10 L2:
     11         print I16
     12         print I17
     13         end

Can someone clarify what on earth just happened here. Is "ret" not seen as a branch by IMCC so it has no idea it is in a block. I have had a look at cfg.c but it is a bit beyond me what is happening in there.

Harry





Reply via email to