Hello Heiko,

I don't think SDCC 2.4.0 already uses the new concept, but the current
implementation (> 2.5.0 I think) uses a virtual sfr called _XPAGE. When
not defined it defaults to P2, but you can override it by defining it
somewhere in your project, e.g. in the header file. See also the manual
chapter "pdata access by SFR".

If it is impossible to access XRAM outside the first 256 bytes with MOVX
@Ri on this mcu, you will have to copy and adapt crtxinit.asm from the
library and link it with your project. If the mcu has more than one DPTR
(with auto-toggle / auto-increment dptr?) it can be very advantageous to
do so.

The current implementation is the best a standard 8051 can do.
Unfortunately there is no general standard for dual dptr usage on all
derivatives out there.

HTH
Maarten

> Hi,
> 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.
>
> 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?
>
> Regards
> Heiko
>
> --
> Dr. Heiko Mueller  Englerstr. 28       Tel: +49 6221 89467-21
> CEOS GmbH          D-69126 Heidelberg  Fax: +49 6221 89467-29
>                    Germany             http://www.ceos-gmbh.de


-------------------------------------------------------------------------
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

Reply via email to