Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>INC and DEC are egregiously misdesigned. They only modify part
>>of the flags registers, which creates all kinds of dependencies
>>on previous writes to the flag registers.
>>
>>Just don't use them.
>
> These instructions cause complications during CPU design. These
> complications are in the CPU and paid for, so there is no reason not
> to use these instructions.

I think Agner Fog explains it better than I can.

From his "Optimizing subroutines in assembly language - An
optimization guide for x86 platforms" in the version of
2021-01-31:

# The INC and DEC instructions do not modify the carry flag but
# they do modify the other arithmetic flags. Writing to only part
# of the flags register costs an extra μop on some CPUs. It can
# cause a partial flags stalls on some older Intel processors if
# a subsequent instruction reads the carry flag or all the flag
# bits. On all processors, it can cause a false dependence on the
# carry flag from a previous instruction.

# Use ADD and SUB when optimizing for speed. Use INC and DEC when
# optimizing for size or when no penalty is expected.

> And if you think that Intel/AMD will be able to get rid of these
> instructions if VFX Forth does not use them, think again.

It will surely be kept, but if I were king, I would ban generating
these instructions in all compilers unless explictly optimizing
for size.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>INC and DEC are egregiously misdesigned. They only modify part
>>>of the flags registers, which creates all kinds of dependencies
>>>on previous writes to the flag registers.
>>>
>>>Just don't use them.
>>
>> These instructions cause complications during CPU design. These
>> complications are in the CPU and paid for, so there is no reason not
>> to use these instructions.
>
>I think Agner Fog explains it better than I can.
>
>From his "Optimizing subroutines in assembly language - An
>optimization guide for x86 platforms" in the version of
>2021-01-31:
>
># The INC and DEC instructions do not modify the carry flag but
># they do modify the other arithmetic flags. Writing to only part
># of the flags register costs an extra μop on some CPUs. It can
># cause a partial flags stalls on some older Intel processors if
># a subsequent instruction reads the carry flag or all the flag
># bits.

Unfortunately, this does not tell me which CPUs are affected.

># On all processors, it can cause a false dependence on the
># carry flag from a previous instruction.

That seems to presume that INC and DEC work by producing a single
merged flags result, so INC/DEC would need to merge the flags they
change with the carry flag from some earlier instruction. AFAIK in
modern CPUs (probably going back quite a while) there are three
individual flag parts (IIRC C,V, and the rest). Intel demonstrates
with ADX that Intel CPUs don't have such a performance gotcha, and
IIRC Mitch Alsup mentioned that AMD also does it that way (don't
remember when they started with that).

>It will surely be kept, but if I were king, I would ban generating
>these instructions in all compilers unless explictly optimizing
>for size.

You are king, at least in name:-)

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

Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> # On all processors, it can cause a false dependence on the
>> # carry flag from a previous instruction.
>
> That seems to presume that INC and DEC work by producing a single
> merged flags result, so INC/DEC would need to merge the flags they
> change with the carry flag from some earlier instruction. AFAIK in
> modern CPUs (probably going back quite a while) there are three
> individual flag parts (IIRC C,V, and the rest). Intel demonstrates
> with ADX that Intel CPUs don't have such a performance gotcha, and
> IIRC Mitch Alsup mentioned that AMD also does it that way (don't
> remember when they started with that).

There are many other instructions that do partial flags updates.
e.g. BTC Bit Test and Complement, CMPXCHGxxx Compare and Exchange,

The various shift SAL/SAR/SHL/SHR and rotate RCL/RCR/ROL/ROR
only updates CF flag if the masked count is != 0.
Rotates update OF if masked count == 0 but shifts do not.
Other flags are unaffected.
So shift unit has to read the old CF and OF and decide whether
to overwrite or propagate them based on count and operation.

