Backward branch, warnocked.
Pete Lomax
Leo clarified this as a problem with backward branch circa 3/12/03:
Sorry to be a pain in the butt, but I need to be told that there has
been no improvement in the last two months on this ;-(
.sub _main
goto L1
test:
$I1 = 1
ret
L1:
$I2 = 2
call test
print $I2 # prints 1, not 2
end
.end
Surely it can't just be me that thinks this is rather fundamental?
How fundamental *is* the problem, can it *ever* be fixed?
Again, sorry to be a pain, but I'd like the truth/an update, please!
Or some hints... file level variables... better ways to code this...
Pete
PS use parrot -o and examine the output .pasm:, $I1 and $I2 (or
.local int i, .local int j) get assigned the same register.
Michal Wallace
> .sub _main
> goto L1
> test:
> $I1 = 1
> ret
> L1:
> $I2 = 2
> call test
> print $I2 # prints 1, not 2
> end
> .end
...
> Again, sorry to be a pain, but I'd like the truth/an update, please!
> Or some hints... file level variables... better ways to code this...
>
> Pete
> PS use parrot -o and examine the output .pasm:, $I1 and $I2 (or
> .local int i, .local int j) get assigned the same register.
Huh. That is pretty funky. The problem is that
imcc doesn't realize the two variables ought to
be distinct, right?
A workaround is to call pushtopi and poptopi
around the "call" statement...
What's the benefit of doing it this way, rather
than using separate subs?
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------
Pete Lomax
<mic...@sabren.com> wrote:
>On Tue, 3 Feb 2004, Pete Lomax wrote:
>
>> .sub _main
>> goto L1
>> test:
>> $I1 = 1
>> ret
>> L1:
>> $I2 = 2
>> call test
>> print $I2 # prints 1, not 2
>> end
>> .end
>Huh. That is pretty funky. The problem is that
>imcc doesn't realize the two variables ought to
>be distinct, right?
Yup.
>
>A workaround is to call pushtopi and poptopi
>around the "call" statement...
Um. Why topi? why not bottomi? why not saveall?
What if I want some side effects? What if I don't know exactly which
variables will/will not be affected? Or what happens if it is a
spilled register I _don't_ want updated?. More to the point how do I
work out which registers to restore to the ones I _did_ want updated?
Er.. sorry, you appear to have touched a raw nerve there...
>What's the benefit of doing it this way, rather
>than using separate subs?
Does this answer?:
.sub _main
$I2 = 2
call _m2
print $I2 # prints 1, not 2
end
.end
.sub _m2
$I1 = 1
ret
.end
I'm using a single sub because of a complete lack of file-level
variables. This I see as a serious, fundamental flaw.
Pete
Leopold Toetsch
> Leo clarified this as a problem with backward branch circa 3/12/03:
> Surely it can't just be me that thinks this is rather fundamental?
> How fundamental *is* the problem, can it *ever* be fixed?
It can be fixed. It'll take a lot of overhead. Following all branches in
spaghetti code is a PITA.
Just don't do that. Separate your subs in distinct compilation units.
leo
Harry Jackson
> Leo clarified this as a problem with backward branch circa 3/12/03:
>
> Sorry to be a pain in the butt, but I need to be told that there has
> been no improvement in the last two months on this ;-(
>
> goto L1
> test:
> $I1 = 1
> ret
> L1:
> $I2 = 2
> call test
> print $I2 # prints 1, not 2
> end
>
> Surely it can't just be me that thinks this is rather fundamental?
> How fundamental *is* the problem, can it *ever* be fixed?
>
> Again, sorry to be a pain, but I'd like the truth/an update, please!
> Or some hints... file level variables... better ways to code this...
>
> Pete
> PS use parrot -o and examine the output .pasm:, $I1 and $I2 (or
Not sure if this answers your question. At the bottom of this email
there is a bit taken from the IMCC.faq, I have pointed to the bit that I
think may tell us what has happened. When the above piece of code gets
converted to pasm we get
1 _main:
2 branch L1
3 test:
4 set I16, 1
5 ret
6 L1:
7 set I16, 2
8 bsr test
9 print I16
10 end
11
12
This is a branch not a subroutine call so IMCC as per the spec does not
take care of the scoping in this case.
To code it using subs we could use
1 .sub _main prototyped
2 .sym Sub connect
3 newsub connect, .Sub, _connect
4
5 $I1 = 2
6 .pcc_begin prototyped
7 .pcc_call connect
8 retconnect:
9 .pcc_end
10 print $I1
11 end
12 .end
13
14 .sub _connect
15 $I1 = 1
16 print $I1
17 .pcc_begin_return
18 .pcc_end_return
19 .end
This prints
12
as expected.
Harry
Taken from the IMCC.faq
What are IMC variables?
IMC has 2 classes of variables, symbolic registers and named variables.
Both are mapped to real registers, but there are a few minor
differences. Named variables must be declared. They may be global or
local, and may be qualified by a namespace. Symbolic registers, on the
other hand, do not need declaration,
----->but their scope never extends outside of a subroutine unit.
Symbolics registers basically give compiler front ends an easy way to
generate code from their parse trees or AST. To generate expressions
compilers have to create temporaries.
Symbolic Registers (or Temporaries)
Symbolic registers have a $ sign for the first character, have single
letter (S,N,I,P) for the second character, and 1 or more digits for the
rest. By the 2nd character IMCC determines which set of Parrot registers
it belongs to.
Simon Cozens
> It can be fixed. It'll take a lot of overhead. Following all branches in
> spaghetti code is a PITA.
>
> Just don't do that. Separate your subs in distinct compilation units.
And then you don't need to worry about the fact that Parrot running
computer-generated IMCC could well silently give incorrect answers!
--
She said that she was working for the ABC News,
It was as much of the alphabet as she knew how to use
-- Elvis Costello
Dan Sugalski
>Leo clarified this as a problem with backward branch circa 3/12/03:
>
>Sorry to be a pain in the butt, but I need to be told that there has
>been no improvement in the last two months on this ;-(
Short answer: Don't do that.
Longer answer: IMCC ought to notice that and either complain or handle it
>Surely it can't just be me that thinks this is rather fundamental?
>How fundamental *is* the problem, can it *ever* be fixed?
It's doable. It needs doing, honestly. Unfortunately it looks like
IMCC's been hacked into submission (A big reason that v2 is being
worked on) enough to make it difficult.
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.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Harry Jackson
> 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