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

#118665

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.

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]

#118675

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.

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

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

#118677

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.

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

#118679

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

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

#118680

On Sat, 17 Oct 2026 19:39:42 GMT
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.

How do you know?
Nature is inventive.

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

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

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

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.

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

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

On Sat, 17 Oct 2026 20:54:44 -0000 (UTC), Lawrence D´Oliveiro
<ldo@nz.invalid> wrote:

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

The problem with the original report was that they attempted with the
grammar turn [at least some kinds of] semantic errors into syntax
errors.

Note that the *revised* report used a different grammar - something
they called "NEST": still 2-level, still very complex [though less so
than the original vW grammar], but they did not try to encode
semantics directly, instead referencing discussions in accompanying
text.

I read both 68 reports - original and revised. Mind you it was long
ago, but my recollection is that the revised report really wasn't any
more understandable than the original ... just longer because the NEST
formalism was somewhat less expressive than the vW.

YMMV.


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

+1

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

#118687 — Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg))

George Neuner <gneuner2@comcast.net> writes:
>On Sat, 17 Oct 2026 20:54:44 -0000 (UTC), Lawrence D´Oliveiro
><ldo@nz.invalid> wrote:
>>Isn’t that why formal specification languages were invented? For some
>>reason they never caught on.
>>
>>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.
>
>The problem with the original report was that they attempted with the
>grammar turn [at least some kinds of] semantic errors into syntax
>errors.

My take is that BNF was a big success in formalizing a part of a
language.  So what do you do when you are successful?  You try to
follow up on that.  So they wanted to formalize more of the language,
and go beyond the limits of BNF (context-free grammars) with Vw
grammars.  This was technically successful, but from a usability POV
it was not.

Nevertheless, there have been attempts to formally specify programming
languages completely, or at least more of them than just the
context-free grammar part of them.  AFAIK all attempts to formally
specify everything in the language definition have been unsuccessful:
not only did the specification become too hard to understand for the
programmers, but it seems to me that the programming language also
became to hard to extend by its designers.

A team at the IBM Lab in Vienna made a formal specification for PL/I;
I attended a lecture by Heinz Zemanek (the team leader) where he
mentioned something about an implementor disagreeing with the formal
specification for recursion (disagreements between implementor and
specification can also happen with specifications written in a natural
language, so that may not say much).  Anyway,
<https://en.wikipedia.org/wiki/PL/I#Standardization> says "The
standard is couched as a formal definition[17] using a "PL/I
Machine"[21] to specify the semantics."  This sounds like the
operational semantics that was developed by the IBM Lab Vienna, so
maybe the standardization committee picked up this work.  But it seems
that the first standard never had a followon; was the definition too
unwieldy?

Standard ML has been formally specified, and, given the audience of
this language, if any programming language may have success going
there, it should be a language like ML.  There is a first revision
(1990) and a second revision (1997), and SML seems to have reached the
end of its evolution there.

Other programming languages have formalized parts of the language
beyond the context-free grammar, probably the parts that can be
described well with a formalism, such as the type system.  I guess
some of these attempts have been successful, and others not so much.

Concerning terms like "semantic errors" or "static semantics" they
make it appear that there is a fundamental difference between syntax
and "static semantics" (the part that is not context-free and that is
checked by the compiler).  It seems to me that that's just a matter of
what is expressed in the BNF.  E.g., in Algol 60 the computation of
conditions for if-statements have special BNF rules, whereas some
later programming languages have a boolean type and putting a
non-boolean between IF and THEN produces a type error, not a syntax
error.

So I don't think that there is a fundamental difference, and if there
was a formalism that is as easy to work with (both for programmers and
for language designers) as BNF is, we would be using that formalism
for that; and if that formalism also took over the role that BNF has
now, we would be considering all the errors that this formalism finds
to be in the same category.

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

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

#118710 — Re: Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg))

I thought, though, that the main problem with Algol 68 was not that it
was described poorly, but that although people were still able to
understand the language well enough despite an unconventional formal
description language... it was a large and complicated language,
advancing the state of the art, and thus it was found difficult to
implement.
Hence, Pascal - a language which modernized Algol 60 without trying to
be a language on an entirely new level.

John Savard

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

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

On Mon, 19 Oct 2026 00:09:11 GMT, John Savard wrote:

> I thought, though, that the main problem with Algol 68 was not that
> it was described poorly, but that although people were still able to
> understand the language well enough despite an unconventional formal
> description language... it was a large and complicated language,
> advancing the state of the art, and thus it was found difficult to
> implement.

Algol 60 was a difficult language to implement less than a decade
earlier. It was a driver of the state of the art back then, too.
(And some still found it hard in 1968.)

I think the form of the language specification played a big part in
making it seem more intimidating than it was.

Algol 68 would be a doddle to implement nowadays. In fact, Marcel Van
Der Veer’s “Algol 68 Genie” implementation is being incorporated into
GCC, I believe.

Many of the terms pioneered in the Algol 68 specification did become
popular -- which shows you how new those concepts were at the time:
“heap”, “overload”, “dereference”. Others were not so popular:
“transput” (for “I/O”), “name” (for “address”, would you believe),
“mode” (for “type”).

