Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!riley From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley) Newsgroups: comp.sys.amiga.tech Subject: Re: Lattice C 5.02 Message-ID: <8116@batcomputer.tn.cornell.edu> Date: 5 Jun 89 21:08:50 GMT References: <8906041609.AA24115@ucbvax.Berkeley.EDU> <3859@eos.UUCP> Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 48 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.