Re: Backward branch, warnocked.
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 Bs. A B 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
Re: Backward branch, warnocked.
At 1:12 AM + 2/3/04, Pete Lomax wrote: 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 [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Backward branch, warnocked.
[EMAIL PROTECTED] (Leopold Toetsch) writes: > 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
Re: Backward branch, warnocked.
Pete Lomax <[EMAIL PROTECTED]> wrote: > 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
Re: Backward branch, warnocked.
Pete Lomax wrote: 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. 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 3newsub 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.
Re: Backward branch, warnocked.
On Mon, 2 Feb 2004 20:51:21 -0500 (EST), Michal Wallace <[EMAIL PROTECTED]> 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
Re: Backward branch, warnocked.
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 ... > 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: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Backward branch, warnocked.
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.
