lost DATA space

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.

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.

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.
Hans-Bernhard, that is NOT the issue, the issue is to get DATA not IDATA in the 10-1f area

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.
I do NOTHING "to get this behaviour"
as I said above when I add 9 bytes of global data I get DATA overflow STILL with 10-1f occupied by IDATA. The release is 7.xx. you see in the first post what it looks like with reduced DATA use, in the second map the DATA overflows and 10-1f is still IDATA.

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.
That is EXACTLY it!! why does the linker put IDATA not DATA in the DATA area?. Of course, if my DATA end before 80 then it is perfectly OK to start IDATA there, again that is NOT it.

Reinhard, Jon, please explain I am willing to jump through hoops to get DATA in that memory.

What it looks like is that the DATA is somehow in "segments" and the linker refuses to put any DATA in the 10-1f if it does not have a "DATA segment" small enough. I have never heard of "segmenting" DATA in C, but if that is required and there is a method, pray tell.

Erik

Simply "DECLARE (ie. make public)" DATA in a source module other than the one that declares the SMAIN data.

Your problem is that the DATA-GROUP and SMAIN declarations are each too big to fit in lower memory. My guess is that any other declarations you make are also in the SMAIN group or are defined together in another single module.

Split them up.

What it looks like is that the DATA is somehow in "segments" and the linker refuses to put any DATA in the 10-1f if it does not have a "DATA segment" small enough.


Exactly. Each .c file produces its own segment of code and segment of global data. (One segment for each memory type, actually, and you also get segments for the function locals/temps.) The linker cannot split up those segments into pieces; the segment is the smallest chunk with which it can work. It doesn't locate individual variables any more than it does individual functions. To break up a segment, you have to break up the C source into separate .c files.

(I usually run into this problem more often with functions than with data, but I imagine the same restriction applies.)

These map files are the result of a failed link, right? In that case, the linker might not have allocated that early idata segment early. It might have done so after all the data was located (or couldn't fit), and then put it in the first hole it could find.

You could adjust the bit area up in memory (rather than from 20-2f) to 2A-2F. That would make the gap grow by 10 more bytes. The linker could then fit a a larger segment into the gap.

Jon

You could adjust the bit area up in memory (rather than from 20-2f) to 2A-2F. That would make the gap grow by 10 more bytes. The linker could then fit a a larger segment into the gap.
a VERY cumbersome workaround, it would "blow up in your face when you added a few variables that happened to go in the segment that you made room for by moving the bit data up.

I rallly think this is an issue Keil should consider "fixing" since DATA space is the most precious commodity in the '51.

For now I'll stick with the workaround I found of declaring some "well known and stable" DATA variables in a separate segment in assembler.

Erik