Eric, >> If your program is >> large and complex enough you can still run out of data >> memory. > > How does the compiler determine when this will happen? Is there any > compile-time warning?
The compiler doesn't, the linker does. And the warning is the error you already saw. > And just to be clear, sdcc by default (the "small memory model") creates > space for the function-local variables (i.e. not global or static) in > data memory, and leaves them there. This means that functions are never > reenterant. This is different from the more traditional GCC way of > having all function-local non-static variables allocated on the stack. > Is this correct? That's correct. Because the 8051 is ill-equiped for stack access (pretty small stack and lacks good instructions) and one usually does not need reentrancy the default is static allocation of locals. The goal here is efficiency. > Everything builds (yay!) when I use stack-auto. My code even runs. But > when I then try and create a large global buffer (say, to store a single > sector) things build just fine, but the program itself doesn't run. This large buffer is in xdata right? Otherwise it eats up your precious data memory. > When I look at my .map I see: > > Area Addr Size Decimal Bytes > (Attributes) > -------------------------------- ---- ---- ------- ----- > DSEG 0000 006F = 111. bytes (REL,CON) > > Value Global > -------- -------------------------------- > 0008 _bp > > > > Hexadecimal > > Area Addr Size Decimal Bytes > (Attributes) > -------------------------------- ---- ---- ------- ----- > SSEG 0021 00DF = 223. bytes (REL,OVR) > > Value Global > -------- -------------------------------- > 0021 __start__stack > > How can my dseg and my sseg add up to more than 256 bytes? Well it can't. Maybe the calculation for this report has a bug. > Hexadecimal > > Area Addr Size Decimal Bytes > (Attributes) > -------------------------------- ---- ---- ------- ----- > XSEG 0100 022B = 555. bytes > > Value Global > -------- -------------------------------- > 0D:0100 _buffer > 0D:0305 __gptrput_PARM_2 > 0D:0306 __mulint_PARM_2 > 0D:0308 _memcmp_PARM_2 > 0D:030B _memcmp_PARM_3 > 0D:0310 __divulong_PARM_2 > 0D:031C _memset_PARM_2 > 0D:031D _memset_PARM_3 > 0D:031F _memcpy_PARM_2 > 0D:0322 _memcpy_PARM_3 > 0D:0327 __mullong_PARM_2 This is for --model-large right? Without --stack-auto right? Btw. Make sure that you use the same options for compiling and linking. Maarten ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
