[comp.sys.amiga.tech] HELP!!! - C bug?

wdimm@lehi3b15.csee.Lehigh.EDU (William Dimm) (07/09/89)

I just pulled out some routines that I wrote with Lattice 4.0
and tried to compile them with 5.02.  And, well, remember the
black screen with the red letters....  I think I found the line causing the
problem (dissasembled by CPR underneath):
	bytes -= (unsigned int)(op.count - result->ops);
		MOVE.L  056A(A4),D0
		MOVE.L  D0,D1
		MOVEA.L FFF8(A5),A0
		SUB.L   (A0),D1
		MOVEQ   #0A,D2
		DIVS.W  D2,D1
		SUB.L   D0,FFAA(A5)

I don't know 68000 assembler, so I don't know if the compiler
is generating correct code above.  The variables being subtracted
are pointers of the same type.  I set a breakpoint, and found that
the pointers were the same.  But, rather than the value of 'bytes' 
remaining the same after executing this line, it becomes a VERY large
number.  I changed 'bytes' to type 'int' and found that it became a large
negative number after this line.  I tried compiling with the '-b0' option, 
but it didn't help.  Can anybody tell me if the above Assembly is correct?
A quick response would be greatly appreciated.  Also, if anyone has
the 5.03.20 patches mentioned earlier on this list, I would appreciate
it if you could mail them to me - I can't call the Lattice BBS right now
(no modem). 
 
	 Thanks,
			Bill Dimm     wdimm@lehi3b15.csee.Lehigh.EDU     wcd0@lehigh.BITNET

P.S.  The troublesome line was of course followed by a memcpy() - just my
luck!

cmcmanis%pepper@Sun.COM (Chuck McManis) (07/10/89)

In article <596@lehi3b15.csee.Lehigh.EDU> (William Dimm) writes:
> ... I think I found the line causing the problem (dissasembled by 
> CPR underneath):
>	bytes -= (unsigned int)(op.count - result->ops);

>  The variables being subtracted are pointers of the same type.

Hmmm, What do you hope to gain by subtracting two pointers? Since
you seem to be assigning a variable "bytes" to be some number 
minus this number I get the impression you want the size of something?
Unfortunately, the above statement won't cut it. The other interesting
things that come to light. Why is one of your pointers called "count"
and one of them called "ops" ? Variables named 'count' usually contain
an integer. The code that CPR spit out seems to think one is an integer
as well. 

>		MOVE.L  056A(A4),D0
			* Move the global 32 bit variable at $056A+A4 to D0
>		MOVE.L  D0,D1
			* Copy it into D1
>		MOVEA.L FFF8(A5),A0
			* Move the local Pointer (probably "result" into A0)
>		SUB.L   (A0),D1
			* Subtract result->ops from op.count
>		MOVEQ   #0A,D2
>		DIVS.W  D2,D1
			* Divide the result by 10. This would indicate
			* that sizeof(*(result->ops)) == 10
>		SUB.L   D0,FFAA(A5)
			* Subtract result from "bytes"

Random questions, what are you trying to do? What are the types of 
result->ops and op.count (how about the structures or unions defining
them). Then you can get a real answer.

--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"

wdimm@lehi3b15.csee.Lehigh.EDU (William Dimm) (07/11/89)

First, I would like to thank everyone who responded to my plea for
help.  The final, definitive answer to the problem is this:  Lattice 5.02
screwed up (as I suspected).  I figured out what each of the Assembly
lines does by using CPR to check the registers after executing each line.
Also, someone who sent me a response came to exactly the same conclusion.
The translation of each line is under it:

 748:       bytes -= (unsigned int)(op_count - result->ops)
00C7F888:  MOVE.L    056A(A4),D0                           
  Move contents of op_count (an address) to D0
00C7F88C:  MOVE.L    D0,D1                                 
  Copy contents of D0 to D1
00C7F88E:  MOVEA.L   FFF8(A5),A0                           
  Move address of result->ops to A0
00C7F892:  SUB.L     (A0),D1                               
  Subtract value pointed to by A0 from contents of D1 and store result in D1
00C7F894:  MOVEQ     #0A,D2                                
  Move hex A (decimal 10) into D2  (this is the size of the structs pointed to)
00C7F896:  DIVS.W    D2,D1                                 
  Divide contents of D1 by D2, and store the result in D1
00C7F898:  SUB.L     D0,FFAA(A5)                           
  Subtract the contents of D0 from contents of 'bytes' and store in 'bytes'

So, if you were paying attention, you noticed that the last line of 
Assemler is quite 'out-of-whack' with everything else that is going on.
It is subtracting D0, which is op_count (a pointer) from 'bytes' rather 
than subtracting the difference which it computed and put in D1.
The last line of Assembly should have been:
00C7F898:  SUB.L     D1,FFAA(A5)

The C line which caused the problem was followed by:
	bytes *= sizeof(struct op_type); /* the structs being pointed to */
	memcpy(address1,address2,bytes);  /* visit the GURU */

The problem which I had doesn't occur in all cases where 
pointers are being subtracted (I couldn't replicate it with a
small program), so it appears that something special had to happen
to confuse the compiler.

I notified Lattice of this problem.  If anyone has any of the
patches (greater than 5.02) which might fix this, please, PLEASE send
them to me!  Finally, the mystery is over, this thread is dead...

	Thanks,  
		Bill Dimm
		wdimm@lehi3b15.csee.Lehigh.EDU  or  wcd0@lehigh.BITNET