Ivan Godard wrote:
> On 1/25/2022 7:48 AM, EricP wrote:
>> Stephen Fuld wrote:
>>> On 1/22/2022 3:42 AM, Terje Mathisen wrote:
>>>> Stephen Fuld wrote:
>>>
>>>>> Anyway, if one had this instruction, the main loop in the code
>>>>> above could be something like
>>>>>
>>>>>
>>>>> loop:
>>>>> LDUB R10,[R1+R9]
>>>>> CARRY R6,IO
>>>>> LBF R12,R10,R2 ;I am not sure about R2, It should
>>>>> be the start of the packed buffer.
>>>>> STD R12,[R3+R9<<3]
>>>>> ADD R9,R9,#1
>>>>> CMP R11,R9,R4
>>>>> BLT R11,loop
>>>>
>>>> That is really quite nice.
>>>
>>> Thank you!
>>>
>>>
>>>>>
>>>>> For a savings of about 10 instructions in the I cache, but fewer in
>>>>> execution (but still significant) depending upon how often the
>>>>> instructions under the predicate are executed.
>>>>>
>>>>>
>>>>> Anyway, Of course, I invite comments, criticisms, etc. One obvious
>>>>> drawback is that this only addresses the "decompression" side.
>>>>> While I briefly considered a "Store Bit Field", I discarded it as
>>>>> it seemed too complex, and presumably would used less frequently,
>>>>> as compression/coding happens less frequently than
>>>>> decompression/decoding.
>>>>
>>>> Encoding is almost always far easier than decoding, since there are
>>>> zero surprises when encoding. Yes, for codecs/compression it can be
>>>> a _lot_ of work to figure out a near-optimal encoding, but the
>>>> actual conversion of the selected option into a bit stream is easy.
>>>
>>> Good point, that I hadn't thought of. More reason why the
>>> hypothetical "Store Bit Field" isn't needed.
>>
>> High bandwith compression happens more these days with video
>> conferencing.
>> Maybe its a chicken & egg thing - we do more because we can do more.
>>
>> Unless Bit Field Insert requires significantly more hardware than
>> BF Extract I don't see why one would leave it out.
>>
>> BFEXT requires a data and BF specifier source regs + 1 dest reg,
>> so fits in the standard RISC 2R 1W port model.
>>
>> BFINS requires a struct source, data source, BF specifier regs, + dest
>> reg,
>> so 3R 1W ports. Also instruction would require 4 register specifiers
>> unless you allow the struct source and dest reg to be the same specifier.
>> That bothers some, but if you have FMA then you probably have already
>> crossed that Rubicon. I would rather have the functionality than stick
>> to a somewhat arbitrary design philosophy.
>>
>> There are a bunch of bit field manipulation instructions beyond those
>> useful for multimedia codec encode/decode, signal processing, crypto.
>> butterfly, reverse butterfly, permute, mix.
>>
>> Then there is the whole area of double-wide shifts and bit fields
>> to facilitate bit stream processing.
>>
>>
>
> You don't offer dynamic BFINS/EXT? Dynamc needs two more registers,
> unless you separately buid a descriptor like Mitch.

Similar to Mitch, I'd have a bit field specifier as two 1-byte items,
the width and start pos, either in lower 16 bits of a register,
or a 16-bit immed constant.

That allows both to fit in 32-bit instructions.

BFEXT rd_data, rs1_struct, rs2_wpfield
BFEXT rd_data, rs1_struct, <#width,#pos>

BFINS rsd_struct, rs1_data, rs2_wpfield
BFINS rsd_struct, rs1_data, <#width,#pos>

Note for insert the rsd_struct is both source and dest register.

Future long format instructions could separate out the 5 insert registers
but that requires a 48-bit instruction, and I didn't want to bite off
the wide decoder right off the bat as that affects the whole fetch logic.

I'm still debating double-wide instruction formats.
Insert/extract could be very long format with 5-8 register specifiers.
Alternatively it could be two instructions operating on high and low parts,
like MULL and MULH.

EricP wrote:
> Ivan Godard wrote:
>>
>> You don't offer dynamic BFINS/EXT? Dynamc needs two more registers,
>> unless you separately buid a descriptor like Mitch.
>
> Similar to Mitch, I'd have a bit field specifier as two 1-byte items,
> the width and start pos, either in lower 16 bits of a register,
> or a 16-bit immed constant.
>
> That allows both to fit in 32-bit instructions.
>
> BFEXT rd_data, rs1_struct, rs2_wpfield
> BFEXT rd_data, rs1_struct, <#width,#pos>

Oh and BFEXT sign extends the result.
There is also BFEXTZ to extract and zero extend result.

> BFINS rsd_struct, rs1_data, rs2_wpfield
> BFINS rsd_struct, rs1_data, <#width,#pos>
>
> Note for insert the rsd_struct is both source and dest register.
>
> Future long format instructions could separate out the 5 insert registers
> but that requires a 48-bit instruction, and I didn't want to bite off
> the wide decoder right off the bat as that affects the whole fetch logic.
>
> I'm still debating double-wide instruction formats.
> Insert/extract could be very long format with 5-8 register specifiers.
> Alternatively it could be two instructions operating on high and low parts,
> like MULL and MULH.

The wide bit field instructions extract and insert a 1..64 bit
value in a 128-bit two register container.
These essentially take all the branchy code dealing with register
straddles and sign/zero extend and makes it straight line code.

My concern is to not embed in the ISA a requirement for a large
number of read or write ports. For example, on an FPGA which has
1R 1W register banks, every extra read port requires a duplicate
register bank, and a write port requires an extra write cycle.
So keeping the ISA to requiring 3R 1W ports is a goal.

For wide extract, the low part is extracted to position 0.
The high part, if any, is extracted and positioned at some
offset in its output data. Then the low and high are OR'd.
There is also some fiddling about to get the sign extension right
depending on whether it lands in the low or high part.

BWEXTL rd_datal, rs1_structl, rs2_wpfield
BWEXTH rd_datah, rs1_structh, rs2_wpfield
OR rsd_datah, rs_datal

So a wide extract takes 3 instructions and only needs 2R 1W ports.
And there are variants with immediate <#width,#pos> and for zero extended.

Wide insert modifies the high and low structs separately as needed
and needs 3R 1W ports like BFINS.

BWINSL rsd_structl, rs1_data, rs2_wpfield
BWINSH rsd_structh, rs1_data, rs2_wpfield

