Hallo, Heiko Müller schrieb: > we are using sdcc 2.4.0 (debian sarge) for uC ATMEL AT89C51ED2. > The initialization of global xdata (XISEG) is not properly performed > without option '-no-xinit-opt' when the internal XRAM of uC > is used and XISEG ends above 0xFFh.
the AT89C51RD2/ED2 deviates from a standard mcs51 core with respect to its pdata addressing mode. "Accesses to XRAM above 0FFH can only be done by the use of DPTR." (page 25 of 08/05 datasheet) > Looking into the *.asm output shows: > > 1 ;-------------------------------------------------------- > 2 ; File Created by SDCC : FreeWare ANSI-C Compiler > 3 ; Version 2.4.0 Mon Nov 6 18:07:35 2006 > 4 > 5 ;-------------------------------------------------------- > 6 .module ****** > 7 .optsdcc -mmcs51 --model-small > 8 [...] > 9 ;-------------------------------------------------------- > 10 ; global & static initialisations > 11 ;-------------------------------------------------------- > 12 .area GSINIT (CODE) > 13 .area GSFINAL (CODE) > 14 .area GSINIT (CODE) > 15 __sdcc_gsinit_startup: > 16 mov sp,#__start__stack - 1 > 17 lcall __sdcc_external_startup > 18 mov a,dpl > 19 jz __sdcc_init_data > 20 ljmp __sdcc_program_startup > 21 __sdcc_init_data: > 22 ; _mcs51_genXINIT() start > 23 mov r1,#l_XINIT > 24 mov a,r1 > 25 orl a,#(l_XINIT >> 8) > 26 jz 00003$ > 27 mov r2,#((l_XINIT+255) >> 8) > 28 mov dptr,#s_XINIT > 29 mov r0,#s_XISEG > 30 mov p2,#(s_XISEG >> 8) > 31 00001$: clr a > 32 movc a,@a+dptr > 33 movx @r0,a > 34 inc dptr > 35 inc r0 > 36 cjne r0,#0,00002$ > 37 inc p2 > 38 00002$: djnz r1,00001$ > 39 djnz r2,00001$ > 40 mov p2,#0xFF > 41 00003$: > 42 ; _mcs51_genXINIT() end > > The code uses movx w.r.t. r0 and p2 (lines:29-35) for writing to XISEG. This > does not work if XISEG is located in XRAM (internal memory) of the uC (as for > the T89C51ED2). IMHO it would be more portable to use 'movx @dptr, a'. This > would not depend on the physical location of the XISEG. > > With sdcc option '-no-xinit-opt' the initialization is done explicitely by > assignments and works fine, but code size is larger. > > This problem seems persistent also for the most recent sdcc v2.6.0. Is there > any reasion not to change _mcs51_genXINIT() accordingly? Perhaps, I overlook > some other implications? It could be changed, but I doubt there would be a consensus to use a more lengthy initialization routine for all devices in order to support a specific mcs51 derivative with a non-standard pdata addressing mode. Newer versions of SDCC are more easy to adapt. (In this context "Newer" denotes "later than 2004-03-17" - see ChangeLog) > "Englerstr. 28" Hoppla, just seen this. This is less than 2 km line-of-sight from here! I guess I should rather call by phone instead of writing emails!) Grüße, Frieder ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
