Mitch's My66000 has a compare instruction which produces a multitude
of result bits in a target register. This can then later be used
for a branch or predicate on bit, or shifted to get an integer
value.

Just wondering: Are there other architectures which use a
similar approach? ARM uses condition codes, MIPS/Alpha use
comparisons which have zero or one put into a general register,
POWER has several fields in its condition register, 68000 has a
flags register, ...

On Saturday, February 4, 2023 at 3:39:43 AM UTC-5, Thomas Koenig wrote:
> Mitch's My66000 has a compare instruction which produces a multitude
> of result bits in a target register. This can then later be used
> for a branch or predicate on bit, or shifted to get an integer
> value.
>
> Just wondering: Are there other architectures which use a
> similar approach? ARM uses condition codes, MIPS/Alpha use
> comparisons which have zero or one put into a general register,
> POWER has several fields in its condition register, 68000 has a
> flags register, ...

I cannot think of any others. The older archs seem to use c,v,n,z flags. Decode
takes place during branch instead of compare.

The My66000 approach is a good way of doing a lot of comparisons using only
a single instruction. It is somewhat like using a GPR as a flags register. the c,v,n,z
flags could be present, but it makes more sense just to decode them at the same
time into single bit values as that is what logic ultimately operates on. The
decode is during the compare instead of during the branch. The equivalent of
SETcc is available by doing a bit extract of the compare result. I am using the
same approach for compares in the Thor2023 architecture. Thor2023 has branch
on register zero / non-zero in addition to branch on bit set.
Specifying only a single register in the branch instruction allows a nice large branch
displacement.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Mitch's My66000 has a compare instruction which produces a multitude
>of result bits in a target register. This can then later be used
>for a branch or predicate on bit, or shifted to get an integer
>value.
>
>Just wondering: Are there other architectures which use a
>similar approach?

The 88000 architecture (by Mitch Alsup) also uses this approach.

>POWER has several fields in its condition register

Power is similar in having separate bits for <,=,> (and a fourth bit,
don't remember what that does) for each comparison result rather than
having the more common NZCV collection. But because it does not have
the full complement of bits, it needs several compare instructions.

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

On Saturday, February 4, 2023 at 2:39:43 AM UTC-6, Thomas Koenig wrote:
> Mitch's My66000 has a compare instruction which produces a multitude
> of result bits in a target register. This can then later be used
> for a branch or predicate on bit, or shifted to get an integer
> value.
>
> Just wondering: Are there other architectures which use a
> similar approach? ARM uses condition codes, MIPS/Alpha use
> comparisons which have zero or one put into a general register,
> POWER has several fields in its condition register, 68000 has a
> flags register, ...
<
My Mc 88K architecture had something very similar.

On Saturday, February 4, 2023 at 4:55:23 AM UTC-6, robf...@gmail.com wrote:
> On Saturday, February 4, 2023 at 3:39:43 AM UTC-5, Thomas Koenig wrote:
> > Mitch's My66000 has a compare instruction which produces a multitude
> > of result bits in a target register. This can then later be used
> > for a branch or predicate on bit, or shifted to get an integer
> > value.
> >
> > Just wondering: Are there other architectures which use a
> > similar approach? ARM uses condition codes, MIPS/Alpha use
> > comparisons which have zero or one put into a general register,
> > POWER has several fields in its condition register, 68000 has a
> > flags register, ...
> I cannot think of any others. The older archs seem to use c,v,n,z flags. Decode
> takes place during branch instead of compare.
>
> The My66000 approach is a good way of doing a lot of comparisons using only
> a single instruction. It is somewhat like using a GPR as a flags register. the c,v,n,z
> flags could be present, but it makes more sense just to decode them at the same
> time into single bit values as that is what logic ultimately operates on. The
> decode is during the compare instead of during the branch. The equivalent of
> SETcc is available by doing a bit extract of the compare result. I am using the
> same approach for compares in the Thor2023 architecture. Thor2023 has branch
> on register zero / non-zero in addition to branch on bit set.
> Specifying only a single register in the branch instruction allows a nice large branch
> displacement.
<
In addition, Brian's compiler is capable of seeing a comparison at one
place in the subroutine, and using it multiple times -- just like any other
common sub-expression.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, February 4, 2023 at 2:39:43 AM UTC-6, Thomas Koenig wrote:
>> Mitch's My66000 has a compare instruction which produces a multitude
>> of result bits in a target register. This can then later be used
>> for a branch or predicate on bit, or shifted to get an integer
>> value.
>>
>> Just wondering: Are there other architectures which use a
>> similar approach? ARM uses condition codes, MIPS/Alpha use
>> comparisons which have zero or one put into a general register,
>> POWER has several fields in its condition register, 68000 has a
>> flags register, ...
><
> My Mc 88K architecture had something very similar.

Yes indeed. I should have thought to look there :-)

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, February 4, 2023 at 4:55:23 AM UTC-6, robf...@gmail.com wrote:
>> On Saturday, February 4, 2023 at 3:39:43 AM UTC-5, Thomas Koenig wrote:
>> > Mitch's My66000 has a compare instruction which produces a multitude
>> > of result bits in a target register. This can then later be used
>> > for a branch or predicate on bit, or shifted to get an integer
>> > value.
>> >
>> > Just wondering: Are there other architectures which use a
>> > similar approach? ARM uses condition codes, MIPS/Alpha use
>> > comparisons which have zero or one put into a general register,
>> > POWER has several fields in its condition register, 68000 has a
>> > flags register, ...
>> I cannot think of any others. The older archs seem to use c,v,n,z flags. Decode
>> takes place during branch instead of compare.
>>
>> The My66000 approach is a good way of doing a lot of comparisons using only
>> a single instruction. It is somewhat like using a GPR as a flags register. the c,v,n,z
>> flags could be present, but it makes more sense just to decode them at the same
>> time into single bit values as that is what logic ultimately operates on. The
>> decode is during the compare instead of during the branch. The equivalent of
>> SETcc is available by doing a bit extract of the compare result. I am using the
>> same approach for compares in the Thor2023 architecture. Thor2023 has branch
>> on register zero / non-zero in addition to branch on bit set.
>> Specifying only a single register in the branch instruction allows a nice large branch
>> displacement.
><
> In addition, Brian's compiler is capable of seeing a comparison at one
> place in the subroutine, and using it multiple times -- just like any other
> common sub-expression.

