Jan Bruns wrote:
>
> "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?

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

Jan Bruns wrote:
>>> 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

"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

Jan Bruns wrote:
>
> "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

"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