Frage zu Win32

[pl]

hi,

eine Abfrage auf SYSTEM\CurrentControlSet\Control\TimeZoneInformation\Bias liefert mir 0xFFFFFFC4 wie ist das zu verstehen?

Bitte mal um Hinweises.

PS: 60 Sekunden sollen da rauskommen, also wie komme ich mit og. Bias auf 60 s?

[Rolf B]

Hallo pl,

guckst Du in regedit.exe nach. Da steht:

ActiveTimeBias REG_DWORD 0xffffffc4

Hausaufgabe: bestimme den int32-Wert dieses DWORD-Bitmusters.

Rolf

[Tabellenkalk]

Hallo,

PS: 60 Sekunden sollen da rauskommen, also wie komme ich mit og. Bias auf 60 s?

Passt 48+12?

Gruß
Kalk

[ursus contionabundo]

Als Idee:

( 0xFFFFFFFF - 0xFFFFFFC4 ) wäre, wenn ich mich nicht den Fingern verzählt habe, 59(dezimal).

[Rolf B]

Hallo ursus,

und du bist um 1 daneben, weil ... ?

Informatik 101

Rolf

[ursus contionabundo]

und du bist um 1 daneben, weil ... ?

Keine Ahnung, nicht mein Gebiet. Liegt es am Vorzeichen?

[Rolf B]

Hallo ursus,

ganz warm!

Rolf

[ursus contionabundo]

ganz warm!

Na, Rolf, dann verschaff mir (und PL gleich mit) doch eine Erkenntnis auf dem Gebiet.

[pl]

und du bist um 1 daneben, weil ... ?

Keine Ahnung, nicht mein Gebiet. Liegt es am Vorzeichen?

Ja. Zeitzonen Bias ist vorzeichenbehaftet. Also ich denke auch daß man da 1 + 0xFFFFFFFF - $value; rechnen sollte um auf die 60 zu kommen. Bzw. auf 120 wenn SZ.

MfG

use strict;
use warnings;
use Win32::Registry;

my $hand;
my $path = quotemeta('SYSTEM\CurrentControlSet\Control\TimeZoneInformation');
$::HKEY_LOCAL_MACHINE->Open($path, $hand) or die $^E;
my ($type, $value);
$hand->QueryValueEx("ActiveTimeBias", $type, $value) or die $^E;

print 1 + 0xFFFFFFFF - $value;

.test ok

[Rolf B]

Hallo pl,

1 + 0xFFFFFFFF - $value;

Ich würde sicherheitshalber 0xFFFFFFFF - $value + 1 rechnen, für den Fall, dass das System mit uint32 rechnet. Das Kommutativgesetz gilt nur in der reinen Mathematik, nicht unbedingt in der Computerarithmetik.

Und zur Theorie: eine negative Zahl wird im Zweierkomplement gespeichert, d.h. man flippt die Bits und addiert 1 dazu.

Bits flippen - ich mach's mal mit 16 Bit um kleinere Zahlen zu haben - ist das gleiche wie von 0xffff abziehen. "Bits flippen + 1" bedeutet demzufolge: Subtrahieren von 0x10000.

Macht man es nochmal, bekommt man 0x10000 - (0x10000 - x) = x - zweifaches Negieren gibt also korrekt wieder den Ausgangswert.

D.h. wenn ich 123 und -60 addieren will, dann ist a als 0x007b gespeichert und b als 0xffc4. Addiere ich das mit den Bordmitteln eines 16-Bit Prozessors, kommt 0x003f und ein gesetztes Carry-Flag heraus. Was korrekt +63 ist. Weil - ich addiere ja 123 + (0x10000 - 60), und 0x10000 ist für einen 16-bit Prozessor das gleiche wie 0 und ein Carry-Bit. Weil ich aber weiß, dass ich da signed-int Werte und keine int-Werte addiert habe, beachte ich das Carry-Flag nicht, sondern nehme statt dessen das Overflow-Flag, das nach anderen Regeln bestimmt wird. TL;DR-Version: Addiere ich zwei Zahlen mit gleichem Vorzeichen und das Ergebnis hat das entgegengesetzte Vorzeichen, liegt ein Overflow vor. Sonst nicht.

Update: Ich sehe gerade, dass Janosch dazu einen schönen Beitrag im Wiki verfasst hat.

Rolf

[pl]

Hi Rolf

1 + 0xFFFFFFFF - $value;

