Was macht eigentlich 'btr'?

[Manuel Ems]

Hallo.
Ich beisse mir schon den ganzen Tag die Zaehne an folgender Frage aus:
was bewirkt 'btr'?

Ich habe schon gesucht und leider nichts brauchbares gefunden. :(
Aus dem Code in dem ich es gesehen habe geht hervor dass es irgendwas
mit den Bits anstellt, aber was genau konnte ich auch nicht rausfinden.

Danke an alle die die Geduld aufbringen diese Frage zu beantworten ;)


Manuel

[Robert Riebisch]

Post by Manuel Ems
was bewirkt 'btr'?

Dann lösen wir's mal mit Google in 5 Sekunden auf:
http://www.google.de/search?q=assembler+btr

[Wolfgang Fellger]

Post by Manuel Ems
was bewirkt 'btr'?

Bit Test & Reset

Doppelfunktionalität:
- setzt das Carry-Flag auf Wert des angegebenen Bits
- setzt Bit im Operand auf 0

[Herbert Kleebauer]

Post by Manuel Ems
Hallo.
was bewirkt 'btr'?
Ich habe schon gesucht und leider nichts brauchbares gefunden. :(
Aus dem Code in dem ich es gesehen habe geht hervor dass es irgendwas
mit den Bits anstellt, aber was genau konnte ich auch nicht rausfinden.
Danke an alle die die Geduld aufbringen diese Frage zu beantworten ;)

http://support.intel.com/design/pentium4/manuals/index_new.htm


http://developer.intel.com/design/pentiumii/manuals/243190.htm
http://developer.intel.com/design/pentiumii/manuals/243191.htm
http://developer.intel.com/design/pentiumii/manuals/243192.htm

[Sebastian Biallas]

Post by Manuel Ems
Hallo.
was bewirkt 'btr'?

Falls Du Dich fragst, warum man ausgerechnet so eine obskure Operation
mit einer eigenen Anweisung bedacht hat: Die Krux ist, dass btr atomar
ausgeführt wird (auf SMP-System braucht er noch ein lock-Präfix), und
sich so hervorragend für Synchronisationsaufgaben eignet.

[Jan Bruns]

Post by Sebastian Biallas

Post by Manuel Ems
was bewirkt 'btr'?

Falls Du Dich fragst, warum man ausgerechnet so eine obskure Operation

Warum sollte man sich das fragen?
BitTest-Befehle sind selbst auf RISC-Systemen häufig vorhanden,
und mit x86-CISCs haben wir sogar so völlig schräge Dinge wie
bspw. BCD-Rechnungen im Befehlssatz.

Und ich finde, so ein BitTest mit Set/Reset wird doch viel zu oft
tatsächlich benötigt, als daß solche Programmsequenzen wie etwa
diese hier:


// OP in EAX,
// Bitnum in EBX

push ecx
push ebx

mov ecx,eax
mov ebx,dword ptr[some_base + 4*ebx]
and ecx,ebx
pushf
not ebx
and eax,ebx
popf

pop ebx
pop ecx

// result in ZF statt CF


auf 'nem CISC-System ernsthaft sein müssten (und diese sequenz ist
fuktional immer noch weit davon entfernt, ).

Post by Sebastian Biallas
Die Krux ist, dass btr atomar
ausgeführt wird (auf SMP-System braucht er noch ein lock-Präfix), und
sich so hervorragend für Synchronisationsaufgaben eignet.

Verstehe ich nicht. Zum einen kann man dch zahlreiche andere Befehle
ebenfalls mit einem LOCK-Präfix versehen, und zum anderen scheint mir
auch die atomare Ausführung von bspw. "BTR dword ptr[000FFFFF],8"
gar nicht garantiert zu sein.

Zumidest finde ich in der Auflistung
http://support.intel.com/design/pentium4/manuals/index_new.htm
System Programming Guide, Part 1
7.1.1 Guaranteed Atomic Operations

keinen Hinweis dazu, und in der Befehlsbeschreibung ist gar nur
definiert, daß das Bit gelöscht wird. Eine Garantie, daß der
Operand nicht "zefetzt" werden könnte, finde ich da nirgends
(ausser man verwendet LOCK, was denn aber doch BTR nicht auszeichnet).

Gruss

Jan Bruns

[Sebastian Biallas]

Post by Jan Bruns

Post by Sebastian Biallas

Post by Manuel Ems
was bewirkt 'btr'?

Falls Du Dich fragst, warum man ausgerechnet so eine obskure Operation

Warum sollte man sich das fragen?

Weil die Semantik von btr schon hinreichend obskur ist und (auf den
ersten Blick) sehr einfach "simuliert" werden kann.

Post by Jan Bruns
BitTest-Befehle sind selbst auf RISC-Systemen häufig vorhanden,

