Hello Maarten, I use --no-pack-iram because I do _not_ want the linker to use 'unused register banks'. There are _no_ 'unused register' banks. My application consist of two parts: a firmware and a 'user application'. When I compile and link the 'user application' I have to make sure that the linker does not allocate memory which is already used by the firmware part, hence the --no-pack-iram when linking the 'user application'.
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