Sounds like the reasonable thing to do.

Regarding M88000: Looking at early releases (gcc 3.3, no less)
for the m88k machine description, I see that that port did indeed
use CCMode in general registers, so I would expect the same behavior
for that port.

What gcc does (and, I presume, LLVM as well) is to model condition
codes to a class of registers. This can be a hard-coded single
register (like on x86), several specialized registers like POWER,
or general registers like MIPS or m88k (or my66000, if anybody
should attempt a gcc port).

On architectures with more than one condition code registers
these can then be treated with the same algorithms for register
allocation, common subexpression elimination etc like general
registers.

Why is nobody mentioning the x86 flags register? A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.

State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op. This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom).

On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
> Why is nobody mentioning the x86 flags register? A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
>
> State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op.
<
What makes you think that CMP-Bcnd cannot be fused into one OP that rides
down the pipeline in a single beat ?? Branch does not deliver a result, and at
the 95% level, the branch consumes the result of the CMP. So we have 2 inst
that consume 2 normal operands and deliver 1 result combined with a possible
change of control point.
<
>This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom).
<
MIPS and RISC-V take that strategy. However when I survey the CMP-Bcnd-s
in EMBench and CoreMark emitted by the LLVM compiler for both My 66000
and for RISC-V, I see no useful advantage.
<
I should note (for those not paying attention):: that My 66000 has a complete
set of branches with respect to zero (including floating point.) So, all comparisons
against zero are essentially equivalent; Forward.Com versus My 66000.
<
For the remaining 40% if branches an awful lot of them are comparisons
to/with non-zero constants, of which MIPS and RISC-V do not have direct
instruction support. Maybe Forward.Com has constants with its alu-bcnd
that the other 2 do not.
<
When I started reading the code out of the LLVM RISC-V compiler and started
to compare with My 66000 compiler assembly; I honestly though that the
Alu-Bcnd would be a place My 66000 ISA got beat up. However, after looking
at 200,000 lines of asm out of each compiler, I do not see any advantage--sure
there are cases where the MIPS strategy works (and well!) but there are other
cases where access to constants was at least as valuable. and all in all, it turns
out to be a wash.
<
I would be happy to plow through that ASM again to extract illustrative
examples where this side won and that side lost, and vice versa.

