Braucht printf Resourcen im BDATA-Bereich?

[Storr der Schnitter (Gast)]

Hallo allerseits!
Ich habe in einem Projekt (8051-Derivat;Keil uVision2) fast den
gesamten BDATA-Bereich in Benutzung. Jetzt habe ich zusätzlich die
printf-Funktion verwendet und erhalte vom Linker prompt eine
Fehlermeldung:
     ERROR L107: ADDRESS SPACE OVERFLOW
     SPACE: BIT
     SEGMENT: ?BI?PRINTF?PRINTF
     LENGTH: 0001H.1
Gibt es eine Möglichkeit zu verhindern, das printf Resourcen aus diesem
(kostbaren) Bereich verbrät?
Gibt es eine Übersicht welche Standardfunktion welchen Speicher
benutzt?
Danke

Jan

[Tester (Gast)]

Die printf Funktion selbst benötigt keinen Speicher im BDATA Bereich.

Wie sieht den der Source zu deinem Problem aus?

[Storr der Schnitter (Gast)]

Ich hab' mal ein Testprojekt erzeugt, indem lediglich printf aufgerufen
wird:
     void main (void) {
                       printf("TEST");
                      }

Wenn ich das ganze compiliere erhalte ich im Output Window die
Meldung:
     Program Size: data=15.1 xdata=40 code=1095

Im M51-File des Linkers steht folgende Information:
     TYPE    BASE      LENGTH    RELOCATION   SEGMENT NAME
     -----------------------------------------------------
       *   *    D A T A   M E M O R Y    *   *  
     REG     0000H     0008H     ABSOLUTE     "REG BANK 0"
     DATA    0008H     0005H     UNIT         DATA_GROUP      <==
             000DH     0013H                  *** GAP ***
     BIT     0020H.0   0001H.1   UNIT         BIT_GROUP       <==
             0021H.1   0000H.7                *** GAP ***
     IDATA   0022H     0001H     UNIT         ?STACK

kommentiere ich die printf-Zeile aus erhalte ich folgende Meldung:
     Program Size: data=9.0 xdata=0 code=16

Im M51-File des Linkers steht dann folgende Information:
     TYPE    BASE      LENGTH    RELOCATION   SEGMENT NAME
     -----------------------------------------------------
       *   *    D A T A   M E M O R Y    *   *  
     REG     0000H     0008H     ABSOLUTE     "REG BANK 0"
     IDATA   0008H     0001H     UNIT         ?STACK

Es werden also 6.1 Bytes im DATA-Bereich benötigt, wobei 1.1 Bytes
(Segment BIT_GROUP) im BDATA (0x20...0x2F) liegen.

Gruss, Jan

[Tester (Gast)]

Unglaublich aber wahr: Die PRINTF Funktion verwendet SETB/CLR 20.0 bis
20.7 und 21.0. (siehe Auszug aus PRINTF Assembler Listing).

Wobei noch zu bemerken wäre: woher kommt die Länge von 0.7 Bytes im
Register 21.1 ?
Und: Wie kommst du auf einen L107 Fehler im BDATA Bereich?

                 PRINTF:
C:0x006E    E4       CLR      A
C:0x006F    C207     CLR      0x20.7
C:0x0071    F508     MOV      0x08,A
C:0x0073    900000   MOV      DPTR,#C_STARTUP(0x0000)
C:0x0076    1203D7   LCALL    C?PSTXDATA(C:03D7)
C:0x0079    E4       CLR      A
C:0x007A    F509     MOV      0x09,A
C:0x007C    F50B     MOV      0x0B,A
C:0x007E    F50C     MOV      0x0C,A
C:0x0080    E509     MOV      A,0x09
C:0x0082    6007     JZ       C:008B
C:0x0084    7F20     MOV      R7,#0x20
C:0x0086    120046   LCALL    C:0046
C:0x0089    80F5     SJMP     C:0080
C:0x008B    750AFF   MOV      0x0A,#0xFF
C:0x008E    C201     CLR      0x20.1
C:0x0090    C200     CLR      0x20.0
C:0x0092    C202     CLR      0x20.2
C:0x0094    C203     CLR      0x20.3
C:0x0096    C205     CLR      0x20.5
C:0x0098    C206     CLR      0x20.6
C:0x009A    C208     CLR      0x21.0
C:0x009C    120012   LCALL    C:0012
C:0x009F    FF       MOV      R7,A
C:0x00A0    700D     JNZ      C:00AF
C:0x00A2    300705   JNB      0x20.7,C:00AA
C:0x00A5    7F00     MOV      R7,#?_PRINTF517?BYTE(0x00)
C:0x00A7    120057   LCALL    C:0057
C:0x00AA    AF0C     MOV      R7,0x0C
C:0x00AC    AE0B     MOV      R6,0x0B
C:0x00AE    22       RET
C:0x00AF    B4255F   CJNE     A,#0x25,C:0111
C:0x00B2    C2D5     CLR      F0(0xD0.5)
C:0x00B4    C204     CLR      0x20.4
C:0x00B6    120012   LCALL    C:0012
C:0x00B9    FF       MOV      R7,A
C:0x00BA    24D0     ADD      A,#PSW(0xD0)
C:0x00BC    B40A00   CJNE     A,#0x0A,C:00BF
C:0x00BF    501A     JNC      C:00DB
C:0x00C1    75F00A   MOV      B(0xF0),#0x0A
C:0x00C4    7809     MOV      R0,#0x09
C:0x00C6    30D505   JNB      F0(0xD0.5),C:00CE
C:0x00C9    08       INC      R0
C:0x00CA    B6FF01   CJNE     @R0,#0xFF,C:00CE
C:0x00CD    06       INC      @R0
C:0x00CE    C6       XCH      A,@R0
C:0x00CF    A4       MUL      AB
C:0x00D0    26       ADD      A,@R0
C:0x00D1    F6       MOV      @R0,A
C:0x00D2    20D504   JB       F0(0xD0.5),C:00D9
C:0x00D5    7002     JNZ      C:00D9
C:0x00D7    D203     SETB     0x20.3
C:0x00D9    80D9     SJMP     C:00B4
C:0x00DB    24CF     ADD      A,#0xCF
C:0x00DD    B41A00   CJNE     A,#0x1A,C:00E0
C:0x00E0    EF       MOV      A,R7
C:0x00E1    5004     JNC      C:00E7
C:0x00E3    C2E5     CLR      0xE0.5
C:0x00E5    D204     SETB     0x20.4
C:0x00E7    020258   LJMP     C:0258
C:0x00EA    D201     SETB     0x20.1
C:0x00EC    80C6     SJMP     C:00B4
C:0x00EE    D200     SETB     0x20.0
C:0x00F0    80C0     SJMP     C:00B2
C:0x00F2    D202     SETB     0x20.2
C:0x00F4    80BC     SJMP     C:00B2
C:0x00F6    D2D5     SETB     F0(0xD0.5)
C:0x00F8    80BA     SJMP     C:00B4
usw.

[Storr der Schnitter (Gast)]

Die 0.7 Bytes ist ist der Rest des angeknabberten Register 21 (21.0 wird
ja noch verwendet). Sie stellen einen freien Bereich dar, deshalb der
Segmentname *** GAP ***.

Den Fehler L107 habe ich nicht mit diesem Testprojekt erhalten, den
bekomme ich in meinem eigentlichen Projekt (wäre zu komplex
darzustellen). Da habe ich, wie schon erwähnt, den BDATA-Bereich
komplett zu. Daher die Meldung.

Gruss, Jan