C51 returns the following error:
*** ERROR C249: 'DATA': SEGMENT TOO LARGE
Rather than switching to the COMPACT or LARGE memory model I would like to manually declare some variables into xdata. I would however like to know what the compiler is actually putting in the data segment and what is taking up the most space. Is there some way I can get this information in the absence of the .MAP file?
Thanks,
Stijn
If you did that, then everything that was defaulting to DATA would default to XDATA - so then you would see it...
About the linker: it doesn't come into play. The compiler (C51) returns the error and only generates an .LST file, so I have nothing to run the linker on.
I disagree with the premise: "Somewhat obviously: no. The map file is precisely where you're supposed to get that information.". The compiler obviously knows the data segment is too large. There is no fundamental reason why it should not be able to tell me what it puts in the data segment. Even just reporting the size of the segment would be very helpful.
Using the large memory model and trying to guess what the compiler would have put in the data segment for the small memory model is somewhat helpful but not very convenient. However, maybe the COMPACT memory model would make the same split...
And concerning the somewhat insulting statement "You're never going to get 2 gallons of crap in a 1 gallon bucket.": I'm in a situation where I was asked to make other peoples (non-crappy) code work with a different compiler. Having some more compiler feedback would help.
The compiler obviously knows the data segment is too large
I don't have the C51 tools loaded any more so can't try this out, but as a suggestion you might want to try getting the compiler to produce an assembler source file and then look at that.
And what was the code foot print on that compiler/platform, which I'm going to guess isn't an 8051
Does your code have large local/automatic stack allocations?
I have yet to see the compiler return "data segment too large", but quite often seen the linkr do it
Well given the error number/format it certainly looks to be a compiler generated error, so one might assume it's trying unsuccessfully to juggle some resources to make the C work. The Keil description of this error lacks any real useful insight to it's source.
Break the source into smaller pieces, observe if the error points at a particular line, or can be otherwise isolated in the .LST or bisection.
Given the special needs of the 8051 processor, it's quite easy for the compiler to spot a single object file that alone adds more data than what may fit. Why wait for the linker to confirm? It's even likely that Keil has one-byte offset values in the object file format and already there knows that they have no free offset values to assign to the pre-linked data object offsets.
When porting code from other compilers, it's meaningful to locate arrays and larger structs and tag them for XDATA storage and leave DATA for smaller variables.
... and trying to guess (sic) what the compiler would have put in the data segment for the small memory model
There's no guessing about it!
When you change from Small to Large, exactly what went into DATA will then be in XDATA