Some comments, 1) Analog Devices has no datasheet for this thing on their website ?! 2) Keil has a datasheet rev.0 from 2003 ?! 3) It seems that when you enable the 11-bit stack push, pop, call & ret will work just fine. But when accessing parameters, local variables & temporaries on stack SDCC uses @Ri indexing. So when stack has rolled over into xram, it will access the wrong data! I do not recommend to use this option unless you're willing to adapt SDCC itself at several places! 4) If you're really afraid the 8 bit stack will overflow (have you checked how much it uses now?) you can even go to --xstack. This will build a software stack in pdata (movX @Ri) for parameters and local variables. The hardware stack will only be used for push, pop, call & ret and for temporaries. 5) There are no near term improvements to be expected on the use or location of temporaries. 6) Breaking up large function into smaller ones might help. 7) I do not recommend to try to reduce stack usage. I think it will make things worse. 8) It's a very good idea to see if the interrupts actually use the registers in the bank you reserved for them. A good ISR is short and simple with no function calls and therefor may not need any register at all.
Greets, Maarten > 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 > ------------------------------------------------------------------------- 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
