for this: IDATA 0010H 000CH UNIT ?ID?SMAIN 001CH 0004H *** GAP *** .... DATA 0056H 0022H UNIT ?DT?SMAIN IDATA 0078H 0001H UNIT ?STACK I am losing 16 bytes of the precious commodity DATA storage. Does anyone know of a way to get DATA in the 10-1f slot?. (I have enough globals, that I can use it for globals if that makes it doable). cross posted on 8052 Erik
[Missing toolset selection, guessed.] There's no sign of any space having been "lost", in that example --- that map still shows you having more DATA space than you can use. There's even room for some of the ?STACK segment, down there. I guess that's caused only by selecting a non-problematic example case, but still: it'd be easier to answer if you showed compiler input triggering this, instead of just excerpts of map file output.
There's no sign of any space having been "lost", in that example --- that map still shows you having more DATA space than you can use. There's even room for some of the ?STACK segment, down there. no not "more DATA space than you can use". I want/need more. This is the result after moving stuff to IDATA to "kill" the overflow error that made no map appear and have a few DATA slots for the next modules. I guess that's caused only by selecting a non-problematic example case, but still: it'd be easier to answer if you showed compiler input triggering this, instead of just excerpts of map file output. if i put DATA variables matching the size 78-7f/80 back I get DATA overflow (and no map). Erik
correcting a misspeak: From memory I posted that with the error (L107 address space overflow - data) there was no map. What it is is that the DATA segment for which there is not enough room get totally dropped. this is the result after adding 2 longs and a short to the example shown in first post
* * * * * * * D A T A M E M O R Y * * * * * * * REG 0000H 0008H ABSOLUTE "REG BANK 0" REG 0008H 0008H ABSOLUTE "REG BANK 1" IDATA 0010H 000CH UNIT ?ID?SMAIN 001CH 0004H *** GAP *** BIT 0020H.0 0002H.5 UNIT ?BI?SMAIN BIT 0022H.5 0000H.7 UNIT _BIT_GROUP_ 0023H.4 0000H.4 *** GAP *** DATA 0024H 0032H UNIT _DATA_GROUP_ IDATA 0056H 0001H UNIT ?STACK * * * * * * * X D A T A M E M O R Y * * * * * * * XDATA 0000H AC22H UNIT ?XD?XDATAF
if i put DATA variables matching the size 78-7f/80 back I get DATA overflow I may not understand well what you mean by "put ... matching the size", but note that with two register banks in use, and 4 bytes' worth of BIT variables, as shown in the map from your next posting, you only have 0x6c bytes of normal DATA space left, not 0x78. And again, this is impossible to diagnose if you don't tell how exactly you got this behaviour out of which version of the tools. For the record, I never saw it place any ?ID? segments before the _DATA_GROUP_, nor for that matter any ?DT? one before ?ID? ones.
You didn't loose data from 0x10 to 0x1F. MAIN declared an IDATA block of 12 bytes and the linker put that in the data space. If you had some DATA in small chunks that could be sandwiched in the 16 bytes, the linker would have put them at location 0x10. I have found that having each module declare its own global variables rather than getting them all collected into MAIN, the linker has a much easier time and can do a better job.
View all questions in Keil forum