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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#118713 — Re: Documentation (was Re: Performance of xchg reg,reg)

In article <6ad5609b.8505984@news.eternal-september.org>,
John Savard <quadibloc@invalid.com> wrote:
>On Sun, 18 Oct 2026 09:45:00 -0400, George Neuner
><gneuner2@comcast.net> wrote:
>
>>The problem with the original report was that they attempted with the
>>grammar turn [at least some kinds of] semantic errors into syntax
>>errors.
>
>Obviously, there's no way one can enable a compiler to flag logic
>errors in programs. A Turing-complete language can calculate anything,
>so how can it tell you that you were calculating this when you wanted
>to calculate that?

With apologies, arguments like these always seem to me to miss
the forest for the trees a bit.  Some constructs clearly violate
the documented semantics of e.g. a language.

Yes, these langauges are all Turing-complete and so on, and no,
we cannot solve _The_ Halting Problem, in all of its glorious
generality.  But, we can solve any number of specific halting
_problems_.  For example, I can see that, `for (;;);` is a loop
that does not terminate.  With enough effort, I can take that
down some reasonably long paths.

So, too, one can spot a lot of logic errors.  There's no reason
a compiler can't see this, for example:

?	if (ptr == NULL) {
?		int v = *ptr++;
?		*ptr = v + 10;
?	}

And flag it with a error: "you dereferenced a pointer right
after you asserted it was nil; did you invert the condition?"

Similarly, I posted about Rust a few days ago, which can do all
sorts of fun stuff with its borrow checker to assert that an
object is still alive while references to it exist, and so on,
and reject programs at compilation time that violate those
semantics.

>Of course, with AI, we might be able to do something there.
>
>But already many modern languages do have strict type-checking.
>
>So even if Algol 68 was over-ambitious in this regard, trying to have
>the language help the programmer avoid more mistakes is basically a
>sound idea.

Agreed.  Indeed, we've gone much farther than just mere type
checking.

	- Dan C.
	

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

#118727 — Re: Documentation (was Re: Performance of xchg reg,reg)

On Mon, 19 Oct 2026 01:52:51 -0000 (UTC),
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

>In article <6ad5609b.8505984@news.eternal-september.org>,
>John Savard <quadibloc@invalid.com> wrote:
>>On Sun, 18 Oct 2026 09:45:00 -0400, George Neuner
>><gneuner2@comcast.net> wrote:
>>
>>>The problem with the original report was that they attempted with the
>>>grammar turn [at least some kinds of] semantic errors into syntax
>>>errors.
>>
>>Obviously, there's no way one can enable a compiler to flag logic
>>errors in programs. A Turing-complete language can calculate anything,
>>so how can it tell you that you were calculating this when you wanted
>>to calculate that?
>
>With apologies, arguments like these always seem to me to miss
>the forest for the trees a bit.  Some constructs clearly violate
>the documented semantics of e.g. a language.
>
>Yes, these langauges are all Turing-complete and so on, and no,
>we cannot solve _The_ Halting Problem, in all of its glorious
>generality.  But, we can solve any number of specific halting
>_problems_.  For example, I can see that, `for (;;);` is a loop
>that does not terminate.  With enough effort, I can take that
>down some reasonably long paths.
>
>So, too, one can spot a lot of logic errors.  There's no reason
>a compiler can't see this, for example:
>
>?	if (ptr == NULL) {
>?		int v = *ptr++;
>?		*ptr = v + 10;
>?	}
>
>And flag it with a error: "you dereferenced a pointer right
>after you asserted it was nil; did you invert the condition?"


Absolutely compiler analysis can catch (some) semantic errors ... that
never was in question.  


The problem with the *original* Algol68 report was that they tried to
encode semantics using the syntax, the idea being that the parser then
could catch semantic errors as syntax errors.

The revised report changed direction: the syntax no longer tried to
encode the semantics ... but it still was hard to read because the
syntax definitions made copious /reference/ to semantics discussed in
accompanying text.


>Similarly, I posted about Rust a few days ago, which can do all
>sorts of fun stuff with its borrow checker to assert that an
>object is still alive while references to it exist, and so on,
>and reject programs at compilation time that violate those
>semantics.
>
>>Of course, with AI, we might be able to do something there.
>>
>>But already many modern languages do have strict type-checking.
>>
>>So even if Algol 68 was over-ambitious in this regard, trying to have
>>the language help the programmer avoid more mistakes is basically a
>>sound idea.
>
>Agreed.  Indeed, we've gone much farther than just mere type
>checking.
>
>	- Dan C.
>	

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

#118737 — Re: Documentation (was Re: Performance of xchg reg,reg)