Aber nicht solche, die auch mit Speicher funktionieren. Ein btr
Äquivalent ist mir übrigens auf keiner anderen Architektur bekannt (ich
kenne aber außer x86 nur PowerPC hinreichend gut).

Post by Jan Bruns
und mit x86-CISCs haben wir sogar so völlig schräge Dinge wie
bspw. BCD-Rechnungen im Befehlssatz.

Das sind aber Altlasten.

Post by Jan Bruns
Und ich finde, so ein BitTest mit Set/Reset wird doch viel zu oft
tatsächlich benötigt, als daß solche Programmsequenzen wie etwa

Ein Bittest mit Reset lässt sich in 2 Anweisungen zusammenbauen (sofern
die Bitnummer bekannt ist, ein Test + ein (Re)set), bzw 5 Anweisungen
(vorher noch einmal Shiften). Zumindest solange man nicht benötigt, dass
er atomar ist.

Post by Jan Bruns

Post by Sebastian Biallas
Die Krux ist, dass btr atomar
ausgeführt wird (auf SMP-System braucht er noch ein lock-Präfix), und
sich so hervorragend für Synchronisationsaufgaben eignet.

Verstehe ich nicht. Zum einen kann man dch zahlreiche andere Befehle
ebenfalls mit einem LOCK-Präfix versehen,

Ja und? Es geht hier um die Semantik von btr.

Post by Jan Bruns
und zum anderen scheint mir
auch die atomare Ausführung von bspw. "BTR dword ptr[000FFFFF],8"
gar nicht garantiert zu sein.

Und warum?

Post by Jan Bruns
Zumidest finde ich in der Auflistung
http://support.intel.com/design/pentium4/manuals/index_new.htm
System Programming Guide, Part 1
7.1.1 Guaranteed Atomic Operations

Kann ich gerade nicht drauf zugreifen. Ich denke mal die meinen da etwas
anderes.

Ich kenne folgenden Text:

| Bus-locking may be necessary for certain operations to be atomic on
| multiprocessor machines. According to the Intel documentation this
| is necessary for the following operations:

| - The bit test and modify instructions (BTS, BTR and BTC).
| - The exchange instructions (XADD, CMPXCHG, CMPXCHG8B).
| - The following single-operand arithmetic and logical instructions:
| INC, DEC, NOT, and NEG.
| - The following two-operand arithmetic and logical instructions:
| ADD, ADC, SUB, SBB, AND, OR, and XOR.

| The XCHG instruction is automatically locked.

Post by Jan Bruns
keinen Hinweis dazu, und in der Befehlsbeschreibung ist gar nur
definiert, daß das Bit gelöscht wird. Eine Garantie, daß der
Operand nicht "zefetzt" werden könnte, finde ich da nirgends
(ausser man verwendet LOCK, was denn aber doch BTR nicht auszeichnet).

lock brauchst Du nur auf SMP-Systemen. Nun zeig mir doch mal bitte, wie
Du die Semantik eines btr nachbaust, sodass er atomar ist. Ohne
spin-lock mit cmpxchg oder so wird das nicht gehen.

[Martin Wodrich]

Post by Sebastian Biallas
lock brauchst Du nur auf SMP-Systemen. Nun zeig mir doch mal bitte, wie
Du die Semantik eines btr nachbaust, sodass er atomar ist.

Im Grunde ist es doch so:
Brauchst du mehr als eine Anweisung für einen Vorgang, dann mußt
du dich ziemlich anstrengen dies atomar hinzubekommen.

Post by Sebastian Biallas
Ohne spin-lock mit cmpxchg oder so wird das nicht gehen.

Schaffst du es aber mit einer einzelnen Anweisung so ist
das ganze relativ trival. Auf normalen Single-CPU-Systemen
brauchst du fast gar nichts tun (da es eben keine möglichen
Unterbrechnungen zwischen zwei Anweisungen gibt, sondern
nur zwischen zwei Anweisungen (*)).
Auf SMP-Systemen kann dir aber immer noch die anderen CPUs
reinspucken. Also lock.

(*) zu beachten gibt es nur Hardware mit CPU-unabhängigem
Buszugriff. Solange die aber nicht auf die betreffende
Speicherstelle zugreift ist es allerdings egal.

[Sebastian Biallas]

Post by Martin Wodrich

Post by Sebastian Biallas
lock brauchst Du nur auf SMP-Systemen. Nun zeig mir doch mal bitte, wie
Du die Semantik eines btr nachbaust, sodass er atomar ist.

Brauchst du mehr als eine Anweisung für einen Vorgang, dann mußt
du dich ziemlich anstrengen dies atomar hinzubekommen.

Eben. Und bts/btr/btc zeichnet eben aus, dass sie ihre Aufgabe in einer
Anweisung machen.

Post by Martin Wodrich

Post by Sebastian Biallas
Ohne spin-lock mit cmpxchg oder so wird das nicht gehen.

