Im letzten Beitrag haben wir uns mit dem MSB bzw wertniedrigsten Bit beschäftigt, hier soll es um seinen Konterpart, das LSB oder werthöchste Bit gehen. Je nachdem ob wir einen Typ mit oder ohne Vorzeichen verwenden zeigt uns dieses Bit das Vorzeichen an bzw teilt uns mit das der Wert sehr gross, in Bezug zum Datentyp, ist.

Vorüberlegungen

Im Gegensatz zum letzten Artikel ergibt sich ein Problem: Durch die verschiedenen Bitbreiten der Typen liegt das interessante Bit immer woanders:

Angestrebt ist eine Lösung die für alle Datentypen gleichermassen funktioniert. Wie wir aus dem vorherigen Beitrag wissen, können wir mit der bitweisen Und-Verknüpfung prüfen, ob ein spezifisches Bit gesetzt ist oder eben nicht. Nachteilig auf den ersten Blick, wirken die variablen Positionen unseres Zielbits. Ein Wert muss sich zum anderen hin bewegen, dafür gibt gibt es die sogenannten Shift-Operatoren << und >>, welchen den linken Operanden um die rechts gegebene Anzahl Bits in Richtung der Pfeilspitzen verschieben. Die Wirkung hängt in der ersten Linie davon ab, wie stark die verwendete Sprache von der Hardware abstrahiert, dazu an andere Stelle mehr. Das Referenzhandbuch für D¹ cmacht keine Angaben dazu wie sich die Shiftoperatoren verhalte, das obliegt wohl dem verwendeten Compiler.

Um es kurz zu halten, eine Variable zu sparen und den finalen Ausdruck im return-Statement nicht zu zu sehr in die Länge zu ziehe, werden wir im Folgenden useren Prüfling nach rechts schieben, bis das original LSB an der Position 0 steht und wir wie gewohnt das MSB checken können.

Implementierung

Was wollen wir erhalten?

Zuerst wieder die Frage nach den gewünschten Resultaten. Es soll ein boolzurückgegeben werden, welches mitteilt ob das LSB gesetzt ist, da wir die komplette Pallete an Integertypen abdecken wollen, ist das Template das Mittel der wahl, mehr dazu in Kürze:

unittest
{
	import std.stdio: writeln, write;
	writeln("Testing lsbtest:");
	write("byte:  14 (expecting: false): ");
	assert(false == LSBset!(byte).check(14));
	write("passed\n ubyte: 254 (expexting: true): ");
	assert(true == LSBset!(ubyte).check(254));
	write("passed\n int: -2 (expected: true): ");
	assert(true == LSBset!(int).check(-2));
	write("passed\n long: 2000000 (expected: false): ");
	assert(false == LSBset!(long).check(200000));
	writeln("passed");
	writeln("All tests (4) passed."); 
}

Das Template

Die angestrebte generische Lösungsvariante wird in D durch Templates² realisiert. Grob gesagt handelt es dabei um Container für Funktionen und Variablen, die eine spezielle Syntax für Platzhalter zulassen, wo normalerweise ein wohldefinierter Typbezeicher stünde. Sollen jetzt Routinen mit einer Gruppe verwandter Datentypen, also solchen mit identischen Eigenschaften, arbeiten – wie hier mit Ganzzahltypen –, müssen wir jene nur schblonieren und, wie in den Unittests gezeigt, entsprechend initialiesieren. Im Falle unserer Überlegungen sähe, dass dann exemplarisch so aus:

template LSBset(T)
{
	bool check(T candidate)
	{
		candidate = candidate >> ((T.sizeof*8) -1);
		return (1 == (candidate & 1));
	} 
}
// es folgen obenstehende Tests

Wie der Dokumentation zu entnehmen ist gibt es in D zwei Varianten Bits nach rechts (kleiner werdende Richtung) zu schieben. a) unter Beibehaltung des Vorzeichens (>>) b) ohne Beachtung des Vorzeichens (>>>)