On Sunday, February 5, 2023 at 3:01:17 PM UTC-5, MitchAlsup wrote:
> On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
> > Why is nobody mentioning the x86 flags register? A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
> >
> > State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op.
> <
> What makes you think that CMP-Bcnd cannot be fused into one OP that rides
> down the pipeline in a single beat ?? Branch does not deliver a result, and at
> the 95% level, the branch consumes the result of the CMP. So we have 2 inst
> that consume 2 normal operands and deliver 1 result combined with a possible
> change of control point.
> <
> >This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom)..
> <
> MIPS and RISC-V take that strategy. However when I survey the CMP-Bcnd-s
> in EMBench and CoreMark emitted by the LLVM compiler for both My 66000
> and for RISC-V, I see no useful advantage.
> <
> I should note (for those not paying attention):: that My 66000 has a complete
> set of branches with respect to zero (including floating point.) So, all comparisons
> against zero are essentially equivalent; Forward.Com versus My 66000.
> <
I assume this means EQ, NE, LT, LE, GT, GE compares against zero? I only
included EQ, NE in my ISA, but there is still time to change this.

> For the remaining 40% if branches an awful lot of them are comparisons
> to/with non-zero constants, of which MIPS and RISC-V do not have direct
> instruction support. Maybe Forward.Com has constants with its alu-bcnd
> that the other 2 do not.
> <
> When I started reading the code out of the LLVM RISC-V compiler and started
> to compare with My 66000 compiler assembly; I honestly though that the
> Alu-Bcnd would be a place My 66000 ISA got beat up. However, after looking
> at 200,000 lines of asm out of each compiler, I do not see any advantage--sure
> there are cases where the MIPS strategy works (and well!) but there are other
> cases where access to constants was at least as valuable. and all in all, it turns
> out to be a wash.
> <
> I would be happy to plow through that ASM again to extract illustrative
> examples where this side won and that side lost, and vice versa.

I found many compare-to-immediate then branch used in switch() processing. The
compiler saved some code by testing for one-hot switches then using BBS and BBC
instructions to test for constants. The compiler has a capability to generate one-hot
case constants using enums. Which are then used for switch statements. Which
then can branch using BBS and BBC without needing a compare. Wondering if
My66000 compiler can do something similar.

On Sunday, February 5, 2023 at 5:55:31 PM UTC-6, robf...@gmail.com wrote:
> On Sunday, February 5, 2023 at 3:01:17 PM UTC-5, MitchAlsup wrote:
> > On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
> > > Why is nobody mentioning the x86 flags register? A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
> > >
> > > State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op.
> > <
> > What makes you think that CMP-Bcnd cannot be fused into one OP that rides
> > down the pipeline in a single beat ?? Branch does not deliver a result, and at
> > the 95% level, the branch consumes the result of the CMP. So we have 2 inst
> > that consume 2 normal operands and deliver 1 result combined with a possible
> > change of control point.
> > <
> > >This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom).
> > <
> > MIPS and RISC-V take that strategy. However when I survey the CMP-Bcnd-s
> > in EMBench and CoreMark emitted by the LLVM compiler for both My 66000
> > and for RISC-V, I see no useful advantage.
> > <
> > I should note (for those not paying attention):: that My 66000 has a complete
> > set of branches with respect to zero (including floating point.) So, all comparisons
> > against zero are essentially equivalent; Forward.Com versus My 66000.
> > <
> I assume this means EQ, NE, LT, LE, GT, GE compares against zero? I only
> included EQ, NE in my ISA, but there is still time to change this.
<
You get {float, double, signed, unsigned}×{==, !=, <, <=, >, >=} against zero.
<
> > For the remaining 40% if branches an awful lot of them are comparisons
> > to/with non-zero constants, of which MIPS and RISC-V do not have direct
> > instruction support. Maybe Forward.Com has constants with its alu-bcnd
> > that the other 2 do not.
> > <
> > When I started reading the code out of the LLVM RISC-V compiler and started
> > to compare with My 66000 compiler assembly; I honestly though that the
> > Alu-Bcnd would be a place My 66000 ISA got beat up. However, after looking
> > at 200,000 lines of asm out of each compiler, I do not see any advantage--sure
> > there are cases where the MIPS strategy works (and well!) but there are other
> > cases where access to constants was at least as valuable. and all in all, it turns
> > out to be a wash.
> > <
> > I would be happy to plow through that ASM again to extract illustrative
> > examples where this side won and that side lost, and vice versa.
<
> I found many compare-to-immediate then branch used in switch() processing.. The
> compiler saved some code by testing for one-hot switches then using BBS and BBC
> instructions to test for constants. The compiler has a capability to generate one-hot
> case constants using enums. Which are then used for switch statements. Which
> then can branch using BBS and BBC without needing a compare. Wondering if
> My66000 compiler can do something similar.
<
My 66000 has a Jump-Through-Table instruction (switch) as 1 word instruction.
The instruction examines the table index, and if it is our of bounds, control is
transferred to default: otherwise an element in the table is accessed and used
as an offset to the JTT instruction as a PIC control transfer. 1 instruction, 4 cycles,
and the table is accessed via the instruction cache.
<
Most switch offset tables are comprised of 16-bit elements (although many
could be 8-bit entries). There is another form of JTT that is appropriate for
method calling.

