IAR Workbench - Komisch

Andreas Gast #1542611
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!
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Rufus Τ. F. Persönliche Seite #1542638
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan B. Gast #1542752
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan B. Gast #1544751
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren