Hi, da ich in einer Rechenoperation mehrere Faktoren zusammenrechne, die ich dann am Ende erst runden mag reichen mir leider 32 Bit nicht aus, ich brauche mehr.. 64. Wenn ich allerdings einen uint64_t verwende bläht das meinen Flash und den Ram extrem auf. Was kann man da tun? Gibt es noch ne alternative Vorgehensweise? lg PoWl
Paul Hamacher schrieb: > Wenn ich allerdings einen uint64_t verwende bläht das > meinen Flash und den Ram extrem auf. Die entsprechenden Routinen sind halt, im Gegensatz zu vielen anderen Dingen beim AVR-GCC, nicht mit der Hand optimiert, sondern sie werden beim Beu des GCC automatisch generiert. Das merkt man ihnen an.
Jörg Wunsch schrieb: > Paul Hamacher schrieb: >> Wenn ich allerdings einen uint64_t verwende bläht das >> meinen Flash und den Ram extrem auf. > > Die entsprechenden Routinen sind halt, im Gegensatz zu vielen anderen > Dingen beim AVR-GCC, nicht mit der Hand optimiert, sondern sie werden > beim Beu des GCC automatisch generiert. Das gilt heutzutage nicht mehr: Seit avr-gcc 4.7 sind die Operationen für 64-bit skalare Interer auch in Assembler, siehe zB die Erklärung in http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-dimode.md?view=markup Das liesse sich zwar noch optimieren, aber irgendwo muss mal Schluss sein :-) Je nach Eingabe dürfte die 64-Bit Division sogar schneller sein als die 32-Bit Division mit gleichen Eingabewerten. Siehe auch die Release-Notes: http://gcc.gnu.org/gcc-4.7/changes.html
Johann L. schrieb: > Das gilt heutzutage nicht mehr: Seit avr-gcc 4.7 Müsste leider heissen: Das wird im Zukunft nicht mehr gelten, wenn avr-gcc 4.7 seinen Weg in die üblichen toolchains gefunden haben wird... Nicht jeder baut seinen tools frisch auf den aktuellen Sourcen. Oliver
Johann L. schrieb: > Das gilt heutzutage nicht mehr: Seit avr-gcc 4.7 sind die Operationen > für 64-bit skalare Interer auch in Assembler Danke, gut zu wissen! Oliver schrieb: > Nicht jeder baut seinen tools frisch auf den aktuellen Sourcen. Dann musst du halt denjenigen nerven, der dir deine Toolchain liefert. GCC 4.7.0 ist schon ein Vierteljahr alt, inzwischen gibt's schon GCC 4.7.1 (seit knapp einem Monat). U. U. ist aber Selbstbauen der schnellere Weg (und nur beim ersten Mal nicht so einfach, wenn man's einmal gemacht hat, ist es nicht mehr so tragisch9.
Es gibt auch bBuilds von 4.7.1 für Windos, siehe http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=963192#963192 Und für Linux-Anwender ist Bauen der Tools eh easy.
Man kann es auch mit dem alten WINAVR 2010 benutzen. Man muß nur eine Lib hinzulinken: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113673 Es scheint tatsächlich an dem fehlenden Assemblercode gelegen haben, daß sich lange keiner daran getraut hat. Kurz nachdem ich ihn bei AVRfreaks veröffentlich habe, hat ihn auch jemand in die offizielle Lib integriert. Peter
und wenn du das problem nicht durch 64 bit variablen sondern durch N1/i+N2/i+N3/i+(N1%i+N2%i+N3%i)=Mittelwert klein hältst? wenn die mittelung über 2^n geht ist das schön durch schieben zu lösen... (als beispiel für einen mittelwert) welche operation willst du denn genau durchführen?
multiplikation mehrere zahlen und dann teilen durch eine ebenso relativ große zahl. bisher hab ich das halt unter hinnahme von genauigkeitsverlusten zwischendrin alles mal durch faktor 100 geteilt und hinterher nochmal anstatt erst am ende, damit ich eben im 32-bit bereich bleiben kann. das mit dem neuen GCC oder der lib werd ich mir auf jeden fall mal anschauen! das könnte einige probleme einfach in luft auflösen.
Mann muss auch nicht immer krampfhaft mit Festkommaarithmetik rechnen, Gleitkomma hat auch seine Berechtigung, vor allem wenn es um Multiplikation mehrerer großer Zahlen geht.
stimmt aber wenn ich die gleitkomma-lib noch mit einbinde ist mein µC sofort voll ;)
Paul Hamacher schrieb: > stimmt aber wenn ich die gleitkomma-lib noch mit einbinde ist mein µC > sofort voll ;) Ausprobiert oder Hörensagen? Die Gleitkommabibliothek der avr-libc dürfte drastisch kompakter sein als die alten 64-bit-Routinen (zumal sie ja auch nur mit 24 bit Genauigkeit rechnen muss).
noch ein punkt: wenn der avr-gcc zu viele funktionsparameter in einer funktion hat wird der stack zur übergabe der parameter verwendet, WIMRE tut es das ab über 8 bytes, darunter verwendet er ein paar reservierte register. ein uint64_t sind schonmal 8 bytes. abhilfe in diesem fall: pointer auf uint64_t verwenden um parameter zu übergeben. spart code bei funktionsaufrufen und stack. die 64bit arithmetik bleibt aber so gross
Paul Hamacher schrieb: > da ich in einer Rechenoperation mehrere Faktoren zusammenrechne, die ich > dann am Ende erst runden mag reichen mir leider 32 Bit nicht aus, ich > brauche mehr.. 64. Wenn du pi auf 2000 Stellen ausrechnen möchtest, wirst du auch mit 64 Bit nicht weit kommen. Vielleicht solltest du dein Problem erstmal auf einen rechnerfreundlichen Algorithmus umformen.
v.N. schrieb: > Wenn du pi auf 2000 Stellen ausrechnen möchtest, wirst du auch mit 64 > Bit nicht weit kommen. Siehe 4000 Stellen von Pi mit ATtiny2313. Der steht zwar in float-Arithmetik, ist aber auch in 64-Bit Arithmetik handhabbar :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.