First, correcting myself, since I managed to confuse true and false :

-[ Tue, Aug 11, 2009 at 12:11:00PM +0200, rixed@happyleptic.org ]----
> 1004b670:	24010001 	li	at,1	; a1 = true

No, 1 is false. True would be 3. Thus :

> 1004b674:	10410051 	beq	v0,at,1004b7bc <$173>	; cmp previous return value with true, and if so goto $173 where we left

Of course, we break out of this sequence of "&&"s if the test is false.

> 1004b6a4:	24010001 	li	at,1	; true
> 1004b6a8:	10410041 	beq	v0,at,1004b7b0 <$174>	; if both stamps are eq, goto $174 which is equivalent to $147.

Same remark as above.

> ; The end when dataUnchanged is true. We could have reused $174 or $173.
> ; So each time you write a && b && c you end up with 3 different true(s) ?

So here at the end, dataUnchanged is false.

But this does change much to the problem.

So, After this little training, deciphering the second code (the one whithout FPU code
which happen to work) is a piece of cake. Basically, instead of the FP registers comparison
we have this :


1004b718 <$180>:
1004b718:   8fa5000c    lw a1,12(sp)   ; a1 = [sp+12], aka t0
1004b71c:   3c18100c    lui   t8,0x100c   ; t8 = 0x100c+2244 -> same C function than before (equality test)
1004b720:   0c033a9e    jal   100cea78 <caml_c_call>  ; call it...
1004b724:   271808c4    addiu t8,t8,2244

Ie the added function "is_same a b = a = b" had the (well known) consequence to replace
the inline equality testing by the generic C version.

So, the bug lies in the inline equality function for float values.

Stay tunned !

:-)