Forum: Mikrocontroller und Digitale Elektronik IAR Workbench - Komisch


von Andreas (Gast)


Lesenswert?

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!

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

> 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.

von Stefan B. (Gast)


Lesenswert?

> 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.

von Andreas (Gast)


Lesenswert?

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???

von Stefan B. (Gast)


Lesenswert?

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.

von Jörg S. (joerg-s)


Lesenswert?

Vielleicht auch das falsche Device/µC in den Einstellungen ausgewählt?

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
Noch kein Account? Hier anmelden.