Ich würde sicherheitshalber 0xFFFFFFFF - $value + 1 rechnen, für den Fall, dass das System mit uint32 rechnet.

Ok, bisher bin ich bei Perl. Aber die Registry mit C auslesen kommt auch noch dran 😉

Das Kommutativgesetz gilt nur in der reinen Mathematik, nicht unbedingt in der Computerarithmetik.

Interessant [..]. Danke Dir!

[pl]

Moin,

1 + 0xFFFFFFFF - $value;

Ich würde sicherheitshalber 0xFFFFFFFF - $value + 1 rechnen, für den Fall, dass das System mit uint32 rechnet.

Der Datentyp ist DWORD (WinAPI). Auf meiner Kiste sicherlich ein 32 Bit Integer, aber schon hierzu gibt es widersprüchliche Informationen.

Legt der Typ die Länge auf 32 Bit fest oder ist die Länge dieses Typs von der Rechnerarchitektur abhängig?

Schön' Sontag.

[Rolf B]

Hallo pl,

DWORD ist in der Microsoft-Welt ein fester Begriff für 32 Bit und von der Architektur unabhängig.

Es ist ein Artefakt der 16-Bit Welt, wo ein WORD architekturkonform aus 16 Bit bestand. Dementsprechend sind 32 Bits ein D(ouble)WORD und 64 Bits ein Q(uadruple)WORD.

Rolf

[Matthias Apsel]

Hallo Rolf B,

DWORD ist in der Microsoft-Welt ein fester Begriff für 32 Bit und von der Architektur unabhängig.

Ich hätte es nicht auf die Microsoft-Welt beschränkt.

Es ist ein Artefakt der 16-Bit Welt, wo ein WORD architekturkonform aus 16 Bit bestand. Dementsprechend sind 32 Bits ein D(ouble)WORD und 64 Bits ein Q(uadruple)WORD.

So isses.

Bis demnächst
Matthias

[Rolf B]

Hallo Matthias,

Ich hätte es nicht auf die Microsoft-Welt beschränkt.

Sorry, ich kenne es nur von da.

In den 80ern habe ich auch IBM Großrechner Assembler gelernt, die damalige /360 (bzw. /370) Architektur, und die ist von Anfang an 32-bittig gewesen. Demzufolge war dort ein WORD 32-bit und für 16 Bits gab's das HALFWORD.

