Hallo zusammen, Habe die Freeware-Version von Embedded Workbench für MAXQ ( 4K ) Habe folgendes Problem: Wenn ich folgende simple Rechenoperation einfüge, x= 16000000/160*(y+768)/1024; zeigt mein Kompiler 2 467 bytes of CODE memory (+ 512 absolute ) 1 014 bytes of DATA memory an. wenn ich die Rechenoperation in Gleitkommazahlen ändern will: x= 16000000./160*(y+768)/1024; ( Nur ein Punkt..) 3 573 bytes of CODE memory (+ 512 absolute ) 1 014 bytes of DATA memory Wenn ich "weitere Punkte" hinzufüge: x= 16000000./160.*(y+768.)/1024.; Fatal Error[e89]: Too much object code produced (more than 0x1000 bytes) for this package Ist das möglich, dass eine float-Zahl die Code-Größe so verändert ??? Das Problem würde nicht mehr auftreten, wenn ich die Lizenz kaufen würde, oder?? Vielen Dank im voraus!
> Ist das möglich, dass eine float-Zahl die Code-Größe so verändert ??? Ja, natürlich, denn es muss die floatingpointlibrary gelinkt werden, die den Code für arithmetische und sonstige Operationen mit FP-Zahlen enthält. > Das Problem würde nicht mehr auftreten, wenn ich die Lizenz kaufen > würde, oder?? Ja, nur ist die bei IAR nicht sehr ... günstig. Setz Dich lieber gut hin, bevor Du Dich nach deren Preis erkundigst.
> x= 16000000./160*(y+768)/1024; ( Nur ein Punkt..) Angenommen int x, y; Der C Compiler kann das so rechnen und tut das anscheinend Zwischenergebnis float a = 1600000f/160 Zwischenergebnis int b = y+768 Zwischenergebnis int c = b/1024 Endergebnis x = a * (float) c Die Reihenfolge in der die Zwischenergebnisse berechnet werden, ist nicht vorgegeben. Der Compiler kann die frei anordnen. Die Gleitkommarechnung beim Endergebnis kann man wegoptimieren., wenn Compiler weiss, dass a und c Ganzzahlig sind. Die Gleitkommarechnung beim Zwischenergebnis a kann der Compiler zur Compilezeit machen. Insgesamt wird zur Laufzeit keine Gleitkommarechnung benötigt. Die entsprechende Library kann aus dem Code raus bleiben! > x= 16000000./160.*(y+768.)/1024.; Typ x, y egal Zwischenergebnis float a = 1600000f/160f ggf. y nach float Promotion Zwischenergebnis float b = y+768f Zwischenergebnis float c = b/1024f Zwischenergebnis d = a * c ggf. d in Typ von x Demotion x = d Hier muss mehrfach zur Laufzeit mit Gleitkomma gerechnet werden, dass das wesentlich umfangreicher ist sieht man.
Habe mir jetzt die 30-Tage-Evaluation Version gedownloaded... Ist immernoch das selbe Problem, obwohl keine Beschränkung der Comilliergröße ist. Hat jemand dafür eine Erklärung???
Hat dein µC vielleicht nur 4K (0x1000) Platz für Code? Dann kann der Compiler auch nur 4K dort reinpacken und wenn der Compiler aufgrund deines Programmes mehr erzeugt hat, mosert er (zu Recht). Vielleicht kannst du deine Berechnung ohne Gleitkommarechnung ausführen? Dann würde die Codemenge ja ausreichen. Um das zu beurteilen, müsste man wissen, was du berechnen willst. Und der Artikel Festkommaarithmetik kann auch Inspirationen geben.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.