Felix, It's a bit more complicated than what's written in the manual but the basics are correct. When using large memory model and no reentrancy all automatics are placed in xdata by default. But xdata is expensive to use, because everything must be done through the accumulator and data pointer. Consider a simple addition: x = y + z; SDCC must get y from xdata into ACC and temporarily store it somewhere because it needs ACC again to get z from xdata. SDCC tries to store it in a register, but when it needs to remember a lot of those, the registers are used up and it reverts to using spill locations in DATA. When it has taken z into ACC it can add y to it and finally store ACC to x. Now what if y which was spilled to data never really gets used without the spill location? Then there no longer is any reason to allocate memory for it in XDATA! So SDCC ends up renaming the spill location sloc to the real name y.
When using large memory model SDCC might need alot of those spill locations and they can fill up all data memory without having one single variable put there by the user. The fact that SDCC is not good at overlaying only makes this worse. Maarten > Could you explain what you mean by: "The local variables are > probably necessary spill locations that no longer needed > to be in xdata"? > > >From section 3.6 of sdcc's documentation: > "Automatic (local) variables and parameters to functions can either be > placed on the stack or in data-space. The default action of the compiler > is to place these variables in the internal RAM (for small model) or > external RAM (for large model)" > >From this I reasoned that when using the large model, local variables and > parameters to functions get allocated in XDATA. This conclusion is > obviously wrong since local variables sometimes get allocated in DATA? > > Still from section 3.6 of sdcc's documentation: > "Local variables can be assigned storage classes..." > I tried that using 'xdata' on local variables but nothing changed. > > I feel that I'm misunderstanding the memory allocation described in > section 3.6 of sdcc's documentation ... > > I will try to boil it down: if I write an application never using > any special storage class and compile and link it with large model I > will end up with an empty 'DSEG' in the map file. Correct ? > > Many thanks for your help, Felix > > Maarten Brock wrote: > > > Hi Felix, > > > I see no function parameters in your list, only spill > > locations and local variables. The local variables are > > probably necessary spill locations that no longer needed > > to be in xdata. > > > Why do you use --no-pack-iram? > > > There was a bug in SDCC that made all local variables > > globally visible. A side-effect is that they are > > reported in the map file. When debugging you want to be > > able to view those locals and hence they become globally > > visible again. > > > Hope this helps, > > Maarten > > >> Hello, > >> > >> For an mcs51 target I'm using sdcc 2.6.0 now. > >> After linking a project the linker tells me that there is not enough > >> space in DATA memory. No problem, I just moved some symbols to XDATA. > >> While doing so I found that the linker is allocating lots of memory in > >> DATA just for functional parameters; here is an example: > >> > >> /* this is the function prototype */ > >> void HexByteToString(BYTE Value, char *String, BOOL Uppercase) > >> > >> And this is the relevant contents of the map file: > >> > >> Area Addr Size Decimal Bytes (Attributes) > >> -------------------------------- ---- ---- ------- ----- ------------ > >> DSEG 0030 004B = 75. bytes (REL,CON) > >> > >> Value Global > >> -------- -------------------------------- > >> 0030 LLCDWrite$n$1$1 > >> 0031 LLCDWrite$ch$1$1 > >> 0032 LLCDWrite$Pos$1$1 > >> 0033 LLCDWrite$byArgPrefix$1$1 > >> 0034 LLCDWrite$SignChar$1$1 > >> 0035 LLCDWrite$Width$1$1 > >> 0036 LLCDWrite$Precision$1$1 > >> 0037 LLCDWrite$CharVal$1$1 > >> 0038 LLCDWrite$byVal$1$1 > >> 0039 LLCDWrite$WordVal$1$1 > >> 003B LLCDWrite$nVal$1$1 > >> 003D LLCDWrite$lVal$1$1 > >> 0041 LHexByteToString$sloc0$1$0 > >> ..... > >> > >> I am of course using the large-model as stated in the documentation. > >> As it seems the problem always occures when I use pointer arguments. > >> According to the documentation (if I understand everything correctly) > >> sdcc should allocate memory for these arguments in XDATA and not in > >> DATA memory (assumed I do not tell it do so by declaring the function > >> reentrant). Here is the command line I use for sdcc: > >> > >> sdcc --model-large --xram-loc 0x0800 --code-loc 0x2000 --data-loc 0x30 > >> --idata-loc 0x30 -Wl -bBSEG=0x30 --iram-size 0x100 --no-pack-iram > >> --debug ./build/stm.rel ... > >> > >> How do I get sdcc to use XDATA instead of DATA for these kind of > >> functional arguments? XSTACK is no option for me. > >> > >> > >> As side effect I experienced the following strange thing: > >> > >> As I switched from version 2.5.0 to 2.6.0 I observed that the > >> map file does not contain the table of symbols allocated in the > >> DATA memory. Only when I add the command line option '--debug' > >> to sdcc 2.6.0 these symbols appear in the map file. > >> I just check again with sdcc 2.5.0: with this version the command line > >> option '--debug' is not necessary for the linker to dump the table of > >> symbols allocated in the DATA memory to the map file. > >> Has there been any change in how the map file is generated? Can anyone > >> confirm that '--debug' is mandatory for the linker to dump symbols > >> allocated in DATA memory? > >> > >> many thanks, Felix > >> > >> > >> > >> > >> ------------------------------------------------------------------------- > >> Using Tomcat but need to do more? Need to support web services, security? > >> Get stuff done quickly with pre-integrated technology to make your job > >> easier > >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >> _______________________________________________ > >> Sdcc-user mailing list > >> Sdcc-user@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/sdcc-user > >> > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Sdcc-user mailing list > > Sdcc-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
