koren@hpfelg.HP.COM (Steve Koren) (05/27/90)
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.valentin@cbmvax.commodore.com (Valentin Pepelea) (05/31/90)
In article <13920063@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: > >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. F-line instructions are coprocessor instructions. Perhaps one of the variables you are using, "bytes" or "num_in" has been defined as a floating point variable? This is pure speculation, of course, but there's not much I can do to help you. Try isolating the piece of code you are using, and then strip it down until the error does not occurr any more. Then post the resulting pieces of code on the Lattice BBS, so that the Lattice folks may fix the bug. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be