Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #118579 > unrolled thread

Performance of xchg reg,reg

Back to article view | Back to comp.arch

Contents

  Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-13 08:43 +0000
    Re: Performance of xchg reg,reg Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-14 00:23 +0000
      Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 07:00 +0000
        Re: Performance of xchg reg,reg MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-14 22:35 +0000
          Re: Performance of xchg reg,reg Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-14 23:07 +0000
          Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-15 06:05 +0000
            Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-15 07:06 +0000
              Re: Performance of xchg reg,reg EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-16 09:47 -0400
                Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 16:04 +0000
                Re: Performance of xchg reg,reg Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-17 05:46 +0000
    Re: Performance of xchg reg,reg Michael S <already5chosen@yahoo.com> - 2026-10-14 22:29 +0300
    Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-15 14:21 -0700
      Re: Performance of xchg reg,reg Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-15 21:42 +0000
        Re: Performance of xchg reg,reg Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-16 14:45 +0200
      Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 05:50 +0000
        Re: Performance of xchg reg,reg Michael S <already5chosen@yahoo.com> - 2026-10-16 11:34 +0300
          Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 18:23 +0000
            Re: Performance of xchg reg,reg scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 20:48 +0000
              Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-16 14:28 -0700
              Re: Performance of xchg reg,reg Thomas Koenig <tkoenig@netcologne.de> - 2026-10-17 09:48 +0000
            Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 02:50 +0000
              Re: Performance of xchg reg,reg MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-17 17:11 +0000
                Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:31 +0000
                  Re: Performance of xchg reg,reg MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-17 19:39 +0000
                    Re: Performance of xchg reg,reg Michael S <already5chosen@yahoo.com> - 2026-10-17 23:20 +0300
                    Re: Documentation (was Re: Performance of xchg reg,reg) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-17 20:54 +0000
                      Re: Documentation (was Re: Performance of xchg reg,reg) George Neuner <gneuner2@comcast.net> - 2026-10-18 09:45 -0400
                        Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg)) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-18 14:08 +0000
                          Re: Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg)) quadibloc@invalid.com (John Savard) - 2026-10-19 00:09 +0000
                            Re: Algol 68 (was Re: Documentation) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 01:46 +0000
                              Re: Algol 68 (was Re: Documentation) quadibloc@invalid.com (John Savard) - 2026-10-21 14:15 +0000
                                Re: Algol 68 (was Re: Documentation) Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-21 18:34 +0300
                                  Re: Algol 68 (was Re: Documentation) quadibloc@invalid.com (John Savard) - 2026-10-21 19:38 +0000
                                    Re: Algol 68 (was Re: Documentation) aph@littlepinkcloud.invalid - 2026-10-22 09:51 +0000
                                    Re: Algol 68 (was Re: Documentation) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-10-22 14:15 -0700
                                      Re: Algol 68 (was Re: Documentation) scott@slp53.sl.home (Scott Lurndal) - 2026-10-23 14:08 +0000
                          Re: PL/I, was Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg)) John Levine <johnl@taugh.com> - 2026-10-19 03:24 +0000
                            Re: PL/I, was Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg)) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-19 05:34 +0000
                          Re: Algol 68 Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-18 23:34 -0400
                        Re: Documentation (was Re: Performance of xchg reg,reg) quadibloc@invalid.com (John Savard) - 2026-10-19 00:18 +0000
                          Re: Documentation (was Re: Performance of xchg reg,reg) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:52 +0000
                            Re: Documentation (was Re: Performance of xchg reg,reg) George Neuner <gneuner2@comcast.net> - 2026-10-19 14:50 -0400
                              Re: Documentation (was Re: Performance of xchg reg,reg) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 02:05 +0000
                          Re: Algol 68 (was Re: Documentation) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 01:54 +0000
                          Re: Documentation (was Re: Performance of xchg reg,reg) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-19 07:44 +0000
                          Re: Documentation (was Re: Performance of xchg reg,reg) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-19 12:24 -0400
                      Re: Documentation (was Re: Performance of xchg reg,reg) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-18 17:48 +0000
                    Re: Performance of xchg reg,reg George Neuner <gneuner2@comcast.net> - 2026-10-18 08:59 -0400
                    Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-18 15:08 +0000
                      Re: Performance of xchg reg,reg Michael S <already5chosen@yahoo.com> - 2026-10-18 18:43 +0300
                        Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-18 16:57 +0000
                          Re: Performance of xchg reg,reg Michael S <already5chosen@yahoo.com> - 2026-10-18 20:47 +0300
                            Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 18:07 +0000
                            Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-18 21:04 +0000
                          Re: Performance of xchg reg,reg Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-18 23:43 -0400
                            Re: Performance of xchg reg,reg Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-10-19 06:57 -0700
                              Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-19 14:27 -0700
                              Re: Performance of xchg reg,reg Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-20 10:00 -0400
                            Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 02:00 +0000
                              Re: Performance of xchg reg,reg scott@slp53.sl.home (Scott Lurndal) - 2026-10-20 14:09 +0000
                                Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-20 16:44 -0700
                              Re: Performance of xchg reg,reg Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-20 10:05 -0400
                                Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 19:56 +0000
                            Re: Performance of xchg reg,reg anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-22 10:54 +0000
                              Re: Performance of xchg reg,reg Michael S <already5chosen@yahoo.com> - 2026-10-22 22:11 +0300
                        Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 17:40 +0000
                          Re: Performance of xchg reg,reg Michael S <already5chosen@yahoo.com> - 2026-10-18 20:54 +0300
                            Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 18:25 +0000
                        Re: Performance of xchg reg,reg MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-18 18:01 +0000
                      Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 17:59 +0000
                    Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 17:09 +0000
                  Re: Performance of xchg reg,reg EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-18 12:31 -0400
                    Re: Performance of xchg reg,reg cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 17:47 +0000
              Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-18 12:27 -0700
                Re: Performance of xchg reg,reg EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-19 09:38 -0400
                  Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-19 14:08 -0700
                    Re: Performance of xchg reg,reg Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 21:21 +0000
                      Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-19 14:26 -0700
                    Re: Performance of xchg reg,reg Joseph Seigh <jseigh_es00@xemaps.com> - 2026-10-19 19:17 -0400
                      Re: Performance of xchg reg,reg "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-19 22:41 -0700
                        Re: Performance of xchg reg,reg MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-20 16:45 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#118757