On Sunday, February 5, 2023 at 7:23:42 PM UTC-5, MitchAlsup wrote:
> On Sunday, February 5, 2023 at 5:55:31 PM UTC-6, robf...@gmail.com wrote:
> > On Sunday, February 5, 2023 at 3:01:17 PM UTC-5, MitchAlsup wrote:
> > > On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
> > > > Why is nobody mentioning the x86 flags register? A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
> > > >
> > > > State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op.
> > > <
> > > What makes you think that CMP-Bcnd cannot be fused into one OP that rides
> > > down the pipeline in a single beat ?? Branch does not deliver a result, and at
> > > the 95% level, the branch consumes the result of the CMP. So we have 2 inst
> > > that consume 2 normal operands and deliver 1 result combined with a possible
> > > change of control point.
> > > <
> > > >This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom).
> > > <
> > > MIPS and RISC-V take that strategy. However when I survey the CMP-Bcnd-s
> > > in EMBench and CoreMark emitted by the LLVM compiler for both My 66000
> > > and for RISC-V, I see no useful advantage.
> > > <
> > > I should note (for those not paying attention):: that My 66000 has a complete
> > > set of branches with respect to zero (including floating point.) So, all comparisons
> > > against zero are essentially equivalent; Forward.Com versus My 66000.
> > > <
> > I assume this means EQ, NE, LT, LE, GT, GE compares against zero? I only
> > included EQ, NE in my ISA, but there is still time to change this.
> <
> You get {float, double, signed, unsigned}×{==, !=, <, <=, >, >=} against zero.
> <
> > > For the remaining 40% if branches an awful lot of them are comparisons
> > > to/with non-zero constants, of which MIPS and RISC-V do not have direct
> > > instruction support. Maybe Forward.Com has constants with its alu-bcnd
> > > that the other 2 do not.
> > > <
> > > When I started reading the code out of the LLVM RISC-V compiler and started
> > > to compare with My 66000 compiler assembly; I honestly though that the
> > > Alu-Bcnd would be a place My 66000 ISA got beat up. However, after looking
> > > at 200,000 lines of asm out of each compiler, I do not see any advantage--sure
> > > there are cases where the MIPS strategy works (and well!) but there are other
> > > cases where access to constants was at least as valuable. and all in all, it turns
> > > out to be a wash.
> > > <
> > > I would be happy to plow through that ASM again to extract illustrative
> > > examples where this side won and that side lost, and vice versa.
> <
> > I found many compare-to-immediate then branch used in switch() processing. The
> > compiler saved some code by testing for one-hot switches then using BBS and BBC
> > instructions to test for constants. The compiler has a capability to generate one-hot
> > case constants using enums. Which are then used for switch statements. Which
> > then can branch using BBS and BBC without needing a compare. Wondering if
> > My66000 compiler can do something similar.
> <
> My 66000 has a Jump-Through-Table instruction (switch) as 1 word instruction.
> The instruction examines the table index, and if it is our of bounds, control is
> transferred to default: otherwise an element in the table is accessed and used
> as an offset to the JTT instruction as a PIC control transfer. 1 instruction, 4 cycles,
> and the table is accessed via the instruction cache.
> <
> Most switch offset tables are comprised of 16-bit elements (although many
> could be 8-bit entries). There is another form of JTT that is appropriate for
> method calling.

