From: SourceForge.net <no...@so...> - 2012-06-13 11:44:57
|
Bugs item #3534523, was opened at 2012-06-12 01:04 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3534523&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mcs51(8051) target Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Phil () Assigned to: Nobody/Anonymous (nobody) Summary: Wrong code generation: Pointer member on 256B XDATA boundary Initial Comment: The conditions for reproducing this bug are a little obtuse, so please bear with me: 1. A structure exists in XDATA memory. 2. That structure has an XDATA pointer as its first member (its a linked list). 3. The placement of the structure in XDATA is such that the pointer member spans a 256B boundary. 4. A function exists that simply takes a pointer to the structure and assigns it to the pointer member (linked list initialisation). 5. That function has external linkage. This is significant, the generated code is different otherwise. In this specific set of circumstances, the generated code increments the dptr before saving the value of dph. Since dpl is 0xff, the action of incrementing dptr means dph is changed, thus the incorrect value is stored. Sample code testcase.c attached. $ sdcc testcase.c $ sdcc -v SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.0 #7066 (Nov 22 2011) (Mac OS X i386) ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2012-06-13 04:44 Message: It does not matter if the function is marked extern or not. What matters is whether the function is prototyped or not. It fails for both mcs51 and ds390. For ds390 an xdata pointer is 3 bytes which makes it a bit harder to fix. Also for ds390 it fails both with and without prototype, although different code is generated. ---------------------------------------------------------------------- Comment By: Phil () Date: 2012-06-12 02:28 Message: See https://sourceforge.net/projects/sdcc/forums/forum/1865/topic/5343383/index/page/1 for discussion of a workaround using a peephole rule. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3534523&group_id=599 |