Small Device C Compiler suite

Hi Maarten,

On Sunday 09 October 2005 16:21, Maarten Brock wrote:
> Ernst,
>
>
> You must have tried really hard to read the manual and overlook the --
> xram-loc option ;-) It's a bit easier than -Wl-bXISEG=0x1000

Heh, nod, I overlooked that. Just copied the -Wl-b option I used to move my 
secondary interrupt table arround.
Regarding that, another quick question:
Will sdcc be able to emit code for different segments from a single .c file?

#pragma save
#pragma codeseg SOMESEG
void abc() {...
#pragma restore

doesn't seem to work. I'm currently running 2.5.3 #1117 (Sep 29 2005)

> Why do you think MOVC is faster than MOVX ? It needs setting up both A and
> DPTR instead of just DPTR.

Well, for xdata array accesses,  the code generated is something like:
mov     a, <offset>
add     a,#_testdata
mov     dpl,a
clr     a
addc    a,#(_testdata >> 8)
mov     dph,a
movx    a,@dptr
mov <destination>,a

For code array access, its:
mov     a, <offset>
mov     dptr,#_testdata
movc    a,@a+dptr
mov <destination>, a

which looks quite a bit faster to me.

> SDCC does not support the Von Neumann architecture for 8051, only Harvard
> where code, xdata, data and sfr are all different memories.

Well, I found a solution working for me without being overly ugly:
I changed my array definitions all to live in code space, so they can be 
uploaded together with the firmware, and use an xdata pointer to it whenever 
I need write access:

code char test_code[64]={1,2,...};
void func() {
xdata char * const test_x=(xdata char *)test;
...
test_x[4]=5;
}


The sdcc optimizer completely removes "test_x" from the code here, and 
generates a movx access just fine:

;main.c:13: test_x[4]=5;
;     genPointerSet
;     genFarPointerSet
 mov     dptr,#(_test + 0x0004)
 mov     a,#0x05
 movx    @dptr,a


/Ernst

Ernst,

> Will sdcc be able to emit code for different segments from a single .c file?
> 
> #pragma save
> #pragma codeseg SOMESEG
> void abc() {...
> #pragma restore
> 
> doesn't seem to work. I'm currently running 2.5.3 #1117 (Sep 29 2005)

No, unfortunately that is not supported.

> > Why do you think MOVC is faster than MOVX ? It needs setting up both A and
> > DPTR instead of just DPTR.
> 
> Well, for xdata array accesses,  the code generated is something like:
> mov     a, <offset>
> add     a,#_testdata
> mov     dpl,a
> clr     a
> addc    a,#(_testdata >> 8)
> mov     dph,a
> movx    a,@dptr
> mov <destination>,a
> 
> For code array access, its:
> mov     a, <offset>
> mov     dptr,#_testdata
> movc    a,@a+dptr
> mov <destination>, a
> 
> which looks quite a bit faster to me.

In this case you're absolutely right.

> Well, I found a solution working for me without being overly ugly:
> I changed my array definitions all to live in code space, so they can be 
> uploaded together with the firmware, and use an xdata pointer to it whenever 
> I need write access:
> 
> code char test_code[64]={1,2,...};
> void func() {
> xdata char * const test_x=(xdata char *)test;
> ...
> test_x[4]=5;
> }
> 
> 
> The sdcc optimizer completely removes "test_x" from the code here, and 
> generates a movx access just fine:
> 
> ;main.c:13: test_x[4]=5;
> ;     genPointerSet
> ;     genFarPointerSet
>  mov     dptr,#(_test + 0x0004)
>  mov     a,#0x05
>  movx    @dptr,a

Casting the pointer in such cases is a very good solution.

Have fun,
Maarten

Ernst Bachmann wrote:
>>Why do you think MOVC is faster than MOVX ? It needs setting up both A and
>>DPTR instead of just DPTR.
> 
> Well, for xdata array accesses,  the code generated is something like:
> mov     a, <offset>
> add     a,#_testdata
> mov     dpl,a
> clr     a
> addc    a,#(_testdata >> 8)
> mov     dph,a
> movx    a,@dptr
> mov <destination>,a
> 
> For code array access, its:
> mov     a, <offset>
> mov     dptr,#_testdata
> movc    a,@a+dptr
> mov <destination>, a
> 
> which looks quite a bit faster to me.

Hi Ernst,

you can get SDCC to generate shorter code for xdata
array access as well:)
If you specify that a (char indexed) array begins
at an address dividable by 0x0100 you get:


         mov     dpl,r2
         mov     dph,#(_test >> 8)
         movx    a,@dptr




extern xdata char at 0x0100 test[256];

char func() {
     unsigned char i = 0;

     do {
         test[i] = 0xff;
     } while (--i);

     return test[i];
}



Currently SDCC does not automatically place "char x[256]",
"int y[128]" or "int y[256]" at a block address so you will have to
to this "by hand".

Feature Request #1017497 is related:
http://sourceforge.net/tracker/index.php?func=detail&aid=1017497&group_id=599&atid=350599

Greetings,

Frieder