mikrocontroller.net

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


Autor: Tobias Wegner (oo7)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: defekter Notebookakku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist völlig normal.

Autor: Bertrik Sikken (bertrik)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Tommy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, würde ich auch vorschlagen, einfach selbst die bytes über die 
schnittstelle kloppen

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Tobias Wegner (oo7)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.