Hi, I was looking at the stack roll-over capability of the Aduc842, and I thing you can take great advantage of it! This is from the datasheet:
"By default, the stack operates exactly like an 8052 in that it rolls over from FFH to 00H in the general-purpose RAM. On the parts, however, it is possible (by setting CFG841.7 or CFG842.7) to enable the 11-bit extended stack pointer. In this case, the stack rolls over from FFH in RAM to 0100H in XRAM. The 11-bit stack pointer is visible in the SP and SPH SFRs. The SP SFR is located at 81H as with a standard 8052. The SPH SFR is located at B7H. The 3 LSBs of this SFR contain the 3 extra bits necessary to extend the 8-bit stack pointer into an 11-bit stack pointer." I never tried this before, but according to the datasheet, it would be very easy to activate in sdcc. In _sdcc_external_startup or the top of your main function (I don't remember where the stack is initialized) add: CFG842|=0x80; // Enable 11-bit stack SPH=0x7 // Locate stack at 0x700 SP=0; If that doesn't work, try not changing SPH and SP, and link with --xram-loc 0x200, as the stack would roll over from data 0xff to xram 0x100. Then, by making some of your new functions reentrant, you should be able to free some data memory. Or you can go to the extreme of making all reentrant (using stack-auto) and free lots of data memory. Jesús At 05:58 AM 10/3/2006, you wrote: >Maarten Brock wrote: > > Hello Karl, > > > > Yes, you ran out of 'data' memory. Especially when > > accessing xdata (--model-large) the compiler uses many > > temporaries which are stored in registers and then in > > data memory. It tries to overlay them but is not very > > good at that. The result: high usage of the limited data > > memory resource. As you can see in the .mem file all is > > used. It has no point putting temporaries in xdata as > > xdata access (only indirect) was the issue in the first > > place. > > > > Am I saying all hope is lost? No, not all. You can try > > to use --stack-auto to put all temporaries on the stack. > > The stack uses idata which can be about twice as big as > > data memory, but it also might introduce extra > > temporaries. Also on the stack overlaying happens by > > definition in it's most efficient way. But I cannot > > guarantee this will solve your problems, it might even > > create more as stack pressure rises and stack overflows > > can happen. > > > > Greets, > > Maarten > > > > > >Thanks for the info. I'm thinking though that --stack-auto will cause >more problems with potential stack overflows. > >Any near term improvements coming the the compiler to help improve it's >usage of these temporaries? > >Are there things i can do with my code, that will make the compiler work >better to help improve things? > >What i have in mind: >* remove reentrant function (i have 1 now) I would think that this only >reduces stack usage though. >* break functions into smaller pieces >* reduce function depth (reduce stack usage) >* I have 2 register banks for high priority interrupts allocated, I may >try not "using x" register bank, trade off on performance, but will add >a few bytes of "data" space. >* This processor (analog devices ADUC842) supports a 11 bit stack >pointer (SP and SPH) that would allow me to use --stack-auto and now >worry about overflows. However I don't know how to make SDCC do this, >or if it's supported. > > >I'm trying these now... > >Thanks > >-- >Karl Hiramoto http://karl.hiramoto.org/ > > > >> Hi all, > >> > >> My code was compiling/linking/running fine, I added a few functions, > >> and now when linking i get: > >> > >> ?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area > >> OSEG. > >> > >> sdcc -v > >> SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 > >> 2.6.1 #4398 (Oct 2 2006) (UNIX) > >> > >> I also had the same with the 2.6.0 release. > >> > >> > >> I compile/link with args like: > >> > >> sdcc -c --iram-size 256 --model-large --xram-size 2048 --code-size > >> 63487 --opt-code-size --profile -I/usr/local/sdcc/share/sdcc/include > >> -L/usr/local/sdcc/share/sdcc/lib/large SD_MMC.c > >> /usr/local/sdcc/share/sdcc/include/malloc.h:46: warning 187: ISO C90 > >> does not support flexible array members > >> sdcc --iram-size 256 --model-large --xram-size 2048 --code-size 63487 > >> --opt-code-size --profile -I/usr/local/sdcc/share/sdcc/include > >> -L/usr/local/sdcc/share/sdcc/lib/large main.rel adc.rel alarms.rel > >> bluetooth.rel dac.rel interrupt.rel timer.rel uart.rel eeprom.rel > >> temperature.rel lookup_table.rel motor.rel lonworks-compat.rel > >> velocity.rel vfd_lcd_led.rel vel_to_vol.rel pressure.rel humidity.rel > >> FAT_format_disk.rel FAT_File_System.rel String_Util.rel > >> flash_sect_serv.rel SD_MMC.rel > >> ?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area > >> OSEG. > >> ?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area > >> OSEG. > >> > >> > >> $ cat main.mem > >> 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|1|1|1|1|1|1|1|1| > >> 0x10:|2|2|2|2|2|2|2|2|a|a|a|a|b|b|b|b| > >> 0x20:|B|B|B|B|c|c|c|c|d|d|e|e|e|e|f|f| > >> 0x30:|f|f|g|g|g|g|g|g|g|g|h|h|h|h|h|h| > >> 0x40:|h|h|h|h|h|h|i|i|i|i|i|i|i|i|j|j| > >> 0x50:|j|j|k|k|k|k|l|l|l|l|l|l|l|l|l|l| > >> 0x60:|l|l|m|m|n|n|n|n|o|o|o|o|o|p|p|q| > >> 0x70:|q|q|q|q|q|q|q|r|s|s|s|s|s|t|Q|S| > >> 0x80:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0x90:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0xa0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0xb0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0xc0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0xd0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0xe0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0xf0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| > >> 0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData, > >> S:Stack, A:Absolute > >> > >> ERROR: Couldn't get 4 bytes allocated in internal RAM for area OSEG. > >> Stack starts at: 0x7f (sp set to 0x7e) with 129 bytes available. > >> > >> Other memory: > >> Name Start End Size Max > >> ---------------- -------- -------- -------- -------- > >> PAGED EXT. RAM 0 256 > >> EXTERNAL RAM 0x0000 0x0593 1428 2048 > >> ROM/EPROM/FLASH 0x0000 0xbdf8 48633 63487 > >> > >> > >> > >> If interested, i can post .map, .mem, .sym, .lnk. > >> > >> Am I reading the error message correctly?: There is no more overlay > >> space? I have plenty of xram where I would think variables could be > >> allocated. > >> > >> > >> Should I be using different compile/link flags? My target processor is > >> analog devices ADUC842. > >> > >> Thanks.. > >> > >> -- > >> Karl Hiramoto http://karl.hiramoto.org/ > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Sdcc-user mailing list >Sdcc-user@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