Schaffst du es aber mit einer einzelnen Anweisung so ist
das ganze relativ trival. Auf normalen Single-CPU-Systemen
brauchst du fast gar nichts tun (da es eben keine möglichen
Unterbrechnungen zwischen zwei Anweisungen gibt, sondern
nur zwischen zwei Anweisungen (*)).

Das ist doch genau der Punkt.

[Jan Bruns]

Post by Sebastian Biallas

Post by Jan Bruns
und mit x86-CISCs haben wir sogar so völlig schräge Dinge wie
bspw. BCD-Rechnungen im Befehlssatz.

Das sind aber Altlasten.

Hehe, Altlasten. Also nötig sind die Dinger nicht gerade,
da sind wir uns einig.

Post by Sebastian Biallas
Kann ich gerade nicht drauf zugreifen. Ich denke mal die meinen da etwas
anderes.

Vereinfacht zusammengefasst sind auf Intel-Systemen quasi nur
alle alignten Speicherzugriffe garantiert "atomar", auf neueren
Systemen allerdings auch solche, die innerhalb einer einzigen
Cachline stattfinden.

Post by Sebastian Biallas

Post by Jan Bruns
und zum anderen scheint mir
auch die atomare Ausführung von bspw. "BTR dword ptr[000FFFFF],8"
gar nicht garantiert zu sein.

Und warum?

Weil der Speicheroperand nunmal nicht in der Liste der garantiert
atomar behandelten Schreibzugriffe aufgelistet ist.

Post by Sebastian Biallas
lock brauchst Du nur auf SMP-Systemen. Nun zeig mir doch mal bitte, wie
Du die Semantik eines btr nachbaust, sodass er atomar ist. Ohne
spin-lock mit cmpxchg oder so wird das nicht gehen.

Darauf ist Martin ja schon eingegangen.

Wie Du ja selbst zitiert hast, ist die Liste der lockbaren Befehle
lang, zeichnet BTR nicht aus.


Gruss

Jan Bruns

[Sebastian Biallas]

Post by Jan Bruns

Post by Sebastian Biallas
Kann ich gerade nicht drauf zugreifen. Ich denke mal die meinen da etwas
anderes.

Vereinfacht zusammengefasst sind auf Intel-Systemen quasi nur
alle alignten Speicherzugriffe garantiert "atomar", auf neueren
Systemen allerdings auch solche, die innerhalb einer einzigen
Cachline stattfinden.

Schön, wusste ich bereits. Was hat das jetzt mit btr zu tun?

Post by Jan Bruns

Post by Sebastian Biallas

Post by Jan Bruns
und zum anderen scheint mir
auch die atomare Ausführung von bspw. "BTR dword ptr[000FFFFF],8"
gar nicht garantiert zu sein.

Und warum?

Weil der Speicheroperand nunmal nicht in der Liste der garantiert
atomar behandelten Schreibzugriffe aufgelistet ist.

Hast Du den von mir zitierten Text gelesen? Hast Du mal nach "btr
atomic" gegoogled? Hast Du überhaupt mal selber bts/btr/btc gebraucht
oder einen Compiler gesehen, der diese Anweisungen generiert? Oder hast
Du Dich nicht mal gefragt, warum die von einer libc_atomic zur Verfügung
gestellt werden?

Post by Jan Bruns

Post by Sebastian Biallas
lock brauchst Du nur auf SMP-Systemen. Nun zeig mir doch mal bitte, wie
Du die Semantik eines btr nachbaust, sodass er atomar ist. Ohne
spin-lock mit cmpxchg oder so wird das nicht gehen.

Darauf ist Martin ja schon eingegangen.

Er hat das eigentlich nur bestätigt.

Post by Jan Bruns
Wie Du ja selbst zitiert hast, ist die Liste der lockbaren Befehle
lang, zeichnet BTR nicht aus.

Natürlich zeichnet das btr nicht aus, dass er lockbar ist. Ihn zeichnet
aber aus, dass seine Sematik hinreichnend obskur ist, dass es
"eigentlich" unnötig gewesen wäre, dafür eine eigene Anweisung zu
schaffen. Er stellt halt eine Operation zur Verfügung, die man gerne
atomar hätte (in der Liste gibt es ja noch andere Befehle, die auch in
diese Kategorie fallen. xadd und cmpxchg werden in normalem Code wohl
nicht auftreten, sondern werden eben nur zur Synchronisation gebraucht).

[Jan Bruns]

Post by Sebastian Biallas
Hast Du den von mir zitierten Text gelesen? Hast Du mal nach "btr
atomic" gegoogled? Hast Du überhaupt mal selber bts/btr/btc gebraucht
oder einen Compiler gesehen, der diese Anweisungen generiert? Oder hast
Du Dich nicht mal gefragt, warum die von einer libc_atomic zur Verfügung
gestellt werden?

