From: SourceForge.net <no...@so...> - 2006-12-22 16:16:09
|
Bugs item #1572067, was opened at 2006-10-06 13:47 Message generated for change (Comment added) made by frief 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: fixed Status: Closed Resolution: Fixed Priority: 5 Private: No 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: Frieder Ferlemann (frief) Date: 2006-12-22 17:16 Message: Logged In: YES user_id=589052 Originator: YES > Maybe you did something wrong. Probably, yes: it seems my /usr/local/bin/aslink is outdated (it's from 2006-11-19). It seems aslink is not freshly generated on my system: mkdir build2 cd build2 ../sdcc/configure --disable-pic16-port --disable-pic-port make sudo make install The directory build2/bin then holds only 12 files: as-gbz80 as-hc08 asx8051 as-z80 link-gbz80 link-z80 makebin packihx sdcc sdcclib sdcdb sdcpp (link-hc08 is also missing although I didn't exclude hc08 in the configure command line) If I manually copy aslink from today's snapshot page into /usr/local/bin everything works as advertised:) (So eventually something is broken on my system) Greetings, Frieder ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-12-22 14:35 Message: Logged In: YES user_id=888171 Originator: NO Frieder, Maybe you did something wrong. I cannot reproduce your findings. I did the same and _a is at 0x70 and _b is at 0xf0 here. Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-12-22 01:17 Message: Logged In: YES user_id=589052 Originator: YES Hi Maarten, I just compiled the original snippet with SDCC #4521: sdcc --data-loc 0x70 --idata-loc 0xf0 bug1572067.c but I still seem to have a problem: unsigned char __data a[0x10] is at 0x08 (--dataloc 0x70) and unsigned char __idata b[0x10] is at 0x18 (--idata-loc 0xf0) I would have expected them at >=0x70 and at >=0xf0? Thanks, Frieder ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-12-21 21:57 Message: Logged In: YES user_id=888171 Originator: NO I think I finally nailed this in SDCC 2.6.2. #4521. --data-loc and --idata-loc are now used as lower bound when allocating. Any absolute global variable with an initializer is allocated now (solution b). You can now put a byte at an absolute address in 'bdata' with an initializer and access the bits with uninitialized bit variables at corresponding absolute bit addresses. See also regression test absolute.c. ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2006-10-18 19:26 Message: Logged In: YES user_id=603650 That is a very good idea Maarten! ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-10-18 12:51 Message: Logged In: YES user_id=589052 > .. opinion of Frieder and .. Yes, that's fine. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-10-17 22:53 Message: Logged In: YES user_id=888171 I've been thinking about this a bit more and came to the conclusion that --data-loc and --idata-loc could still be useful. When allocating they can be used as the lower bound which is currently a hardcoded 0. But I would like the opinion of Frieder and Jesus on this. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-10-09 20:27 Message: Logged In: YES user_id=888171 I agree with Jesus that --data-loc and --idata-loc should not be used with --pack-iram, some error message might be in order. Or at least put it in the manual. OTOH I still would like to get rid of --no-pack-iram in the first place. a) already almost works as is. Only when bits are located (segment BSEG_BYTES) they overwrite absolute segments. If you put an ABS at 0x2F it works. I will fix this part soon. Currently absolute variables in code memory are not allocated when no initializer is used: SDCC creates an equ. If you do use an initializer it is allocated in .area CABS (ABS,CODE). So for xdata, pdata, idata, data, bit memory you vote to allocate for every variable that is placed with __at unless it is declared extern? I proposed two solutions, because I'm afraid it will break current behaviour and thus code already in use out there. I think b) is less likely to break someones code, but I consider c) more clean. Anyway, I'm thinking of these new segments: XABS (ABS,XDATA) for xdata & pdata and IABS (ABS,DATA) for idata & data. Bit memory needs more attention as it does not fit the current implementation. Do we actually need that? I'm open for suggestions, Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-10-09 16:27 Message: Logged In: YES user_id=589052 Steven, I didn't even notice the report was hijacked, I found everything on-topic:) Jesus, it's true that together with the additional option --no-pack-iram the locating is fine. Nevertheless I consider it a valid bug report if the data variable "a" is allocated at location 0x08 when --data-loc explicitly specifies the beginning of the data segment to be at 0x70. Maarten, a) yes:) b,c) it would be nice if having a different handling of allocation for b) and c) could be avoided? Maybe allocate non-extern "data" and "bit" variables (regardless whether initialized) and not allocate "sfr" and "sbit"? ---------------------------------------------------------------------- Comment By: Steven Borley (sjborley) Date: 2006-10-08 18:44 Message: Logged In: YES user_id=1270801 Ah, yes, of course you are right, Maarten. idata does cover 0x00 to 0xFF. I was thinking of idata as just the area that can *only* be indirectly addressed but that's not right and the SDCC manual does make this clear. So the SDCC is correct and this not a bug. Maarten you suggestions sound good to me, but I'm not going to comment further for fear of putting my other foot in mouth too and hence not having a leg to stand on. Frieder, my apologies for hijacking your bug report. ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2006-10-08 18: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 17: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 15: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-08 00: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 23: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 23: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 |