Again, the struct register is both source and dest but that
allows the 3 register instruction to fit into the 32-bit format.

MitchAlsup wrote:
> On Tuesday, January 25, 2022 at 1:07:11 PM UTC-6, EricP wrote:
>>
>> A New Basis for Shifters in General-Purpose Processors for
>> Existing and Advanced Bit Manipulations, 2008
>> https://www.researchgate.net/publication/220332176_A_New_Basis_for_Shifters_in_General-Purpose_Processors_for_Existing_and_Advanced_Bit_Manipulations
>>
> <
> My 66000 ISA encodings:
> <
>> describes the following bit field operations:
>> - rotate right & left
> CARRY Rs,{I}
> SL/SR Rd,Rs,off
>> - shift right & left with zero or sign fill
> SL/SR Rd,Rs,off
>> - bit field extract & insert
> SL Rd,Rs,<len,off>
> INS Rd,Rb,<len,off>
>> - mix select right or left subwords
> MUX Rd,Rs1,Rs2,mask // but level multiplex between s1 and s2 based on S3
>> - butterfly and inverse butterfly
> BITR Rd,Rs,<len,off>
>> - parallel extract and insert (scatter, gather)
>> - popcount
> POP Rd,Rs
>> - bit dot product
> ???

It was described in a different paper
"Advanced Bit Manipulation Instruction Set Architecture" 2006 as:

The DOTPROD instruction ANDs its two inputs, r2 and r3,
and then computes the parity of the result.
DOTPROD replaces a sequence of
- AND of the two inputs,
- POPCNT of the result,
- AND to isolate the least significant bit.

Example Usage: Error correcting coding.

>> - bit matrix multiply
> BMM Rd,Rb,[Rbm]
>> I would add:
>> - find first/last bit set/clear
> FF1 Rd,Rs // can be from the left or from the right.
> FF1 Rd,~Rs
> SET = INS Rd,#~0,<len,off>
> CLR = IINS Rd,#0,<len,off>
> <
> Looks like I got most of them.

On Wednesday, January 26, 2022 at 9:54:42 AM UTC-6, EricP wrote:
> MitchAlsup wrote:
> > On Tuesday, January 25, 2022 at 1:07:11 PM UTC-6, EricP wrote:
> >>
> >> A New Basis for Shifters in General-Purpose Processors for
> >> Existing and Advanced Bit Manipulations, 2008
> >> https://www.researchgate.net/publication/220332176_A_New_Basis_for_Shifters_in_General-Purpose_Processors_for_Existing_and_Advanced_Bit_Manipulations
> >>
> > <
> > My 66000 ISA encodings:
> > <
> >> describes the following bit field operations:
> >> - rotate right & left
> > CARRY Rs,{I}
> > SL/SR Rd,Rs,off
> >> - shift right & left with zero or sign fill
> > SL/SR Rd,Rs,off
> >> - bit field extract & insert
> > SL Rd,Rs,<len,off>
> > INS Rd,Rb,<len,off>
> >> - mix select right or left subwords
> > MUX Rd,Rs1,Rs2,mask // but level multiplex between s1 and s2 based on S3
> >> - butterfly and inverse butterfly
> > BITR Rd,Rs,<len,off>
> >> - parallel extract and insert (scatter, gather)
> >> - popcount
> > POP Rd,Rs
> >> - bit dot product
> > ???
> It was described in a different paper
> "Advanced Bit Manipulation Instruction Set Architecture" 2006 as:
>
> The DOTPROD instruction ANDs its two inputs, r2 and r3,
> and then computes the parity of the result.
> DOTPROD replaces a sequence of
> - AND of the two inputs,
> - POPCNT of the result,
> - AND to isolate the least significant bit.
<
Thanks.
>
> Example Usage: Error correcting coding.
> >> - bit matrix multiply
> > BMM Rd,Rb,[Rbm]
> >> I would add:
> >> - find first/last bit set/clear
> > FF1 Rd,Rs // can be from the left or from the right.
> > FF1 Rd,~Rs
> > SET = INS Rd,#~0,<len,off>
> > CLR = IINS Rd,#0,<len,off>
> > <
> > Looks like I got most of them.

On 1/25/2022 11:06 AM, EricP wrote:
> Stephen Fuld wrote:
>> On 1/25/2022 7:48 AM, EricP wrote:
>>
>>> There are a bunch of bit field manipulation instructions beyond those
>>> useful for multimedia codec encode/decode, signal processing, crypto.
>>> butterfly, reverse butterfly, permute, mix.
>>
>> Can you tell us what they are?
>
> I don't personally need such instructions as I rarely operate on
> bit fields and when I do it is not performance critical,
> but I note that others feel they do need them. One example paper:
>
> A New Basis for Shifters in General-Purpose Processors for
> Existing and Advanced Bit Manipulations, 2008
> https://www.researchgate.net/publication/220332176_A_New_Basis_for_Shifters_in_General-Purpose_Processors_for_Existing_and_Advanced_Bit_Manipulations
>
>
> describes the following bit field operations:
> - rotate right & left
> - shift right & left with zero or sign fill
> - bit field extract & insert
> - mix select right or left subwords
> - butterfly and inverse butterfly
> - parallel extract and insert (scatter, gather)
> - popcount
> - bit dot product
> - bit matrix multiply
>
> I would add:
> - find first/last bit set/clear
>
> potential usage in:
>
> - dna sequencing and sequence compression, alignment
> - crypto
> - error correction
> - bit stream signal processing, multiplexing
>

Thank you for the link. As Mitch said, his design includes almost all
of these, and many/most have been included in machines from mainframes
in the 1960s. As far as the details of the circuitry to implement them,
which the paper talks about, I am not competent to comment.

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

