Maarten:

        Thanks for the reply! 

On Tue, Mar 16, 2010 at 09:18:40AM +0100, Maarten Brock wrote:
> Peter,
> 
> > I'm compiling stuff for the Wiznet W7100 8051 varient and hit the 
> > dreaded "can't allocate DSEG" error. A search through the forum indicates 
> > that --stack-auto and/or large model may fix this. Large model alone didn't
> > seem to so I rebuilt from source (vi Cygwin) from a recent snap and modified
> > the makefile (probably incorrectly by hand, is there a more proper way via 
> > a build option?) to create all the -stack-auto librarys apparantly 
> > correctly.
> 
> It was not meant as first try --model-large and if 
> that's not enough than put --stack-auto on top of it. It 
> means try either --model-large or --stack-auto and if 
> both don't work you might go for the combination. And 
> the small-stack-auto library is in the installer.

        Well in somewhat the wrong order, I tried the code that is working in
--model-medium compiled as --model-large (without the --stack-auto) and it
compiles but doesn't work (although changing back to --model-medium does).
If I'm not missing some option that I need, I'll start poking at why its 
breaking with somewhat simpler code (it currently has serial as well as TCP/IP
code) and see if I can figure out the problem. 

> 
> But the better solution is to find a few bigger 
> variables in data/idata that can be moved to 
> idata/pdata/xdata and stick to --model-small.
> 

        Unfortunatly I looked at that first :-). The overflow in DSEG is all
sloc variables and I don't know how to move those (thats what stack-auto 
is supposed to do I think?) out of the internal ram.

/usr/local/bin//sdcc --model-medium --funsigned-char   main.rel wiz.rel time.rel
 sntp.rel socket.rel wizmemcpy.rel lcd.rel sio.rel console.rel delay.rel fifo.re
l gps.rel dtp.rel tp.rel
?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area DSEG.
?ASlink-Error-Could not get 2 consecutive bytes in internal RAM for area DSEG.
?ASlink-Error-Could not get 3 consecutive bytes in internal RAM for area DSEG.
?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area DSEG.
?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area DSEG.
?ASlink-Error-Could not get 1 consecutive byte in internal RAM for area DSEG.
?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area DSEG.
?ASlink-Error-Could not get 9 consecutive bytes in internal RAM for area OSEG.
?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.
make: *** [timeserv.hex] Error 1

        Pretty much all of DSEG is in function arguments like this one in the
tcp/ip routine (all the local variables are declared xdata):

...
        .area DSEG    (DATA)
_wiz_read32_sloc0_1_0:
        .ds 3
_wiz_write32_sloc0_1_0:
        .ds 2
_wiz_read48_sloc0_1_0:
        .ds 3
_wiz_write48_sloc0_1_0:
        .ds 2
_wiz_set_memsize_sloc0_1_0:
        .ds 2
_wiz_set_memsize_sloc1_1_0:
        .ds 2
_wiz_set_memsize_sloc2_1_0:
        .ds 2
_wiz_set_memsize_sloc3_1_0:
        .ds 2
_wiz_set_memsize_sloc4_1_0:
        .ds 2
...

        Is there a way I don't know of to move that to xdata? I have lots of
free external ram, I just need to figure out how to get the compiler to use it
(even if inefficiently as its there anyway :-)):

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|3|3|3|3|3|3|3|3|
0x20:|B|B|B|T|a|a|a|a|a|a|a|a|a|a|a|a|
0x30:|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|a|
0x40:|a|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|
0x50:|b|b|b|b|b|b|b|b|b|c|c|c|c|c|c|c|
0x60:|c|c|c|c|c|c|c|c|c|c|c|d|d|d|d|d|
0x70:|d|d|d|d|d|d|d|d|d|e|e|f|f|f|f|f|
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:Abso
lute

ERROR: Couldn't get 22 bytes allocated in internal RAM for area DSEG.
ERROR: Couldn't get 4 bytes allocated in internal RAM for area OSEG.
Stack starts at: 0x80 (sp set to 0x7f) with 128 bytes available.

Other memory:
   Name             Start    End      Size     Max
   ---------------- -------- -------- -------- --------
   PAGED EXT. RAM   0x0000   0x00f6     247      256
   EXTERNAL RAM     0x00f7   0x2e2d   11575    65536
   ROM/EPROM/FLASH  0x0000   0x5365   21350    65536

> >    Compiling like this:
> > 
> > /usr/local/bin//sdcc -c wiz.c --model-large --stack-auto --funsigned-char
> > wiz.c:89: error 16: variable 'tmpEA' must be static to have storage class 
> > in ree
> > ntrant function
> > 
> > gets lots of these error messages here (I'm converting from Keil):
> > 
> >   volatile unsigned char xdata tmpEA;
> > 
> > this is fixable by adding a static as it requests:
> > 
> >   static volatile unsigned char xdata tmpEA;
> > 
> > or by
> > 
> >   volatile unsigned char tmpEA;
> 
> What was the memory model you used with Keil? It looks 
> like it was not written for any reentrant model. I guess 
> it will fail with Keil too when you choose a reentrant 
> model.

        I don't have Keil (and at $2K US am not likely to buy it :-)) but this
code is written for it and runs (I have .hex files from the original code). 
>From the Makefile I think it is using large model (only because the asm flags 
set large). I would assume (but don't know for sure) that it should be 
reentrant by default. From the original Makefile:

KEIL = c:/apps/keil/c51

ASM = $(KEIL)/bin/a51
AFLAGS = set "(large)" debug ep xref

CC = $(KEIL)/bin/c51
CFLAGS = code noaregs objectextend symbols debug

export C51INC = ../W7100/inc

LINK = $(KEIL)/bin/bl51
export C51LIB = $(KEIL)/lib

HEX = $(KEIL)/bin/oh51

Peter Van Epp

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Reply via email to