C took syntax words like “struct”, “void”, “int”, “long” and “short”
straight from Algol 68.

> Hence, Pascal - a language which modernized Algol 60 without trying
> to be a language on an entirely new level.

Niklaus Wirth was possibly the biggest critic of the Algol 68 effort.
He and Tony Hoare had previously created Algol-W, which pioneered the
concept of record structures (taking a simpler form than COBOL’s
convoluted record structures). Pascal was basically the next step in
the evolution of that.

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

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

On Mon, 19 Oct 2026 01:46:21 -0000 (UTC), Lawrence
=?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:

>Niklaus Wirth was possibly the biggest critic of the Algol 68 effort.
>He and Tony Hoare had previously created Algol-W, which pioneered the
>concept of record structures (taking a simpler form than COBOL’s
>convoluted record structures). Pascal was basically the next step in
>the evolution of that.

And, of course, one might mention MODULA-2, which took certain
advanced ideas seen in Ada and put them in a Pascal-like context.

John Savard

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

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

On 2026-10-21 17:15, John Savard wrote:
> On Mon, 19 Oct 2026 01:46:21 -0000 (UTC), Lawrence
> =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
> 
>> Niklaus Wirth was possibly the biggest critic of the Algol 68 effort.
>> He and Tony Hoare had previously created Algol-W, which pioneered the
>> concept of record structures (taking a simpler form than COBOL’s
>> convoluted record structures). Pascal was basically the next step in
>> the evolution of that.
> 
> And, of course, one might mention MODULA-2, which took certain
> advanced ideas seen in Ada and put them in a Pascal-like context.

My understanding is that the influences went from Modula-2 to Ada, and 
Wikipedia agrees with me, saying that Modula-2 first appeared in 1978. 
The development of these languages overlapped in time, but Modula-2 was 
finalized and published before Ada.

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

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

On Wed, 21 Oct 2026 18:34:46 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> wrote:

>My understanding is that the influences went from Modula-2 to Ada, and 
>Wikipedia agrees with me, saying that Modula-2 first appeared in 1978. 

You're quite right. I searched for more information, and apparently
Concurrent Pascal was "first", with MODULA-2 coming very shortly
after. And then, after the two competing models of those languages
were discussed for a while, Ada included the feature as well.

However, one source claimed that PL/I should really be given the
credit for including parallel constructs well before Concurrent
Pascal.

John Savard

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

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

John Savard <quadibloc@invalid.com> wrote:
> On Wed, 21 Oct 2026 18:34:46 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> wrote:
> 
>>My understanding is that the influences went from Modula-2 to Ada, and 
>>Wikipedia agrees with me, saying that Modula-2 first appeared in 1978. 
> 
> You're quite right. I searched for more information, and apparently
> Concurrent Pascal was "first", with MODULA-2 coming very shortly
> after. And then, after the two competing models of those languages
> were discussed for a while, Ada included the feature as well.
> 
> However, one source claimed that PL/I should really be given the
> credit for including parallel constructs well before Concurrent
> Pascal.

I think that's a rather IBM-centric view. The Burroughs B5000 (after
1961) OS was written in an Algol dialect called ESPOL, which
necessarily had concurrency support. The first production PL/I
compiler shipped in 1966.

Andrew.

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

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

On 10/21/2026 12:38 PM, John Savard wrote:
> On Wed, 21 Oct 2026 18:34:46 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> wrote:
> 
>> My understanding is that the influences went from Modula-2 to Ada, and
>> Wikipedia agrees with me, saying that Modula-2 first appeared in 1978.
> 
> You're quite right. I searched for more information, and apparently
> Concurrent Pascal was "first", with MODULA-2 coming very shortly
> after. And then, after the two competing models of those languages
> were discussed for a while, Ada included the feature as well.
> 
> However, one source claimed that PL/I should really be given the
> credit for including parallel constructs well before Concurrent
> Pascal.

I vaguely recall that there was an optional feature in the COBOL 
standard for concurrent processing, or something like that.  It wasn't 
implemented in the compiler I used and I never investigated exactly what 
it was.  But it certainly predated Pascal, Ad and other such languages.

Does anyone else know anything about this?



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

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

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

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 10/21/2026 12:38 PM, John Savard wrote:
>> On Wed, 21 Oct 2026 18:34:46 +0300, Niklas Holsti
>> <niklas.holsti@tidorum.invalid> wrote:
>> 
>>> My understanding is that the influences went from Modula-2 to Ada, and
>>> Wikipedia agrees with me, saying that Modula-2 first appeared in 1978.
>> 
>> You're quite right. I searched for more information, and apparently
>> Concurrent Pascal was "first", with MODULA-2 coming very shortly
>> after. And then, after the two competing models of those languages
>> were discussed for a while, Ada included the feature as well.
>> 
>> However, one source claimed that PL/I should really be given the
>> credit for including parallel constructs well before Concurrent
>> Pascal.
>
>I vaguely recall that there was an optional feature in the COBOL 
>standard for concurrent processing, or something like that.  It wasn't 
>implemented in the compiler I used and I never investigated exactly what 
>it was.  But it certainly predated Pascal, Ad and other such languages.
>
>Does anyone else know anything about this?