In article <7tocdllvftsndin92d9q2kjf90if8dha8p@4ax.com>,
George Neuner  <gneuner2@comcast.net> wrote:
>On Mon, 19 Oct 2026 01:52:51 -0000 (UTC),
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>>In article <6ad5609b.8505984@news.eternal-september.org>,
>>John Savard <quadibloc@invalid.com> wrote:
>>>On Sun, 18 Oct 2026 09:45:00 -0400, George Neuner
>>><gneuner2@comcast.net> wrote:
>>>
>>>>The problem with the original report was that they attempted with the
>>>>grammar turn [at least some kinds of] semantic errors into syntax
>>>>errors.
>>>
>>>Obviously, there's no way one can enable a compiler to flag logic
>>>errors in programs. A Turing-complete language can calculate anything,
>>>so how can it tell you that you were calculating this when you wanted
>>>to calculate that?
>>
>>With apologies, arguments like these always seem to me to miss
>>the forest for the trees a bit.  Some constructs clearly violate
>>the documented semantics of e.g. a language.
>>
>>Yes, these langauges are all Turing-complete and so on, and no,
>>we cannot solve _The_ Halting Problem, in all of its glorious
>>generality.  But, we can solve any number of specific halting
>>_problems_.  For example, I can see that, `for (;;);` is a loop
>>that does not terminate.  With enough effort, I can take that
>>down some reasonably long paths.
>>
>>So, too, one can spot a lot of logic errors.  There's no reason
>>a compiler can't see this, for example:
>>
>>?	if (ptr == NULL) {
>>?		int v = *ptr++;
>>?		*ptr = v + 10;
>>?	}
>>
>>And flag it with a error: "you dereferenced a pointer right
>>after you asserted it was nil; did you invert the condition?"
>
>Absolutely compiler analysis can catch (some) semantic errors ... that
>never was in question.  

Sorry, I was referring specifically to the factually incorrect
statement that "there's no way one can enable a compiler to flag
logic errors in programs," quoted above, which is flatly
incorrect.

>The problem with the *original* Algol68 report was that they tried to
>encode semantics using the syntax, the idea being that the parser then
>could catch semantic errors as syntax errors.
>
>The revised report changed direction: the syntax no longer tried to
>encode the semantics ... but it still was hard to read because the
>syntax definitions made copious /reference/ to semantics discussed in
>accompanying text.

Oophf.  Sounds painful.

	- Dan C.

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

#118714 — Re: Algol 68 (was Re: Documentation)

On Mon, 19 Oct 2026 00:18:32 GMT, John Savard wrote:

> Obviously, there's no way one can enable a compiler to flag logic
> errors in programs. A Turing-complete language can calculate
> anything, so how can it tell you that you were calculating this when
> you wanted to calculate that?

All the Algol 68 two-level grammar approach was trying to do was
formalize rules that were already being spelled out in narrative text
in other contemporary (and subsequent) language specifications. Basic
things like
  * A name for something must be declared before it can be referenced.
  * Types of expected versus actual values must be compatible, with
    some predefined set of implicit conversions allowed (e.g.
    passing/assigning an integer where a float value is expected, but
    not the other way round).
  * A redeclaration of a name in an inner scope shadows (makes
    inaccessible for the duration) a definition in an outer scope.

There was (and still is) the debate over what is “syntax” and what is
“semantics”? Algol 68 was just trying to push the boundary to take
some of what was thought to be “semantics” and show that it was just
“syntax”, after all.

So you see, they were not trying to do overly clever stuff like the
Java compiler insisting that a variable could possibly be accessed
before its first assignment, and this can’t be allowed, when it’s
quite apparent to any human reader that can follow the program logic,
that no such situation can occur.

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

#118721 — Re: Documentation (was Re: Performance of xchg reg,reg)

John Savard <quadibloc@invalid.com> schrieb:
> On Sun, 18 Oct 2026 09:45:00 -0400, George Neuner
><gneuner2@comcast.net> wrote:
>
>>The problem with the original report was that they attempted with the
>>grammar turn [at least some kinds of] semantic errors into syntax
>>errors.
>
> Obviously, there's no way one can enable a compiler to flag logic
> errors in programs.

>A Turing-complete language can calculate anything,
> so how can it tell you that you were calculating this when you wanted
> to calculate that?

There are three possibilities:  a) A formal verification can succeed,
b) it can fail to make a determination, or c) it can show up bugs.

c) is already implemented with many compiler warnings and errors,
a simple example:

$ cat do.f90
program main
  implicit none
  integer :: i
  real, dimension(5) :: a
  do i=1,6
    a(i) = i + 2
  end do
  print *,a
end

$ gfortran do.f90
do.f90:6:6:

    5 |   do i=1,6
      |          2
    6 |     a(i) = i + 2
      |      1