On 10/20/2026 7:09 AM, Scott Lurndal wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <jwv8q3uqrxf.fsf-monnier+comp.arch@gnu.org>,
>> Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>>> Anton Ertl [2026-10-18 16:57:26] wrote:
>>>> And actually all the stuff about XCHG with memory operands does not
>>>> contradict this sentence.  It could be understood as meaning that
>>>> while all the other aspects of locking don't apply to "XCHG reg, reg",
>>>> the assertion of the LOCK# signal still has to occur, and that's why
>>>> Intel processors implement a slow XCHG reg, reg.
>>>
>>> How could code witness the difference?
>>>
>>> I believe AMD can claim that its behavior is consistent with the
>>> behavior you'd get when asserting the LOCK# signal.
>>
>> The effects of a bus lock include disallowing memory operations
>> (except for instruction fetches or page table accesses) passing
>> a locked operation.  If `XCHG reg,reg` where indeed treated as
>> though it asserted `LOCK#` for the duration of its execution, it
>> could be (ab)used to force that behavior:  From sec 11.1.2.2 of
>> SDM Volume 3a (Sept 2026 version):
>>
> 
> It's worth noting that AMD processors (in the 2008 timeframe) would
> assert the LOCK# signal if a highly contended cache line could not
> be acquired in exclusive mode within a certain window of time,
> even if the access was completely encapsulated in said cache line.
> 
> I suspect that is still the case.

I almost have to agree. I think it was there for some sort of anti 
livelock...? Try bashing the shit out of a LOCK CMPXCHG with another 
thread just writing to the address trying to make the CAS fail, over and 
over again... It might force some internal logic to assert a real bus lock.

[toc] | [prev] | [next] | [standalone]

#118747

Dan Cross [2026-10-20 02:00:48] wrote:
> In article <jwv8q3uqrxf.fsf-monnier+comp.arch@gnu.org>,
> Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>>How could code witness the difference?
> The effects of a bus lock include disallowing memory operations
> (except for instruction fetches or page table accesses) passing
> a locked operation.

Ah, so it doesn't just make the operation atomic, but it additionally
imposes barrier-style restrictions on reordering surrounding memory
operations?  I see, thanks.


=== Stefan

[toc] | [prev] | [next] | [standalone]

#118751

In article <jwvzew8mpwv.fsf-monnier+comp.arch@gnu.org>,
Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>Dan Cross [2026-10-20 02:00:48] wrote:
>> In article <jwv8q3uqrxf.fsf-monnier+comp.arch@gnu.org>,
>> Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>>>How could code witness the difference?
>> The effects of a bus lock include disallowing memory operations
>> (except for instruction fetches or page table accesses) passing
>> a locked operation.
>
>Ah, so it doesn't just make the operation atomic, but it additionally
>imposes barrier-style restrictions on reordering surrounding memory
>operations?  I see, thanks.

Well, to be clear, I don't think that _that particular form_ of
`xchg` actually does.  But if the destination were a memory
operand, it would, yes.  :-)

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#118771

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>Anton Ertl [2026-10-18 16:57:26] wrote:
>> And actually all the stuff about XCHG with memory operands does not
>> contradict this sentence.  It could be understood as meaning that
>> while all the other aspects of locking don't apply to "XCHG reg, reg",
>> the assertion of the LOCK# signal still has to occur, and that's why
>> Intel processors implement a slow XCHG reg, reg.
>
>How could code witness the difference?

Depends on the hardware.  If there is some device connected t the
LOCK# signal (e.g., another CPU), and that behaves differently when
the signal is asserted, the code can measure that.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

[toc] | [prev] | [next] | [standalone]

#118774