On Wednesday, April 28, 2021 at 12:28:45 PM UTC-5, EricP wrote:
> Anton Ertl wrote:
> > Thomas Koenig <tko...@netcologne.de> writes:
> >
> >> # On all processors, it can cause a false dependence on the
> >> # carry flag from a previous instruction.
> >
> > That seems to presume that INC and DEC work by producing a single
> > merged flags result, so INC/DEC would need to merge the flags they
> > change with the carry flag from some earlier instruction. AFAIK in
> > modern CPUs (probably going back quite a while) there are three
> > individual flag parts (IIRC C,V, and the rest). Intel demonstrates
> > with ADX that Intel CPUs don't have such a performance gotcha, and
> > IIRC Mitch Alsup mentioned that AMD also does it that way (don't
> > remember when they started with that).
> There are many other instructions that do partial flags updates.
> e.g. BTC Bit Test and Complement, CMPXCHGxxx Compare and Exchange,
>
> The various shift SAL/SAR/SHL/SHR and rotate RCL/RCR/ROL/ROR
> only updates CF flag if the masked count is != 0.
> Rotates update OF if masked count == 0 but shifts do not.
> Other flags are unaffected.
> So shift unit has to read the old CF and OF and decide whether
> to overwrite or propagate them based on count and operation.
<
The architect who designed this flag stuff should be taken out and shot,
then hanged, drawn and quartered, and dropped in boiling oil.

MitchAlsup wrote:
> On Wednesday, April 28, 2021 at 12:28:45 PM UTC-5, EricP wrote:
>> Anton Ertl wrote:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>
>>>> # On all processors, it can cause a false dependence on the
>>>> # carry flag from a previous instruction.
>>>
>>> That seems to presume that INC and DEC work by producing a single
>>> merged flags result, so INC/DEC would need to merge the flags they
>>> change with the carry flag from some earlier instruction. AFAIK in
>>> modern CPUs (probably going back quite a while) there are three
>>> individual flag parts (IIRC C,V, and the rest). Intel demonstrates
>>> with ADX that Intel CPUs don't have such a performance gotcha, and
>>> IIRC Mitch Alsup mentioned that AMD also does it that way (don't
>>> remember when they started with that).
>> There are many other instructions that do partial flags updates.
>> e.g. BTC Bit Test and Complement, CMPXCHGxxx Compare and Exchange,
>>
>> The various shift SAL/SAR/SHL/SHR and rotate RCL/RCR/ROL/ROR
>> only updates CF flag if the masked count is != 0.
>> Rotates update OF if masked count == 0 but shifts do not.
>> Other flags are unaffected.
>> So shift unit has to read the old CF and OF and decide whether
>> to overwrite or propagate them based on count and operation.
> <
> The architect who designed this flag stuff should be taken out and shot,
> then hanged, drawn and quartered, and dropped in boiling oil.
>
Hmmm...

To me it almost sounds like you don't particularly like it, tell me that
can't be true!

More seriously, with perfect 20-20 hindsight it would have been better,
starting about 20 years after the original 8086 design, to have had a
separate set of flag-updating instructions.

OTOH, I really cannot blame them too much given how many times I have
taken advantage of the various flag quirks in my asm code, and as I
wrote a few days ago, some of these were crucially important in getting
the 8088 in the original PC to run usefully fast.

The main Achilles' heel back then was the extremely low bandwidth of
just 1/4 byte per cycle, and it had to be shared by code & data
combined, so minimizing the number of executed bytes as well as taken
branches were the only really important rules.

