Hallo, wenn man einen uC mit FPU hat, kann man die FPU nicht nutzen, indem man dem compiler sagt er solle doch bitte keine FPU Befehle verwenden. Gibt es einen Fall, wann das jemals sinnvoll sein könnte?
Ich bin mir nicht sicher, ob sie 'abschaltbar' ist. Die Komponenten im STM, die man braucht müssen zuvor 'eingeschaltet' werden. Falls das mit der FPU ebenfalls so ist wäre Stromsparen ein Argument...
sina anargo schrieb: > Hallo, > > wenn man einen uC mit FPU hat, kann man die FPU nicht nutzen, indem man > dem compiler sagt er solle doch bitte keine FPU Befehle verwenden. Gibt > es einen Fall, wann das jemals sinnvoll sein könnte? Verwendung von einem RTOS, welches die FPU-Register beim Kontextwechsel nicht sichert @ Mr.Moe: muss gar nicht hardwareseitig abschaltbar sein. Wenn der Compiler einfach die FPU-Instruktions nicht verwendet ;)
Hi Sinapse, schau Dir mal die AN4044 zur FPU im STM32F4 an. Das Teil ist spezialisiert auf 32bit-Float-Arithmetik. Dem GCC musst Du dediziert mitteilen, dass Du in diesem Bereich arbeiten möchtest: - Variablen als float deklarieren - bei Funktionsaufrufen die f-Variante verwenden (e.g. asinf statt asin) Mein letzter Stand ist: sobald Du double deklarierst, wird die FPU überhaupt nicht verwendet. Bei Tests mit dem GCC 4.6 mit FPU sind float-Aufgaben grob doppelt so schnell gelöst worden. Grüße, Marcus
iizi schrieb: > @ Mr.Moe: muss gar nicht hardwareseitig abschaltbar sein. Wenn der > Compiler einfach die FPU-Instruktions nicht verwendet ;) Ich nehme an wenn man Strom sparen will, wird man sie schon explizit abschalten müssen. Marcus H. schrieb: [schnipp] Toll, wie du so gar nicht auf die Frage eingehst. @sinapse: mir fällt auch nur Stromsparen ein. Allerdings kann man dann auch gleich einen Core ohne FPU nehmen. XL
sina anargo schrieb: > Gibt es einen Fall, wann das jemals sinnvoll sein könnte? Bugs in der FPU, defekte FPU, oder zum testen
Ach Axel, verzeih, war ein langer Tag. Vielleicht habe ich die Frage falsch verstanden. Ich habe Gründe angegeben, warum es Sinn machen könnte die FPU nicht zu verwenden. gähn Zum Thema Strom sparen: wenn die CPU die meiste Zeit schläft, die FPU 25% des CPU Stroms braucht und doppelt so schnell wie die CPU ist, könnte es sich sogar lohnen, die FPU zu nehmen um früher wieder ins Bett zu kommen. Und beim oben zitierten STM32F4 muss man die FPU nach dem Reset dediziert wecken. gute Nacht
Marcus H. schrieb: > Ach Axel, verzeih, war ein langer Tag. Vielleicht habe ich die Frage > falsch verstanden. Offensichtlich. Zugegeben, die Frage ist auch eher merkwürdig. Aber das ist wiederum kein Grund, mit der Antwort auf eine ganz andere Frage darauf zu antworten. > Ich habe Gründe angegeben, warum es Sinn machen könnte die FPU nicht zu > verwenden. Nein. Du hast ausgeführt wie man es anstellen muß um die FPU zu verwenden. Und ein paar Fälle aufgeführt, wo die FPU auch dann nicht verwendet wird wenn sie vorhanden ist. Keines davon war gefragt. > Zum Thema Strom sparen: wenn die CPU die meiste Zeit schläft, die FPU > 25% des CPU Stroms braucht und doppelt so schnell wie die CPU ist, > könnte es sich sogar lohnen, die FPU zu nehmen um früher wieder ins Bett > zu kommen. Auch das war nicht die Frage. > Und beim oben zitierten STM32F4 muss man die FPU nach dem Reset > dediziert wecken. Das würde ja darauf hindeuten, daß es da ein Stromsparpotential gibt, wenn man die FPU absichtlich nicht aufweckt. XL
Die FPU ist beim Cortex-M3 und anderen Cores optional. Daher hat der Compiler Schalter, um die Nutzung der FPU zu konfigurieren. Man schaltet die FPU i.d.R. daher nicht aus, sondern überhaupt erst ein. AFAIR verändert es die Calling Convention, wenn man die FPU aktiviert. Vielleicht man hat irgendwelche Binärblobs aus dritter Hand, die die Calling Convention ohne FPU verlangen. Das ist aber auch so ziemlich das Einzige, was mir einfällt.
ja... das ganze zielte darauf ab, warum überhaupt die FPU im Compiler aktiviert/deaktiviert werden kann. Dachte im deaktivierten Zustand kann es doch noch Vorteile geben, die mir nur nicht einfallen. Aber: greg schrieb: > Man schaltet > die FPU i.d.R. daher nicht aus, sondern überhaupt erst ein. das wird es wohl sein. Danke und lg
Hi Sinapse, dann war ich vielleicht doch nicht so weit daneben. Mögliche Gründe auf die FPU zu verzichten: 1. Leistungsaufnahme 2. Kontextwechselaufwand (Speicher, Latenzzeit) 3. ggf. bessere Genauigkeit bei Firmwareemulation (double statt float bei STM32F4) Gründe 2/3 sind ausschlaggebend, warum ich in meinen STM32F4 Designs meist die FPU schlafen lasse. Der Geschwindigkeitsfaktor 2 kommt höchstens bei schnellen Filtern zum Zug. Grüße, Marcus
Marcus H. schrieb: > Der Geschwindigkeitsfaktor 2 kommt höchstens bei schnellen Filtern zum > Zug. Den Faktor 2 hast Du Dir mal eben so einfallen lassen? Nach meiner Erfahrung ist dieser Faktor deutlich höher.
Nö Gast, ich zitiere mal eben meinen Lieblingsautor aus Post #3823345: "Bei Tests mit dem GCC 4.6 mit FPU sind float-Aufgaben grob doppelt so schnell gelöst worden." Der Test war eine gemischte Folge von Arithmetik, Trigonometrie und dergl.. Ansonsten habe ich auch schon die AN4044 genannt. Da kannst Du die (tatsächlich recht kurzen) Laufzeiten für die einzelnen FPU-Befehle raussuchen.
Der fundamentale Vorteil dieses Schalters erschliesst sich sofort, wenn man zu den Entwicklern des Compilers und/oder der entsprechenden Runtime-Library gehört und den Code ohne FPU auf einem Prozessor mit FPU testen will.
:
Bearbeitet durch User
Marcus H. schrieb: > Nö Gast, ich zitiere mal eben meinen Lieblingsautor aus Post #3823345: > "Bei Tests mit dem GCC 4.6 mit FPU sind float-Aufgaben grob doppelt so > schnell gelöst worden." Hier zitierst Du Dich selber? Ist das jetzt besonders witzig? Marcus H. schrieb: > Ansonsten habe ich auch schon die AN4044 genannt. Da steht unter 4.4, dass die Testroutinen mit FPU Faktor 11,5 - 17 schneller laufen. Beitrag "Re: Controller mit FPU"
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.