> 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.
You'd need to define what "good" means here. The generated code looks correct
since (1) 'a' is on the stack and thus loading from it cannot trap (2) it is
not marked volatile and (3) the result of the load is unused when the memory
location is uninitialized. So, from an external viewpoint, the generated
code behaves as if there were no "problematic" loads and looks therefore OK.
--
Eric Botcazou