Da alle Ganzzahltypen unterstützt werden sollen, bleibt uns nur ersterer, ansonsten ernten wir Fehler während der Übersetzung. Gründe hierfür sind nicht unterstützte implizite Typumwandlungen (soganannte Casts) von Vorzeichen behafteten Typen (byte und int) in vorzeichenlose Typen.

Ebenfalls als neues Syntaxelement shen wir die Eigenschaft³ sizeof, die jedem Datentyp – damit auch jeder Variablen – begegeben ist Anzahl der belegten Bytes liefert. Um die Grösse in Bit zu erhalten, multiplizieren wir mit acht. Damit das zu prüfende Bit nicht aus dem Speicher hinausgeschoben wird, subtrahieren wir eins, weil n — 1 Shiftings das LSB auf die Position des MSB bringen.

Zum Abschluss noch der MSB-Test, wie wir ihn bereits kennen.

Weiter oben sprach ich von kryptischen Ausdrücken, welche entstehen können, wenn man bestrebt alles in kompaktester Weise zu notieren. Als Beispiel bringe ich obige Variante als Einzeiler, die beim Debuggen keine Freude macht, wenn der compiler einen Fehler wirft:

	return (1  ==((candidate >> ((candidate.sizeof*8) -1)) & 1));

Fazit

Templating in der hier gezeigten Form ist sehr elegant, da man keine komplette Klasse konstruieren muss um generischen Code zu bauen, hier der funktional Identische Code in Pascal

{$mode objfpc}
program lsbset;
type
	generic TLsbSet<_T> = class(TObject)
	public
		function check(candidate : _T) : boolean;
	end;
	
	TIsIntegerNegative = specialize TLsbSet<integer>;
	
	
	function TLsbSet.check(candidate: _T) : boolean;
	begin
		{$ifdef ENDIAN_LITTLE}
			candidate := candidate shr ((sizeOf(candidate)*8)-1);
		{$else}
			candidate: = candidate shl ((sizeOf(candidate)*8)-1);
		{$endif}
		check := (1 = candidate and 1);
	end;

	
var
	negint : TIsIntegerNegative;
	
Begin
	
		negint := TIsIntegerNegative.create;
		
		writeln('Is -12 negative: ', negint.check(-12));
		writeln('Is 1024 negative: ', negint.check(1024));

End.

Zieht man das Hauptprogramm ab, weil ich in D den vom DMD bereitgestellten Default-Stub (Schalter -main) für den Testrunner nutze, erkennt der/die geneigte Lesende sehr deutlich den Code-Überhang, der durch das Definieren und Implemtieren der Klasse entsteht. Zusätzlich sieht man, dass der Code Rücksicht auf die Endianess der Zielarchitektur nemen muss, da auf Big-Endian-Systemen nach links zu schieben ist, D abstrahiert diesen Schritt für den Programmierer dankenswerter Weise.

Kehrseite der Medalie ist allerdings, dass man in D nicht auf triviale Weise in die oberen 32 Bit eines long-Wertes hineinschieben kann, da es bei Linksshifts eine Beschränkung auf höchstens 31 Schritte gibt. Das MSB zu setzen geht dann zwar, aber man kommt mit seiner 1 dann nicht auf konsitente Art zu Bit 63. Dies ist auch einer der Gründe, warum ich diese Variante hier nicht vorgestellt habe.

Referenzen

Wenn man von einer anderen Programmiersorache kommt – in meinem Fall Pascal — und sich an neue heran wagt, sucht man seine vertrauten Helfelein.

Ich hantiere gerne mit Ganzzahlen, um Beispielsweise Primzahllisten zu ereugen. Eine Hauptfrage die sich in diesem Kontext stellt, ist ob ein Kandidat gerade oder ungerade ist. In Pascal greift der findige Programmierer zum Funktion odd() aus der Unit System, welche die gewünschte Information in eine boolean-Wertes liefert. Die Sprache D kennt eine solche Hilfsroutine out of the Box nicht, zumindest hab ich die in der Standardbibliothek bislang nicht gefunden. Als kleine Fingerübung implentieren wir ein solche im Nachgang.