Burroughs added concurrent programming extensions to COBOL74 back
in the 70's.   USAGE IS TASK, for example; also the PROCESS verb
was added.

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

#118717 — Re: PL/I, was Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg))

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>A team at the IBM Lab in Vienna made a formal specification for PL/I;
>I attended a lecture by Heinz Zemanek (the team leader) where he
>mentioned something about an implementor disagreeing with the formal
>specification for recursion (disagreements between implementor and
>specification can also happen with specifications written in a natural
>language, so that may not say much).  Anyway,
><https://en.wikipedia.org/wiki/PL/I#Standardization> says "The
>standard is couched as a formal definition[17] using a "PL/I
>Machine"[21] to specify the semantics."  This sounds like the
>operational semantics that was developed by the IBM Lab Vienna, so
>maybe the standardization committee picked up this work.  But it seems
>that the first standard never had a followon; was the definition too
>unwieldy?

I have a copy of the ANSI PL/I standard which uses VDL which I find close to impenetrable.

The syntax part is OK but the semantics are endless definitions of something
in terms of something else and I could never find the places where your program
actually did anything.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#118718 — Re: PL/I, was Algol 68 (was: Documentation (was Re: Performance of xchg reg,reg))

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>A team at the IBM Lab in Vienna made a formal specification for PL/I;
>>I attended a lecture by Heinz Zemanek (the team leader) where he
>>mentioned something about an implementor disagreeing with the formal
>>specification for recursion (disagreements between implementor and
>>specification can also happen with specifications written in a natural
>>language, so that may not say much).  Anyway,
>><https://en.wikipedia.org/wiki/PL/I#Standardization> says "The
>>standard is couched as a formal definition[17] using a "PL/I
>>Machine"[21] to specify the semantics."  This sounds like the
>>operational semantics that was developed by the IBM Lab Vienna, so
>>maybe the standardization committee picked up this work.  But it seems
>>that the first standard never had a followon; was the definition too
>>unwieldy?
>
>I have a copy of the ANSI PL/I standard which uses VDL which I find close to impenetrable.

Thanks.  Yes, VDL is the specification language that the group at IBM
Labs Vienna designed in order to define the formal semantics of PL/I
(the V in VDL stands for Vienna).  So the PL/I standard used their
work.

>The syntax part is OK but the semantics are endless definitions of something
>in terms of something else and I could never find the places where your program
>actually did anything.

Interesting.  I have seen this overfactoring in programs as well as
natural-language specifications.  Factoring is useful to avoid
repeating stuff, but when you are interested in one specific thing,
you would rather prefer that much of the factored-out stuff is
inlined.

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

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

#118720 — Re: Algol 68

Anton Ertl [2026-10-18 14:08:34] wrote:
> My take is that BNF was a big success in formalizing a part of a
> language.  So what do you do when you are successful?  You try to
> follow up on that.  So they wanted to formalize more of the language,
> and go beyond the limits of BNF (context-free grammars) with Vw
> grammars.  This was technically successful, but from a usability POV
> it was not.

Yup.  That was before type systems.

> Standard ML has been formally specified, and, given the audience of
> this language, if any programming language may have success going
> there, it should be a language like ML.  There is a first revision
> (1990) and a second revision (1997), and SML seems to have reached the
> end of its evolution there.

FWIW, I don't think the end of SML's evolution is a consequence of its
having a formal spec, but admittedly, some of the factors that made it
have a formal spec may have also been factors in the end of
its evolution.

> Concerning terms like "semantic errors" or "static semantics" they
> make it appear that there is a fundamental difference between syntax
> and "static semantics" (the part that is not context-free and that is
> checked by the compiler).  It seems to me that that's just a matter of
> what is expressed in the BNF.

Agreed.  The dividing line between lexical analysis, syntactic analysis,
and "static semantics" mostly comes down to what is most convenient
for a given set of tools: those things that work well with a regexp/DFA
get handled in the lexical analysis, then those which work well with
BNF/PEG are done in the syntactic analysis, and whatever's left over is
dumped into the "static semantics".

> E.g., in Algol 60 the computation of conditions for if-statements have
> special BNF rules, whereas some later programming languages have
> a boolean type and putting a non-boolean between IF and THEN produces
> a type error, not a syntax error.

Because in the mean time, people realized that moving it to types makes
for a simpler grammar and in return they let you have a more flexible
language where you can precompute those booleans into a variable that
you later test in the if-statement.

A related example would be `break` statements in C, which are allowed to
occur only in loops and switch statements: you could encode that detail
directly in the grammar, but it's usually considered easier to do it
later on as a "static check" (more clear, less code).  Not only it's
simpler but it also makes it easier to emit meaningful error messages.


=== Stefan

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

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

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?

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.

John Savard

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

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

Back to top | Article view | comp.arch

csiph-web