Warning: Array reference at (1) out of bounds (6 > 5) in loop beginning at (2)

If you develop code with formal verification and hit b), you have the
option of not accepting the code.

I believe Lean is a language which implements a) and shows missing
goals for b), but I have never worked with it.

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

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

#118728 — Re: Documentation (was Re: Performance of xchg reg,reg)

John Savard [2026-10-19 00:18:32] wrote:
> Obviously, there's no way one can enable a compiler to flag logic
> errors in programs.

Compilers' ability to report errors mostly depend on the presence of
redundancy in the source code.  That redundancy depends can be
influenced by the design of the language.

So, in theory, a compiler can very much flag most logic errors in
a program, simply by requiring all source code to come in two different
forms (e.g. a "spec" and an "implementation") and to automatically
verify that the two match.

> A Turing-complete language can calculate anything, so how can it tell
> you that you were calculating this when you wanted to calculate that?

And the same still holds for non-Turing-complete languages, admittedly.


=== Stefan

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

#118696 — Re: Documentation (was Re: Performance of xchg reg,reg)

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted:

> On Sat, 17 Oct 2026 19:39:42 GMT, MitchAlsup wrote:
> 
> > Writing high quality documentation is fundamentally hard.
> 
> Isn’t that why formal specification languages were invented? For some
> reason they never caught on.

There numerous examples of "minutia" in CPU design where one can 
never provide a sufficiently formal quantification of what that
part does. A series of unsigned operations culminating in a signed
operation that result in a single multi-wide signed result.
 
> For a classic example, look at the Algol-68 language spec. Yet many
> people threw up their hands in horror at how it was written.
> 
> > It took me nearly 40 years of doing so to get to the point a
> > mischievous engineer could NOT misunderstand what I had written.
> 
> Presumably you include lots of examples?

Yes, a while back I was having a bit of trouble describing shift
instructions {both signed and unsigned} in snippets of C-like
code. Eventually, I drew up figures illustrating how each bit
moved through the calculation(s). And the figures did way more 
in the definition department than any c-code snippet could.

For example (especially) the double wide shift instructions and
insert instructions that arise when the shift instruction is in
the shadow of a CARRY modifier. It is easy in a figure to illus-
trate how bits cross from one 64-bit container to another, over-
flow off the top and shift up into another from the bottom (and
vice versa).

>                                          I remember something Jerry
> Pournelle said, critiquing the product documentation he had to read
> for his columns in “BYTE” magazine, back in the day: “You can never
> have too many examples”.

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

#118684

On Sat, 17 Oct 2026 19:39:42 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:


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

+1


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

Also remember that the documents are describing the operations of a
family of implementations.  However unlikely, there may be members
that still have to play by those old rules.

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

#118688

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.

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

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

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

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

#118689

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.

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

#118692

Michael S <already5chosen@yahoo.com> writes:
>On Sun, 18 Oct 2026 15:08:23 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> 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.
...
>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=E2=80=99s 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.

Chris M. Thomasson wrote in <11arg45$2p70p$1@dont-email.me>:
|Well, for some reason the LOCK prefix is implied for XCHG.

Given that the thread up to that point was aboyt XCHG reg, reg (and
according to the subject it still is), he seems to be an example that
what Intel wrote about XCHG and LOCK can be misunderstood.  I looked
at the documentation and cited the relevant sentences in
<2026Oct16.075055@mips.complang.tuwien.ac.at>; most occurences clearly
refer only to XCHG where one operand is in memory.  The exception is:

|The XCHG instruction always asserts the LOCK# signal regardless of the
|presence or absence of the LOCK prefix.

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.  I don't think that's
what Intel intends and implements, but that's what a reading of their
manual implies.

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

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

#118694

On Sun, 18 Oct 2026 16:57:26 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Michael S <already5chosen@yahoo.com> writes:
> >On Sun, 18 Oct 2026 15:08:23 GMT
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:  
> >> 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.  
> ...
> >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=E2=80=99s 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.  
> 
> Chris M. Thomasson wrote in <11arg45$2p70p$1@dont-email.me>:
> |Well, for some reason the LOCK prefix is implied for XCHG.
> 
> Given that the thread up to that point was aboyt XCHG reg, reg (and
> according to the subject it still is), he seems to be an example that
> what Intel wrote about XCHG and LOCK can be misunderstood.  I looked
> at the documentation and cited the relevant sentences in
> <2026Oct16.075055@mips.complang.tuwien.ac.at>; most occurences clearly
> refer only to XCHG where one operand is in memory.  The exception is:
> 
> |The XCHG instruction always asserts the LOCK# signal regardless of
> the |presence or absence of the LOCK prefix.
> 