Auf meinem Amiga (Motorola 68000) war ein Wort aber ebenfalls 16 Bit (da gab's die .b, .w und .l Suffixe für entsprechende Angaben).

Rolf

[Matthias Apsel]

Hallo Rolf B,

Sorry, ich kenne es nur von da.

In Pascal war das auch so.

Bis demnächst
Matthias

[pl]

DWORD ist in der Microsoft-Welt ein fester Begriff für 32 Bit und von der Architektur unabhängig.

Danke Dir! Und offensichtlich signed. In meiner API Doku find' ich da nix.

MfG

[Rolf B]

Hallo pl,

Und offensichtlich signed

Nein. DWORD ist vorzeichenneutral, es sind einfach 32 Bit. Ob sie mit oder ohne Vorzeichen gedeutet werden, ist Sache des Benutzers. Der Timezone-Bias ist vorzeichenbehaftet und offenbar negativ wenn man östlich von Greenwich ist. Andere REG_DWORD Einträge sind Mengenangaben oder Bitmaps und damit vorzeichenlos.

Rolf

[pl]

Ok, ein kleiner Test

    DWORD b = -1;
    unsigned char *oct = (unsigned char*)&b;
    printf("%x %x %x %x", oct[0], oct[1], oct[2], oct[3] );

ff ff ff ff 

Mit b=1 zeigt sich ein LE 😉

[Rolf B]

Hallo pl,

das ist jetzt kein sonderlich guter Test. Habe gerade mal mit dem Online C Compiler bei Tutorialspoint getestet, da kann man unsigned int a = -1; problemlos zuweisen und findet dann 0xffffffff vor. Und int a = 0xc0000000; klappt auch. Offenbar prüft der nicht, ob er signed und unsigned mischt (da gibt's eine Option für damit er drüber mault, die wusste ich aber nicht mehr 😳)

Rolf

[pl]

hi

das ist jetzt kein sonderlich guter Test. Habe gerade mal mit dem Online C Compiler bei Tutorialspoint getestet, da kann man unsigned int a = -1; problemlos zuweisen und findet dann 0xffffffff vor.

Also dasselbe Ergebnis. uint32_t b = -1; geht problemlos mi MinGW gcc auf XP.

Mein Test sollte übrigens auch die Endiannes zeigen, mit b=1 tut er das.

MfG

[Robert B.]

Moin Rolf,

Ok, ein kleiner Test

DWORD b = -1;
unsigned char *oct = (unsigned char*)&b;
printf("%x %x %x %x", oct[0], oct[1], oct[2], oct[3] );

ff ff ff ff

das ist jetzt kein sonderlich guter Test.

Na doch, er will ja wissen, wie b intern dargestellt wird. Gut, man könnte auch anders tricksen, es läuft aber auf das Gleiche hinaus:

typedef union {
    DWORD dw;
    unsigned char b[sizeof(DWORD)];
} DWordBytes;

Habe gerade mal mit dem Online C Compiler bei Tutorialspoint getestet, da kann man unsigned int a = -1; problemlos zuweisen und findet dann 0xffffffff vor.

Das ist in C und C++ sogar ein gängiges Vorgehen um sehr einfach den maximalen Wert eines unsigned Datentyps zu bestimmen, z.B.

const size_t MaxSize = -1;

printf("%xz\n", MaxSize);
    /* gibt ffffffff bei 32 Bit aus, ffffffffffffffff bei 64 Bit */

Und int a = 0xc0000000; klappt auch. Offenbar prüft der nicht, ob er signed und unsigned mischt (da gibt's eine Option für damit er drüber mault, die wusste ich aber nicht mehr 😳)

Ja, wenn keine Prüfung eingeschaltet ist, wird einfach das gegebene Bitmuster anders interpretiert.

Viele Grüße
Robert

[pl]

moin,

Ok, ein kleiner Test

DWORD b = -1;
unsigned char *oct = (unsigned char*)&b;
printf("%x %x %x %x", oct[0], oct[1], oct[2], oct[3] );

ff ff ff ff

das ist jetzt kein sonderlich guter Test.

Na doch, er will ja wissen, wie b intern dargestellt wird.

Ja, und die Byteorder natürlich. Das alles wird ja erst interessant wenn Daten nach draußen gehen, also in Dateien, Sockets, stdout usw. Erst da spielt ja die ByteLength ein Rolle, wieviel Bytes hingegen im Speicher belegt werden ist heutzutage weniger interesant.

So dient die Typisierung hauptsächlich dazu, Daten portabel zu machen, das gilt für integer genauso wie für float Typen.

Also egal ob mit C eine FPNR in ein Socket geschrieben wird oder dieselbe floating Point Number mit Perl und pack()-Schablone f die Bytesequenz ist genau dieselbe.

Und was die Byteorder betrifft: Dafür gibt es eine Festlegung, nämlich die, daß der BigEndian die sog. Networkorder beschreibt. Net -- das ist das was uns verbindet.

MfG

[Rolf B]

Hallo pl,

Also egal ob mit C eine FPNR in ein Socket geschrieben wird oder dieselbe floating Point Number mit Perl und pack()-Schablone f die Bytesequenz ist genau dieselbe.

*seufz*

Nein. Die Bytesequenz einer Fließkommazahl hängt davon ab, welche technische Darstellung der Prozessor verwendet. Und ich meine jetzt nicht nur den Unterschied float/double oder LE/BE. Diese Probleme hast Du auch, aber es kommt noch was hinzu: IEEE 754 ist sehr häufig, aber nicht universell. Microsoft Binary dürfte obsolet sein (das wurde von MS BASIC verwendet), aber IBM HFP ist durchaus noch in Gebrauch.

Also: Überträgst Du Fließkommazahlen binär, kann die Übertragung zu unbekannten Geräten inkompatibel sein. Es gibt gute Gründe, weshalb die Internetstandards Zahlen in Textdarstellung übertragen.

Rolf

[pl]

hi,

Also egal ob mit C eine FPNR in ein Socket geschrieben wird oder dieselbe floating Point Number mit Perl und pack()-Schablone f die Bytesequenz ist genau dieselbe.

*seufz*

Nein. Die Bytesequenz einer Fließkommazahl hängt davon ab, welche technische Darstellung der Prozessor verwendet.

Nimm mal bitte den Code

    float f = 1.23;
    unsigned char *oct = (unsigned char*)&f;
    printf("%0.2f: %X %X %X %X\n", f, oct[0], oct[1], oct[2], oct[3] );

// 1.23: A4 70 9D 3F

und teste den auf verschiedenen Rechnerarchitekturen.

Ich nehme mal an, daß diese Maschine kein WinXP ist, aber das liefert immerhin dasselbe Ergebnis.

Ebenso hier.

Mag sein, daß Fließkommazahlen eine Sonderrolle spielen, aber ohne Typisierung der 1, 2 und 4 Byte Integer wäre keine Zeichenkodierung möglich und schon gar nicht portabel.

MfG

[ursus contionabundo]

teste den auf verschiedenen Rechnerarchitekturen

Ich kenne mich in Euren Sphären "nicht so detailliert" aus (weshalb ich keinerlei Ahnung habe, was bezweckt wird), habe aber das folgende mal getestet:

#include <stdio.h>
  
int main()
{
    float f = 1.23;
    unsigned char *oct = (unsigned char*)&f;
    printf("%0.2f: %X %X %X %X\n", f, oct[0], oct[1], oct[2], oct[3] );

    return 0;
}

gcc test.c && chmod 500 a.out && ./a.out && rm -f a.out;

Ergebnisse:

1. Linux (x86_64 x86_64 GNU/Linux):

1.23: A4 70 9D 3F

2. Linux (armv7l armv7l armv7l GNU/Linux):

1.23: A4 70 9D 3F

Das war auf echtem "Blech". Ich kann auch ein wenig Zeug emulieren...

[pl]

Na das ist doch mal ein Ergebnis!

Danke Dir!!!

Was bezweckt wird: Floating Point Typisierung als plattformübergreifend zu verstehen.

[pl]

Moin;

interessant wirds, wie schon gesagt, beim Transport:

    uint32_t v = 1146244951;
    float    f = 841.239685058594;
    fwrite( (char*)&v, sizeof v, 1, stdout); // WORD
    fwrite( (char*)&f, sizeof f, 1, stdout); // WORD

also wenn Zahlen den Hauptspeicher verlassen in Richtung Dateien, Sockets, stdout, USB.. Entscheidend ist, daß die Sequenzen stets dieselben sind insbesondere die byteLength. Dann sind die Daten portable und plattformübergreifend wiederherstellbar (maschinenlesbar).

Gleichermaßen wird auch der Transportlayer transparent. Auch in Sachen Strings gibt es Möglichkeiten, z.B. ein Auffüllen (padding) mit Nullbytes womit diese Strings auch gleich terminiert sind. Oder, bei variabler Länge, die byteLength eines Strings wird vor dem String mit 1, 2, oder 4 Bytes kodiert. Also wenn diese 4 Bytes WORD lauten heißt das, daß für den sich daran anschließenden String genau 1146244951 Bytes zu lesen sind.

byteLength+String sind ein sog. Tupel.

MfG

[Rolf B]

Hallo pl,

interessant wirds, wie schon gesagt, beim Transport:

In der Tat, vor allem deshalb, weil für die float-Typen das gleiche gilt wie für die int-Typen. Der C Standard garantiert Dir sizeof(float) <= sizeof(double) <= sizeof(long double), aber niemand garantiert ein „echt kleiner“ oder „sizeof(float) == 32“.

Binärübertragung ist riskant. Der Programmcode wird einfacher - aber nur so lange, wie Du die verwendeten Maschinen genau kennst. So, wie Du es programmiert hast, ist es nicht portabel und funktioniert nur auf Maschinen mit einer bestimmten Architektur. Das sind sehr viele Maschinen, aber längst nicht alle. D.h. dein Programm sollte in der Startup-Phase zumindest eine Assert-Folge enthalten, die deine Architekturannahmen (wie sizeof(float)==32 oder bestimmte Endianness) überprüft und das Programm abbricht, wenn sie nicht erfüllt sind.

Rolf

[pl]

Hi Rolf,

deswegen gibt es ja die Networkorder! Und guck Dir mal das DNS Protokoll an, da werden die Zahlen binär übertragen. Ohne DNS kein Internet.

Und ja, das Net Time Protocol. Der Zeitserver vom Physikalisch Technischen Institut Braunschweig liefert ganze 4 Bytes für aktuelle Uhrzeit samt Datum! Das ist ein 32 Bit Integer mit der Anzahl der Sekunden sein 1.1.1900. In Networkorder, als Big Endian.

Und Transparenz: Wieviele Meter Glasfaser, Kupfer, Funkstrecken, Switches, Router zwischen dem Zeitserver und einem PC stehen, ist für das NTP völlig nebensächlich.

MfG

[ursus contionabundo]

Der Zeitserver vom Physikalisch Technischen Institut Braunschweig liefert ganze 4 Bytes für aktuelle Uhrzeit samt Datum!

Bist Du Dir da ganz sicher?

Die Zeitstempel im NTP sind 64 Bits lang. 32 Bits kodieren die Sekunden seit dem 1. Januar 1900 00:00:00 Uhr, weitere 32 Bits den Sekundenbruchteil. Auf diese Weise lässt sich ein Zeitraum von 2^32 Sekunden (etwa 136 Jahre) mit einer Auflösung von 2^−32 Sekunden (etwa 0,23 Nanosekunden) darstellen.

Quelle: Wikipedia NTP

Und Transparenz: Wieviele Meter Glasfaser, Kupfer, Funkstrecken, Switches, Router zwischen dem Zeitserver und einem PC stehen, ist für das NTP völlig nebensächlich.

"völlig nebensächlich"? Da brauchst Du aber rockstabile "Roundtrips" (von ntpstat als "delays" angezeigt). Sonst geht das für DSL-Kunden, WLAN-Teilnehmern mit laufendem Moped vor der Tür, Teilnehmern in Glasfasernetzen mit Gateway von und zu Kupfer oder auch nur gut belasteten Routern oder bei dynamischen Routing über unterschiedliche Strecken im Bereich von Dezisekunden "in die Hose". Nicht nur bei wissenschaftlichen Experimenten mit weit entfernten Orten (z.B. der Suche nach Schwerkraftwellen, geologischen Untersuchungen mittels "Schallwellen") sondern auch im Aktienhandel kann ein Glaube an Genauigkeit im Nanosekunden-Bereich durchaus zu einem Problem werden.

[pl]

Der Zeitserver vom Physikalisch Technischen Institut Braunschweig liefert ganze 4 Bytes für aktuelle Uhrzeit samt Datum!

Bist Du Dir da ganz sicher?

Ja sicher doch, auf Port 37 kommen 4 Bytes. Kannst mit telnet abrufen.

Die Zeitstempel im NTP sind 64 Bits lang. 32 Bits kodieren die Sekunden seit dem 1. Januar 1900 00:00:00 Uhr,

Genau da haben wir das doch worum es geht! 32 Bit sind genau 4 Bytes!

Und was die Typisierung betrifft, solange wir uns im Hauptspeicher bewegen: In C haben wir die Speicheradresse und der Type legt fest, wieviele Bytes da zu lesen sind.

MfG

[ursus contionabundo]

[PL] Und ja, das Net Time Protocol. Der Zeitserver vom Physikalisch Technischen Institut Braunschweig liefert ganze 4 Bytes für aktuelle Uhrzeit samt Datum!

[UC] Bist Du Dir da ganz sicher?

[PL] Ja sicher doch, auf Port 37 kommen 4 Bytes. Kannst mit telnet abrufen.

Du verwechselst da was: "Net Time Protocol" (a.k.a. "NTP") und "Port 37" passen nämlich nicht zusammen!

Das Time-Protokoll, gemäß RFC 868, dessen Server an Port 37 listet, und Network Time Protocol, gemäß RFC 958, dessen Server an Port 123 listet, sind zwar beides sozusagen "Schuhe". Aber das eine (TIME) ist quasi eine "Sandale" und das andere (NTP) im Vergleich eher ein "Stiefel".

Es bleibt bei meiner Aussage:

[UC] Die Zeitstempel im NTP sind 64 Bits lang.

Besagte 64 Bit sind 8 Byte.

[pl]

Es bleibt bei meiner Aussage:

Die Zeitstempel im NTP sind 64 Bits lang.

Logisch, wenn 32 Bit 4 Bytes sind, sind 64 Bit 8 Bytes. Wer hätt's gedacht 😉

MfG

[pl]

Hier mal was Praktisches:

Aktuelle Zeit vom Zeitserver

my $sh = IO::Socket::INET->new( "ptbtime2.ptb.de:37" ) or die $@;

erstellt das Socket auf Port 37. Dasselbe funktioniert plattformunabhängig mit jeder Programmiersprache. Für die aktuelle Zeit, also die seit 1.1.1900 abgelaufenen Sekunden, werden genau 4 Bytes aus dem Socket gelesen.

MfG

[pl]

Etwas weniger pragmatisch: Datum und Uhrzeit in dezimaler Darstellung. Da kann man ungefähr abschätzen wann mit 0xFFFFffff das Maß voll ist 😉

[ursus contionabundo]

Etwas weniger pragmatisch: Datum und Uhrzeit in dezimaler Darstellung. Da kann man ungefähr abschätzen wann mit 0xFFFFffff das Maß voll ist 😉

Wieso "abschätzen"? Bei beiden Protokollen (TIME, NTP) ist klar, dass es zu einem "Jahr 2036"-Problem kommen kann.

Exakt am 7. Februar 2036.

Programme, die TIME nutzen, sollen die tatsächliche Zeitangabe aus dem übermittelten Wert vorsichtig anhand "contextabhängiger Informationen" berechnen. Hoffen wir, dass die "contextabhängigen Informationen" nicht auch als Integer in Sekunden seit dem 1.1.1900 00:00:00 gespeichert wurden...

[pl]

Warum sollte es ein Problem geben? Wenn auf einer 32-Bit-Macheta 0xFFFFffff erreicht wurde, geht die Zählung einfach bei 0x1 wieder los.

Der Vollständigkeit halber: Was wir die Tage in Perl und in C taten geht natürlich auch mit JavaScript:

var buffer = new ArrayBuffer(4);
var dv = new DataView(buffer);
var seconds = '%seconds%'; // Initial beim Laden der Seite

function uhr(){
    seconds++;
    dv.setUint32(0, seconds);
    $('#a').text(dv.getUint8(0));
    $('#b').text(dv.getUint8(1));
    $('#c').text(dv.getUint8(2));
    $('#d').text(dv.getUint8(3));
}

// Uhr zum Ticken anregen
window.setInterval(uhr, 1000);

Also die in einem 32-Bit-Integer enthaltenen Oktetten dezimal darstellen. Damit läuft die Uhr 😉 MfG

[Robert B.]

Hallo Rolf,

Nein. Die Bytesequenz einer Fließkommazahl hängt davon ab, welche technische Darstellung der Prozessor verwendet.

Wobei für C++ IEEE-754 definiert ist.

Viele Grüße
Robert

[Rolf B]

Hallo Robert,

nein, ist es nicht. Da steht "Usually", nicht "Mandatory". Ich bezweifle, dass die C++ Runtime auf einem IBM Großrechner auf das native Fließkommaformat des System-Z Prozessors verzichtet und IEEE 754 in Saftware emuliert. Was man davon hat, sah man damals bei Microsoft Binary.

Rolf

[Robert B.]

Hallo Rolf,

nein, ist es nicht. Da steht "Usually", nicht "Mandatory".

das steht im Fließtext. In der folgenden Tabelle ist es die einzige Angabe zum Format.

Ich bezweifle, dass die C++ Runtime auf einem IBM Großrechner auf das native Fließkommaformat des System-Z Prozessors verzichtet und IEEE 754 in Saftware emuliert. Was man davon hat, sah man damals bei Microsoft Binary.

Woher bekommen wir so einen Rechner zum Ausprobieren?

Viele Grüße
Robert

[pl]

Woher bekommen wir so einen Rechner zum Ausprobieren?

Warum ausprobieren? Den Algorithmus eins IBM Großrechners kann man doch auch auf einem Blatt Papier nahvollziehen um zu prüfen, welche Bytes sich aus einer fpnr 1.23 ergeben.

Zumindest wenn man den Algorithmus verstanden hat 😉

PS: Wir können auch eine andere Zahl nehmen mit der es sich evntl besser rechnen läst.

[Robert B.]

Hallo pl,

Woher bekommen wir so einen Rechner zum Ausprobieren?

Warum ausprobieren? Den Algorithmus eins IBM Großrechners kann man doch auch auf einem Blatt Papier nahvollziehen um zu prüfen, welche Bytes sich aus einer fpnr 1.23 ergeben.

Steht auf deinem Blatt Papier auch, wie die C-oder C++-Runtime dort mit Floating-Zahlen umgeht?

Viele Grüße
Robert

[pl]

Klar, wenn Du das hier ausdruckst, kriegst Du das auch in Papierform.

Also zum Nachvollziehen der Algorithmen, wie Zahlen auf Bytes abgebildet werden.

MfG

[Rolf B]

Hallo pl und Robert,

Beispiele für IBM HFP stehen im verlinkten Wikipedia-Artikel.

Den Computer zum Ausprobieren hätte ich vor mir stehen (ok, die Terminal-Emulation dafür), wenn ich denn nach der Überstellung unseres Hosts an die Konzern-EDV noch wüsste, wie man mit dem Toolstack da ein Bastelprogrämmchen schreibt das nicht gleich in die Produktionshistorie geht.

Vor 2005, auf dem alten Host, hätte ich das noch hinbekommen... Aber hier macht eh keiner z/OS C. Da hängt überall noch ein obol dran.

Rolf

[pl]

PS: Es ist schon übel daß die Entwicklung mancher internationaler Standards Jahrzehnte braucht! So ist es auch nicht weiter verwunderlich, daß USB-Geräte bis heute keine Fließkommazahlen kennen!

MfG

[ursus contionabundo]

So ist es auch nicht weiter verwunderlich, daß USB-Geräte bis heute keine Fließkommazahlen kennen!

Wieso in aller Welt sollten die "USB-Geräte" DAS können?

Um dem Host die Vendor-Id und die Produkt-Id (etwas wie '174c:55aa') mitzuteilen und danach ein anderes Protokoll zu stapeln reicht der primitive, weil für Pfennig-Hardware in Mäusen, PS2 / RS-232-Adaptern und analogen Modems vorgesehene "Transportmechanismus"... Das gilt auch für Speichersticks: Speicher-Adressen sind "nur ganz selten" Fließkommazahlen, die Daten, die dann durchgehen, "blobs".

[pl]

So ist es auch nicht weiter verwunderlich, daß USB-Geräte bis heute keine Fließkommazahlen kennen!

Wieso in aller Welt sollten die "USB-Geräte" DAS können?

Um beispielsweise eine Temperaturangabe 20.3°C als Bytesequenz auf den Bus zu schieben.

Um dem Host die Vendor-Id und die Produkt-Id (etwas wie '174c:55aa') mitzuteilen

VID und PID sind feste Bytesequenzen. Aber der Informationsfluß läuft andersherum, es ist ja nicht so, daß sich die Geräte selbst mitteilen, das sieht nur so aus. Wenn Du ein bestimmtes USB Gerät ansprechen willst, musst Du den ganzen Bus nach VID und PID scannen. Und dann kann es sein, daß unter einer VID:PID gleich mehrere Geräte stecken.

Kannst ja hier mal reingucken wie ich das gemacht habe. Ansonsten wäre es übrhaupt kein Problem, eine Temperaturangane wie 20.4°C auf 4 Bytes zu legen, da gibt es Algorithmen die Geräte am COM-Port schon seit Urzeiten nutzen.

Guggst Du UART floating Point, MfG

[klawischnigg]

Hi there,

So ist es auch nicht weiter verwunderlich, daß USB-Geräte bis heute keine Fließkommazahlen kennen!

Wieso in aller Welt sollten die "USB-Geräte" DAS können?

Um beispielsweise eine Temperaturangabe 20.3°C als Bytesequenz auf den Bus zu schieben.

Dazu braucht man Fliesskommazahlen? Echt jetzt?

[pl]

Es geht um den Transport! Das B in USB steht für Bus!

[klawischnigg]

Es geht um den Transport! Das B in USB steht für Bus!

Ich versteh's trotzdem nicht. Was ist das für ein Aufwand, eine möglicherweise aus einer Messung oder sonstwoher gewonnene Zahl vor dem Transport umzuwandeln? Oder, andersrum: Was mit einem Bus transportiert wird, geht den Bus in Wahrheit genau gar nichts an. Dafür wiederum steht das "U" in USB…

[pl]

Es geht um den Transport! Das B in USB steht für Bus!

Ich versteh's trotzdem nicht. Was ist das für ein Aufwand, eine möglicherweise aus einer Messung oder sonstwoher gewonnene Zahl vor dem Transport umzuwandeln?

Damit sie transportiert werden kann.

Oder, andersrum: Was mit einem Bus transportiert wird, geht den Bus in Wahrheit genau gar nichts an. Dafür wiederum steht das "U" in USB…

So isses. Transportiert werden Bytes. Genauso wie in Dateien Bytes gespeichert werden. Nun ist es aber so, daß man auf dem Bus wissen muss wieviele Bytes da zu lesen sind. Genau dafür gibt es Algorithmen für Fließkommazahlen. Also egal, ob der Sensor 128.75°C oder -5.1°C ermittelt, das sind immer genau 4 Bytes, egal ob mit oder ohne Vorzeichen.

MfG

[Robert B.]

Moin pl,

Transportiert werden Bytes. Genauso wie in Dateien Bytes gespeichert werden. Nun ist es aber so, daß man auf dem Bus wissen muss wieviele Bytes da zu lesen sind. Genau dafür gibt es Algorithmen für Fließkommazahlen. Also egal, ob der Sensor 128.75°C oder -5.1°C ermittelt, das sind immer genau 4 Bytes, egal ob mit oder ohne Vorzeichen.

Wenn du die üblichen Floating-Point-Darstellungen verwendest, hast du zwar immer genau vier Bytes, aber bestimmte Floating-Point-Werte nie genau.

Viele Grüße
Robert

[Rolf B]

Hallo Leute,

lasst euch doch nicht trollen. PL lacht sich schief. Ob USB kein Float kann, ist genauso wichtig und richtig wie die Unfähigkeit der Apollo-11 Rakete, Hunde zu transportieren.

Die entscheidende Aussage ist: U steht für Universal und der Content, der mit diesem Bus fährt, ist dem Bus komplett egal. Er ist diskrimierungsfrei. Wenn eine Application also eine Bytesequenz über den Bus schieben will, die einer IEEE 754 Float Sequenz entspricht, kann sie das tun (genauso wie Niel Armstrong rein theoretisch seinen Bello hätte einladen können).

Wenn das nicht passiert - tja - dann wird's wohl Gründe geben. Z.B. dass Armstrong gar keinen Hund besaß (oder nichts davon bekannt ist). Das big/little endian Problem, Prozessörchen im Host Gerät die keine Float-Instruktionen haben, oder das kleine Detail der IEEE 754 Rundung (20.3 = 203/10 != 20.299999237060546875 (der Approximationswert der mit IEEE 754 erreichbaren Annäherung 0x41a26666 - Quelle)

Aber USB ist's nicht schuld.

Rolf

[pl]

Hallo Leute,

Die entscheidende Aussage ist: U steht für Universal und der Content, der mit diesem Bus fährt, ist dem Bus komplett egal.

So isses. Genauso wie es einer Datei egal ist, was die Bytes die sie transportiert darstellen sollen. Der Fachbegriff der diesen Sachverhalt beschreibt, heißt Transparenz. Und selbstverständlich ist auch USB transparent für die Geräte die Anwendungen mit Daten versorgen.

Das Bytegeschnatter was PCAPUSB (eine Wireshark Erweiterung für USB) da sichtbar macht interessiert allenfalls den Programmierer der dafür sorgt, das seine API den Layer transparent macht.

MfG

[pl]

hi

Transportiert werden Bytes. Genauso wie in Dateien Bytes gespeichert werden. Nun ist es aber so, daß man auf dem Bus wissen muss wieviele Bytes da zu lesen sind. Genau dafür gibt es Algorithmen für Fließkommazahlen. Also egal, ob der Sensor 128.75°C oder -5.1°C ermittelt, das sind immer genau 4 Bytes, egal ob mit oder ohne Vorzeichen.

Wenn du die üblichen Floating-Point-Darstellungen verwendest, hast du zwar immer genau vier Bytes, aber bestimmte Floating-Point-Werte nie genau.

Die Genauigkeit ist eine Frage des Algorithmus und damit natürlich auch die Frage wieviele Bytes sich daraus ergeben und bei der Wiederherstellung zu lesen sind. MfG

[Matthias Apsel]

Hallo Rolf B, @PL

Nein. DWORD ist vorzeichenneutral, es sind einfach 32 Bit.

Das war teilweise auch schon bei Herrn Wirth so:

|Type | Range | Bytes |----| | Byte | 0 .. 255 | 1 | Shortint | -128 .. 127 | 1 | Smallint | -32768 .. 32767 | 2 | Word | 0 .. 65535 | 2 | Integer | smallint or longint | 2 or 4 | Cardinal | longword | 4 | Longint | -2147483648 .. 2147483647 | 4 | Longword| 0..4294967295 | 4 | Int64 | -9223372036854775808 .. 9223372036854775807 | 8 | QWord | 0 .. 18446744073709551615 | 8

http://wiki.freepascal.org/Variables_and_Data_Types

Bis demnächst
Matthias