Forum: Compiler & IDEs Preprocessor frage ARM<->Xmega


von H. R. (hacker_r)


Lesenswert?

Hi
versteht einer warum ich hier 2 verschiedene Resultate kriege?
Jeweils der IAR Compiler für XMEGA und Stm32F0 ARM
es geht um folgende Zuweisung:

volatile uint32_t Temp = (u32)((357.796/ 40ul) *16777216ul);

Auf Xmega16 ist Temp = 0x08F1E4F0
Auf STM32F0 ist Temp = 0x08F1E4F7
???????

von Martin B. (ratazong)


Lesenswert?

Habs mal kurz ausprobiert und wie vermutet bekomme ich Deine beiden 
ergebnisse mit nur einem Compiler.

XMEGA rechnet mit floats

#include <stdio.h>
#include <stdint.h>

void main(void)
{
double xd=357.796;
float xf=357.796;
uint32_t Temp1 = (uint32_t)((xd/ 40ul) *16777216ul);
uint32_t Temp2 = (uint32_t)((xf/ 40ul) *16777216ul);


printf("%x %x\n",Temp1,Temp2);
}

von H. R. (hacker_r)


Lesenswert?

passt danke

von Martin B. (ratazong)


Lesenswert?

Ach ja,
man könnte noch probieren ob der STM Compiler in float rechnet, wenn man

volatile uint32_t Temp = (u32)((357.796f/ 40ul) *16777216ul);

Aber eigentlich sollte der XMEGA Preprocessor ja in double rechnen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Martin B. schrieb:
> Aber eigentlich sollte der XMEGA Preprocessor ja in double rechnen.

Präprozessor wurde im Beispiel nicht verwendet.

avr-gcc/++ implementiert nur ein 32-Bit double und ist damit nicht 
Standard-konform, siehe "Deviations from the Standard"

http://gcc.gnu.org/wiki/avr-gcc#Deviations_from_the_Standard

von Martin B. (ratazong)


Lesenswert?

Johann L. schrieb:
> Präprozessor wurde im Beispiel nicht verwendet.
>
> avr-gcc/++ implementiert nur ein 32-Bit double und ist damit nicht
> Standard-konform, siehe "Deviations from the Standard"
>
> http://gcc.gnu.org/wiki/avr-gcc#Deviations_from_the_Standard

Stimmt. Präprozessor wurde nicht verwendet.

Der Compiler kam von IAR.
Nehmen die den GCC?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Martin B. schrieb:
> Der Compiler kam von IAR.
> Nehmen die den GCC?

My bad.  Hab nicht richtig hingelesen.

von (prx) A. K. (prx)


Lesenswert?

Martin B. schrieb:
> Aber eigentlich sollte der XMEGA Preprocessor ja in double rechnen.

Daumenregel: Zu 99.9% ist die Aussage falsch, dass der Präprozessor 
irgendwas berechnet.

von Rolf M. (rmagnus)


Lesenswert?

A. K. schrieb:
> Martin B. schrieb:
>> Aber eigentlich sollte der XMEGA Preprocessor ja in double rechnen.
>
> Daumenregel: Zu 99.9% ist die Aussage falsch, dass der Präprozessor
> irgendwas berechnet.

Wenn es um Gleitkomma geht, ist die Aussage zu 100% falsch.

von (prx) A. K. (prx)


Lesenswert?

Martin B. schrieb:
>> avr-gcc/++ implementiert nur ein 32-Bit double und ist damit nicht
>> Standard-konform, siehe "Deviations from the Standard"

> Der Compiler kam von IAR.

Die Erklärung dürfte trotzdem richtig sein, denn der IAR für AVR macht 
das auch so, wenn man nicht --64bit_doubles angibt.

: Bearbeitet durch User
von Martin B. (ratazong)


Lesenswert?

Rolf M. schrieb:
> A. K. schrieb:
>> Martin B. schrieb:
>>> Aber eigentlich sollte der XMEGA Preprocessor ja in double rechnen.
>>
>> Daumenregel: Zu 99.9% ist die Aussage falsch, dass der Präprozessor
>> irgendwas berechnet.
>
> Wenn es um Gleitkomma geht, ist die Aussage zu 100% falsch.

Mensch, wie kann ich das nur wieder gut machen? Hatte es schon 
zugegeben. Hoffentlich verzeiht ihr mir.

Der Praeprocessor ist unschuldig.

von Rolf M. (rmagnus)


Lesenswert?

Alles gut. Nimm's nicht so schwer, kann ja jedem mal passieren ;-)

von (prx) A. K. (prx)


Lesenswert?

Das ging nicht nur an Rolf. Der Thread selbst heisst so.

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.