In real code the only common instructions that ran slower then their
load time was probably just MUL and the repeated string ops. I know I
used a MUL to allow the prefetch queue to fill up when I wanted to
measure the size of it to check if I was running on an 8088 or a 16-bit
bus 8086 (which had 2 more prefetch buffer bytes).

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Wednesday, April 28, 2021 at 2:24:21 PM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Wednesday, April 28, 2021 at 12:28:45 PM UTC-5, EricP wrote:
> >> Anton Ertl wrote:
> >>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>
> >>>> # On all processors, it can cause a false dependence on the
> >>>> # carry flag from a previous instruction.
> >>>
> >>> That seems to presume that INC and DEC work by producing a single
> >>> merged flags result, so INC/DEC would need to merge the flags they
> >>> change with the carry flag from some earlier instruction. AFAIK in
> >>> modern CPUs (probably going back quite a while) there are three
> >>> individual flag parts (IIRC C,V, and the rest). Intel demonstrates
> >>> with ADX that Intel CPUs don't have such a performance gotcha, and
> >>> IIRC Mitch Alsup mentioned that AMD also does it that way (don't
> >>> remember when they started with that).
> >> There are many other instructions that do partial flags updates.
> >> e.g. BTC Bit Test and Complement, CMPXCHGxxx Compare and Exchange,
> >>
> >> The various shift SAL/SAR/SHL/SHR and rotate RCL/RCR/ROL/ROR
> >> only updates CF flag if the masked count is != 0.
> >> Rotates update OF if masked count == 0 but shifts do not.
> >> Other flags are unaffected.
> >> So shift unit has to read the old CF and OF and decide whether
> >> to overwrite or propagate them based on count and operation.
> > <
> > The architect who designed this flag stuff should be taken out and shot,
> > then hanged, drawn and quartered, and dropped in boiling oil.
> >
> Hmmm...
>
> To me it almost sounds like you don't particularly like it, tell me that
> can't be true!
<
I jest not.
<
>
> More seriously, with perfect 20-20 hindsight it would have been better,
> starting about 20 years after the original 8086 design, to have had a
> separate set of flag-updating instructions.
>
No flags at all is better still. The PDP-8 showed the way (excepting for that
link bit thingie.)
>
>
> OTOH, I really cannot blame them too much given how many times I have
> taken advantage of the various flag quirks in my asm code, and as I
> wrote a few days ago, some of these were crucially important in getting
> the 8088 in the original PC to run usefully fast.
>
> The main Achilles' heel back then was the extremely low bandwidth of
> just 1/4 byte per cycle, and it had to be shared by code & data
> combined, so minimizing the number of executed bytes as well as taken
> branches were the only really important rules.
>
> In real code the only common instructions that ran slower then their
> load time was probably just MUL and the repeated string ops. I know I
> used a MUL to allow the prefetch queue to fill up when I wanted to
> measure the size of it to check if I was running on an 8088 or a 16-bit
> bus 8086 (which had 2 more prefetch buffer bytes).
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

MitchAlsup wrote:
> On Wednesday, April 28, 2021 at 12:28:45 PM UTC-5, EricP wrote:
>> Anton Ertl wrote:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>
>>>> # On all processors, it can cause a false dependence on the
>>>> # carry flag from a previous instruction.
>>> That seems to presume that INC and DEC work by producing a single
>>> merged flags result, so INC/DEC would need to merge the flags they
>>> change with the carry flag from some earlier instruction. AFAIK in
>>> modern CPUs (probably going back quite a while) there are three
>>> individual flag parts (IIRC C,V, and the rest). Intel demonstrates
>>> with ADX that Intel CPUs don't have such a performance gotcha, and
>>> IIRC Mitch Alsup mentioned that AMD also does it that way (don't
>>> remember when they started with that).
>> There are many other instructions that do partial flags updates.
>> e.g. BTC Bit Test and Complement, CMPXCHGxxx Compare and Exchange,
>>
>> The various shift SAL/SAR/SHL/SHR and rotate RCL/RCR/ROL/ROR
>> only updates CF flag if the masked count is != 0.
>> Rotates update OF if masked count == 0 but shifts do not.
>> Other flags are unaffected.
>> So shift unit has to read the old CF and OF and decide whether
>> to overwrite or propagate them based on count and operation.
> <
> The architect who designed this flag stuff should be taken out and shot,
> then hanged, drawn and quartered, and dropped in boiling oil.

INC, DEC and RCL/RCR/ROL/ROR are courtesy of the 8008.
The rotates were 1 bit only and it had no shifts.
It has 4 flags, carry, zero, sign and parity
and the partial flag updates starts here
(e.g. rotates only update CF not others).

The auxiliary carry flag, aka half/nibble carry, comes from the 8080.

The overflow flag and multi-bit shifts and rotates are from 8086.

The real kicker is that for shifts, the value of the OF flag
is only set correctly if the shift count == 1.
For all other count values, the OF flag is undefined
(and the 8086 manual notes this).

So to summarize, in x86 and x64, WRT shifts and the overflow flag,
all that separate flag rename and value forwarding and OoO wake-up
network logic everyone worked so diligently to create,
its' purpose is to maintain compatibility back to the 8086
with a value that, for shift count != 1, is documented as garbage.

Have a nice day! :-)