Vorzeichenbehaftete Zahlen und Endianess

[himitsu]

Wer liest denn die Hilfe?

(außer sie heißt dont read me.doc )

[Benmik]

Zitat von himitsu:

TBytes ist ein gemanagter Typ, und wenn du ohne VAR und OUT arbeitest, wird/kann mit einer Kopie des Arrays weitergearbeitet werden.

Hier hast nur den Vorteil, dass außer bei Strings das CopyOnWrite seit Jahrzehnten im Arsch ist, drum geht das "zufällig" auch ohne VAR, so lange man kein SetLength benutzt.

Ich finde es richtig schlimm, welche Tretminen sich immer wieder bei den scheinbar harmlosesten Sachen finden. OK, Delphi ist für Profis gemacht, aber ich bin sicher, dass ein Haufen Profis viele Tretminen nicht kennen.

Zitat von himitsu:

Swap ist aber auch echt böse, da das CodeInsight dort Integer als Parameter nennt.

Ich habe Swap immer für Word gebraucht, und dann die Hilfe gelesen. 2. und 3. Byte bei Integer? Wird seinen Grund haben, aber was zum Teufel bedeutet das in der Praxis? Das war der Punkt, an dem ich mich um eine hauseigene Lösung bemüht habe. Das geht mir öfter so.

[Uwe Raabe]

Zitat von Benmik:

Ich habe Swap immer für Word gebraucht, und dann die Hilfe gelesen. 2. und 3. Byte bei Integer? Wird seinen Grund haben, aber was zum Teufel bedeutet das in der Praxis?

Swap kommt ja noch aus der 16-Bit Welt, wo Integer eben nur 16-Bit hatten.

Das 2. und 3. Byte bezeichnen in diesem Zusammenhang aber eben die Lo-Bytes. Swap vertauscht in dem Integer die beiden niedrigen Bytes, als wäre es ein Word. Insofern ist das Verhalten schon konsistent. Die Nummerierung der Bytes bezieht sich offenbar auf das verlinkte Beispiel.

Delphi-Quellcode:

var
  X: Integer;
begin
  X := $A0B1C2D3;
  Assert(Swap(X) = $A0B1D3C2);
end;

[Benmik]

Aber das ist doch nicht das, was man will (und erwartet), wenn die vier Byte eines Integers vertauscht werden sollen?!

[Uwe Raabe]

Zitat von Benmik:

Aber das ist doch nicht das, was man will (und erwartet), wenn die vier Byte eines Integers vertauscht werden sollen?!

Das kommt auf die Erwartungshaltung an. Swap tauscht hat früher immer nur zwei Bytes getauscht und tut es auch jetzt noch. Bei vier Bytes ist es ja kein Swap mehr, sondern eine Umsortierung. Man muss das auch immer im Kontext des Hinweises betrachten, der in der Hilfe steht:

Zitat:

Hinweis: Die Prozedur dient lediglich der Abwärtskompatibilität.

[himitsu]

Zitat:

Abwärtskompatibilität.....

Jetzt könnte man sich natürlich fragen, warum es THash.ToBigEndian nicht als Word gibt.
und gerade in THash hätte ich nicht nach sowas gesucht ... eher in den Helpern der ordinalen Typen.


Jupp, wenn ich im CodeInsight das Integer sehe, denkt man zu schnell, dass das Delphi-Swap die Kapselung des Assembler-BSWAP ist und das dreht sowohl bei Word, also auch Integer alle Bytes um, jenachdem was man als Register reingibt. (z.B. AX oder EAX und vielleicht sogar auch RAX)

Aber gerade bei diesen beiden System-Units muß man immer doppelt hinsehn. Auch bei der Compiliermagic zeigt's CodeInsight dort hin, selbst wenn es garnicht dort liegt und da wird es noch schlimmer.

[Benmik]

Da finde ich gerade bei Stackoverflow Folgendes:

Delphi-Quellcode:

function ByteSwap64(Value: Int64): Int64;
asm
{$IF Defined(CPUX86)}
  mov    edx, [ebp+$08]
  mov    eax, [ebp+$0c]
  bswap  edx
  bswap  eax
{$ELSEIF Defined(CPUX64)}
  mov    rax, rcx
  bswap  rax
{$ELSE}
{$Message Fatal 'ByteSwap64 has not been implemented for this architecture.'}
{$ENDIF}
end;

von unserem Freund David Heffernan.
Tatsächlich "rax".

[jfheins]

Zitat von Benmik:

Über das Vertauschen von Bytes bei Little Endian <-> Big Endian findet man viel im Netz, auch hier wurde das Thema schon ausführlich diskutiert.

Wozu ich praktisch nichts gefunden habe, ist das Konvertieren bei Zahlen mit Vorzeichen, und insbesondere bei 64-Bit-Apps (da sind alle Assembler-Lösungen, die so gepostet werden, gleich vom Tisch).

Also - wie konvertiert man ShortInt, SmallInt, Integer, Int64, Single oder Double in einer 64-Bit-App?

Vielleicht hilft auch folgende Betrachtungsweise:
Endianess ist ja die Byte-Reihenfolge. D.h. gedanklich als ersten Schritt muss man die Bytes in die richtige Reihenfolge bringen.
Dann, als 2. Schritt weißt du wo das most significant bit ist und kannst (für einen Integer) das Vorzeichen ablesen.

Für die Endianess kannst du also vorzeichenbehaftete und unbehaftete Werte völlig gleich behandeln. Daher wirst du auch nur wenig Code extra für vorzeichen finden - schlicht weil das Vorzeichen (noch) keine Rolle spielt. Was wichtig ist: Wieviele bits hat der Wert.

Zitat:

aber wie z.B. die das machen, dass ein Integer genauso viele Werte aufnehmen kann wie ein Cardinal trotz des Vorzeichenbytes, das verstehe ich nicht so richtig

Große Überraschung: Es ist kein Vorzeichen-Byte und auch kein Vorzeichen-Bit
Bei einer 1-Byte Zahl hat das linke bit entweder einen Wert von 128 (ohne Vorzeichen) oder -128 (mit Vorzeichen)
Würde man sich tatsächlich nur auf das Vorzeichen beschränken, wäre ein signed byte auf +- 127 limitiert und könnte -128 nicht darstellen. Dafür hätte man eine +0 und eine -0.
Irgendwann früher mal hat wohl jemand zwei Nullen für überflüssig befunden und dem linken Bit dann diese Bedeutung zugewiesen.

[himitsu]

Jupp, mit einem Vorzeichenbit wäre es ein Wert weniger, da die 0 doppelt ist.

PS: Siehe Fließkommazahlen IEEE-754

https://de.wikipedia.org/wiki/Zweierkomplement
https://de.wikipedia.org/wiki/IEEE_754