Hi, Maarten. Thanks for the quick reply. Originally, I had many problems with stack overflows but by changing things here and there I've overcome most of them. So I probably don't need to squeeze every single byte for the stack. Although I'm pondering switching to model-huge so I might change my mind on that one.
I still went and had a look at some sdcc library files. For instance, _divulong.c declares a variable BOOL c; Then in the respective asm file, c is being allocated to b0 (since BOOL is __bit as far as I can understand). Am I looking in the right place? So for example, if I were to recompile libraries with BOOL defined as unsigned char, would I be breaking everything? Even if that worked, I assume I'd be putting extra burden on stack during execution so I wonder if the overall result would be an improvement. Thanks again for your time Regards geo On 3 Nov 2010, at 18:24, Maarten Brock wrote: > Hi George, > > The T represents the bit bank which contains 8 pseudo bit-registers like > the regular 4 banks of byte registers. It is used by reentrant functions > that need bit parameters or local bit variables. There are probably some > library functions that use it. As it is a bit bank it cannot be moved out > of the bit-addressable area and thus cannot go to address 0x08. Are you > sure you need to squeeze out those last few bytes for the stack? > > Maarten > >> Hello all >> >> I'm building the Contiki OS for cc2430 (8051 with model-large stack-auto). >> This is the start of my memory layout after building (rest allocated for >> stack). What I am trying to achieve is make more room for the stack, >> without using --xstack. Using sdcc 3.0.0 #6037 >> >> I can easily move the a, b, c Data bytes back to external RAM. However, >> what's causing me hassle is the T byte at 0x20. My map file shows BIT_BANK >> starting at 0020 with size 1 but nothing listed underneath so I can't >> understand what's being put there. I've looked at the various asm files >> and I can't find anything. It can't be the bit-addressable SFRs, surely? >> sdcc libraries perhaps? >> >> Is it possible to remove T altogether or perhaps move it to, say, 0x08? >> Would this result in the stack starting at a lower address? I've tried >> --stack-loc, --data-loc, -Wl -bBSEG but no success. >> >> Any advice would be appreciated. Thanks a lot >> geo >> >> Internal RAM layout: >> 0 1 2 3 4 5 6 7 8 9 A B C D E F >> 0x00:|0|0|0|0|0|0|0|0|a|a|a|a|a|a|a|a| >> 0x10:|a|a|a|a|b|b|b|b|b|b|b|b|b|c| | | >> 0x20:|T|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >> 0x30:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >> > > ------------------------------------------------------------------------------ > Achieve Improved Network Security with IP and DNS Reputation. > Defend against bad network traffic, including botnets, malware, > phishing sites, and compromised hosts - saving your company time, > money, and embarrassment. Learn More! > http://p.sf.net/sfu/hpdev2dev-nov > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
