Forum: Compiler & IDEs sprintf kostet 19k bei WinARM ?!


von Tobias W. (oo7)


Lesenswert?

Hallo Zusammen!

Ich habe für Debugzwecke meinem Programm eine kleine Routine 
hinzugefügt, die Speicherinhalt als Hexdump über die serielle 
Schnittstelle ausgibt und benutze dazu sprintf mit %x. Dabei habe ich 
festgestellt, dass durch bloßen Ein- und Auskommentieren sich die Größe 
des Programms um 19kB ändert.

In diesem Fall ist es ja nicht weiter schlimm, da es eh nur für einen 
kurzen Test benutzt wird. Trotzdem würde mich für die Zukunft 
interessieren, ob das normal ist, oder ich da grundsätzlich was falsch 
gemacht habe?

Die Suche lieferte mir bisher nur die Information, dass sprintf aufgrund 
des Funktionsumfanges recht groß ist, aber wenn ich daran denke, dass 
ich sprintf auch auf deutlich kleineren Controllern, wenn auch mit 
anderen Compiler und RTLs, benutzt habe kommt mir das doch sehr seltsam 
vor!

Ich benutze einen AT91SAM7S mit WinARM.

Viele Grüße,
Tobias Wegner

von defekter Notebookakku (Gast)


Lesenswert?

Das ist völlig normal.

von Bertrik S. (bertrik)


Lesenswert?

Try this implementation:
http://www.menie.org/georges/embedded/index.html#printf

I used this successfully on a LPC2148 and it takes only slightly more 
than 1k of code.

von Tommy (Gast)


Lesenswert?

Ja, würde ich auch vorschlagen, einfach selbst die bytes über die 
schnittstelle kloppen

von Peter D. (peda)


Lesenswert?

Das ist völlig normal, daß ein 32-Bitter wesentlich mehr Code braucht, 
als ein 8-Bitter.

Zusätzlich hat er eine RISC-Architektur, die keine direkten Befehle auf 
SRAM oder IO-Register erlaubt und auch keine Bitbefehle.

Z.B. ein simples Löschen eines Interruptbits kostet aufm 8051 2 Bytes 
und aufm ARM 20 Bytes.

Bzw. da die meisten Interruptbits des 8051 automatisch bei Eintritt 
gelöscht werden, sinds aufm 8051 oftmals nur 0 Byte.


Peter

von Falk (Gast)


Lesenswert?

@Peter Dannegger

> Z.B. ein simples Löschen eines Interruptbits kostet aufm 8051 2 Bytes
> und aufm ARM 20 Bytes.

20????? Wirklich? Hat der ARM 32 Bit Befehle, ähnlich wie der AVR (16 
Bit), oder haben die Befehle unterschiedliche Längen?
Oder willst du uns auf den ARM nehmen ;-)

(5 Euro in die Schlechte-Wortspiel-Kasse)

MFG
Falk

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Dass Peter hier wieder sein 8051er-Loblied singt war zu erwarten. Aber 
mit Extrembeispielen zu argumentieren macht keinen Sinn - oder wollen 
wir mal den Code für ein 32x32 Multiply & Accumulate vergleichen?

Der eigentliche Grund für diesen Unterschied ist die Float-Unterstützung 
in printf. Deine 19 kB bestehen also nicht nur aus printf, sondern 
enthalten dazu noch die komplette Floating Point Bibliothek. Wenn 
Float-Unterstützung nicht gebraucht wird sollte man iprintf nehmen.

Und wenn es keinen triftigen Grund gibt der dagegen spricht sollte man 
immer für Thumb-Befehlssatz kompilieren, damit erreicht man eine 
deutlich höhere Codedichte. Auf Prozessoren mit schmaler Flash-Anbindung 
und ohne Cache (AT91SAM7) ist er sogar oft schneller.

von A.K. (Gast)


Lesenswert?

Mit printf werden grosse Teile der newlib reingezogen, darunter 
beispielsweise auch Speicherverwaltung. Die newlib ist nicht derart auf 
Platz programmiert wie das Äquivalent aus WinAVR.

von Tobias W. (oo7)


Lesenswert?

Erstmal vielen Dank an Alle für die Antworten!

Mein Gewissen und Weltbild sind damit gerettet. Ich werde in Zukunft 
also printf zu vermeiden oder zumindest die Integerversion verwenden.

Mit Thumb und Arm Mode bin ich noch nicht so ganz vertraut, bisher bin 
ich froh, wenn es kompiliert. (Ja, ich bin Microsoft Visual Studio 
verwöhnt, da braucht man keine Makefiles ;)) Aber mit ist auch klar, 
dass ich mich da mal einarbeiten muss.

von Peter D. (peda)


Lesenswert?

Andreas Schwarz wrote:
> Dass Peter hier wieder sein 8051er-Loblied singt war zu erwarten. Aber
> mit Extrembeispielen zu argumentieren macht keinen Sinn - oder wollen
> wir mal den Code für ein 32x32 Multiply & Accumulate vergleichen?


Bitschubserei ist kein Extrembeispiel, sondern oftmals Brot und Butter 
einer typischen MC-Anwendung.

Man wird in praktischen Anwendungen mit nem 32Bit-RISC nie die 
Codeeffizienz eines 8-Bitters erreichen.
Bei Flashgrößen von typisch 265kB ist das heutzutage aber nicht mehr so 
wichtig. Man sollte es eben nur wissen. Daher wird eben printf zusammen 
mit float gelinkt, was ja beim 8051 auch schon mit 2kB zu Buche schlägt 
(1kB ohne float).

Auch fügt ein 8Bit-Compiler nie eine 32Bit-Multiplikation direkt ein, 
sondern lädt die Register mit den Operanden und ruft sie auf. Sie steht 
also nur einmal im Code und hat damit keinen signifikanten Einfluß auf 
die Gesamtgröße.

Man muß die Kirche im Dorf lassen, d.h. der 32Bitter hat nur dort 
Vorteile, wo wirklich schnell 32Bittig gerechnet werden muß oder wo 
großer Speicher schnell adressiert werden muß.


Oftmals werden 32Bitter leider nur dazu eingesetzt, um den Benutzer mit 
langweiligen Animationen auf nem Grafikdisplay zu nerven, wären der 
eigentliche sinnvolle Funktionscode schon von nem 4Bitter zu wuppen ist.


Peter

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.