phil@eos.UUCP (Phil Stone) (06/05/89)
In article <8906041609.AA24115@ucbvax.Berkeley.EDU> 11TSTARK@GALLUA.BITNET (Timothy Stark) writes: <problems with Lattice 5.0> > I have another problems. My program kept to get a visit from GURU. >I cannot find a bug in my source file. I decided to put debug information >at starting routines. When it hits GURU, I get last information from >debug routines. I looked into my source file but I still unable to find >a bug. It must be a bug in compiler which generate incorrect instructions. >It may results as illegal instruction, A emulation, or F emulation GURUs >with task address (.000032D2 -- I am not sure that). What do I do next? > >-- Tim Stark (Note: I'm responding to comp.sys.amiga so Tim will see this answer, but I think the topic is more appropriate to the .tech group, so follups are directed there). Tim, I assume you have CodeProbe with your Lattice 5.0. You can use this to single-step through suspected problem areas in your code; often this will enable you to see where the crash occurs. 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; }; In a certain function, the following code occurs: struct foo *fooptr; unsigned short temp; . . . fooptr->bar2++; if( fooptr->shortbar != 0xFFFF ) fooptr->shortbar = temp; 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). Certain tweaking, like changing the unsigned short field to an 'int' field, made the problem go away. But this seems to be a strange problem which was not generated from the same source using Lattice 3.01 (my previous version). What gives? Do y'all need more detail on this? Also, I haven't tried the Lattice on-line support; is this indicated? Again, notice that followups have been directed to comp.sys.amiga.tech. Phil Stone (phil@eos.arc.nasa.gov | ames!eos!phil)
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (06/06/89)
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.