On Thu, 22 Oct 2026 10:54:04 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >Anton Ertl [2026-10-18 16:57:26] wrote:  
> >> And actually all the stuff about XCHG with memory operands does not
> >> contradict this sentence.  It could be understood as meaning that
> >> while all the other aspects of locking don't apply to "XCHG reg,
> >> reg", the assertion of the LOCK# signal still has to occur, and
> >> that's why Intel processors implement a slow XCHG reg, reg.  
> >
> >How could code witness the difference?  
> 
> Depends on the hardware.  If there is some device connected t the
> LOCK# signal (e.g., another CPU), and that behaves differently when
> the signal is asserted, the code can measure that.
> 
> - anton

My undersanding is that in server x86 CPU physical LOCK# signal does not
exist for more than decade. Probably much longer in desktop and laptop
devices.

[toc] | [prev] | [next] | [standalone]

#118693

In article <20261018184318.00000bee@yahoo.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>On Sun, 18 Oct 2026 15:08:23 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>> >cross@spitfire.i.gajendra.net (Dan Cross) posted:  
>> >> What I'm saying is that, as written, the bits in the `LOCK`
>> >> description above _could_ be interpreted to mean that _any_
>> >> `XCHG` will always assert the `LOCK#` signal, including an
>> >> `XCHG` that does not touch memory at all.  The "Why?" was
>> >> rhetorical, as in, "Why would the system do that?"  For example,
>> >> if one wrote, `xchg %ecx, %eax`, why should that assert `LOCK#`?
>> >> Truly I don't know, and I was just speculating.  
>> >
>> >Writing high quality documentation is fundamentally hard.  
>> 
>> I don't think that's the issue here.  They just did not limit the
>> sentence "The XCHG instruction always asserts the LOCK# signal
>> regardless of the presence or absence of the LOCK prefix."  to XCHG
>> instructions with memory operands.  That would be easy to fix, but
>> they did not.  And Chris M. Thomasson understood it as including
>> XCHG reg, reg.
>> 
>> My guess is that it is easy to fix in principle, but you have to deal
>> with all kinds of red tape for such a fix, so unless there is good
>> reason, you don't do it.
>
>Frankly, I don't understand what both you and Dan Cross are talking
>about.

Because you are not reading the same thing we are.

