|
From: Cary R. <cy...@ya...> - 2008-04-22 16:57:39
|
--- On Mon, 4/21/08, Stephen Williams <st...@ic...> wrote:
> I think we are looking for some sort of uninitialized
> memory problem.
> It appears that the %xnor opcode is fine in your case, but
> there is
> some problem managing the index variable. Try putting a
> test print
> in the of_ADDI function to look at the first word of the
> lva array
> that is returned by the vector_to_array before and after
> the "for"
> loop that does the addition. At the very least, this will
> confirm
> that the index variable value is stuck.
>
> Perhaps the %set/v or %load/v (if not the %addi) are not
> working
> properly? Seeing what's going into/out of the %addi may
> help us pin
> it down.
This appears to be some kind of race condition! Oh fun!!. I can simplify the the loop down to the large1 assign and the two xnor assignments. Deleting either one of the xnor assignments will make the inf looping go away. The %addi is always getting 0 from the tread vector, so it appears to be working correctly. It also looks like the %load/v has the correct signal value (it starts at zero and then goes to 1). The only thing between the %load/v and the %addi are a couple of %mov instructions to pad the value.
If I add 100 to the thread addresses for the code that increments the loop counter everything works correctly, so it appears that when we have two xnor statements the second one is some how changing values after it should be and is zeroing the loop counter. I'm not certain how this is happening since the xnor should be producing all ones as output. I can send the reduced test case and a.out file if that helps. FYI the second xnor and the loop counter increment use the same or overlapping thread space addresses.
Cary
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
|