On 05/24/10 05:46, Hariharan wrote:
Hello all,
I found something a little odd with delay slot scheduling. If i had
the following bit of code (Note that "get" builtin functions in
picochip stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i < 5; i++)
{
a[i] = (int) getctrlIn();
}
switch (a[3])
{
case 0:
return 4;
default:
return 13;
}
}
The relevant bit of assembly for this compiled at -Os is
_L2:
GET 0,R[5:4] // R[5:4] := PORT(0)
_picoMark_LBE5=
_picoMark_LBE4=
.loc 1 13 0
STW R4,(R3)0 // Mem((R3)0{byte}) := R4
ADD.0 R3,2,R3 // R3 := R3 + 2 (HI)
.loc 1 11 0
SUB.0 R3,R2,r15 // CC := (R3!=R2)
BNE _L2
=-> LDW (FP)3,R5 // R5 = Mem((FP)6{byte})
.loc 1 22 0
=-> is the delay slot marker. Note that the LDW instruction has been
moved into the delay slot. This corresponds to the load in "switch
(a[3]" statement above. The first 3 times around this loop, LDW would
be loading uninitialised memory. The loaded value is ignored until we
come out of the loop and hence the code is functionally correct, but i
am not sure introduction of uninitialised memory access by the
compiler when there was none in the source is good.
I browsed around the delay branch code in reorg.c, but couldn't find
anything that checks for this. Is this the intended behaviour? Can
anyone familiar with delay branch code help?
It's not ideal, but there's no way for reorg to know that a particular
memory location is uninitialized as a result trying to "fix" this
problem would ultimately result in reorg not being allowed to fill delay
slots with memory references except under very very restrictive
circumstances.
From a correctness standpoint, the uninitialized value will never be
used, so it should cause no ill effects on your code. The biggest
effect would be tools like valgrind & purify (if supported on your
architecture) would report the uninitialized memory read. [Which begs
the question how does purify handle this on sparc-solaris? ]
Jeff
Thanks
Hari