Vorüberlegungen

Es gibt zwei Herangehensweisen an dieses Thema: a) eine arithmetische, über den Modulo-Operator a%b b) eine logische über bitweise Verknüpfungen.

Variante a) ist aus meiner Sicht langweilig, weil zu oft verwendet. Da die gängigen Prozessoren der x86/x64 keine Assembler-Instruktion für die Modulo-Rechnung haben, ist diese Variante von den Laufzeitkosten her recht teuer, da sie aus mehreren Opcodes zusammengebaut werden muss. Bei Variante b) ist nur zu Prüfen ob im Kandidaten das wertniederste Bit – engl. most significant bit (MSB) – gesetzt ist, da dieses den Wert 1 repräsentiert. Dankenswerter Weise müssen wir hier keine besondere Rücksich auf die Speicherrepräsentation des Kandidaten nehmen. Der größte Vorteil liegt in der Tatsache, dass alle moderenen Prozessorfamilien bitweise Logikoperatoren in ihren Assemblern haben und in diesen sehr effizient sind.

Implementierung

Was wollen wir erhalten?

Die Sprache D hat ein interessantes Feature, eingebaute Unittests¹, deshalb überlegen wir zuerst welche Ergebnisse wir erhalten wollen. Die Funktion soll ein bool liefern, derart dass sie true zurückgibt, wenn die Zahl ungerade ist, ansonsten false, die Tests sehen dann zum Beispiel so aus:

unittest
{
  import std.stdio: write, writeln;
  writeln("testing odd()");
  write("testing with even argument (expecting: false): ");
  assert(false == odd(4));
  write("pass\ntesting with odd value (expecting: true): ");
  assert(true == odd(3));
  writeln("pass\n odd() passed all tests (2)!");
}

Die Funktion

Die von mir bevorzugte Variante ist b). Da geprüft werden soll ob ein spezifisches Bit gesetzt ist, wählen wir die und-Verknüpfung, da diese folgende Eigenschaften hat:

Da wir keine Zwischenschritte haben können wir die Rechnung direkt in der return-Anweisung vornehemen, womit der Quelcode dann folgende Form annimmt:

@safe @nogc nothrow pure
bool odd(immutable ulong n)
{
  return (1 == (n & 1));
}
// hier folgen die Unittests

DMD compiliert oben stehendes zu nach stehenden Assembler Zeilen:

and       RDI,1
mov       EAX,1
cmp       RDI,RAX
setz      AL
ret

Variante a)

Der Vollständigkeit halber hier noch D-Code und Assembler für Variante a):

@safe @nogc nothrow pure
bool mododd(immutable ulong n)
{
  return (1 == (n % 2));
}

Wie schaut nun der Assembler-Code aus? Erwartet hatte ich etwas in folgender Form:

mov       RAX,RDI
mov       ECX,2
xor       EDX,EDX
div       RCX
cmp       RDX,1
setz      AL
ret

Wobei mir nicht klar ist, warum er das EDX-Register löscht in dem er es mir mit sich selbst »exklusiv odert«?

Da moderne Compiler »mitdenken« und optimieren sehen wir einen alten bekannten wieder:

and       RDI,1
mov       EAX,1
cmp       RDI,RAX
setz      AL
ret

Der Compiler substituiert das Modulo durch den MSB-Set-Test.

Fazit

Es ist ineteressant, Dinge mal anders zu machen, um Verständnis für Abläufe zu entwickeln über welche man sich kaum mehr Gedanken macht. Augenscheinlich ist dies wegen der höheren Kerntakte und schieren Speichermengen heute auch kaum mehr notwendig, aber je nach Platform ist händische Voroptimierung durchaus sinnvoll, weil moderne Compiler dann nicht die Nachlässigkeiten von Programmieren oder Codegeneratoren ausbügeln müssen, sondern kleinteiliger optimieren können.

Changelog

2026-03-09: Referenzen hinzugefügt. 2026-03-15: Umstelung Tabelle auf HTML, da jekyll keine MArkdown-Table-Syntax unterstützt.

Referenzen