Ja, ich habe den Text gelesen, und selbst schon oftmals die BT-Befehle
benutzt, auch BTS/BTR und BTC. Ich finde die recht praktisch bei der
Handhabung von Bitfeldern, und würde auf diese Funktionalität nur ungern
verzichten.

Warum allerdings zu irgendwelchen C-compilern irgendwelche Bibliotheken
existieren, geht mich herzlich wenig an, ich mag und verwende C nicht.

Gruss

Jan Bruns

[Sebastian Biallas]

Post by Jan Bruns

Post by Sebastian Biallas
Hast Du den von mir zitierten Text gelesen? Hast Du mal nach "btr
atomic" gegoogled? Hast Du überhaupt mal selber bts/btr/btc gebraucht
oder einen Compiler gesehen, der diese Anweisungen generiert? Oder hast
Du Dich nicht mal gefragt, warum die von einer libc_atomic zur Verfügung
gestellt werden?

Ja, ich habe den Text gelesen, und selbst schon oftmals die BT-Befehle
benutzt, auch BTS/BTR und BTC. Ich finde die recht praktisch bei der
Handhabung von Bitfeldern, und würde auf diese Funktionalität nur ungern
verzichten.

Und ich ziehe allein aus Geschwindigkeitsgründen eine
test/(and|or|xor)-Kombination btr/bts/btc vor. Zumindest bei AMD sind
das nämlich VectorPath-Anweisungen, wenn man sie mit einem
Speicheroperand benutzt.

bt, bsf und bsr hingegen sind wirklich praktische Befehle.

Post by Jan Bruns
Warum allerdings zu irgendwelchen C-compilern irgendwelche Bibliotheken
existieren, geht mich herzlich wenig an, ich mag und verwende C nicht.

Dass btr eine atomare Operation zur Verfügung stellt, hat nichts mit C
zu tun.

[Jan Bruns]

Post by Sebastian Biallas

Post by Jan Bruns
Ja, ich habe den Text gelesen, und selbst schon oftmals die BT-Befehle
benutzt, auch BTS/BTR und BTC. Ich finde die recht praktisch bei der
Handhabung von Bitfeldern, und würde auf diese Funktionalität nur ungern
verzichten.

Und ich ziehe allein aus Geschwindigkeitsgründen eine
test/(and|or|xor)-Kombination btr/bts/btc vor. Zumindest bei AMD sind
das nämlich VectorPath-Anweisungen, wenn man sie mit einem
Speicheroperand benutzt.

Das mag angehen, ist schon lange her, daß ich zuletzt den
XP optimization guide gelesen habe.

Wenn ich das richtig in Erinnerung habe, war der Unterschied von
Vector-Path-Anweisungen zu einem Standardbefehlen im Höchstfall
der Faktor 3 (nur ein Befehl, statt bestenfalls 3 gleichzeitig).

Ausserdem ist die bt?-Veriante deutlich kürzer, was bspw. bei kurzen
Schleifen die Wahrscheinlichkeit erhöht, daß die komplette Schleife
in den Befehls-decoder passt.

Und letzlich kann man durchaus auch die Meinung vertreten, daß
ein komplexer Befehlssatz dazu da ist, auch als solcher genutzt
zu werden. CPU-spezifische Optimiereungen sind ja 'ne extrem
kurzfristige Sache, da kann schon beim nächsten CPU-Modell 'ne
"Optimierung" mal wieder kontraproduktiv sein.

Post by Sebastian Biallas

Post by Jan Bruns
Warum allerdings zu irgendwelchen C-compilern irgendwelche Bibliotheken
existieren, geht mich herzlich wenig an, ich mag und verwende C nicht.

Dass btr eine atomare Operation zur Verfügung stellt, hat nichts mit C
zu tun.

Daß er das nicht tut, hat nichts mit C-Bibs zu tun, da hast Du recht, ja.

Post by Sebastian Biallas
| Bus-locking may be necessary for certain operations to be atomic

Gruss

Jan Bruns

[Sebastian Biallas]

Post by Jan Bruns

Post by Sebastian Biallas

Post by Jan Bruns
und zum anderen scheint mir
auch die atomare Ausführung von bspw. "BTR dword ptr[000FFFFF],8"
gar nicht garantiert zu sein.

Und warum?

Weil der Speicheroperand nunmal nicht in der Liste der garantiert
atomar behandelten Schreibzugriffe aufgelistet ist.

Sorry, bei nochmaligem Lesen sehe ich jetzt, dass es Dir da (warum auch
immer) wohl um unalignten Speicherzugriff ging. Bei bts/btr/btc gibt es
aber doch wohl überhaupt keinen Grund, die auf unalignten Speicher
loszulassen, da sie sowieso nur Auswirkung auf ein Bit haben.