On 1/26/2022 7:01 AM, EricP wrote:
> EricP wrote:
>> Ivan Godard wrote:
>>>
>>> You don't offer dynamic BFINS/EXT? Dynamc needs two more registers,
>>> unless you separately buid a descriptor like Mitch.
>>
>> Similar to Mitch, I'd have a bit field specifier as two 1-byte items,
>> the width and start pos, either in lower 16 bits of a register,
>> or a 16-bit immed constant.
>>
>> That allows both to fit in 32-bit instructions.
>>
>>   BFEXT rd_data, rs1_struct, rs2_wpfield
>>   BFEXT rd_data, rs1_struct, <#width,#pos>
>
> Oh and BFEXT sign extends the result.
> There is also BFEXTZ to extract and zero extend result.
>
>>   BFINS rsd_struct, rs1_data, rs2_wpfield
>>   BFINS rsd_struct, rs1_data, <#width,#pos>
>>
>> Note for insert the rsd_struct is both source and dest register.
>>
>> Future long format instructions could separate out the 5 insert registers
>> but that requires a 48-bit instruction, and I didn't want to bite off
>> the wide decoder right off the bat as that affects the whole fetch logic.
>>
>> I'm still debating double-wide instruction formats.
>> Insert/extract could be very long format with 5-8 register specifiers.
>> Alternatively it could be two instructions operating on high and low
>> parts,
>> like MULL and MULH.
>
> The wide bit field instructions extract and insert a 1..64 bit
> value in a 128-bit two register container.
> These essentially take all the branchy code dealing with register
> straddles and sign/zero extend and makes it straight line code.

I don't think so for successive operations, like decompressing the next
character from a compressed string. At least as I understand what you
are saying, on the first operation, you load the first two words and
extract some bits. But now you don't know if the next field to extract
is entirely contained in the words you have loaded, or spans into the
third word. Depending on this, you either do or don't need to load the
third word. If you say you always load the "starting word" and the next
one, you are sometimes doing extra loads of data that is already in a
register.

>
> My concern is to not embed in the ISA a requirement for a large
> number of read or write ports. For example, on an FPGA which has
> 1R 1W register banks, every extra read port requires a duplicate
> register bank, and a write port requires an extra write cycle.
> So keeping the ISA to requiring 3R 1W ports is a goal.

