amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > IEEE754 vs FFP [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

08.04.2003, 20:22 Uhr

Mad_Dog
Posts: 1944
Nutzer
Folgender Code:

code:
/* IEEE_Test
 * Autor: Norman Walter
 * Datum: 8.4.2003
 */

#include <stdio.h>
#include <exec/types.h>
#include <math.h>
#include <clib/mathtrans_protos.h>
#include <libraries/mathieeesp.h>

int readbit(int n,unsigned long w)
{
  return ( (w >> n) & 0x1 );
}

main()
{
  int i;
  float n = 123.0;          // Eine Beispiel Floating Point Zahl
  printf("IEEE_Test\n");
  printf("n=%X\n",n);
  
  // Alle Bits ausgeben
  for (i=0; i<32; i++)
  {
    printf("%d",readbit(i,(unsigned long)n));
  }
  
  printf("\n");
  
}


Nach IEEE754 Floating Point Standard müßte 123.0 float

0 10000101 11101100000000000000000

Sein: Vorzeichen: 0 = + ,
Charakteristik: 6+E0 = 6+127 = 133 = 10000101,
Mantisse: 11101100000000000000000 (1,111011 * 2^6).

Irgendwie wird aber was anderes ausgegeben :-(

Eventuell hab ich auch mal wieder nur n Brett vor dem Kopf?

Sind float Werte beim Amiga Standardmäßig im ieee 754 oder Motorola
FFP format gespeichert???


[ - Antworten - Zitieren - Direktlink - ]

08.04.2003, 21:00 Uhr

Georg
Posts: 107
Nutzer
> printf("%d",readbit(i,(unsigned long)n));

Hmm ... wenn ich mich nicht arg täusche konvertiert dieser
(unsigned long) cast hier die float variable nach integer,
und du bekommst dann die bits vom integer wert 123 angezeigt,
nicht vom float wert 123.

Versuch' mal:

printf("%d",readbit(i,*(unsigned long *)&n));

ciao

--
Georg

[ - Antworten - Zitieren - Direktlink - ]

08.04.2003, 21:35 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Georg:
> printf("%d",readbit(i,(unsigned long)n));

Hmm ... wenn ich mich nicht arg täusche konvertiert dieser
(unsigned long) cast hier die float variable nach integer,
und du bekommst dann die bits vom integer wert 123 angezeigt,


Ich will die Bits des Float-Wertes darstellen (siehe Schleife).
Leider stimmen die nicht mit der IEEE Float Darstellung überein :-(


[ - Antworten - Zitieren - Direktlink - ]

08.04.2003, 22:33 Uhr

thomas
Posts: 7716
Nutzer
Und genau das tust du nicht, mit "(unsigned long)n" bekommst du den nach Integer umgerechneten Wert der Fließkommazahl. d.h. im Falle von (float)123,456 bekommst du (int)123 in Binärdarstellung. Du mußt es so machen, wie Georg es schreibt, dann bekommst du die interne Bitdarstellung der Fließkommazahl.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ Dieser Beitrag wurde von thomas am 08.04.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

08.04.2003, 23:15 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von thomas:
Du mußt es so machen, wie Georg es schreibt, dann bekommst du die interne Bitdarstellung der Fließkommazahl.


Dann bekomme ich aber:

00101100 10011011 10010001 11100000

und das entspricht nicht der Darstellung von 123.0 nach IEEE754.




[ Dieser Beitrag wurde von Mad_Dog am 08.04.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

09.04.2003, 23:27 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Mad_Dog:
Sind float Werte beim Amiga Standardmäßig im ieee 754 oder Motorola
FFP format gespeichert???

Weder noch. Das verwendete Format ist Sache des Compilers und kann u.U. auch noch davon abhängen, ob mit FPU-Unterstützung übersetzt wird oder ohne.
Zum Konvertieren benutzt man deshalb Bibliotheksfunktionen, für die jeder Compiler eine angepaßte Version mitbringt.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

09.04.2003, 23:39 Uhr

Tessien
Posts: 55
Nutzer
Moinsen.

Ist die Bitdarstellung einer float-zahl wirklich compilierabhängig? Dann war es wohl Glückssache, daß ich beim Portieren von StormC/Amiga zu VisualC/Windows nur die Endiankorrektur vornehmen musste.

Ich denke eher, das Format ist überall das gleiche, nur halt nicht IEEE irgendwas. Es kann auf jeden Fall nicht Compilersache sein, daß der Prozessor es ja verstehen muss und die verschiedenen Compiler ja Programme für den selben Prozessor erzeugen.

Bye, Thomas
--
Thomas Schulze - programmer at Dreamworlds Development - http://www.dreamworlds.de

[ - Antworten - Zitieren - Direktlink - ]

11.04.2003, 00:06 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Tessien:
Ich denke eher, das Format ist überall das gleiche, nur halt nicht IEEE irgendwas. Es kann auf jeden Fall nicht Compilersache sein, daß der Prozessor es ja verstehen muss und die verschiedenen Compiler ja Programme für den selben Prozessor erzeugen.

Nein.
Der Compiler erzeugt den Code, den der Prozessor ausführen muß, dieser Code muß mit den vom Compiler verwendeten Datenformaten arbeiten, der Prozessor führt nur den Code aus.
Code, der für 68k-Prozessoren ohne FPU übersetzt wurde, läuft natürlich auch auf 68k-Prozessoren mit FPU. Er benutzt sie aber trotzdem nicht, deshalb wird er auch nicht das FPU-Datenformat benutzen, da es keine Vorteile bringt.
Deshalb kannst Du u.U. nicht einmal die Bibliotheken desselben Compilers miteinander verlinken, wenn sie mit unterschiedlichen Optionen übersetzt wurden.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

11.04.2003, 13:44 Uhr

Tessien
Posts: 55
Nutzer
Zitat:
Original von Holger:
Nein.
Der Compiler erzeugt den Code, den der Prozessor ausführen muß, dieser Code muß mit den vom Compiler verwendeten Datenformaten arbeiten, der Prozessor führt nur den Code aus.
Code, der für 68k-Prozessoren ohne FPU übersetzt wurde, läuft natürlich auch auf 68k-Prozessoren mit FPU. Er benutzt sie aber trotzdem nicht, deshalb wird er auch nicht das FPU-Datenformat benutzen, da es keine Vorteile bringt.
Deshalb kannst Du u.U. nicht einmal die Bibliotheken desselben Compilers miteinander verlinken, wenn sie mit unterschiedlichen Optionen übersetzt wurden.

Doch.

Zur Präzisierung: Wir gehen mal von normalen Prozessoren mit FPU aus und nicht von so asbach-alten Dingen wie dem 68k.

Wenn Du auf diesem System float-Variablen miteinander verrechnest, hat der Compiler grundsätzlich keinerlei Einfluss auf das Bit-Format dieser Variablen. Wenn man einer dieser Variablen aber einen direkten Wert zuweist (f = 2.0f), muss der Compiler sich an das Prozessor-vorgegebene Format halten. Ich sehe da keine Spielräume auf Compilerseite.

Deine Darstellung ist ebenfalls richtig, aber nur für FPU-lose Systeme, auf denen irgendwelche Mathebibliotheken die Funktion emulieren. Allerdings sehe ich selbst da keine Entscheidungsfreiheiten, da man Felder dieser Variablen auf Platte schreiben kann. Irgendjemand anderer, der die liest, muss sie ja auch verstehen können.

@Mad_Dog:

Zur Klärung: Hat Dein System eine FPU?

Bye, Thomas

--
Thomas Schulze - programmer at Dreamworlds Development - http://www.dreamworlds.de

[ - Antworten - Zitieren - Direktlink - ]

11.04.2003, 17:19 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
@Mad_Dog:

Zur Klärung: Hat Dein System eine FPU?


Yep. Ist ein A4000/030.

Habe mit den Compileroptionen (StormC 3.0) herumgespielt:
FPU-Code, Mathe Bibliotheken. Keine Änderung der Binärausgabe.

Das ieee754 Format ist übrigens auch im RKM dokumentiert, allerdings
mit einem Fehler: Die Charakteristik hat 8 Bit, und nicht 7 Bit.
Der einzige Unterschied zur x86 Binärdarstellung dürfte eigentlich nur
der sein, daß bei Motorola 68k Big Endian verwendet wird.

Aber da gibt es ja auch noch das Motorola FFP Format...



[ - Antworten - Zitieren - Direktlink - ]

12.04.2003, 17:52 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Tessien:
Wenn Du auf diesem System float-Variablen miteinander verrechnest, hat der Compiler grundsätzlich keinerlei Einfluss auf das Bit-Format dieser Variablen. Wenn man einer dieser Variablen aber einen direkten Wert zuweist (f = 2.0f), muss der Compiler sich an das Prozessor-vorgegebene Format halten. Ich sehe da keine Spielräume auf Compilerseite.


Also erst einmal ist der Speicher nicht die CPU.
Deshalb müssen wir uns klarmachen, daß es im Speicher IEEE-Formate, FPU-eigene Binärformate und dann noch single, double und extended Präzision gibt. In der FPU gibt es aber nur genau ein Format, in der 68881 und Nachfolger grundsätzlich rechnen. Deshalb muß der Compiler den notwendigen Code erzeugen, um den Transfer zwischen Speicherort und -format einer Variablen und dem FPU-Register durchzuführen.
Und das tut er auch. Aber nur, wenn tatsächlich ein solcher Transfer stattfindet, nicht für Zwischenergebnisse einer Operation. Deshalb produziert eine inline Konstruktion etwas anderes, als wenn mit Pointern auf Variablen gearbeitet wird. Ändert man das obenstehede Programm in
[code]
int i;
float n = 123.0; // Eine Beispiel Floating Point Zahl
int *ii=(int*)&n;
printf("IEEE_Test\n");
printf("n=%X\n",*ii);

// Alle Bits ausgeben
for (i=31; i>=0; i--)
{
printf("%d",readbit(i,*ii));
}

printf("\n");
[/quote]
kommt zumindest mit gcc auch IEEE raus. Aber nur dann.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.04.2003, 20:54 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Holger:

Also erst einmal ist der Speicher nicht die CPU.
Deshalb müssen wir uns klarmachen, daß es im Speicher IEEE-Formate, FPU-eigene Binärformate und dann noch single, double und extended Präzision gibt. In der FPU gibt es aber nur genau ein Format, in der 68881 und Nachfolger grundsätzlich rechnen. Deshalb muß der Compiler den notwendigen Code erzeugen, um den Transfer zwischen Speicherort und -format einer Variablen und dem FPU-Register durchzuführen.


Schon wieder was gelernt :-)
Habe gedacht, float und double Variablen wären automatisch im ieee754
Format (32bit für float, 64Bit für double) im Speicher, wenn man einer
Variablen nen Wert zuweist.

Zitat:
code:
int i;
  float n = 123.0;          // Eine Beispiel Floating Point Zahl
  int   *ii=(int*)&n;
  printf("IEEE_Test\n");
  printf("n=%X\n",*ii);
  
  // Alle Bits ausgeben
  for (i=31; i>=0; i--)
  {
    printf("%d",readbit(i,*ii));
  }
  
  printf("\n");


kommt zumindest mit gcc auch IEEE raus. Aber nur dann.


Danke!

Funktioniert übrigens mit StormC 3.0 genauso.




[ Dieser Beitrag wurde von Mad_Dog am 12.04.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > IEEE754 vs FFP [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.