I had a similar memory indirect jump, JMPI, in a previous architecture I think DSD9, but it
just replaced the low order 16 or 32 bits of the program counter with a value from a table
rather than using PIC. PIC code could still be done with this restriction provided things
were kept aligned on 64k boundaries. With an MMU and paged memory system,
programs can be loaded at the same fixed address or at least on page boundaries. This
removes some of the requirement of PIC code.

DSD9 architecture had a full complement of integer branches on register compared to an
eight-bit immediate value. This was great for handling sparse switch() statements. This
could be squeezed into branches because a 40-bit instruction word was used.

DSD9 also used postfix words for large constants, something I have kept for the more
recent Thor2023. Because instructions are a fixed size, postfix decoding always occurs at
the same bits in the aligned cache line. I think it is almost as efficient as having bits to
decode the constant size in the first instruction word. It conserves bits in the first
instruction word though since bits are not needed for the constant size. I traded off the
constant size bits for other useful bits. Thor2023 supports up to 128-bit constants without
having to be loaded into a register. It follows the My66000 in that which operand is the
constant may be swapped for instructions that are non-commutative.

robf...@gmail.com wrote:
>
> DSD9 also used postfix words for large constants, something I have kept for the more
> recent Thor2023. Because instructions are a fixed size, postfix decoding always occurs at
> the same bits in the aligned cache line. I think it is almost as efficient as having bits to
> decode the constant size in the first instruction word. It conserves bits in the first
> instruction word though since bits are not needed for the constant size. I traded off the
> constant size bits for other useful bits. Thor2023 supports up to 128-bit constants without
> having to be loaded into a register. It follows the My66000 in that which operand is the
> constant may be swapped for instructions that are non-commutative.

How does this "postfix word" encoding work?

On Monday, February 6, 2023 at 10:20:19 AM UTC-5, EricP wrote:
> robf...@gmail.com wrote:
> >
> > DSD9 also used postfix words for large constants, something I have kept for the more
> > recent Thor2023. Because instructions are a fixed size, postfix decoding always occurs at
> > the same bits in the aligned cache line. I think it is almost as efficient as having bits to
> > decode the constant size in the first instruction word. It conserves bits in the first
> > instruction word though since bits are not needed for the constant size. I traded off the
> > constant size bits for other useful bits. Thor2023 supports up to 128-bit constants without
> > having to be loaded into a register. It follows the My66000 in that which operand is the
> > constant may be swapped for instructions that are non-commutative.
> How does this "postfix word" encoding work?

A postfix works in a similar fashion to a prefix except that it follows the instruction word rather
than preceding it. In ascending memory layout it looks like | Instruction | Postfix1 | Postfix2 | Note
the instruction is always decoded at the same position of the buffer, as are the postfix instructions.
A prefix would cause decoding to shift. The instruction buffer must be large enough to contain the
instruction and all postfixes. In terms of a classic pipeline the pipeline regs must be wide enough
to accommodate the decoded constant. Because the instruction and postfixes can all be decoded
at the same time, the PC can increment to skip over the postfixes so they do not consume clock
cycles to fetch.

The postfix itself is an opcode combined with a numeric constant. In the Thor2023 case
| 32-bit constant | 3-bit op | 5-bit opcode |. The 3-bit op determines which 32-bit piece of the full
constant is contained in the payload area. For integers, the first 32-bit would be represented by the
postfix | 32-bit constant | 0 | 31 |. The first constant sign extends to the machine width. The second
postfix constant overrides bits 32 to 63 while leaving the low order bits in place. Note that most
integer instructions may use a 16-bit immediate constant. This constant is overridden by postfixes
when a larger constant is needed only if postfixes are present. Float postfixes are slightly more
complex as they may be either 32-bit single precision values if only a single postfix is present or
64-bit double precision values. The values are converted to the FP width.

Thor2023 is slightly more complex in that it currently has a 96-bit width and can use three postfix
instructions. There is provision for up to four postfixes, the ISA is still in flux.

