|
From: Stephen W. <st...@ic...> - 2008-04-22 21:08:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think you are saying that changing this: ~ %load/v 12, v0x855918_0, 4; ~ %mov 132, 12, 4; ~ %mov 136, 0, 28; ~ %addi 132, 1, 32; ~ %set/v v0x855918_0, 132, 4; to this: ~ %load/v 12, v0x855918_0, 4; ~ %mov 32, 12, 4; ~ %mov 36, 0, 28; ~ %addi 32, 1, 32; ~ %set/v v0x855918_0, 32, 4; will bring the infinite loop back for you? I don't see anything wrong. I think we need to see the value of the thread bit4 after every opcode:-( Cary R. wrote: | --- On Tue, 4/22/08, Stephen Williams <st...@ic...> wrote | |> When you say that %addi is getting a 0, do you mean |> lva[0]==0, |> or lva==0? The latter means that there were XZ bits in the |> vector |> so it will cancel the add. That's probably not |> what's happening, |> but I'm just double-checking. | | I was checking inside the loop so I'm fairly sure it is lva[idx]. | |> Can you send me the a.out from your compile of the reduced |> test |> program? (And the reduced test program as well.) Need to |> make |> sure we are generating the same code from a given input. | | Attached. The a.out is the modified add 100 to get things to work. It should be obvious what needs to be removed to bring the inf. loop back. | | - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIDlPMrPt1Sc2b3ikRAnQAAJ93NeWINaAv2nJn/liX2kqanLJQuwCbBZvu bhhzLyi7lwExTEP1oPDs2sA= =eTvY -----END PGP SIGNATURE----- |