Re: Was macht eigentlich 'btr'?
Robert Riebisch
> Ich beisse mir schon den ganzen Tag die Zaehne an folgender Frage aus:
> was bewirkt 'btr'?
Dann lösen wir's mal mit Google in 5 Sekunden auf:
http://www.google.de/search?q=assembler+btr
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
Wolfgang Fellger
>was bewirkt 'btr'?
Bit Test & Reset
Doppelfunktionalität:
- setzt das Carry-Flag auf Wert des angegebenen Bits
- setzt Bit im Operand auf 0
--
Wolfgang Fellger
Herbert Kleebauer
Manuel Ems wrote:
>
> 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 ;)
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
> Hallo.
> Ich beisse mir schon den ganzen Tag die Zaehne an folgender Frage aus:
> 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.
--
Gruß,
Sebastian
Jan Bruns
"Sebastian Biallas":
> Manuel Ems wrote:
>> Ich beisse mir schon den ganzen Tag die Zaehne an folgender Frage aus:
>> was bewirkt 'btr'?
> Falls Du Dich fragst, warum man ausgerechnet so eine obskure Operation
> mit einer eigenen Anweisung bedacht hat:
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, ).
> 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
>
> "Sebastian Biallas":
>> Manuel Ems wrote:
>
>>> Ich beisse mir schon den ganzen Tag die Zaehne an folgender Frage aus:
>>> was bewirkt 'btr'?
>
>> Falls Du Dich fragst, warum man ausgerechnet so eine obskure Operation
>> mit einer eigenen Anweisung bedacht hat:
>
> 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.
> 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).
> und mit x86-CISCs haben wir sogar so völlig schräge Dinge wie
> bspw. BCD-Rechnungen im Befehlssatz.
Das sind aber Altlasten.
>
> 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:
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.
>> 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.
> und zum anderen scheint mir
> auch die atomare Ausführung von bspw. "BTR dword ptr[000FFFFF],8"
> gar nicht garantiert zu sein.
Und warum?
>
> 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.
> 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.
--
Gruß,
Sebastian
Martin Wodrich
> 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.
Eben z.B. dies:
> 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.
--
Mit freundlichen Gruessen,
Martin Wodrich
Jan Bruns
"Sebastian Biallas":
>> 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.
> 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.
>> 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.
> 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
> Sebastian Biallas <groups...@spamgourmet.com> schrieb am 04.07.06 um 17:18:
>
>> 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.
Eben. Und bts/btr/btc zeichnet eben aus, dass sie ihre Aufgabe in einer
Anweisung machen.
>
> Eben z.B. dies:
>
>> 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.
--
Gruß,
Sebastian
Sebastian Biallas
>
> "Sebastian Biallas":
>> 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?
>>> 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?
>
>> 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.
>
> 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).
--
Gruß,
Sebastian
Sebastian Biallas
>>> 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.
--
Gruß,
Sebastian
Jan Bruns
"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
>
> "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.
> 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.
--
Gruß,
Sebastian
Jan Bruns
"Sebastian Biallas":
>> 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.
>> 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.
>| Bus-locking may be necessary for certain operations to be atomic
Gruss
Jan Bruns