🚀 go-pugleaf

I have a line of C source code which I compile with Lattice.  It is an
innocent little line, in an innocent little program.  The line looks
like this:

        bytes += (num_in = Read(in_fh, buff, BUFFLEN));

The rest of the program is trivial.  (Actually, the only applicable part
of the above line is the Read() call - I can leave the rest out).

Lattice C 5.05, despite my best attempts to convince it otherwise,
insists on generating *floating point* instructions for this line.  This
is more than a bit odd, as there is not one bit of floating point
anywhere in the program.  However, the floating point instruction is
only generated if I use #pragma's and cres.o to get pure code.  If I
use amiga.lib, everything is fine and the program works fine (but
I can't make it pure).

According to CPR, the resulting assembly code for the line above
is:

  50:     do {
  51:         bytes += (num_in = Read(in_fh, buff, BUFFLEN));
003BB0BA:  MOVE.L    D7,D1
003BB0BC:  LEA       00C8(A4),A0           ; 003C5B98
003BB0C0:  MOVE.L    A0,D2
003BB0C2:  MOVEQ     #40,D3
003BB0C4:  F????                <--- * what the heck is this?!? *
003BB0C8:  CLR.B     A4
0033E922:  JSR       FFD6(A6)
0033E926:  ADD.L     D0,D5
0033E928:  MOVE.L    D0,FFEC(A5)

The F???? instruction crashes the machine quite nicely.

Has anyone else seen this behaviour, or know how to fix it?  I've
asked Lattice, but got no response other than a request for the
sample code, which I gave them.  That was several weeks ago.

BTW, I get the same behaviour whether compiled with -O or -D3.

  - steve (koren@hpfela.HP.COM)

PS - If I can ever get this fixed, I will finish SKsh 1.4a and 1.5.
     Right now I'm stuck.  This was the problem that caused some of
     the SKsh 1.4 commands to be non-pure, but I don't want to
     have another release in that kludgy state.  Too much work
     to document what can and cannot be made resident, etc.