Vorzeichenbehaftete Zahlen und Endianess

[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?

[Neutral General]

Es sei denn ich stehe jetzt auf dem Schlauch.. aber genauso wie alles andere? Ich sehe kein Grund warum Little Endian --> Big Endian Probleme mit Vorzeichen-Typen haben sollte.

[himitsu]

Wenn du im Delphi/Pascal/C++/... einen Cast machst, dann kümmert sich der Compiler darum.
Wie der Typ im Speicher liegt, kann dir hierbei vollkommen egal sein, außer du Pointerst wild rum und willst es selbst machen, dann mußt du es natürlich beachten.


Mathematisch auf Bitebene, da ist es für das Zweierkomplement recht einfach.
Ob die höheren Bits (MSB) bzw. niedrigeren Bits (LSB) oben oder unten, vorne oder hinten, links oder rechts stehen, ist mathematisch erstmal egal.

Klein auf Groß: man nehme das höchste Bit und koppiere dessen Inahalt in die/alle höheren "neuen" Bits.

Groß auf Klein: Man nehme alle hohen "alten" Bytes und schneide sie "blind" ab *hust*
oder man schaut erstmal ob die zu entfernenden Bits den gleichen Wert haben, wie das "neue" höchste Bit, und schneide dann ab ... sind die Unterschiedlich, dann gibt es einen Überlauf und man könnte einen Fehler werfen.


PS: Windows ist little-endian, also da hört ein Integer im Speicher mit dem größten Byte auf. :stupid:
Links klein und Rechts groß, so dass ein harter Cast von Integer LongInt auf SmallInt einfach die zwei höheren Bytes quasi "abschneidet".

[Benmik]

@Neutral General:Tja, du hast recht. Es geht um Folgendes:

Delphi-Quellcode:

  procedure Test;
  var ArrNum:array of Byte;
  begin
    ArrNum :=  [00,00,00,08];
    i := PInteger(@ArrNum[0])^;
  end;

Da kommt 134217728 heraus. Ich muss aber auf den Wert 8 kommen.
Ich habe eine Routine zum Umdrehen der Bytes eingesetzt, die ich aus einer umständlichen Vorlage kondensiert habe:

Delphi-Quellcode:

function  SwapArray(Arr:TBytes):TBytes;
var i,n:integer;
begin
  SetLength(Result,Length(Arr));
  n := Length(Arr) - 1;
  For i := 0 to n do
    Result[n - i] := Arr[i];
end;

Außerdem hatte ich folgenden Schnipsel:

Delphi-Quellcode:

function BigEndian2LittleEndian(aInt: integer): integer;
asm
  xchg ah, al;
  rol eax, 16;
  xchg ah, al;
end;

Warum das heute funktioniert und gestern Nacht nicht, ist vermutlich deinem Einfluss und dem der Sterne zu verdanken. Daneben hatte ich noch

Delphi-Quellcode:

Result:= Wert xor $80000000;

, das offenbar mit Integern nicht funktioniert.

Die ASM-Funktion wird vermutlich nicht mit Int64 funktionieren? (Bei meiner langen, unnötigen Suche kam ich auf das Stichwort "rax").

@Himitsu: Ja, mit genau solchen Dingen, die ich (noch) nicht so richtig kapiert habe, habe ich mich Stunden herumgeschlagen und offenbar den einfachen Weg übersehen. Möchte hinzufügen, dass ich die Byte-Repräsentation von SmallInt etc. natürlich verstehe; 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 und muss es auch nicht. Und dann habe ich noch von Feinheiten bis runter zur CPU gelesen - nee, das sollen die Profis unter sich ausmachen.

[himitsu]

Jo, standardmäßig geht es meistens so

Delphi-Quellcode:

function SwapArray(const Arr: TBytes): TBytes;  // CONST kann hier nicht schaden, weil den Input willst ja eh nicht verändern.

oder 

procedure SwapArray(var Arr: TBytes);

oder

procedure SwapArray(const InArr: TBytes; var OutArr: TBytes);  // oder OUT statt VAR

Zitat:

Zitat von Benmik (Beitrag 1470094)

Delphi-Quellcode:

  procedure Test;
  var ArrNum:array of Byte;
  begin
    ...
    i := PInteger(@ArrNum[0])^;
  end;

Sowas geht garnicht.
Wenn Pointer, dann solltest/mußt DU den Speicher reservieren und dort den Inhalt des Arrays reinkopieren.

Denn nach der Prozedur ist die Variable und damit auch das Array nicht mehr vorhanden (die letzte und einzige Referenz endet mit dieser Variable und Delphi gibt den Speicher frei)
und der Pointer zeigt ins Nirvana, egal ob man sich einen Zeiger auf die Variable oder auf die Arraydaten besorgt hatte.


Alle anderen Tricks mit Pointer und Manipulation der Referenzzählung, sollte man tunlichst vermeiden. (vor allem wenn man keine Ahnung von den Interna hat und selbst dann ist sowas selten eine gute Idee)

[Benmik]

Zitat:

Zitat von himitsu (Beitrag 1470100)

...dann solltest/mußt DU den Speicher reservieren und dort den Inhalt des Arrays reinkopieren.

Sekunde, der Speicher wurden doch mit

Delphi-Quellcode:

ArrNum := [00,00,00,08];

reserviert. Und dass die Variable mit der Prozedur ins Nirwana geht, ist doch OK; die Prozedur geht ja noch ewig weiter und am Ende wird die Variable nicht mehr gebraucht.

Deine Hinweise mit var, OUT etc. sind natürlich sehr gut; ich kenne das alles, bin aber oft zu faul/träge/gedankenlos/... . Bei

Delphi-Quellcode:

var

vergesse ich immer, wann nötig und wann nicht: Ist TBytes nicht ein Pointer und braucht kein

Delphi-Quellcode:

var

? Es gibt hier irgendwo eine Liste, die müsste ich mir mal an einen guten Ort kopieren.

EDIT: Jupp,

Delphi-Quellcode:

var

wäre nicht nötig, ist aber vielleicht gut zur Erinnerung. So besser?

Delphi-Quellcode:

procedure SwapArray(var Arr:TBytes);
var i,n:integer; TempArr:TBytes;
begin
  SetLength(TempArr,Length(Arr));
  Move(Arr[0],TempArr[0],Length(Arr));
  n := Length(TempArr) - 1;
  For i := 0 to n do
    Arr[n - i] := TempArr[i];
end;

[himitsu]

TBytes ist ein gemaagter Typ, und wenn du ohne VAR und OUT arbeitest, wird/kann es in einer Kopie des Arrays weitergearbeitet.

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.
Und ich hab schon immer gehofft das wird endlich mal repariert, nach über 20 Jahren. (dank der neuen ManagedRecords kann ich das nun aber selbst bugfixen)


Bei Klassen/Objekten stimmt deine Aussage dennoch.
Dort ist es ein ungemangter Typ (außer im NextGen ala Android und iOS), womit das VAR sich nur auf die Variable bezieht, aber nicht auf den Inahlt des Objekts.

[Uwe Raabe]

Nur falls das mal jemand brauchen könnte.

In System.Hash findet man auch THash.ToBigEndian für 32- und 64-Bit Variablen: System.Hash.THash.ToBigEndian

Für 16-Bit gibt es schon eine ganze Weile die procedure Swap: System.Swap

[himitsu]

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

Für mehrere 2-Bytes könnte man sogar TEncoding missbrauchen. (Unicode/UTF-16, LE und BE)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1470114)

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

Die Hilfe und auch das Beispiel sagen aber auch explizit, was damit passiert.

[himitsu]

Wer liest denn die Hilfe?

(außer sie heißt

Delphi-Quellcode:

dont read me.doc

)

[Benmik]

Zitat:

Zitat von himitsu (Beitrag 1470107)

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:

Zitat von himitsu (Beitrag 1470114)

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:

Zitat von Benmik (Beitrag 1470120)

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:

Zitat von Benmik (Beitrag 1470126)

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. :stupid:
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:

Zitat von Benmik (Beitrag 1470076)

Ü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 :mrgreen:
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