From: SourceForge.net <no...@so...> - 2006-10-08 16:10:29
|
Bugs item #1572067, was opened at 2006-10-06 04:47 Message generated for change (Comment added) made by jesusc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1572067&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: linker Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frieder Ferlemann (frief) Assigned to: Maarten Brock (maartenbrock) Summary: --data-loc, --idata-loc not functional Initial Comment: --data-loc, --idata-loc seem to be non functional. aa and a[0] are both located to 0x08 and bb and b[0] are both located to 0x18: -------8<--------------------------------------- /* sdcc --data-loc 0x70 --idata-loc 0xf0 dl.c */ unsigned char __data a[0x10]; unsigned char __idata b[0x10]; unsigned char __at(0x08) aa; unsigned char __at(0x18) bb; void main(void) { a[0]++; aa++; b[0]++; bb++; } -------8<--------------------------------------- Version 2.6.1 #4402 (Oct 6 2006) 132 ; dl.c:10: a[0]++; 0064 AA 08 136 mov r2,_a ; @0x08 0066 74 01 139 mov a,#0x01 0068 2A 140 add a,r2 0069 F5 08 144 mov _a,a 145 ; dl.c:11: aa++; 006B 05 08 148 inc _aa 149 ; dl.c:12: b[0]++; 006D 78 18 152 mov r0,#_b ; @0x18 006F 86 02 153 mov ar2,@r0 0071 74 01 156 mov a,#0x01 0073 2A 157 add a,r2 0074 78 18 160 mov r0,#_b 0076 F6 161 mov @r0,a 162 ; dl.c:13: bb++; 0077 05 18 165 inc _bb -------8<--------------------------------------- ---------------------------------------------------------------------- >Comment By: Jesus Calvino-Fraga (jesusc) Date: 2006-10-08 09:10 Message: Logged In: YES user_id=603650 --data-loc, --idata-loc are perfectly functional IF you link using --no-pack-iram. I tried it, and it works fine. Therefore I don't think this is a bug, and it should be closed. When --pack-iram is used (the linker default) both --data-loc and --idata-loc are intentionally ignored. In other words: either you optimize the internal RAM usage or the linker does, but not both at the same time. Jesus ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-10-08 08:07 Message: Logged In: YES user_id=888171 With --pack-iram I 'm not sure what --data-loc and --idata- loc should do. I disagree that idata should not go outside 0x80-0xFF. I think idata can theoretically range from 0x00 to 0xFF. Would it help if: a) ABS segments worked in data/idata? b) variables located with __at AND have an initializer would be actually allocated? c) every variable with __at and not declared extern would be allocated? I'll start with a) as that is needed anyway. Maarten ---------------------------------------------------------------------- Comment By: Steven Borley (sjborley) Date: 2006-10-08 06:28 Message: Logged In: YES user_id=1270801 Frieder, I agree with you. This is wrong. However it appears the bug could be with --pack-iram. Packing variables declared __idata should not move them outside 0x80 to 0xFF. I think --idata-loc and --data-loc might be working. The .map file is interesting Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ ISEG 00F0 00E8 = 232. bytes (REL,CON) Value Global -------- -------------------------------- 0018 _b Seems --idata-loc 0xf0 worked (start of ISEG is 0xF0), but variable is not actually placed in ISEG! Also size should be 16 bytes (not 232) -but I guess this is a side-effect of the variable getting moved to 0x18. Steven ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-10-07 15:04 Message: Logged In: YES user_id=589052 >I'm curious as to what you think should happen. Well this one is not a "real world" example but just some code to show the problem, but: SDCC should have allocated the __data variable a from 0x70-0x7f and the __idata variable b from 0xf0-0xff. Now for the real world example: there are requests like "bdata space on 80C51": http://sourceforge.net/forum/forum.php?thread_id=1586910&forum_id=1864 which f.e. need bdata memory at 0x20. Now if you do some absolute variable locating with "__at(0x20)" you want to be certain that SDCC doesn't find an additional use for that very location. If you'd specify --data-loc 0x21 then this would make sure that 0x20 is not triple-used:) The option "-Wl-bDSEG=0x21" which could be expected to be similar to --data-loc 0x21 has no effect either. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-10-07 14:46 Message: Logged In: NO Neither --data-loc nor --idata-loc work unless you use option --no-pack-iram. Otherwise the linker will allocate the variables wherever it finds more convenient. --pack- iram is the default now. ---------------------------------------------------------------------- Comment By: Steven Borley (sjborley) Date: 2006-10-07 14:17 Message: Logged In: YES user_id=1270801 I am not an SDCC developer, but I'm curious as to what you think should happen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1572067&group_id=599 |