Instructions are 40-bits wide.

Should there be a branch to a postfix, the postfix is treated as a NOP instruction. The NOP opcode
and the postfix opcode are the same. They are distinguished by the op3 field.

On Saturday, February 4, 2023 at 3:39:43 AM UTC-5, Thomas Koenig wrote:
> Mitch's My66000 has a compare instruction which produces a multitude
> of result bits in a target register. This can then later be used
> for a branch or predicate on bit, or shifted to get an integer
> value.
>
> Just wondering: Are there other architectures which use a
> similar approach? ARM uses condition codes, MIPS/Alpha use
> comparisons which have zero or one put into a general register,
> POWER has several fields in its condition register, 68000 has a
> flags register, ...

My favorite hack on the 8088:

MOV AL,<value to branch on , 0..3>
ROR AL, 1
AND AL,81h ; I can't remember if this is necessary to not...
JZ <value is zero>
JPE <value is three>
JS <value is one>
JMP <value is two>

- Tim

Timothy McCaffrey wrote:
> On Saturday, February 4, 2023 at 3:39:43 AM UTC-5, Thomas Koenig wrote:
>> Mitch's My66000 has a compare instruction which produces a multitude
>> of result bits in a target register. This can then later be used
>> for a branch or predicate on bit, or shifted to get an integer
>> value.
>>
>> Just wondering: Are there other architectures which use a
>> similar approach? ARM uses condition codes, MIPS/Alpha use
>> comparisons which have zero or one put into a general register,
>> POWER has several fields in its condition register, 68000 has a
>> flags register, ...
>
> My favorite hack on the 8088:
>
> MOV AL,<value to branch on , 0..3>
> ROR AL, 1
> AND AL,81h ; I can't remember if this is necessary to not...
> JZ <value is zero>
> JPE <value is three>
> JS <value is one>
> JMP <value is two>
>

Nice!

I have written code that did three-way branching quite a few times, but
never four, at that point I'd typically use jump tables instead.

The ROR should set all the flag bits afair, so the AND AL,81h can
probably be skipped. In fact, the AND will clear the Overflow Flag which
would have been set by ROR (along with the carry flag) if the starting
value was odd.

OTOH, by including the AND operation this works to branch on the bottom
two bits no matter what the rest contained, but I'd probably prefer an
initial AND AL,3 instead.

Terje

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

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
>> Why is nobody mentioning the x86 flags register? A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
>>
>> State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op.
><
> What makes you think that CMP-Bcnd cannot be fused into one OP that rides
> down the pipeline in a single beat ?? Branch does not deliver a result, and at
> the 95% level, the branch consumes the result of the CMP. So we have 2 inst
> that consume 2 normal operands and deliver 1 result combined with a possible
> change of control point.
><
>>This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom).
><
> MIPS and RISC-V take that strategy. However when I survey the CMP-Bcnd-s
> in EMBench and CoreMark emitted by the LLVM compiler for both My 66000
> and for RISC-V, I see no useful advantage.

That is mostly a question of encoding length, I believe (see below).

> I should note (for those not paying attention):: that My 66000 has a complete
> set of branches with respect to zero (including floating point.) So, all comparisons
> against zero are essentially equivalent; Forward.Com versus My 66000.
><
> For the remaining 40% if branches an awful lot of them are comparisons
> to/with non-zero constants, of which MIPS and RISC-V do not have direct
> instruction support. Maybe Forward.Com has constants with its alu-bcnd
> that the other 2 do not.
><
> When I started reading the code out of the LLVM RISC-V compiler and started
> to compare with My 66000 compiler assembly; I honestly though that the
> Alu-Bcnd would be a place My 66000 ISA got beat up. However, after looking
> at 200,000 lines of asm out of each compiler, I do not see any advantage--sure
> there are cases where the MIPS strategy works (and well!) but there are other
> cases where access to constants was at least as valuable. and all in all, it turns
> out to be a wash.

If an ISA offers sufficient instruction length (or sacrifices enough
entropy) to offer branches featuring a full set of comparisons with
a reasonable offset _and_ would offer constants to compare against
as well, that could lead to an advantage in instruction count.

So, to take this to the extreme, something like

bfgt r1,#3.14159265358979323846, label

(branch if "floating point greater than") would save an instruction,
a register and an instruction size over