>I don't see how sentence from Intel's manual ("If a memory operand is
>referenced, the processor’s locking protocol is automatically
>implemented for the duration of the exchange operation, regardless of
>the presence or absence of the LOCK prefix or of the value of the IOPL")
>or sentence from AMD's manual ("If either operand references memory,
>the processor locks automatically, whether or not the LOCK prefix is
>used and independently of the value of IOPL.") can be pssibly
>misunderstood.

Which part of the Intel and AMD manuals?

What Anton raised, and what I'm also referring to, is a a single
sentence in the SDM's description of the `LOCK` prefix.  For
reference, I am looking at Volume 2A, order number 253666-093US,
published Sept 2026, page 3-565.

Tucked away in the "Description" section, at the end the third
paragraph, which describes what instructions can be prefaced by
`LOCK` and under what conditions, is the single sentence that
reads: "The `XCHG` instruction always asserts the `LOCK#` signal
regardless of the presence or absence of the `LOCK` prefix."
Note: that is a direct quote from the reference.

We know that `XCHG` with a memory destination operand is atomic
and affects memory ordering, etc, regardless of whether the
`LOCK` prefix is explicitly given or not.  The issue is that
that sentence, taken in complete isolation, makes it sound like
this is _also_ the case for `xchg reg, reg`, where the
destination is a _register_ operand.

I claim that that is a misreading, and that a reader should
interpret that last sentence in the context of the first
sentence in that paragraph, that refers specifically to memory
operands; furthermore, other parts of the SDM are clear that
`xchg reg, reg` has no impact on memory ordering, bus locks,
etc.

Regardless, that sentence is ambiguous.  References to the
description of `XCHG`, or to the locking protocols in volume 3,
does not change that.

The latest version of the entire Intel SDM is available online:
https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
I had already quoted the paragarph in question in its entirely.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#118698

On Sun, 18 Oct 2026 17:40:00 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

> In article <20261018184318.00000bee@yahoo.com>,
> Michael S  <already5chosen@yahoo.com> wrote:
> >On Sun, 18 Oct 2026 15:08:23 GMT
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >  
> >> MitchAlsup <user5857@newsgrouper.org.invalid> writes:  
> >> >cross@spitfire.i.gajendra.net (Dan Cross) posted:    
> >> >> What I'm saying is that, as written, the bits in the `LOCK`
> >> >> description above _could_ be interpreted to mean that _any_
> >> >> `XCHG` will always assert the `LOCK#` signal, including an
> >> >> `XCHG` that does not touch memory at all.  The "Why?" was
> >> >> rhetorical, as in, "Why would the system do that?"  For example,
> >> >> if one wrote, `xchg %ecx, %eax`, why should that assert `LOCK#`?
> >> >> Truly I don't know, and I was just speculating.    
> >> >
> >> >Writing high quality documentation is fundamentally hard.    
> >> 
> >> I don't think that's the issue here.  They just did not limit the
> >> sentence "The XCHG instruction always asserts the LOCK# signal
> >> regardless of the presence or absence of the LOCK prefix."  to XCHG
> >> instructions with memory operands.  That would be easy to fix, but
> >> they did not.  And Chris M. Thomasson understood it as including
> >> XCHG reg, reg.
> >> 
> >> My guess is that it is easy to fix in principle, but you have to
> >> deal with all kinds of red tape for such a fix, so unless there is
> >> good reason, you don't do it.  
> >
> >Frankly, I don't understand what both you and Dan Cross are talking
> >about.  
> 
> Because you are not reading the same thing we are.
> 
> >I don't see how sentence from Intel's manual ("If a memory operand is
> >referenced, the processor’s locking protocol is automatically
> >implemented for the duration of the exchange operation, regardless of
> >the presence or absence of the LOCK prefix or of the value of the
> >IOPL") or sentence from AMD's manual ("If either operand references
> >memory, the processor locks automatically, whether or not the LOCK
> >prefix is used and independently of the value of IOPL.") can be
> >pssibly misunderstood.  
> 
> Which part of the Intel and AMD manuals?
> 
> What Anton raised, and what I'm also referring to, is a a single
> sentence in the SDM's description of the `LOCK` prefix.  For
> reference, I am looking at Volume 2A, order number 253666-093US,
> published Sept 2026, page 3-565.
> 
> Tucked away in the "Description" section, at the end the third
> paragraph, which describes what instructions can be prefaced by
> `LOCK` and under what conditions, is the single sentence that
> reads: "The `XCHG` instruction always asserts the `LOCK#` signal
> regardless of the presence or absence of the `LOCK` prefix."
> Note: that is a direct quote from the reference.
> 
> We know that `XCHG` with a memory destination operand is atomic
> and affects memory ordering, etc, regardless of whether the
> `LOCK` prefix is explicitly given or not.  The issue is that
> that sentence, taken in complete isolation, makes it sound like
> this is _also_ the case for `xchg reg, reg`, where the
> destination is a _register_ operand.
> 
> I claim that that is a misreading, and that a reader should
> interpret that last sentence in the context of the first
> sentence in that paragraph, that refers specifically to memory
> operands; furthermore, other parts of the SDM are clear that
> `xchg reg, reg` has no impact on memory ordering, bus locks,
> etc.
> 
> Regardless, that sentence is ambiguous.  References to the
> description of `XCHG`, or to the locking protocols in volume 3,
> does not change that.
> 
> The latest version of the entire Intel SDM is available online:
> https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
> I had already quoted the paragarph in question in its entirely.
> 
> 	- Dan C.
> 


When I want to know what particular insruction does I go to respective
section in Instruction Set Reference.
I can believe that there exist other methodes, but I prefere mine.

[toc] | [prev] | [next] | [standalone]

#118703

In article <20261018205430.00001490@yahoo.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>[snip]
>When I want to know what particular insruction does I go to respective
>section in Instruction Set Reference.
>I can believe that there exist other methodes, but I prefere mine.

Unfortunately, that does not change the fact that there are
multiple sections in the SDM that _can_ be read as mutually
inconsistent with regards to the exact semantics of this
particular operation.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#118701

Michael S <already5chosen@yahoo.com> posted:

> On Sun, 18 Oct 2026 15:08:23 GMT
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> 
> > MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> > >cross@spitfire.i.gajendra.net (Dan Cross) posted:  
> > >> What I'm saying is that, as written, the bits in the `LOCK`
> > >> description above _could_ be interpreted to mean that _any_
> > >> `XCHG` will always assert the `LOCK#` signal, including an
> > >> `XCHG` that does not touch memory at all.  The "Why?" was
> > >> rhetorical, as in, "Why would the system do that?"  For example,
> > >> if one wrote, `xchg %ecx, %eax`, why should that assert `LOCK#`?
> > >> Truly I don't know, and I was just speculating.  
> > >
> > >Writing high quality documentation is fundamentally hard.  
> > 
> > I don't think that's the issue here.  They just did not limit the
> > sentence "The XCHG instruction always asserts the LOCK# signal
> > regardless of the presence or absence of the LOCK prefix."  to XCHG
> > instructions with memory operands.  That would be easy to fix, but
> > they did not.  And Chris M. Thomasson understood it as including
> > XCHG reg, reg.
> > 
> > My guess is that it is easy to fix in principle, but you have to deal
> > with all kinds of red tape for such a fix, so unless there is good
> > reason, you don't do it.
> > 
> 
> Frankly, I don't understand what both you and Dan Cross are talking
> about.
> I don't see how sentence from Intel's manual ("If a memory operand is
> referenced, the processor’s locking protocol is automatically
> implemented for the duration of the exchange operation, regardless of
> the presence or absence of the LOCK prefix or of the value of the IOPL")
> or sentence from AMD's manual ("If either operand references memory,
> the processor locks automatically, whether or not the LOCK prefix is
> used and independently of the value of IOPL.") can be pssibly
> misunderstood.

Look at it from the perspective of the guy verifying that on-die 
interconnect is being used correctly by the cores. {{not every
designer is inside the core !!}}

Say protocol has space for XCHG-Lock and XCHG-without, and the cores
are using later instead of former because the destination does not
need the -lock part to be ATOMIC.
> 
> 

[toc] | [prev] | [next] | [standalone]

#118700

In article <2026Oct18.170823@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>>cross@spitfire.i.gajendra.net (Dan Cross) posted:
>>> What I'm saying is that, as written, the bits in the `LOCK`
>>> description above _could_ be interpreted to mean that _any_
>>> `XCHG` will always assert the `LOCK#` signal, including an
>>> `XCHG` that does not touch memory at all.  The "Why?" was
>>> rhetorical, as in, "Why would the system do that?"  For example,
>>> if one wrote, `xchg %ecx, %eax`, why should that assert `LOCK#`?
>>> Truly I don't know, and I was just speculating.
>>
>>Writing high quality documentation is fundamentally hard.
>
>I don't think that's the issue here.  They just did not limit the
>sentence "The XCHG instruction always asserts the LOCK# signal
>regardless of the presence or absence of the LOCK prefix."  to XCHG
>instructions with memory operands.  That would be easy to fix, but
>they did not.  And Chris M. Thomasson understood it as including
>XCHG reg, reg.
>
>My guess is that it is easy to fix in principle, but you have to deal
>with all kinds of red tape for such a fix, so unless there is good
>reason, you don't do it.

Nah; the SDM changes all the time.  It's hard to hand out
citations to it without an explicit version because of that.
There are mistakes all over it; most of them are pretty minor,
like cross-referring to an old section number or something.
Each revision fixes a few and adds a few others.

I think it just hasn't occurred to anyone that it could be
clearer.

>This sentence already exists in my 1994-vintage Pentium Processor
>User's Manual Vol. 3.  There it is preceeded by:
>
>|The LOCK prefix functions only with the following instructions:
>|
>|...
>|XCHG reg, mem
>|XCHG mem, reg
>|...
>
>With no occurence of XCHG reg, reg anywhere.  But, OTOH, this is not
>really a contradiction to the sentence "The XCHG instruction always
>asserts the LOCK# signal regardless of the presence or absence of the
>LOCK prefix."

Right.  The current text says more or less the same thing,
though phrased slightly differently: "The LOCK prefix can be
prepended only to the following instructions and only to those
forms of the instructions where the destination operand is a
memory operand: [list of instructions...]."

>>What they wrote may have well been exactly what the HW did back then
>>but somewhere between then and now architects and designers figured
>>out other ways and nobody went back to fully scrub the documents.
>
>Actually <https://www.felixcloutier.com/x86/lock> then says that
>"Beginning with the P6 family processors, when [...], the LOCK# signal
>is generally not asserted [...]" and still explains mechanism, finally
>saying "the operation is carried out atomically with regards to
>memory."  If they wrote that as the description of the LOCK prefix,
>much of the rest could be deleted.
>
>Generally, an architecture manual should talk about architectural
>effects, not about asserted signals.
>
>The operational semantics given in
><https://www.felixcloutier.com/x86/lock> is:
>
>| AssertLOCK#(DurationOfAccompaningInstruction);
>
>Oh boy.

That part is fine.  It's talking about the _explicit_ presence
of a `LOCK` prefix, and given the constraints on the
'accompaning' [sic] instruction, that tracks exactly what the
description says.  Volume 3A, sec 11.1.2, describes bus locking,
and what "asserting LOCK#" means.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#118691

In article <1792265982-5857@newsgrouper.org>,
MitchAlsup  <user5857@newsgrouper.org.invalid> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) posted:
>
>> In article <1792257076-5857@newsgrouper.org>,
>> MitchAlsup  <user5857@newsgrouper.org.invalid> wrote:
>> >cross@spitfire.i.gajendra.net (Dan Cross) posted:
>> >
>> >> In article <11au1vu$3ks5m$2@dont-email.me>,
>> >> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> >> >Dan Cross <cross@spitfire.i.gajendra.net> schrieb:
>> >> >> Unfortunately, the information is spread across two sections,
>> >> >> and they contradict.  The description in the `LOCK` prefix
>> >> >> section in the latest version of the Intel SDM includes the text
>> >> >> Anton quoted, while the description of `XCHG` itself makes clear
>> >> >> that the destination operand must be a memory operand for the
>> >> >> locking protocol to automatically apply.  Which is correct?
>> >> >
>> >> >What would be the meaning of LOCK with memory operands?  I can't
>> >> >think of any.
>> >> 
>> >> Using the `LOCK` prefix without a destination operand that is a
>> >> memory operand is an error, and the SDM is quite explicit about
>> >> that.  In fact, it says that an explicit `LOCK` prefix on an
>> >> `XCHG` a register destination operand is _not_ permitted and
>> >> "may" generate an `#UD` exception.
>> >> 
>> >> But sadly, when talking about an `XCHG` _without_ an explicit
>> >> operand, it is left ambiguous; all it says is that, "The `XCHG`
>> >> instruction always asserts the `LOCK#` signal regardless of the
>> >> presence or absence of the `LOCK` prefix."  Devoid of the rest
>> >> of the surrounding context, one could interpret that to mean
>> >> that an `XCHG` _always_ forces a bus lock, irrespective of the
>> >> type of its desintation operand.
>> >> 
>> >> Why? 
>> >
>> >Older machines performed the read, returned the read data to
>> >a core and then sent the data to be written back to memory;
>> >where the time between the read and the write was unknowable.
>> >
>> >Some newer machines take the data to be written and package it
>> >up in an interconnect transaction so the read and write happen
>> >on back-to-back cycles with no possibility of interference.
>> >These are ATOMIC even without any bus-locking. The data read 
>> >out is returned to the core.
>> 
>> No, I get that; I mean in the case where both operands to `XCHG`
>> are _register_ operands.
>> 
>> What I'm saying is that, as written, the bits in the `LOCK`
>> description above _could_ be interpreted to mean that _any_
>> `XCHG` will always assert the `LOCK#` signal, including an
>> `XCHG` that does not touch memory at all.  The "Why?" was
>> rhetorical, as in, "Why would the system do that?"  For example,
>> if one wrote, `xchg %ecx, %eax`, why should that assert `LOCK#`?
>> Truly I don't know, and I was just speculating.
>
>Writing high quality documentation is fundamentally hard. It took
>me nearly 40 years of doing so to get to the point a mischievous
>engineer could NOT misunderstand what I had written. It is harder
>wo write high quality documentation than perform circuit design.
>
>What they wrote may have well been exactly what the HW did back then
>but somewhere between then and now architects and designers figured
>out other ways and nobody went back to fully scrub the documents.

Maybe?  Probably?  I don't know.  *shrug*

I'm not trying to impugn the tech writers at Intel, who I think
generally do a great job.  But this particular paragraph has
obviously lead to some confusion.

Again, I think that, at the end of the day, `xchg reg, reg` has
no effect on memory ordering at all, and that sentence is meant
to be read within the context of that paragraph; ie, the `LOCK`
prefix is implied if it's not specifically given _and_ the
destination is a memory operand.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#118690

On 2026-Oct-17 13:31, Dan Cross wrote:
> In article <1792257076-5857@newsgrouper.org>,
> MitchAlsup  <user5857@newsgrouper.org.invalid> wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) posted:
>>
>>> In article <11au1vu$3ks5m$2@dont-email.me>,
>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>> Dan Cross <cross@spitfire.i.gajendra.net> schrieb:
>>>>> Unfortunately, the information is spread across two sections,
>>>>> and they contradict.  The description in the `LOCK` prefix
>>>>> section in the latest version of the Intel SDM includes the text
>>>>> Anton quoted, while the description of `XCHG` itself makes clear
>>>>> that the destination operand must be a memory operand for the
>>>>> locking protocol to automatically apply.  Which is correct?
>>>>
>>>> What would be the meaning of LOCK with memory operands?  I can't
>>>> think of any.
>>>
>>> Using the `LOCK` prefix without a destination operand that is a
>>> memory operand is an error, and the SDM is quite explicit about
>>> that.  In fact, it says that an explicit `LOCK` prefix on an
>>> `XCHG` a register destination operand is _not_ permitted and
>>> "may" generate an `#UD` exception.
>>>
>>> But sadly, when talking about an `XCHG` _without_ an explicit
>>> operand, it is left ambiguous; all it says is that, "The `XCHG`
>>> instruction always asserts the `LOCK#` signal regardless of the
>>> presence or absence of the `LOCK` prefix."  Devoid of the rest
>>> of the surrounding context, one could interpret that to mean
>>> that an `XCHG` _always_ forces a bus lock, irrespective of the
>>> type of its desintation operand.
>>>
>>> Why?
>>
>> Older machines performed the read, returned the read data to
>> a core and then sent the data to be written back to memory;
>> where the time between the read and the write was unknowable.
>>
>> Some newer machines take the data to be written and package it
>> up in an interconnect transaction so the read and write happen
>> on back-to-back cycles with no possibility of interference.
>> These are ATOMIC even without any bus-locking. The data read
>> out is returned to the core.
> 
> No, I get that; I mean in the case where both operands to `XCHG`
> are _register_ operands.
> 
> What I'm saying is that, as written, the bits in the `LOCK`
> description above _could_ be interpreted to mean that _any_
> `XCHG` will always assert the `LOCK#` signal, including an
> `XCHG` that does not touch memory at all.  The "Why?" was
> rhetorical, as in, "Why would the system do that?"  For example,
> if one wrote, `xchg %ecx, %eax`, why should that assert `LOCK#`?
> Truly I don't know, and I was just speculating.
> 
> But as I said, I don't think that is what the sentence in
> question is _actually_ saying, and I really don't think that
> `xchg %ecx, %eax` _actually_ asserts `LOCK#` (or, these days,
> has anything to do with cache coherency and memory ordering).
> 
>>>        I have no idea; as I said, I'm in the camp of going with
>>> what the description of `XCHG` itself says, and not the what the
>>> description of the `LOCK` prefix says: that sentence is _not_
>>> devoid of context, and besides, there has not been a physical
>>> `LOCK#` signal coming out of an Intel Xeon package since
>>> Nehalem.
>>>
>>> I suppose one could imagine it forcing a poor-man's barrier to
>>> prevent later loads from being reorderd before it (loads can't
>>> migrate before locked instructions).  But we've got explicit
>>> fence instructions for that, so I don't buy it.
>>>
>>> I suspect that sentence is just poorly phrased.
> 
> 	- Dan C.
> 

Intel Volume 3 System Programmers guide 10.1.2 Bus Locking
10.1.2.1 Automatic Locking is explicit: the automatic locking for XCHG
applies to memory operands only. There are a bunch of other situations
where automatic locking is asserted, such as setting the Accessed and
Modified bit on PTE's. BUT it can also depend on PTE caching attributes
and cpu model number.

The other manuals probably didn't want to worry programmers pretty little heads
with all those grotty details.

e.g.
10.1.4 Effects of a LOCK Operation on Internal Processor Caches

For the Intel486 and Pentium processors, the LOCK# signal is always asserted
on the bus during a LOCK operation, even if the area of memory being locked
is cached in the processor.

For the P6 and more recent processor families, if the area of memory being
locked during a LOCK operation is cached in the processor that is performing
the LOCK operation as write-back memory and is completely contained in a
cache line, the processor may not assert the LOCK# signal on the bus.
... blah blah blah

[toc] | [prev] | [next] | [standalone]

#118695

In article <nv6BS.146451$4b2.140904@fx47.iad>,
EricP  <ThatWouldBeTelling@thevillage.com> wrote:
>On 2026-Oct-17 13:31, Dan Cross wrote:
>[snip]
>Intel Volume 3 System Programmers guide 10.1.2 Bus Locking
>10.1.2.1 Automatic Locking is explicit:...
>[snip]

Yes, which in my view, lends more support to requiring that the
sentence in question in the description of the `LOCK` prefix be
read in the context of the overall paragraph, which is clearly
talking about cases where the destination is a memory operand.

Sadly, however, that doesn't make the sentence itself any less
ambiguous, and once you have ambiguity in a technical document
like the SDM, you've got a problem.

Intel can fix this easily by adding another phrase to that last
sentence, ", when the destination is a memory operand."  (Or
words to that effect.)  I'm speculating, but they probably
haven't because it seems rather obvious that that is the intent,
and no one has brought it up as a problem.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#118706

On 10/16/2026 7:50 PM, Dan Cross wrote:
> In article <11au1vu$3ks5m$2@dont-email.me>,
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Dan Cross <cross@spitfire.i.gajendra.net> schrieb:
>>> Unfortunately, the information is spread across two sections,
>>> and they contradict.  The description in the `LOCK` prefix
>>> section in the latest version of the Intel SDM includes the text
>>> Anton quoted, while the description of `XCHG` itself makes clear
>>> that the destination operand must be a memory operand for the
>>> locking protocol to automatically apply.  Which is correct?
>>
>> What would be the meaning of LOCK with memory operands?  I can't
>> think of any.
> 
> Using the `LOCK` prefix without a destination operand that is a
> memory operand is an error, and the SDM is quite explicit about
> that.  In fact, it says that an explicit `LOCK` prefix on an
> `XCHG` a register destination operand is _not_ permitted and
> "may" generate an `#UD` exception.
> 
> But sadly, when talking about an `XCHG` _without_ an explicit
> operand, it is left ambiguous; all it says is that, "The `XCHG`
> instruction always asserts the `LOCK#` signal regardless of the
> presence or absence of the `LOCK` prefix."  Devoid of the rest
> of the surrounding context, one could interpret that to mean
> that an `XCHG` _always_ forces a bus lock, irrespective of the
> type of its desintation operand.
> 
> Why?  I have no idea; as I said, I'm in the camp of going with
> what the description of `XCHG` itself says, and not the what the
> description of the `LOCK` prefix says: that sentence is _not_
> devoid of context, and besides, there has not been a physical
> `LOCK#` signal coming out of an Intel Xeon package since
> Nehalem.

Try a LOCK RMW on memory that straddles a L2 cache line. That should 
trigger a full bus lock.




> 
> I suppose one could imagine it forcing a poor-man's barrier to
> prevent later loads from being reorderd before it (loads can't
> migrate before locked instructions).  But we've got explicit
> fence instructions for that, so I don't buy it.
> 
> I suspect that sentence is just poorly phrased.
> 
> 	- Dan C.
> 

[toc] | [prev] | [next] | [standalone]

#118724

On 2026-Oct-18 15:27, Chris M. Thomasson wrote:
> 
> Try a LOCK RMW on memory that straddles a L2 cache line. That should trigger a full bus lock.

FYI there is an article measuring the effects of cache line split locks

Investigating Split Locks on x86-64
https://chipsandcheese.com/p/investigating-split-locks-on-x86

[toc] | [prev] | [next] | [standalone]

#118729

On 10/19/2026 6:38 AM, EricP wrote:
> On 2026-Oct-18 15:27, Chris M. Thomasson wrote:
>>
>> Try a LOCK RMW on memory that straddles a L2 cache line. That should 
>> trigger a full bus lock.
> 
> FYI there is an article measuring the effects of cache line split locks
> 
> Investigating Split Locks on x86-64
> https://chipsandcheese.com/p/investigating-split-locks-on-x86
> 

I see. Actually, a way to "abuse" it even further is to use a LOCK RMW, 
say even LOCK XADD on something that straddles a cache line issues a bus 
lock. So, I have seen some papers on abusing QPI to gain a remote memory 
barrier or async sync for things like RCU. FlushProcessWriteBuffers 
(windows way), I forgot the damn Linux thing. I think it might be 
sys_membarrier...

[toc] | [prev] | [next] | [standalone]

#118730

On Mon, 19 Oct 2026 14:08:53 -0700, Chris M. Thomasson wrote:

> I forgot the damn Linux thing. I think it might be sys_membarrier...

<https://manpages.debian.org/membarrier(2)> ?

[toc] | [prev] | [next] | [standalone]

#118731

On 10/19/2026 2:21 PM, Lawrence D’Oliveiro wrote:
> On Mon, 19 Oct 2026 14:08:53 -0700, Chris M. Thomasson wrote:
> 
>> I forgot the damn Linux thing. I think it might be sys_membarrier...
> 
> <https://manpages.debian.org/membarrier(2)> ?

Has to be it. Afaict, its a way to help algorithms like RCU, or 
basically any async sync pattern. Say the readers are cheap, the writers 
not so cheap... Fwiw, here is the windows side of the coin:

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushprocesswritebuffers

[toc] | [prev] | [next] | [standalone]

#118734

On 10/19/26 5:08 PM, Chris M. Thomasson wrote:
> On 10/19/2026 6:38 AM, EricP wrote:
>> On 2026-Oct-18 15:27, Chris M. Thomasson wrote:
>>>
>>> Try a LOCK RMW on memory that straddles a L2 cache line. That should 
>>> trigger a full bus lock.
>>
>> FYI there is an article measuring the effects of cache line split locks
>>
>> Investigating Split Locks on x86-64
>> https://chipsandcheese.com/p/investigating-split-locks-on-x86
>>
> 
> I see. Actually, a way to "abuse" it even further is to use a LOCK RMW, 
> say even LOCK XADD on something that straddles a cache line issues a bus 
> lock. So, I have seen some papers on abusing QPI to gain a remote memory 
> barrier or async sync for things like RCU. FlushProcessWriteBuffers 
> (windows way), I forgot the damn Linux thing. I think it might be 
> sys_membarrier...


You are thinking of IPI (inter processsor interrupt) maybe?  membarrier
changed to that apparently because the quiesce points used by the RCU
implementation of membarrier weren't frequent enough.

[toc] | [prev] | [next] | [standalone]

#118739

On 10/19/2026 4:17 PM, Joseph Seigh wrote:
> On 10/19/26 5:08 PM, Chris M. Thomasson wrote:
>> On 10/19/2026 6:38 AM, EricP wrote:
>>> On 2026-Oct-18 15:27, Chris M. Thomasson wrote:
>>>>
>>>> Try a LOCK RMW on memory that straddles a L2 cache line. That should 
>>>> trigger a full bus lock.
>>>
>>> FYI there is an article measuring the effects of cache line split locks
>>>
>>> Investigating Split Locks on x86-64
>>> https://chipsandcheese.com/p/investigating-split-locks-on-x86
>>>
>>
>> I see. Actually, a way to "abuse" it even further is to use a LOCK 
>> RMW, say even LOCK XADD on something that straddles a cache line 
>> issues a bus lock. So, I have seen some papers on abusing QPI to gain 
>> a remote memory barrier or async sync for things like RCU. 
>> FlushProcessWriteBuffers (windows way), I forgot the damn Linux thing. 
>> I think it might be sys_membarrier...
> 
> 
> You are thinking of IPI (inter processsor interrupt) maybe?  membarrier
> changed to that apparently because the quiesce points used by the RCU
> implementation of membarrier weren't frequent enough.

I remember reading a paper from somebody, was it Dice? Damn! Cannot 
remember right now. That abused the QPI, I think the quick path 
interconnect, to give them a "remote" membar to implement async algos. 
Iirc they used misaligned LOCK RMW on something that straddled a l2 
cache line to make the system assert a bus lock. I know I read the damn 
paper but it was way back. Iiirc around 2006-2008 ish? I cannot remember.

The IPI uses things like FlushProcessWriteBuffers over on Windows, Linux 
has one to.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.arch

csiph-web