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?
Thanks
Hari