fcmp r1,r2,#3.14159265358979323846
bgt r2, label

at the cost of having to encode this in the ISA.

Branches being as frequent as they are, this might be a win iff
the bits to encode it are there.

On Tuesday, February 7, 2023 at 12:41:05 AM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
> >> Why is nobody mentioning the x86 flags register? A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register.. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
> >>
> >> State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op.
> ><
> > What makes you think that CMP-Bcnd cannot be fused into one OP that rides
> > down the pipeline in a single beat ?? Branch does not deliver a result, and at
> > the 95% level, the branch consumes the result of the CMP. So we have 2 inst
> > that consume 2 normal operands and deliver 1 result combined with a possible
> > change of control point.
> ><
> >>This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom).
> ><
> > MIPS and RISC-V take that strategy. However when I survey the CMP-Bcnd-s
> > in EMBench and CoreMark emitted by the LLVM compiler for both My 66000
> > and for RISC-V, I see no useful advantage.
> That is mostly a question of encoding length, I believe (see below).
> > I should note (for those not paying attention):: that My 66000 has a complete
> > set of branches with respect to zero (including floating point.) So, all comparisons
> > against zero are essentially equivalent; Forward.Com versus My 66000.
> ><
> > For the remaining 40% if branches an awful lot of them are comparisons
> > to/with non-zero constants, of which MIPS and RISC-V do not have direct
> > instruction support. Maybe Forward.Com has constants with its alu-bcnd
> > that the other 2 do not.
> ><
> > When I started reading the code out of the LLVM RISC-V compiler and started
> > to compare with My 66000 compiler assembly; I honestly though that the
> > Alu-Bcnd would be a place My 66000 ISA got beat up. However, after looking
> > at 200,000 lines of asm out of each compiler, I do not see any advantage--sure
> > there are cases where the MIPS strategy works (and well!) but there are other
> > cases where access to constants was at least as valuable. and all in all, it turns
> > out to be a wash.
> If an ISA offers sufficient instruction length (or sacrifices enough
> entropy) to offer branches featuring a full set of comparisons with
> a reasonable offset _and_ would offer constants to compare against
> as well, that could lead to an advantage in instruction count.
>
> So, to take this to the extreme, something like
>
> bfgt r1,#3.14159265358979323846, label
>
> (branch if "floating point greater than") would save an instruction,
> a register and an instruction size over
>
> fcmp r1,r2,#3.14159265358979323846
> bgt r2, label
>
> at the cost of having to encode this in the ISA.
<
It ends up that the CMP followed by the branch on bit can
be CoIssued since they produce 1 result and do not consume
more than 3 register operands. So, making this 1 long inst
ends up no different than 2 inst that can be CoIssued. And
both cases occupy the same space in the inst stream.
>
> Branches being as frequent as they are, this might be a win iff
> the bits to encode it are there.

On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
> Why is nobody mentioning the x86 flags register?
<
Possibly because it represents something to be avoided rather than something
to be followed. The SMD side treats these 5-bits as 3 different registers {C, O, and ZAPS}
and then has reservation station entries for each one. That is right, more resources are
used to track these 5-bits than are used to track both registers in your typical 2-operand
instruction.
<
> A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
<
SPARC taught us that condition codes are much less harmful to the implementation
when the conditions are only set ON-DEMAND (bit in the instructions) so that the
condition persists over "book keeping" instructions (loop indexes and pointer adjustments).
x86 does not have this, and does a lot of other nasties:: such as shift instructions set C
but do not modify C if the shift count was 0.
>
> State-of-the-art implementations by both Intel and AMD are fusing the compare instruction and the subsequent branch instruction in the decoder into a single compare-and-branch micro-op.
<
Note: one can only fuse these if they are coincident in the instruction stream.
So code scheduling is contraindicated.
<
>This expensive complexity in the decoder can be avoided by making combined alu-and-branch instructions in the first place (like I do in ForwardCom).
<
Which takes just as many instructions to execute in the case of constants.
<
if( i == 7 )
<
CMP Rt,Ri,#7
BNE Rt, else-clause
< versus
MOV Rt,#7
BNE Ri,Rt,else-clause
<
leaving fewer bits in the branch displacement--which leads to other complications.....
In effect you gave more bits to the immediate which you don't need, and you ended up
taking those bits from the Bcnd where you need it for displacements.
<
And the floating point side is "really sad" in RISC-V
<
if( d >= 7.0D0 )
<
FCMP Rt,Rd,#7
BLT Rt,else-clause
< versus
LDD Ft,[lit-pool[7.0D]]
SLT Rt,Fd,Ft
BNE R0,Rt,ele-clause
<
Se, here, we use a F register for the constant, and a R register for the
comparison value, and then we have to arithmetically compare against
0 (r0==0) and we still lost branch displacement bits (at least 5).
<
I should also note that the #7 is (int) that gets promoted to (double)
since the FCMP is a double "operator". So, this costs 2 word storage
containers (both in execute only memory) whereas the RISC-V version
uses 3 words in execute memory and 2 words of literal-pool memory
with the added latency of the LDD,.....2.5× bigger.
<
Agner:: please make Forward.com better than RISC-V here.

