mikrocontroller.net

Forum: Compiler & IDEs uint64_t verwendet und gleich wird 5kb mehr Ram gebraucht


Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

tschuldigung, ich muss euch schon wider mit einer warscheinlich
einfachen Frage nerven. Also ich fasse mich kurz. Ich hab hier eine
hübsche Funktion geschrieben um mit Fat32 von einer Sd Karte zu lesen.
Dabei hab ich mir das so zurecht gelegt, dass ich von jedem beliebigen
Byte in der Datei anfangen zu lesen kann.

Nun desshalb kann die Variable 'start', natürlich sehr gross werden.
(Start gibt das byte an von welchenm gelesen werden soll). Nun habe ich
bis anhin uint32_t verwendet; das klappt bis 32768 auch ganz gut. Nur
wenn ich daraus nun einen uint64_t mache, dann steigt die Codegrösse
von ~4000 bytes auf über 9000 bytes an. Und dies 'bloss',  4
folgenden Rechnungen. Als optimierungslevel beim compilieren verwende
ich 's'.

Was ich auch nicht ganz begreife - ein uint32_t ist in inttypes ja als
unsigned long long definiert. sollte also 32bits lang sein.
Wenn der unsigned ist sollte das ja bedeuten 2^32 = 4294957296
Bei mir gibts allerdings schon ab 32768 Rechnungsfehler.
(multiplikationen verwende ich allerdings nirgends).

Nik

Autor: Stefan M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du konstanten im Code eingibst, solltest du auf jeden Fall immer
die richtigen Postfixe verwenden, sprich z.b. "a = 40000ULL", wenn
die Zahl als unsigned long long gerechet werden soll.

Je nach Rechenoperation kann eine 64bit Rechnung extrem viel mehr Platz
brauchen als eine 32bit Rechnung. Du arbeitest ja schließlich immerhin
mit einem 8bit Kern.

Poste mal deinen Code, manchmal lässt sich bei den Rechnungen was von
Hand optimieren, so dass es schneller zu rechnen geht.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh sch***** im Titel sollte es natürlich heissen 5kb mehr Flash, nicht
Ram.

Das mit den Postfixen werd ich gleich mal versuchen, ich hab nämlich
eine Konstante, wenn das noch nicht hin haut poste ich mal den Code :)

Autor: Nik Bamert (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So ich hab die funktion + Aufruf mal angehängt.

Es könnte auch an meiner Art liegen, wie ich die Zahl berechne(oberster
abschnitt in fread)

Ich müsste irgendwie das abgerundete Ergebniss von start/512 kriegen,
wenn möglich mit einem shift oder so was in der Art? Irgendwie muss es
doch effektiver gehen und ohne dass endlose Zahlen entstehen.

Autor: Stefan M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest dieses "start/512" nur einmal am Anfang der Funktion
berechnen. Außerdem spart "start >> 9" im vergleich zu "start/512"
Speicherplatz, habs grad mal getestet.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem long long ist mir auch schonmal aufgefallen.
5kByte für eine einfache long long Division ist schon extrem.
In Assembler ist da kein unterschied: Man muss nur den Schleifenzähler
anpassen, so dass er 64 statt 32bits verarbeitet.
Da es bei mir nicht auf absolute Genauigkeit ankam, habe ich float
verwendet.

Eigentlich sollte zwischen start>>9 und start/512 kein Unterschied
sein, wenn es unsigned ist: Der Compiler macht aus beiden shifts.
Wenn es signed ist, dann gilt start>>9 != start/512 !
Aus diesem Grund ist es eigentlich immer sichere, wenn man teilt.

Autor: Christian Spahn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Werte hat denn sectors_per_cluster so? Wenn es sich nämlich um
2er Potenzen handelt (4, 8, 16...) würde ich es nämlich auch so
speichern.

Zum einen kommt man dann evtl. mit einer kleineren Variablen aus, zum
anderen kann man die teuren Divisionen durch billige Shifts ersetzen.

Autor: Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie Du schon oben bemerkt hast kann mit mit 32 Bit sehr viel mehr als
32768 speichern/rechnen.
Ich denke der Fehler liegt woanders, ich würde in so einem Fall
versuchen den Code zu debuggen und dabei die Berechnungen
kontrollieren.

Grüße
Walter

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.