Understood. For your restrictions, my proposal would not work. :-( It
was "tailored" to capabilities already provided in the My 66000
architecture.

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

On 1/26/2022 9:49 AM, MitchAlsup wrote:
> On Wednesday, January 26, 2022 at 9:54:42 AM UTC-6, EricP wrote:
>> MitchAlsup wrote:
>>> On Tuesday, January 25, 2022 at 1:07:11 PM UTC-6, EricP wrote:
>>>>
>>>> A New Basis for Shifters in General-Purpose Processors for
>>>> Existing and Advanced Bit Manipulations, 2008
>>>> https://www.researchgate.net/publication/220332176_A_New_Basis_for_Shifters_in_General-Purpose_Processors_for_Existing_and_Advanced_Bit_Manipulations
>>>>
>>> <
>>> My 66000 ISA encodings:

snip

>>>> - butterfly and inverse butterfly
>>> BITR Rd,Rs,<len,off>

I think this is the first time you have mentioned this instruction. Can
you give a description of what it does?

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

On Wednesday, January 26, 2022 at 12:33:53 PM UTC-6, Stephen Fuld wrote:
> On 1/26/2022 7:01 AM, EricP wrote:
> > EricP wrote:
> >> Ivan Godard wrote:
> >>>
> >>> You don't offer dynamic BFINS/EXT? Dynamc needs two more registers,
> >>> unless you separately buid a descriptor like Mitch.
> >>
> >> Similar to Mitch, I'd have a bit field specifier as two 1-byte items,
> >> the width and start pos, either in lower 16 bits of a register,
> >> or a 16-bit immed constant.
> >>
> >> That allows both to fit in 32-bit instructions.
> >>
> >> BFEXT rd_data, rs1_struct, rs2_wpfield
> >> BFEXT rd_data, rs1_struct, <#width,#pos>
> >
> > Oh and BFEXT sign extends the result.
> > There is also BFEXTZ to extract and zero extend result.
> >
> >> BFINS rsd_struct, rs1_data, rs2_wpfield
> >> BFINS rsd_struct, rs1_data, <#width,#pos>
> >>
> >> Note for insert the rsd_struct is both source and dest register.
> >>
> >> Future long format instructions could separate out the 5 insert registers
> >> but that requires a 48-bit instruction, and I didn't want to bite off
> >> the wide decoder right off the bat as that affects the whole fetch logic.
> >>
> >> I'm still debating double-wide instruction formats.
> >> Insert/extract could be very long format with 5-8 register specifiers.
> >> Alternatively it could be two instructions operating on high and low
> >> parts,
> >> like MULL and MULH.
> >
> > The wide bit field instructions extract and insert a 1..64 bit
> > value in a 128-bit two register container.
> > These essentially take all the branchy code dealing with register
> > straddles and sign/zero extend and makes it straight line code.
<
> I don't think so for successive operations, like decompressing the next
> character from a compressed string. At least as I understand what you
> are saying, on the first operation, you load the first two words and
> extract some bits. But now you don't know if the next field to extract
> is entirely contained in the words you have loaded, or spans into the
> third word. Depending on this, you either do or don't need to load the
> third word. If you say you always load the "starting word" and the next
> one, you are sometimes doing extra loads of data that is already in a
> register.
> >
> > My concern is to not embed in the ISA a requirement for a large
> > number of read or write ports. For example, on an FPGA which has
> > 1R 1W register banks, every extra read port requires a duplicate
> > register bank, and a write port requires an extra write cycle.
> > So keeping the ISA to requiring 3R 1W ports is a goal.
<
> Understood. For your restrictions, my proposal would not work. :-( It
> was "tailored" to capabilities already provided in the My 66000
> architecture.
<
The only functionality of My 66000 ISA that requires more than 3R1W
is when CARRY is attached to an instruction. Carry supplies another
Read and another write (up to 4R2W)
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 1/26/2022 11:59 AM, MitchAlsup wrote:
> On Wednesday, January 26, 2022 at 12:33:53 PM UTC-6, Stephen Fuld wrote:
>> On 1/26/2022 7:01 AM, EricP wrote:
>>> EricP wrote:
>>>> Ivan Godard wrote:
>>>>>
>>>>> You don't offer dynamic BFINS/EXT? Dynamc needs two more registers,
>>>>> unless you separately buid a descriptor like Mitch.
>>>>
>>>> Similar to Mitch, I'd have a bit field specifier as two 1-byte items,
>>>> the width and start pos, either in lower 16 bits of a register,
>>>> or a 16-bit immed constant.
>>>>
>>>> That allows both to fit in 32-bit instructions.
>>>>
>>>> BFEXT rd_data, rs1_struct, rs2_wpfield
>>>> BFEXT rd_data, rs1_struct, <#width,#pos>
>>>
>>> Oh and BFEXT sign extends the result.
>>> There is also BFEXTZ to extract and zero extend result.
>>>
>>>> BFINS rsd_struct, rs1_data, rs2_wpfield
>>>> BFINS rsd_struct, rs1_data, <#width,#pos>
>>>>
>>>> Note for insert the rsd_struct is both source and dest register.
>>>>
>>>> Future long format instructions could separate out the 5 insert registers
>>>> but that requires a 48-bit instruction, and I didn't want to bite off
>>>> the wide decoder right off the bat as that affects the whole fetch logic.
>>>>
>>>> I'm still debating double-wide instruction formats.
>>>> Insert/extract could be very long format with 5-8 register specifiers.
>>>> Alternatively it could be two instructions operating on high and low
>>>> parts,
>>>> like MULL and MULH.
>>>
>>> The wide bit field instructions extract and insert a 1..64 bit
>>> value in a 128-bit two register container.
>>> These essentially take all the branchy code dealing with register
>>> straddles and sign/zero extend and makes it straight line code.
> <
>> I don't think so for successive operations, like decompressing the next
>> character from a compressed string. At least as I understand what you
>> are saying, on the first operation, you load the first two words and
>> extract some bits. But now you don't know if the next field to extract
>> is entirely contained in the words you have loaded, or spans into the
>> third word. Depending on this, you either do or don't need to load the
>> third word. If you say you always load the "starting word" and the next
>> one, you are sometimes doing extra loads of data that is already in a
>> register.
>>>
>>> My concern is to not embed in the ISA a requirement for a large
>>> number of read or write ports. For example, on an FPGA which has
>>> 1R 1W register banks, every extra read port requires a duplicate
>>> register bank, and a write port requires an extra write cycle.
>>> So keeping the ISA to requiring 3R 1W ports is a goal.
> <
>> Understood. For your restrictions, my proposal would not work. :-( It
>> was "tailored" to capabilities already provided in the My 66000
>> architecture.
> <
> The only functionality of My 66000 ISA that requires more than 3R1W
> is when CARRY is attached to an instruction. Carry supplies another
> Read and another write (up to 4R2W)

Yes. The availability of the extra ports that CARRY provides are
integral to my proposal.

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

On Wednesday, January 26, 2022 at 1:15:02 PM UTC-6, Stephen Fuld wrote:
> On 1/26/2022 9:49 AM, MitchAlsup wrote:
> > On Wednesday, January 26, 2022 at 9:54:42 AM UTC-6, EricP wrote:
> >> MitchAlsup wrote:
> >>> On Tuesday, January 25, 2022 at 1:07:11 PM UTC-6, EricP wrote:
> >>>>
> >>>> A New Basis for Shifters in General-Purpose Processors for
> >>>> Existing and Advanced Bit Manipulations, 2008
> >>>> https://www.researchgate.net/publication/220332176_A_New_Basis_for_Shifters_in_General-Purpose_Processors_for_Existing_and_Advanced_Bit_Manipulations
> >>>>
> >>> <
> >>> My 66000 ISA encodings:
> snip
> >>>> - butterfly and inverse butterfly
> >>> BITR Rd,Rs,<len,off>
> I think this is the first time you have mentioned this instruction. Can
> you give a description of what it does?
<
What the document says: "Containers of size ≡ width are reverse into an
intermediate operand, and then this intermediate operand is shifted right
(SR) by the offset specification."
<
Len is restricted to powers of 2.
<
So reversing all of the bytes in a register would be::
BITR Rd,Rs,<8,0>
Reversing the higher order 5 bytes in a register would be::
BITR Rd,Rs,<8,40>
The 5 HoBytes in LE from Rs go into the LoBytes of Rd in BE.
<
To reverse all of the bits in a register:
BITR Rd,Rs,<1,0>
To reverse all of the 4-bit fields in a register
BITR Rd,Rs,<4,0>
To reverse the first three (3) 16-bit fields
BITR Rd,Rs,<16,16>
<
I don't remember why I restricted the len field to be power of 2.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 1/26/2022 12:34 PM, MitchAlsup wrote:
> On Wednesday, January 26, 2022 at 1:15:02 PM UTC-6, Stephen Fuld wrote:
>> On 1/26/2022 9:49 AM, MitchAlsup wrote:
>>> On Wednesday, January 26, 2022 at 9:54:42 AM UTC-6, EricP wrote:
>>>> MitchAlsup wrote:
>>>>> On Tuesday, January 25, 2022 at 1:07:11 PM UTC-6, EricP wrote:
>>>>>>
>>>>>> A New Basis for Shifters in General-Purpose Processors for
>>>>>> Existing and Advanced Bit Manipulations, 2008
>>>>>> https://www.researchgate.net/publication/220332176_A_New_Basis_for_Shifters_in_General-Purpose_Processors_for_Existing_and_Advanced_Bit_Manipulations
>>>>>>
>>>>> <
>>>>> My 66000 ISA encodings:
>> snip
>>>>>> - butterfly and inverse butterfly
>>>>> BITR Rd,Rs,<len,off>
>> I think this is the first time you have mentioned this instruction. Can
>> you give a description of what it does?
> <
> What the document says: "Containers of size ≡ width are reverse into an
> intermediate operand, and then this intermediate operand is shifted right
> (SR) by the offset specification."
> <
> Len is restricted to powers of 2.
> <
> So reversing all of the bytes in a register would be::
> BITR Rd,Rs,<8,0>
> Reversing the higher order 5 bytes in a register would be::
> BITR Rd,Rs,<8,40>
> The 5 HoBytes in LE from Rs go into the LoBytes of Rd in BE.
> <
> To reverse all of the bits in a register:
> BITR Rd,Rs,<1,0>
> To reverse all of the 4-bit fields in a register
> BITR Rd,Rs,<4,0>
> To reverse the first three (3) 16-bit fields
> BITR Rd,Rs,<16,16>
> <
> I don't remember why I restricted the len field to be power of 2.

Thanks. It must have been added after you sent me the then latest document.

Provides a lot of interesting capabilities, and I am sure there are
important uses, but not for anything I have done.

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

On Wednesday, January 26, 2022 at 2:50:43 PM UTC-6, Stephen Fuld wrote:
> On 1/26/2022 12:34 PM, MitchAlsup wrote:
> > On Wednesday, January 26, 2022 at 1:15:02 PM UTC-6, Stephen Fuld wrote:
> >> On 1/26/2022 9:49 AM, MitchAlsup wrote:
> >>> On Wednesday, January 26, 2022 at 9:54:42 AM UTC-6, EricP wrote:
> >>>> MitchAlsup wrote:
> >>>>> On Tuesday, January 25, 2022 at 1:07:11 PM UTC-6, EricP wrote:
> >>>>>>
> >>>>>> A New Basis for Shifters in General-Purpose Processors for
> >>>>>> Existing and Advanced Bit Manipulations, 2008
> >>>>>> https://www.researchgate.net/publication/220332176_A_New_Basis_for_Shifters_in_General-Purpose_Processors_for_Existing_and_Advanced_Bit_Manipulations
> >>>>>>
> >>>>> <
> >>>>> My 66000 ISA encodings:
> >> snip
> >>>>>> - butterfly and inverse butterfly
> >>>>> BITR Rd,Rs,<len,off>
> >> I think this is the first time you have mentioned this instruction. Can
> >> you give a description of what it does?
> > <
> > What the document says: "Containers of size ≡ width are reverse into an
> > intermediate operand, and then this intermediate operand is shifted right
> > (SR) by the offset specification."
> > <
> > Len is restricted to powers of 2.
> > <
> > So reversing all of the bytes in a register would be::
> > BITR Rd,Rs,<8,0>
> > Reversing the higher order 5 bytes in a register would be::
> > BITR Rd,Rs,<8,40>
> > The 5 HoBytes in LE from Rs go into the LoBytes of Rd in BE.
> > <
> > To reverse all of the bits in a register:
> > BITR Rd,Rs,<1,0>
> > To reverse all of the 4-bit fields in a register
> > BITR Rd,Rs,<4,0>
> > To reverse the first three (3) 16-bit fields
> > BITR Rd,Rs,<16,16>
> > <
> > I don't remember why I restricted the len field to be power of 2.
> Thanks. It must have been added after you sent me the then latest document.
>
> Provides a lot of interesting capabilities, and I am sure there are
> important uses, but not for anything I have done.
<
Brian (compiler guy) ask for it to deal with endian flipping code sequences
from (I think) a network controller.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

MitchAlsup wrote:
> On Wednesday, January 26, 2022 at 1:15:02 PM UTC-6, Stephen Fuld wrote:
>> On 1/26/2022 9:49 AM, MitchAlsup wrote:
>>>>> My 66000 ISA encodings:
>> snip
>>>>>> - butterfly and inverse butterfly
>>>>> BITR Rd,Rs,<len,off>
>> I think this is the first time you have mentioned this instruction. Can
>> you give a description of what it does?
> <
> What the document says: "Containers of size ≡ width are reverse into an
> intermediate operand, and then this intermediate operand is shifted right
> (SR) by the offset specification."
> <
> Len is restricted to powers of 2.
> <
> So reversing all of the bytes in a register would be::
> BITR Rd,Rs,<8,0>
> Reversing the higher order 5 bytes in a register would be::
> BITR Rd,Rs,<8,40>
> The 5 HoBytes in LE from Rs go into the LoBytes of Rd in BE.

Shouldn't this be BITR Rd,Rs,<8,24> to reverse all the bytes and then
right shift bit offset 24 into offset 0, keeping just the HO 5 bytes?

On Wednesday, January 26, 2022 at 3:18:06 PM UTC-6, EricP wrote:
> MitchAlsup wrote:
> > On Wednesday, January 26, 2022 at 1:15:02 PM UTC-6, Stephen Fuld wrote:
> >> On 1/26/2022 9:49 AM, MitchAlsup wrote:
> >>>>> My 66000 ISA encodings:
> >> snip
> >>>>>> - butterfly and inverse butterfly
> >>>>> BITR Rd,Rs,<len,off>
> >> I think this is the first time you have mentioned this instruction. Can
> >> you give a description of what it does?
> > <
> > What the document says: "Containers of size ≡ width are reverse into an
> > intermediate operand, and then this intermediate operand is shifted right
> > (SR) by the offset specification."
> > <
> > Len is restricted to powers of 2.
> > <
> > So reversing all of the bytes in a register would be::
> > BITR Rd,Rs,<8,0>
> > Reversing the higher order 5 bytes in a register would be::
> > BITR Rd,Rs,<8,40>
> > The 5 HoBytes in LE from Rs go into the LoBytes of Rd in BE.
<
> Shouldn't this be BITR Rd,Rs,<8,24> to reverse all the bytes and then
> right shift bit offset 24 into offset 0, keeping just the HO 5 bytes?
<
you are probably correct.

On Monday, January 24, 2022 at 8:45:56 AM UTC-5, Anton Ertl wrote:
[snip]
> Yet when we look at the performance of 2-wide in-order vs. 2-wide OoO
> machines, we see that the OoO machines are roughly twice as fast; Only
> a small part of this can be explained with OoO papering over cache
> misses:
>
> - Intel Atom 330, 1.6GHz, 512K L2 Zotac ION A, Debian 9 64bit 2.368
> - AMD E-450 1650MHz (Lenovo Thinkpad X121e), Ubuntu 11.10 64-bit 1.216
> - Celeron J1900 (Silvermont) 2416MHz (Shuttle XS35V4) Ubuntu16.10 1.052
>
> - Odroid N2 (1896MHz Cortex A53) Ubuntu 18.04 2.488
> - Odroid N2 (1800MHz Cortex A73) Ubuntu 18.04 1.224
>
> The Atom 330 and Cortex-A53 are in-order, while the AMD E-450,
> Silvermont, and Cortex-A73 are OoO.

As has been mentioned before, hiding L1 latency (reducing the
penalty for larger L1 caches) is also a significant benefit of
OoO. With wire delay increasing more than switching delay (and
cache latency being dominated by wire delay) in more recent
manufacturing processes, this factor likely becomes more
significant. High FO4 cycle time and skewed pipelines would
probably reduce this. (It might be interesting for academic
purposes to graph cycle time, cache size and latency, and other
factors relative to performance across multiple past processes.)

(Skewed pipelines and especially second-chance pipelines where
an operation can issue in two different cycled depending on
operand availability seem to fuzz the boundary of between I-O
and OoO. Forwarding already presents register renaming and in
the case of out-of-order completion handles RAW hazards.)

(While an unconditional load can be hoisted by a compiler, most
ISAs lack the ability to indicate that a load is speculative
much less that it is dependent on a particular condition — this
latter feature might allow branch prediction to defer unlikely
to be used loads, more closely emulating OoO. [Even the Mill
could use such since memory-access scheduling is somewhat
decoupled. Deferring a unlikely load could reduce energy and
potentially improve performance when resources are overcommited
relative to the best case such as no cache bank conflicts.] I
suspect such an indication is not worth the encoding cost, but
the concept seems interesting.)

OoO also has the side effect that wider execution than decode
makes more sense. A 2-wide decode in-order design could
presumably benefit a little from 3- or 4-wide issue even if
no instruction cracking occurs, but such would also presumably
make the design less area and power efficient.

I *suspect* the LaTex benchmark also has much more control flow
complexity and pointer chasing than many workloads. This would
presumably give OoO some advantage over I-O.

The goals of (and design resources for) the in-order designs
are likely different than for the OoO designs; a simple
comparison based on actual products is unlikely to accurately
reflect the best-case differences.

While the I-O designs seem to be more constrained than earlier
(when a 4-wide in-order design seemed reasonable), I doubt
every processor will be an OoO design any time soon. (However,
I am very biased to favor diversity both from a desire for
interesting designs and from a bias toward "over-optimization".)

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>As has been mentioned before, hiding L1 latency (reducing the=20
>penalty for larger L1 caches) is also a significant benefit of=20
>OoO.

Well, "hiding" may be the wrong word. In any case it supports the
idea that OoO is better at extracting instruction-level parallelism
out of a program than compiler scheduling.

>(While an unconditional load can be hoisted by a compiler, most=20
>ISAs lack the ability to indicate that a load is speculative=20
>much less that it is dependent on a particular condition =E2=80=94 this=20
>latter feature might allow branch prediction to defer unlikely=20
>to be used loads, more closely emulating OoO.

That's easy to indicate for in-order: Just put the load where it would
naively be compiled, rather than trying to pull it upwards.

It's much harder to deal with loads that are likely to be used: then
you often want to pull it upwards, but IIRC even IA-64 has limited
possibilities for that: It has predicated instructions, but they have
a data dependency on the condition (and the instruction waits until
the condition is available); it has prefetches, but they don't help
with the final L1 latency; and it has the ALAT, but it only helps to
pull the load up across stores, not across branches.

>I *suspect* the LaTex benchmark also has much more control flow=20
>complexity and pointer chasing than many workloads. This would=20
>presumably give OoO some advantage over I-O.

Yes, it's not matrix multiplication. However, I think that there are
many applications with similar amounts of control flow and pointer
chasing as our LaTeX benchmark.

>The goals of (and design resources for) the in-order designs=20
>are likely different than for the OoO designs;

Not in the case on Bonnell and Silvermont. Both are designed for as
low-power, low-cost cores, and both had the resources of Intel at
their disposal.

>While the I-O designs seem to be more constrained than earlier
>(when a 4-wide in-order design seemed reasonable), I doubt=20
>every processor will be an OoO design any time soon.

I certainly don't expect an OoO replacement for Cortex-M0 or
Cortex-M4, but certainly in AMD64 space in-order has died out.

And it's completely unclear to me why ARM is still designing in-order
A64 cores; they seem to offer no real advantage in J/instruction nor
performance per area over the low-power OoO cores from ARM. What they
offer is more cores/area; maybe the bragging rights of offering 4
E-cores rather than 2 that are twice as fast are the reason. Or maybe
the actual usage of their in-order cores is not reflected in the
performance results I have seen on anandtech. In any case, Apple uses
OoO cores as E-cores.

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

On Sunday, January 30, 2022 at 1:17:54 PM UTC-5, Anton Ertl wrote:
> "Paul A. Clayton" <paaron...@gmail.com> writes:
>>As has been mentioned before, hiding L1 latency (reducing the=20
>>penalty for larger L1 caches) is also a significant benefit of=20
>>OoO.
>
> Well, "hiding" may be the wrong word. In any case it supports the
> idea that OoO is better at extracting instruction-level parallelism
> out of a program than compiler scheduling.

For most ISAs the compiler is very limited in how much it can
schedule operations. While Itanium could hoist loads before
guarding conditions, each load used a register name — even with
128 GPRs this may be a constraint. Use of speculative load values
was possible on Itanium, providing a limited form of software
branch prediction with a software misprediction fallback path.
(Given that static prediction will typically be less accurate than
dynamic prediction, having less information available, this seems
less than ideal.)

I do not know of any implementation of "informing loads", where
a hit/miss condition could be tested and an alternate path taken
to cover miss latency. This is another technique that would allow
software to provide parallelism to an in-order implementation.
(Small threads could also be used for supplying useful work
while waiting for data return on a high latency load.

Compiler-assumed resource constraints (which may be current
but not fundamental) presumably also limit scheduling.

>>(While an unconditional load can be hoisted by a compiler, most=20
>>ISAs lack the ability to indicate that a load is speculative=20
>>much less that it is dependent on a particular condition =E2=80=94 this=20
>>latter feature might allow branch prediction to defer unlikely=20
>>to be used loads, more closely emulating OoO.
>
> That's easy to indicate for in-order: Just put the load where it would
> naively be compiled, rather than trying to pull it upwards.

Did you mean "for out-of-order"? Even with out-of-order, hoisting
a load can be useful.

> It's much harder to deal with loads that are likely to be used: then
> you often want to pull it upwards, but IIRC even IA-64 has limited
> possibilities for that: It has predicated instructions, but they have
> a data dependency on the condition (and the instruction waits until
> the condition is available); it has prefetches, but they don't help
> with the final L1 latency; and it has the ALAT, but it only helps to
> pull the load up across stores, not across branches.

I agree that using a speculative value is more difficult. Branch
resolution and pointer chasing seem to be critical uses; I suspect
even an OoO implementation might benefit from more and more
timely information.

> >I *suspect* the LaTex benchmark also has much more control flow=20
> >complexity and pointer chasing than many workloads. This would=20
> >presumably give OoO some advantage over I-O.
>
> Yes, it's not matrix multiplication. However, I think that there are
> many applications with similar amounts of control flow and pointer
> chasing as our LaTeX benchmark.

I agree that it is probably a more useful "general purpose" benchmark
and certainly useful even if seen as an important corner case.

> >The goals of (and design resources for) the in-order designs=20
> >are likely different than for the OoO designs;
>
> Not in the case on Bonnell and Silvermont. Both are designed for as
> low-power, low-cost cores, and both had the resources of Intel at
> their disposal.

I am not convinced of the equivalence of skill/effort. x86-64 is also
not register rich.

> >While the I-O designs seem to be more constrained than earlier
> >(when a 4-wide in-order design seemed reasonable), I doubt=20
> >every processor will be an OoO design any time soon.
> I certainly don't expect an OoO replacement for Cortex-M0 or
> Cortex-M4, but certainly in AMD64 space in-order has died out.
>
> And it's completely unclear to me why ARM is still designing in-order
> A64 cores; they seem to offer no real advantage in J/instruction nor
> performance per area over the low-power OoO cores from ARM. What they
> offer is more cores/area; maybe the bragging rights of offering 4
> E-cores rather than 2 that are twice as fast are the reason. Or maybe
> the actual usage of their in-order cores is not reflected in the
> performance results I have seen on anandtech. In any case, Apple uses
> OoO cores as E-cores.

I suspect there are valid use cases as well as marketing factors.
(I want to think more on this, but I need to get to work. [Also my dislike
for Google Groups interface is increasing. Composing a post is much
slower — I suspect background javascript is to blame.])
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 1/31/2022 10:22 AM, Paul A. Clayton wrote:

<snip>

> (I want to think more on this, but I need to get to work. [Also my dislike
> for Google Groups interface is increasing. Composing a post is much
> slower — I suspect background javascript is to blame.])

Others report similar. I use Thunderbird via news.eternal-september.org
and have no trouble.

On 1/31/2022 10:57 AM, Ivan Godard wrote:
> On 1/31/2022 10:22 AM, Paul A. Clayton wrote:
>
> <snip>
>
>> (I want to think more on this, but I need to get to work. [Also my
>> dislike
>> for Google Groups interface is increasing. Composing a post is much
>> slower — I suspect background javascript is to blame.])
>
> Others report similar. I use Thunderbird via news.eternal-september.org
> and have no trouble.

I use the same setup. It is all free (you have to give
eternal-september an e-mail address to receive your password) and works
quite well. I do use some add-ons to Tbird to make the display more to
my liking. The one down side versus Google Groups is there seems not
to be any way (at least I haven't found one) to search newsgroup
messages content.

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

On 1/31/2022 12:57 PM, Ivan Godard wrote:
> On 1/31/2022 10:22 AM, Paul A. Clayton wrote:
>
> <snip>
>
>> (I want to think more on this, but I need to get to work. [Also my
>> dislike
>> for Google Groups interface is increasing. Composing a post is much
>> slower — I suspect background javascript is to blame.])
>
> Others report similar. I use Thunderbird via news.eternal-september.org
> and have no trouble.

Same basic setup, though Thunderbird periodically crashes which is kinda
annoying...

On 01/02/22 16:42, BGB wrote:
> On 1/31/2022 12:57 PM, Ivan Godard wrote:
>> On 1/31/2022 10:22 AM, Paul A. Clayton wrote:
>>
>> <snip>
>>
>>> (I want to think more on this, but I need to get to work. [Also my dislike
>>> for Google Groups interface is increasing. Composing a post is much
>>> slower — I suspect background javascript is to blame.])
>>
>> Others report similar. I use Thunderbird via news.eternal-september.org and
>> have no trouble.
>
> Same basic setup, though Thunderbird periodically crashes which is kinda
> annoying...

A decade or so ago my Thunderbird started to work very slowly
with email directories that had an excessive number of entries.
(Now up to 20k, ahem :) )

I switched to SeaMonkey and the problem has not reappeared.
Since SeaMonkey and Thunderbird are so similar, the switch
is trivial and can be reversed.

Tom Gardner wrote:
> On 01/02/22 16:42, BGB wrote:
>> On 1/31/2022 12:57 PM, Ivan Godard wrote:
>>> On 1/31/2022 10:22 AM, Paul A. Clayton wrote:
>>>
>>> <snip>
>>>
>>>> (I want to think more on this, but I need to get to work. [Also my
>>>> dislike
>>>> for Google Groups interface is increasing. Composing a post is much
>>>> slower — I suspect background javascript is to blame.])
>>>
>>> Others report similar. I use Thunderbird via
>>> news.eternal-september.org and have no trouble.
>>
>> Same basic setup, though Thunderbird periodically crashes which is
>> kinda annoying...
>
> A decade or so ago my Thunderbird started to work very slowly
> with email directories that had an excessive number of entries.
> (Now up to 20k, ahem :) )
>
> I switched to SeaMonkey and the problem has not reappeared.
> Since SeaMonkey and Thunderbird are so similar, the switch
> is trivial and can be reversed.

Interesting!

I have been using SeaMonkey forever, i.e. since before it changed it
name from Mozilla to SeaMonkey, and I have never had any serious issues
with my news reading.

I did run my own local news server for a few years but I've been using
news.aioe.org both before and after that period.

ethernal-september has been my backup option which I've never had to
actually use.

Terje

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

On 02/02/22 10:49, Terje Mathisen wrote:
> Tom Gardner wrote:
>> On 01/02/22 16:42, BGB wrote:
>>> On 1/31/2022 12:57 PM, Ivan Godard wrote:
>>>> On 1/31/2022 10:22 AM, Paul A. Clayton wrote:
>>>>
>>>> <snip>
>>>>
>>>>> (I want to think more on this, but I need to get to work. [Also my dislike
>>>>> for Google Groups interface is increasing. Composing a post is much
>>>>> slower — I suspect background javascript is to blame.])
>>>>
>>>> Others report similar. I use Thunderbird via news.eternal-september.org and
>>>> have no trouble.
>>>
>>> Same basic setup, though Thunderbird periodically crashes which is kinda
>>> annoying...
>>
>> A decade or so ago my Thunderbird started to work very slowly
>> with email directories that had an excessive number of entries.
>> (Now up to 20k, ahem :) )
>>
>> I switched to SeaMonkey and the problem has not reappeared.
>> Since SeaMonkey and Thunderbird are so similar, the switch
>> is trivial and can be reversed.
>
> Interesting!
>
> I have been using SeaMonkey forever, i.e. since before it changed it name from
> Mozilla to SeaMonkey, and I have never had any serious issues with my news reading.

My problem was with the email side. I don't retain sufficient
usenet headers for any problem to become apparent.

> I did run my own local news server for a few years but I've been using
> news.aioe.org both before and after that period.
>
> ethernal-september has been my backup option which I've never had to actually use.

I switched to eternal september when VirginMedia (LibertyGlobal now,
IIRC) stopped having a newsnet feed. It is adequate.

I might try news.aioe.org

Marcus <m.delete@this.bitsnbites.eu> writes:

> On 2022-01-07, Tim Rentsch wrote:
>
>> Marcus <m.delete@this.bitsnbites.eu> writes:
>>
>>> On 2021-12-31, Terje Mathisen wrote:
>>>
>>>> Marcus wrote:
>>>>
>>>>> On 2021-12-30, EricP wrote:
>>>>>
>>>>>> C,C++ and a bunch of languages explicitly define booleans as 0
>>>>>> or 1 so this definition won't be optimal for those languages.
>>>>>> VAX Fortran used 0,-1 for LOGICAL but I don't know if that was
>>>>>> defined by the language or implementation dependant.
>>>>
>>>> -1 is better than 1, it can be used as a mask.
>>>>
>>>>> As a software developer I'm painfully aware of this. I decided
>>>>> not to care too much about it, though. Really, most software
>>>>> that relies on this property of C should be frowned upon. E.g.,
>>>>> expressions like:
>>>>>
>>>>> a = b + (c == d);
>>>>>
>>>>> ...aren't really good programming practice.
>>>>
>>>> No! Please tell me it ain't so!
>>>>
>>>> I use that type of constructs all over the place when writing
>>>> branchless code/doing table lookups etc.
>>>
>>> I think that you'll find that the following code produces the
>>> exact same result:
>>>
>>> int a;
>>> if (c == d) {
>>> a = b + 1;
>>> } else {
>>> a = b;
>>> }
>>>
>>> It too is completely branchless.
>>
>> Being branchless is not the high order bit here.
>
> ?? I was responding to a note about relying on comparison results
> having the value 0 or 1 for the purpose of producing branchless
> code.

That isn't what he said. He said he (often) uses such constructs
when writing branchless code. He did not say he uses them only
because they produce branchless code. Producing branchless code is
a benefit, but not the only benefit, or even the most important
benefit.

>>> My main gripe with the former version is the implicit type
>>> conversion (boolean to integer), and that I don't like to see
>>> logical operands and arithmetic operands mixed in the same
>>> expression.
>>
>> Apparently you are thinking of some other language, not C.
>> The result of comparison operators such as == have type int,
>> not some boolean type. And that is not just an accident.
>
> True. I usually dwell in C++ land, and there I'm pretty sure that
> comparison operators return bool, not int.
>
> Well, there's one more thing... In C, integer zero is "falsy", and
> *anything else* is "truthy". But only integer 1 is the valid
> value of "true". E.g. consider:
>
> #define FALSE 0
> #define TRUE 42
>
> int c = (foo > bar);
> if (c) // OK
> if (c == 1) // OK
> if (c == TRUE) // BAD
>
> int c = (foo > bar) ? TRUE : FALSE;
> if (c) // OK
> if (c == 1) // BAD
> if (c == TRUE) // OK
>
> int c = foo - bar; // c is truthy if foo != bar
> if (c) // OK
> if (c == TRUE) // BAD
> if (c == 1) // BAD
>
> So, in general I do not like code that makes assumptions about the
> integer value of a comparison result. I much rather see explicit
> if-then-else statements, and have the compiler reduce it to the
> most optimal form for the target machine (they do that these
> days). But maybe I'm just too influenced by C++ philosophies.

I think I understand your reaction. The last paragraph relates to
your questions in another posting; my response to that posting
may return to your comments here.

Marcus <m.delete@this.bitsnbites.eu> writes:

> On 2022-01-07, Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Marcus wrote:
>>>
>>>> On 2021-12-30, EricP wrote:
>>>>
>>>>> C,C++ and a bunch of languages explicitly define booleans as 0 or 1
>>>>> so this definition won't be optimal for those languages.
>>>>> VAX Fortran used 0,-1 for LOGICAL but I don't know if that
>>>>> was defined by the language or implementation dependant.
>>>
>>> -1 is better than 1, it can be used as a mask.
>>>
>>>> As a software developer I'm painfully aware of this. I decided not to
>>>> care too much about it, though. Really, most software that relies on
>>>> this property of C should be frowned upon. E.g. expressions like:
>>>>
>>>> a = b + (c == d);
>>>>
>>>> ...aren't really good programming practice.
>>>
>>> No! Please tell me it ain't so!
>>>
>>> I use that type of constructs [frequently ...]
>>
>> Totally with you on this. People who don't see the benefit of
>> using 0/1 values instead of if/else in cases like this are stuck
>> in an antiquated way of thinking.
>
> Care to elaborate? What context are we talking about here? C?
> Machine code? Microarchitecture?

Programming languages. I don't mean to include low-level
languages that are basically just glorified assembly languages.
Let's say at the level of C or higher.

> Have a look at https://godbolt.org/z/K7ndn57T1 and feel free to
> compare what machine code you get on different architectures for
> the different C code snippets (spoiler alert: with modern
> compilers there will typically be no difference at all).

I take it as given that compilers of today (or even ten years ago)
can and do generate excellent code in such cases. For the most part
I'm not interested in what machine code is produced, except in those
rare situations where performance is critical to what the program is
doing (and in almost all code written, it isn't).

> My point is that you should strive for writing (high level) code
> that is as clear as possible w.r.t. the intent of the program
> (e.g. avoid error prone constructs). [...]

We agree on the principle. The question is which constructions are
more clear? In another posting in this general thread you say this:

> So, in general I do not like code that makes assumptions about the
> integer value of a comparison result. I much rather see explicit
> if-then-else statements,

My reaction is just the opposite. Insisting on if-then-else is
firmly stuck in the von Neumann imperative mindset. Using "logical
values" as integers is one of the great advances in programming
languages. APL illustrates the power of if-less programming. By
contrast, if/else is usually harder to understand and more likely to
be a source of error. When I'm looking at source code, I usually
find that the more if()s there are, the more likely the code is to
be buggy. It is the if/else, von Neumann imperative style of
programming that was (in part) what I meant above by "antiquated
way of thinking".

Please don't take any of these comments as personal. I am trying to
express a general point of view; I don't mean to focus on any of
your views in particular. My apologies if it came across otherwise.