MitchAlsup wrote:
> On Sunday, February 5, 2023 at 5:20:42 AM UTC-6, Agner Fog wrote:
>> Why is nobody mentioning the x86 flags register?
> <
> Possibly because it represents something to be avoided rather than something
> to be followed. The SMD side treats these 5-bits as 3 different registers {C, O, and ZAPS}
> and then has reservation station entries for each one. That is right, more resources are
> used to track these 5-bits than are used to track both registers in your typical 2-operand
> instruction.
> <
>> A compare instruction, such as cmp eax, ebx, is setting multiple flag bits in the flags register. Different conditional jump instructions can test different flag bits for <, <=, >, >=, ==, !=, signed and unsigned, carry, overflow, and parity. The same flags register is also set by many ALU instructions, such as addition and shift.
> <
> SPARC taught us that condition codes are much less harmful to the implementation
> when the conditions are only set ON-DEMAND (bit in the instructions) so that the
> condition persists over "book keeping" instructions (loop indexes and pointer adjustments).
> x86 does not have this, and does a lot of other nasties:: such as shift instructions set C
> but do not modify C if the shift count was 0.

I agree that there's lots of performance warts on x86, but in the
particular instance of "book keeping" instructions, Intel very carefully
made that possible for some useful situations:

I.e. the core of my favorite TCPIP copy + checksum loop looks like this,
after manually inverting it and combining input/output pointers:

next32:
mov [esi+edi],edx ; Save previous dword
mov edx,[esi] ; Load next

adc eax,edx ; Wrapping checksum via carry
lea esi,[esi+4] ; Update src pointer without touching the flags

dec ecx ; DEC intentionally does not touch CARRY
jnz next32

The loop above achived perfect pairing on a Pentium so it could run
those 6 instructions in 3 clock cycles as long as both source and
destination was in $L1.

PS. It should probably be noted that real code, as in Linux, avoids all
this by simply using a larger (64-bit) accumulator and unrolling the
core: (From memory, I only looked at this once 15-20 years ago)

uint64_t acc = 0;
while (len_dwords >= 4 {
acc += dst32[0] = src32[0];
acc += dst32[1] = src32[1];
acc += dst32[2] = src32[2];
acc += dst32[3] = src32[3];
src32 += 4; dst32 += 4;
}

Back in the 32-bit days, compilers already knew that they could
zero-extend a 32-bit variable to a 64-bit pair and add to an accumulator
pair by simply adding the low dword and ADC a (fixed) zero word to the
high half of the accumulator, so the code above could compile into

next4:
mov ebx,[esi]
mov [edi],ebx
add eax,ebx
adc edx,0
mov ebx,[esi+4]
mov [edi+4],ebx
add eax,ebx
adc edx,0
mov ebx,[esi+8]
mov [edi+8],ebx
add eax,ebx
adc edx,0
mov ebx,[esi+12]
mov [edi+12],ebx
add eax,ebx
adc edx,0
lea esi,[esi+16]
lea edi,[edi+16]
sub ecx,4
jae next4

This version could run the unrolled part in just 2 clock cycles, so
obviously better!

These days, if you still want to do this by hand in the CPU (to verify
that the network card TCP offload engine does not have hardware bugs),
then you would probably SIMD it, keeping the accumulators in a
carry-save pair of vector regs. :-)

Terje

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