What is a source of this? Intel, AMD or somebody else?

> 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.  I don't think that's
> what Intel intends and implements, but that's what a reading of their
> manual implies.
> 
> - anton

Somehow, it does not imply it to me.

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

#118702

In article <20261018204738.00006b41@yahoo.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>On Sun, 18 Oct 2026 16:57:26 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>> >On Sun, 18 Oct 2026 15:08:23 GMT
>> >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:  
>> >> 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.  
>> ...
>> >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=E2=80=99s 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.  
>> 
>> Chris M. Thomasson wrote in <11arg45$2p70p$1@dont-email.me>:
>> |Well, for some reason the LOCK prefix is implied for XCHG.
>> 
>> Given that the thread up to that point was aboyt XCHG reg, reg (and
>> according to the subject it still is), he seems to be an example that
>> what Intel wrote about XCHG and LOCK can be misunderstood.  I looked
>> at the documentation and cited the relevant sentences in
>> <2026Oct16.075055@mips.complang.tuwien.ac.at>; most occurences clearly
>> refer only to XCHG where one operand is in memory.  The exception is:
>> 
>> |The XCHG instruction always asserts the LOCK# signal regardless of
>> the |presence or absence of the LOCK prefix.
>
>What is a source of this? Intel, AMD or somebody else?

This citation has been given many times now, but here it is yet
again: That is the last sentence of the third paragraph in the
"Description" section of the entry on the `LOCK` prefix in
Volume 2A of the Intel SDM, order number 253668-093US (September
2026), page 3-565.  That volume can be downloaded from Intel at:
https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html

>> 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.  I don't think that's
>> what Intel intends and implements, but that's what a reading of their
>> manual implies.
>
>Somehow, it does not imply it to me.

Note that Anton said that it is an implication of _A_ reading
of the manual, not of _ALL_ readings of the manual.  Hence why
it is ambiguous.

	- Dan C.

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

#118707

Michael S <already5chosen@yahoo.com> writes:
>On Sun, 18 Oct 2026 16:57:26 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> |The XCHG instruction always asserts the LOCK# signal regardless of
>> the |presence or absence of the LOCK prefix.
>> 
>
>What is a source of this? Intel, AMD or somebody else?

Intel, from (at least) the 1994 edition of the Pentium Processor
User's Manual Vol 3., through the source of
<https://www.felixcloutier.com/x86/lock>, to the latest SDM cited by
Dan Cross.

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

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

#118719

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.


=== Stefan

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

#118725

On 10/18/2026 8:43 PM, Stefan Monnier 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.
> 
> 
> === Stefan

I believe this all started with empirical data from Anton showing 
different performance between Intel and AMD processors for XCHG 
reg,reg.  There was some speculation that Intel asserted the lock 
protocol and that was the cause.  The discussion then moved to at best 
confusing, and perhaps contradictory documentation.  But has anyone 
addressed the original question?

Specifically, do Intel processors actually do the lock stuff when it 
isn't necessary?  If so, is the cause of the difference?  If not, what 
is the cause?

-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#118732

On 10/19/2026 6:57 AM, Stephen Fuld wrote:
> On 10/18/2026 8:43 PM, Stefan Monnier 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.
>>
>>
>> === Stefan
> 
> I believe this all started with empirical data from Anton showing 
> different performance between Intel and AMD processors for XCHG 
> reg,reg.  There was some speculation that Intel asserted the lock 
> protocol and that was the cause.  The discussion then moved to at best 
> confusing, and perhaps contradictory documentation.  But has anyone 
> addressed the original question?
> 
> Specifically, do Intel processors actually do the lock stuff when it 
> isn't necessary?  If so, is the cause of the difference?  If not, what 
> is the cause?
> 

Bingo! Tango, Locked on.

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

#118748

Stephen Fuld [2026-10-19 06:57:48] wrote:
> On 10/18/2026 8:43 PM, Stefan Monnier 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.
>> === Stefan
> I believe this all started with empirical data from Anton showing different
> performance between Intel and AMD processors for XCHG reg,reg.

Indeed but my question is about the ISA definition, i.e. independent
from any specific implementation.


=== Stefan

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

#118736

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

|Locked operations are atomic with respect to all other memory
|operations and all externally visible events. Only instruction
|fetch and page table accesses can pass locked instructions.
|Locked instructions can be used to synchronize data written by
|one processor and read by another processor.

For example, this could be used before releasing a lock to
prevent a load from migrating into the critical section (though
on a TSO machine this should be ok, since a load can't be
reordered before a store to the same location).

	- Dan C.

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

#118741

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.

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

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

Back to top | Article view | comp.arch

csiph-web