🚀 go-pugleaf

In article <3859@eos.UUCP> phil@eos.UUCP (Phil Stone) writes:
>However, this is not always enlightening.  Am I crazy, or are there
>some significant code-generation bugs in Lattice 5.02?  Here's
>a brief code fragment-example:

>I have a structure defined as follows:
>
>struct foo
>{
>	unsigned short shortbar;
>	unsigned char bar2;
>	unsigned char bar3;
>};

Yes, Lattice 5.02 has trouble auto-incrementing pointers that point to a
structure which contains a short.  I reported this to Lattice a month or
so ago.  They've confirmed it, assigned it an SMR number, and said that it
should be fixed in the next set of patches, but they didn't give me any
estimate when that would be.

I think it only occurs with structures which are 32 bits long and begin
with a short.  The compile generates a "move.w xxx,(An)+", which, as you
say, drops the pointer into the middle of the structure where it clearly
doesn't belong.

>In a certain function, the following code occurs:
>struct foo *fooptr;
>unsigned short temp;
[...]
>	fooptr->bar2++;
>	if( fooptr->shortbar != 0xFFFF )
>		fooptr->shortbar = temp;

Here's a really ugly workaround (hat I discovered.  Put a
"fooptr->bar2 = fooptr->bar2;" here.  This keeps the compiler from
using the inappropriate auto-increment addressing mode (as long as
you don't use the optimizer).  The correct solution is to yell at
Lattice until they fix it.

>	fooptr++;

>Looking at this area of the code with CPR, I noticed that the generated
>assembly code incremented 'fooptr' into the MIDDLE of the next structure
>(a simple wordwise increment, rather than the addition of 4 bytes that
>is required).

-Dan Riley (riley@tcgould.tn.cornell.edu, dsr@lns61.tn.cornell.edu)
-Wilson Lab, Cornell U.