Marcus <m.delete@this.bitsnbites.eu> schrieb:
> On 2021-12-31, Thomas Koenig wrote:
>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>
>>> As a matter of fact, you can now try out MRISC32 on Compiler Explorer
>>> (support was added about a week ago): https://godbolt.org/z/z9sK3MYeM
>>
>> I could not help but start experimenting with that :-)
>>
>> I seen no vectorization for
>>
>> void foo(int * const restrict a, int * const restrict b, int * restrict c, int n)
>> {
>> for (int i=0; i<n; i++)
>> c[i] = a[i]+b[i];
>> }
>>
>> and -fopt-info-vec-missed tells me, at https://godbolt.org/z/vPM3KTrnz ,
>> <source>:3:20: missed: couldn't vectorize loop
>> <source>:3:20: missed: not vectorized: unsupported data-type
>>
>> so it seems some more delving into gcc's secret internals
>> will be required...
>>
>
>
> Yup! Vectorization is not at all implemented (the compiler doesn't even
> know how to use the vector registers), so it's one of the more
> interesting improvements to be done to the MRISC32 GCC machine
> description.
>
> Since I'm not a compiler guy (at all), I'm pretty happy that I've gotten
> this far.

And pretty impressive it is, too. I've never even gotten close to
the machine description part of gcc.

> Auto-vectorization is not on the near term roadmap,
> unfortunately (things like better C++ support is higher up on the prio
> list). Also, the vector part of the ISA is not really finalized yet.
>
> Inline assembler is the solution for MRISC32 vector code. E.g:
>
> https://github.com/mbitsnbites/mc1-doom/blob/master/src/r_draw.c#L89

It might be possible to upgrade this to __builtin, at least, that way
it would be possible to at least the register allocation part to gcc.

Hmm... the only thing that comes to mind when selecting a vector
with size-agnostic vectors is the SVE feature of aarch64, so it might
be possible to pick up something from that. However, this is a _big_
ISA, and I am not sure that poking around there will lead to anything
useful in a reasonable amount of time.

On 2021-12-31, EricP wrote:
> 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.
>
> One or the other usage has to do a negate.
> The question is which usage, boolean or mask, is more common?
> In general it is boolean so it is mask user that should do the negate.
>
> There is a lot of C code that expects that a = b < c; produces 0 or 1.
> So if CMP produces a -1 then a C compiler would always generate a NEG too.
>
> For boolean expressions in IF statements the NEG is unnecessary
> if the branch tests zero/non-zero and so it might be optimized away.
> But that requires the compiler code gen knowing that boolean expressions
> in IF statements are not quite the same as other boolean expressions
> (and we give a special dispensation to & and | operators on booleans).
> Similar rational optimizes any for CMOV conditionals.
>
> It seems easier to have the mask user pay for the NEG.

MRISC32 is a vector-first ISA. Producing masks is the natural choice
when working with vectors.

I was mostly happy to discover that it worked pretty much equally well
for scalars & branches.

So far it seems that using -1 (mask) instead of +1 gives me roughly the
same instruction count in most situations as for architectures that use
a flags register:

* Cond. branch: S[cc] + BS ~= CMP + B[cc]
* Cond. select: S[cc] + SEL ~= CMP + CSEL[cc]/MOV[cc]
* Cond. to 0/1: S[cc] + NEG ~= CMP + CSET[cc]/MOV[cc]

OTOH it's a very good fit when dealing with vectors and even packed
data (SIMD). E.g. the following sequence does bytewise selection for
each vector element:

sltu.b v1, v2, v3
sel v1, v4, v5

SLTU.B does "set if less than (unsigned)" for each byte of a 32-bit
word, and since the instruction operands are vector registers, it will
perform the operation for each vector element (each element is 32 bits
wide).

SEL does "bitwise select", i.e. a = (b & a) | (c & ~a)

One of the key design principles of the MRISC32 ISA is that the same
instructions are used for scalar and for vector operands, with the same
semantics.

/Marcus

EricP <ThatWouldBeTelling@thevillage.com> writes:
>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.
>
>One or the other usage has to do a negate.

Not necessarily, there are architectures that can do both.

E.g., on Aarch64, the Forth word < (which produces 0 or -1) looks as
follows:

55555843A8: ldr x0, [x25,#0x8]! #load second stack item
55555843AC: add x26, x26, #0x8 #update instruction pointer
55555843B0: subs xzr, x0, x27 #compare
55555843B4: csinv x27, xzr, xzr, ge #and reify the ge condition as 0/-1
55555843B8: ldur x1, [x26,#-0x8] #dispatch next primitive
55555843BC: br x1 #dispatch next primitive

>The question is which usage, boolean or mask, is more common?

You can represent a boolean true as -1.

The issue is not "boolean", but C.

>There is a lot of C code that expects that a = b < c; produces 0 or 1.

Not just that, the language guarantees it.

>So if CMP produces a -1 then a C compiler would always generate a NEG too.

Only if the flag needs to be reified (not that common in C, with
branching operators like && and ||).

>For boolean expressions in IF statements the NEG is unnecessary
>if the branch tests zero/non-zero and so it might be optimized away.
>But that requires the compiler code gen knowing that boolean expressions
>in IF statements are not quite the same as other boolean expressions

This is easy to implement in a compiler. E.g., in tree-parsing
instruction selection you would have stuff like:

grammar rule # generated code
root: Condbranch(cond) # branch on the comparison result
cond: Lt(reg,reg) # generate a comparison
reg: cond # reify the cond as 0/1

and as long as the conds are consumed only by condbranches, you get no
reification and not negation.

>(and we give a special dispensation to & and | operators on booleans).

Not sure what you mean by that. You can also optimize & and | with
flags as parameters; assuming a cond is 0/-1 in a register (and not
just something in the condition codes; in that case I would introduce
additional nonterminals):

znz: cond # no code
cond: And(cond,cond) # and
znz: And(cond,reg) # and
znz: And(reg,cond) # and
cond: Or(cond,cond) # or
znz: Or(znz,reg) # or
znz: Or(reg,znz) # or

znz represents a flag as zero/nonzero value, which is useful in
combination with branch on zero instructions (i.e., if the result is
used by such a branch).

>It seems easier to have the mask user pay for the NEG.

Certainly MIPS, Alpha, and RISC-V designers thought so. But of course
it is possible to use instruction combining to eliminate the latency
cost of the negation.

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

On Friday, December 31, 2021 at 2:04:34 PM UTC-6, Anton Ertl wrote:
> EricP <ThatWould...@thevillage.com> writes:
> >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.
> >
> >One or the other usage has to do a negate.
> Not necessarily, there are architectures that can do both.
<
And architectures which provide both--this is my recommendation--
provide both.
>
> E.g., on Aarch64, the Forth word < (which produces 0 or -1) looks as
> follows:
>
> 55555843A8: ldr x0, [x25,#0x8]! #load second stack item
> 55555843AC: add x26, x26, #0x8 #update instruction pointer
> 55555843B0: subs xzr, x0, x27 #compare
> 55555843B4: csinv x27, xzr, xzr, ge #and reify the ge condition as 0/-1
> 55555843B8: ldur x1, [x26,#-0x8] #dispatch next primitive
> 55555843BC: br x1 #dispatch next primitive
> >The question is which usage, boolean or mask, is more common?
> You can represent a boolean true as -1.
>
> The issue is not "boolean", but C.
> >There is a lot of C code that expects that a = b < c; produces 0 or 1.
> Not just that, the language guarantees it.
> >So if CMP produces a -1 then a C compiler would always generate a NEG too.
> Only if the flag needs to be reified (not that common in C, with
> branching operators like && and ||).
<
And then there is My 66000 which has sign control bits in integer calculation
instructions::
<
Rd = -Rs1 - Rs2
<
to avoid 90%± of negation instructions; these pair with the constant attachment
encoding to decrease entropy of the encoding.
<
> >For boolean expressions in IF statements the NEG is unnecessary
> >if the branch tests zero/non-zero and so it might be optimized away.
> >But that requires the compiler code gen knowing that boolean expressions
> >in IF statements are not quite the same as other boolean expressions
> This is easy to implement in a compiler. E.g., in tree-parsing
> instruction selection you would have stuff like:
>
> grammar rule # generated code
> root: Condbranch(cond) # branch on the comparison result
> cond: Lt(reg,reg) # generate a comparison
> reg: cond # reify the cond as 0/1
>
> and as long as the conds are consumed only by condbranches, you get no
> reification and not negation.
<
Almost every reasonable(tm) ISA there is a way to CMP and BC without
having to jump through hoops of NEGs.
<
> >(and we give a special dispensation to & and | operators on booleans).
> Not sure what you mean by that. You can also optimize & and | with
> flags as parameters; assuming a cond is 0/-1 in a register (and not
> just something in the condition codes; in that case I would introduce
> additional nonterminals):
>
> znz: cond # no code
> cond: And(cond,cond) # and
> znz: And(cond,reg) # and
> znz: And(reg,cond) # and
> cond: Or(cond,cond) # or
> znz: Or(znz,reg) # or
> znz: Or(reg,znz) # or
>
> znz represents a flag as zero/nonzero value, which is useful in
> combination with branch on zero instructions (i.e., if the result is
> used by such a branch).
> >It seems easier to have the mask user pay for the NEG.
<
Mask consumers of conditions are less then 10% of consumers of conditions;
so, it makes sense to make them pay.
<
> Certainly MIPS, Alpha, and RISC-V designers thought so. But of course
> it is possible to use instruction combining to eliminate the latency
> cost of the negation.
<
It is even possible to make 90%+ of NEGs disappear by embedding negation/inversion
into the semantics of ISA encoding.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Thursday, December 30, 2021 at 9:51:01 AM UTC-7, EricP wrote:

> VAX Fortran used 0,-1 for LOGICAL but I don't know if that
> was defined by the language or implementation dependant.

I believe it would have been implementation dependent, since
IBM mainframe FORTRAN used 0 and 1 for .FALSE. and .TRUE.
respectively.

John Savard

On Thursday, December 30, 2021 at 2:24:37 PM UTC-7, Quadibloc wrote:
> On Friday, December 24, 2021 at 9:37:14 PM UTC-7, Ivan Godard wrote:
> > On 12/24/2021 10:17 AM, MitchAlsup wrote:
>
> > > There is NO JUSTIFIABLE reason that an instruction is not entirely
> > > self-contained!
>
> > Really? I suppose that might be true for OOO that is emulating
> > sequential execution, but what about VLIW and other wide multi-issue?
>
> > Chopping off the variable and large parts so they can be recognized in
> > parallel lets the issue width no longer depend on how many constants you
> > have.
>
> This is the sort of thing I've been fooling around with finding a way to
> achieve. To avoid too much complexity, my recent designs all involved
> a self-contained 256-bit block which combined as many fixed-length
> instructions as possible with the variable or large parts they needed.

I've turned my attention to Concertina II again, having thought of a
way to simplify one aspect of that design considerably.

There would just be one instruction format, and either blocks would
have no header, or just one kind of header.

Unfortunately, that turns out to have constrained available opcode space
severely enough to require some serious compromises, so it will take
some time to make those livable. Essentially, I have only 30 bits for the
32-bit instructions, since I include a break bit in the instruction itself,
and use half the opcode space for pairs of 15-bit instructions.

John Savard

aph@littlepinkcloud.invalid <aph@littlepinkcloud.invalid> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>> On 2021-12-30 22:07, Thomas Koenig wrote:
>>
>>>> What is the assembly for
>>>>
>>>> _Bool foo (int a, int b)
>>>> {
>>>> return a > b;
>>>> }
>>>>
>>>> for your architecture at a reasonable optimization level?
>>>>
>>>
>>> As a matter of fact, you can now try out MRISC32 on Compiler Explorer
>>> (support was added about a week ago): https://godbolt.org/z/z9sK3MYeM
>>
>>> POWER:
>>> subf 3,3,4
>>> srdi 3,3,63
>>> blr
>>
>> Subtract and right shift of the sign bit. That's another
>> way of doing this, I guess. When I saw this, I thought
>> "Somebody must have been feeling hackish"...
>
> Is it even correct? Surely that's (b - a < 0), not (a > b). I think
> it'd return true for foo(-0x7fffffff, 0x7fffffff). But I don't know
> the POWER ISA at all well, so pls ignore if this is cleverer than I
> think. :-).

POWER uses 64-bit data only (but it generates a 32-bit carry,
just in case), so this is indeed correct.

The code emitted for

_Bool foo (long a, long b)
{ return a > b;
}

is far less pretty and depends on selected CPU and comipiler.

gcc 4.8.5:

cmpd cr7,r3,r4
mfocrf r3,1
rlwinm r3,r3,30,31,31
blr

This moves a condition code into a register and extracts
the bit field.

gcc 12 with -mcpu=power8 (the current default):

sradi r10,r4,63
rldicl r9,r3,1,63
subfc r3,r3,r4
adde r3,r9,r10
xori r3,r3,1
clrlwi r3,r3,24
blr

That is weird. Two shifts and masks, one subtraction, one
addition, one xor, and one instruction that clears bits.

gcc 12 with -mcpu=power9:

li r9,0
li r10,1
cmpd r3,r4
iselgt r3,r10,r9
blr

Load constants into two registers and select based on a compare
instruction.

xlc:

cmpd r3,r4
li r3,1
bgt 14 <foo+0x14>
li r3,0
ori r2,r2,0
blr

Load 1, and conditionally branch around the load of 0. The or
with immediate is a not and some sort of hint to the linker, IIRC.

Clang:

sradi r5,r4,63
rldicl r6,r3,1,63
subfc r3,r3,r4
adde r3,r6,r5
xori r3,r3,1
blr

Same as gcc 12 for POWER8 above, but without the final clear.

At leat from an instruction count, the oldest solution looks
to be the best.

On Saturday, January 1, 2022 at 6:13:25 AM UTC-5, Thomas Koenig wrote:
> a...@littlepinkcloud.invalid <a...@littlepinkcloud.invalid> schrieb:
> > Thomas Koenig <tko...@netcologne.de> wrote:
> >> Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >>> On 2021-12-30 22:07, Thomas Koenig wrote:
> >>
> >>>> What is the assembly for
> >>>>
> >>>> _Bool foo (int a, int b)
> >>>> {
> >>>> return a > b;
> >>>> }
> >>>>
> >>>> for your architecture at a reasonable optimization level?
> >>>>
> >>>
> >>> As a matter of fact, you can now try out MRISC32 on Compiler Explorer
> >>> (support was added about a week ago): https://godbolt.org/z/z9sK3MYeM
> >>
> >>> POWER:
> >>> subf 3,3,4
> >>> srdi 3,3,63
> >>> blr
> >>
> >> Subtract and right shift of the sign bit. That's another
> >> way of doing this, I guess. When I saw this, I thought
> >> "Somebody must have been feeling hackish"...
> >
> > Is it even correct? Surely that's (b - a < 0), not (a > b). I think
> > it'd return true for foo(-0x7fffffff, 0x7fffffff). But I don't know
> > the POWER ISA at all well, so pls ignore if this is cleverer than I
> > think. :-).
> POWER uses 64-bit data only (but it generates a 32-bit carry,
> just in case), so this is indeed correct.
>
> The code emitted for
>
> _Bool foo (long a, long b)
> {
> return a > b;
> }
>
> is far less pretty and depends on selected CPU and comipiler.
>
> gcc 4.8.5:
>
> cmpd cr7,r3,r4
> mfocrf r3,1
> rlwinm r3,r3,30,31,31
> blr
>
> This moves a condition code into a register and extracts
> the bit field.
>
> gcc 12 with -mcpu=power8 (the current default):
>
> sradi r10,r4,63
> rldicl r9,r3,1,63
> subfc r3,r3,r4
> adde r3,r9,r10
> xori r3,r3,1
> clrlwi r3,r3,24
> blr
>
> That is weird. Two shifts and masks, one subtraction, one
> addition, one xor, and one instruction that clears bits.
>
> gcc 12 with -mcpu=power9:
>
> li r9,0
> li r10,1
> cmpd r3,r4
> iselgt r3,r10,r9
> blr
>
> Load constants into two registers and select based on a compare
> instruction.
>
> xlc:
>
> cmpd r3,r4
> li r3,1
> bgt 14 <foo+0x14>
> li r3,0
> ori r2,r2,0
> blr
>
> Load 1, and conditionally branch around the load of 0. The or
> with immediate is a not and some sort of hint to the linker, IIRC.
>
> Clang:
>
> sradi r5,r4,63
> rldicl r6,r3,1,63
> subfc r3,r3,r4
> adde r3,r6,r5
> xori r3,r3,1
> blr
>
> Same as gcc 12 for POWER8 above, but without the final clear.
>
> At leat from an instruction count, the oldest solution looks
> to be the best.

The PowerPC code demonstrates one of the issues with using condition
registers instead of GPRs for comparison results. They end up being
transferred to GPRs anyway. One would think that the compiler should
return a value in a condition register for a function returning a bool. Which
would be much more efficient. There are eight condition register available.
That way the condition register could be specified in a subsequent
conditional statement without needing to convert the GPR value to a
condition code. The equals flag of the condition register could be used to
store the Boolean value. The compiler would have to track values in
condition registers. There should be a ‘set’ instruction for the condition
registers allowing the bits to be transferred to the equals bit.

Compiled code should look something like:
SLT cr0,r3,r4
RET

On Friday, December 31, 2021 at 2:28:04 PM UTC-7, Quadibloc wrote:

> I've turned my attention to Concertina II again, having thought of a
> way to simplify one aspect of that design considerably.
>
> There would just be one instruction format, and either blocks would
> have no header, or just one kind of header.
>
> Unfortunately, that turns out to have constrained available opcode space
> severely enough to require some serious compromises, so it will take
> some time to make those livable. Essentially, I have only 30 bits for the
> 32-bit instructions, since I include a break bit in the instruction itself,
> and use half the opcode space for pairs of 15-bit instructions.

I've come up with something that should work. The sacrifice is that
16-bit instructions will only be available within code blocks with headers -
and they will not be able to be predicated.

John Savard

On 1/1/2022 4:05 AM, robf...@gmail.com wrote:
> On Saturday, January 1, 2022 at 6:13:25 AM UTC-5, Thomas Koenig wrote:
>> a...@littlepinkcloud.invalid <a...@littlepinkcloud.invalid> schrieb:
>>> Thomas Koenig <tko...@netcologne.de> wrote:
>>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
>>>>> On 2021-12-30 22:07, Thomas Koenig wrote:
>>>>
>>>>>> What is the assembly for
>>>>>>
>>>>>> _Bool foo (int a, int b)
>>>>>> {
>>>>>> return a > b;
>>>>>> }
>>>>>>
>>>>>> for your architecture at a reasonable optimization level?
>>>>>>
>>>>>
>>>>> As a matter of fact, you can now try out MRISC32 on Compiler Explorer
>>>>> (support was added about a week ago): https://godbolt.org/z/z9sK3MYeM
>>>>
>>>>> POWER:
>>>>> subf 3,3,4
>>>>> srdi 3,3,63
>>>>> blr
>>>>
>>>> Subtract and right shift of the sign bit. That's another
>>>> way of doing this, I guess. When I saw this, I thought
>>>> "Somebody must have been feeling hackish"...
>>>
>>> Is it even correct? Surely that's (b - a < 0), not (a > b). I think
>>> it'd return true for foo(-0x7fffffff, 0x7fffffff). But I don't know
>>> the POWER ISA at all well, so pls ignore if this is cleverer than I
>>> think. :-).
>> POWER uses 64-bit data only (but it generates a 32-bit carry,
>> just in case), so this is indeed correct.
>>
>> The code emitted for
>>
>> _Bool foo (long a, long b)
>> {
>> return a > b;
>> }
>>
>> is far less pretty and depends on selected CPU and comipiler.
>>
>> gcc 4.8.5:
>>
>> cmpd cr7,r3,r4
>> mfocrf r3,1
>> rlwinm r3,r3,30,31,31
>> blr
>>
>> This moves a condition code into a register and extracts
>> the bit field.
>>
>> gcc 12 with -mcpu=power8 (the current default):
>>
>> sradi r10,r4,63
>> rldicl r9,r3,1,63
>> subfc r3,r3,r4
>> adde r3,r9,r10
>> xori r3,r3,1
>> clrlwi r3,r3,24
>> blr
>>
>> That is weird. Two shifts and masks, one subtraction, one
>> addition, one xor, and one instruction that clears bits.
>>
>> gcc 12 with -mcpu=power9:
>>
>> li r9,0
>> li r10,1
>> cmpd r3,r4
>> iselgt r3,r10,r9
>> blr
>>
>> Load constants into two registers and select based on a compare
>> instruction.
>>
>> xlc:
>>
>> cmpd r3,r4
>> li r3,1
>> bgt 14 <foo+0x14>
>> li r3,0
>> ori r2,r2,0
>> blr
>>
>> Load 1, and conditionally branch around the load of 0. The or
>> with immediate is a not and some sort of hint to the linker, IIRC.
>>
>> Clang:
>>
>> sradi r5,r4,63
>> rldicl r6,r3,1,63
>> subfc r3,r3,r4
>> adde r3,r6,r5
>> xori r3,r3,1
>> blr
>>
>> Same as gcc 12 for POWER8 above, but without the final clear.
>>
>> At leat from an instruction count, the oldest solution looks
>> to be the best.
>
> The PowerPC code demonstrates one of the issues with using condition
> registers instead of GPRs for comparison results. They end up being
> transferred to GPRs anyway. One would think that the compiler should
> return a value in a condition register for a function returning a bool. Which
> would be much more efficient. There are eight condition register available.
> That way the condition register could be specified in a subsequent
> conditional statement without needing to convert the GPR value to a
> condition code. The equals flag of the condition register could be used to
> store the Boolean value. The compiler would have to track values in
> condition registers. There should be a ‘set’ instruction for the condition
> registers allowing the bits to be transferred to the equals bit.
>
> Compiled code should look something like:
> SLT cr0,r3,r4
> RET

This is very similar in effect to having different regfiles for integer
and FP, only in your proposal it's integer (and FP?) and bool. Splitting
regs by type does offer some code (and encoding) advantages, but also
some drawbacks. Think about how you would do VARARGS when bools are
passed in the flags :-)

robf...@gmail.com wrote:
> On Saturday, January 1, 2022 at 6:13:25 AM UTC-5, Thomas Koenig wrote:
>> a...@littlepinkcloud.invalid <a...@littlepinkcloud.invalid> schrieb:
>>> Thomas Koenig <tko...@netcologne.de> wrote:
>>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
>>>>> On 2021-12-30 22:07, Thomas Koenig wrote:
>>>>
>>>>>> What is the assembly for
>>>>>>
>>>>>> _Bool foo (int a, int b)
>>>>>> {
>>>>>> return a > b;
>>>>>> }
>>>>>>
>>>>>> for your architecture at a reasonable optimization level?
>>>>>>
>>>>>
>>>>> As a matter of fact, you can now try out MRISC32 on Compiler Explorer
>>>>> (support was added about a week ago): https://godbolt.org/z/z9sK3MYeM
>>>>
>>>>> POWER:
>>>>> subf 3,3,4
>>>>> srdi 3,3,63
>>>>> blr
>>>>
>>>> Subtract and right shift of the sign bit. That's another
>>>> way of doing this, I guess. When I saw this, I thought
>>>> "Somebody must have been feeling hackish"...
>>>
>>> Is it even correct? Surely that's (b - a < 0), not (a > b). I think
>>> it'd return true for foo(-0x7fffffff, 0x7fffffff). But I don't know
>>> the POWER ISA at all well, so pls ignore if this is cleverer than I
>>> think. :-).
>> POWER uses 64-bit data only (but it generates a 32-bit carry,
>> just in case), so this is indeed correct.
>>
>> The code emitted for
>>
>> _Bool foo (long a, long b)
>> {
>> return a > b;
>> }
>>
>> is far less pretty and depends on selected CPU and comipiler.
>>
>> gcc 4.8.5:
>>
>> cmpd cr7,r3,r4
>> mfocrf r3,1
>> rlwinm r3,r3,30,31,31
>> blr
>>
>> This moves a condition code into a register and extracts
>> the bit field.
>>
>> gcc 12 with -mcpu=power8 (the current default):
>>
>> sradi r10,r4,63
>> rldicl r9,r3,1,63
>> subfc r3,r3,r4
>> adde r3,r9,r10
>> xori r3,r3,1
>> clrlwi r3,r3,24
>> blr
>>
>> That is weird. Two shifts and masks, one subtraction, one
>> addition, one xor, and one instruction that clears bits.
>>
>> gcc 12 with -mcpu=power9:
>>
>> li r9,0
>> li r10,1
>> cmpd r3,r4
>> iselgt r3,r10,r9
>> blr
>>
>> Load constants into two registers and select based on a compare
>> instruction.
>>
>> xlc:
>>
>> cmpd r3,r4
>> li r3,1
>> bgt 14 <foo+0x14>
>> li r3,0
>> ori r2,r2,0
>> blr
>>
>> Load 1, and conditionally branch around the load of 0. The or
>> with immediate is a not and some sort of hint to the linker, IIRC.
>>
>> Clang:
>>
>> sradi r5,r4,63
>> rldicl r6,r3,1,63
>> subfc r3,r3,r4
>> adde r3,r6,r5
>> xori r3,r3,1
>> blr
>>
>> Same as gcc 12 for POWER8 above, but without the final clear.
>>
>> At leat from an instruction count, the oldest solution looks
>> to be the best.
>
> The PowerPC code demonstrates one of the issues with using condition
> registers instead of GPRs for comparison results. They end up being
> transferred to GPRs anyway. One would think that the compiler should
> return a value in a condition register for a function returning a bool. Which
> would be much more efficient. There are eight condition register available.
> That way the condition register could be specified in a subsequent
> conditional statement without needing to convert the GPR value to a
> condition code. The equals flag of the condition register could be used to
> store the Boolean value. The compiler would have to track values in
> condition registers. There should be a ‘set’ instruction for the condition
> registers allowing the bits to be transferred to the equals bit.
>
> Compiled code should look something like:
> SLT cr0,r3,r4
> RET

Just like x86 condition codes, POWER compilers will probably do a better
job if they can inline bool functions, so that the condition code can be
used directly instead of first having to be reified as an int, then
tested again in the calling function.

Terje

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

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

> Just like x86 condition codes, POWER compilers will probably do a better
> job if they can inline bool functions, so that the condition code can be
> used directly instead of first having to be reified as an int, then
> tested again in the calling function.

Very much so.

_Bool gt (long int a, long int b)
{ return a > b;
}

long int mymax(long int a,long int b)
{ return gt(a,b) ? a : b;
}

will give you, with -O3 on a current trunk,

cmpd r3,r4
isellt r3,r4,r3
blr

for mymax.

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>
>> So if CMP produces a -1 then a C compiler would always generate a NEG too.
>
> Only if the flag needs to be reified (not that common in C, with
> branching operators like && and ||).

What I was getting at was that the code gen point would likely be
so far down in the compiler that it would have lost the context necessary
to know whether this expression was a non-reified bool or integer,
it would have to assume it was integer and be forced to spit out a NEG
(as required by the C standard).

That left it with the much harder job of trying to optimize NEG away later.

But I see below that you show how to retain the necessary context.

>> For boolean expressions in IF statements the NEG is unnecessary
>> if the branch tests zero/non-zero and so it might be optimized away.
>> But that requires the compiler code gen knowing that boolean expressions
>> in IF statements are not quite the same as other boolean expressions
>
> This is easy to implement in a compiler. E.g., in tree-parsing
> instruction selection you would have stuff like:
>
> grammar rule # generated code
> root: Condbranch(cond) # branch on the comparison result
> cond: Lt(reg,reg) # generate a comparison
> reg: cond # reify the cond as 0/1
>
> and as long as the conds are consumed only by condbranches, you get no
> reification and not negation.
>
>> (and we give a special dispensation to & and | operators on booleans).
>
> Not sure what you mean by that. You can also optimize & and | with
> flags as parameters; assuming a cond is 0/-1 in a register (and not
> just something in the condition codes; in that case I would introduce
> additional nonterminals):

The & and | operators normally act on integral data types and return
the same types. It would need special handling so they operate on your
cond type and don't trigger reification.

As you show below.

> znz: cond # no code
> cond: And(cond,cond) # and
> znz: And(cond,reg) # and
> znz: And(reg,cond) # and
> cond: Or(cond,cond) # or
> znz: Or(znz,reg) # or
> znz: Or(reg,znz) # or
>
> znz represents a flag as zero/nonzero value, which is useful in
> combination with branch on zero instructions (i.e., if the result is
> used by such a branch).

Yes, this overloading for & and | would do.

The compiler would have to be built to propagate cond as a distinct type.
I was assuming that none of this would be in a C compiler already,
why would it since C defines these all as integer expressions,
which is why it for a port to this ISA that it would always generate
the NEG and then have to try to optimize it away.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>What I was getting at was that the code gen point would likely be
>so far down in the compiler that it would have lost the context necessary
>to know whether this expression was a non-reified bool or integer,

For that you would have to hide the data flow from the comparison to
the branch. Even relatively simple compilers will see this for most
code, and more sophisticated compilers keep track of data flow quite
far; admittedly, it gets a little tricky if there is a phi function in
between (but that's pretty rare for the stuff we are discussing here).

>> This is easy to implement in a compiler. E.g., in tree-parsing
>> instruction selection you would have stuff like:
>>
>> grammar rule # generated code
>> root: Condbranch(cond) # branch on the comparison result
>> cond: Lt(reg,reg) # generate a comparison
>> reg: cond # reify the cond as 0/1
>>
>> and as long as the conds are consumed only by condbranches, you get no
>> reification and not negation.
>>
>>> (and we give a special dispensation to & and | operators on booleans).
>>
>> Not sure what you mean by that. You can also optimize & and | with
>> flags as parameters; assuming a cond is 0/-1 in a register (and not
>> just something in the condition codes; in that case I would introduce
>> additional nonterminals):
>
>The & and | operators normally act on integral data types and return
>the same types. It would need special handling so they operate on your
>cond type and don't trigger reification.

cond is a nonterminal of the tree grammar, not a type. The trick with
tree grammars is that they typically are ambiguous, and the costs (not
shown here) of the code generation rules are used to select the
lowest-cost tree parse. In the present context, reifying will usually
be more expensive and will not be selected if an alternative exists.

>As you show below.
>
>> znz: cond # no code
>> cond: And(cond,cond) # and
>> znz: And(cond,reg) # and
>> znz: And(reg,cond) # and
>> cond: Or(cond,cond) # or
>> znz: Or(znz,reg) # or
>> znz: Or(reg,znz) # or
>>
>> znz represents a flag as zero/nonzero value, which is useful in
>> combination with branch on zero instructions (i.e., if the result is
>> used by such a branch).
>
>Yes, this overloading for & and | would do.
>
>The compiler would have to be built to propagate cond as a distinct type.

As mentioned, cond is a nonterminal, not a type (and root, reg, and
znz are also nonterminals). The rest of the compiler knows nothing
about these nonterminals, and does not need to concern itself with
them. It delivers a fully instantiated tree (i.e., only operators and
terminals) to the tree parser, and the tree parser selects the optimal
(wrt the tree grammar) parse (and thus code) for the tree. E.g.,

if (a<b) ...

could become the tree

Condbranch(Lt(Reg,Reg))

(note that the terminal "Reg" is different from the nonterminal "reg".)

Tree parsing is just one instruction selection technology, but others
(e.g., Davidson-Fraser) are just as capable of avoiding reification of
flags in the common cases. In Davidson-Fraser the conceptual process
might be along the lines of first generating the reification, and then
eliminating it through peephole optimization.

I guess that this is a major reason why we have not yet seen in the
condition handling area the kind of standardization on one particular
architectural style that we have seen in other areas (e.g., register
machines have won quite a while agod, 2s-complement has won a long
time ago, little-endian has won a short time ago, etc.).

In particular, (general-purpose) register machines have won because
compilers are so bad at making good use of special-purpose registers,
yet the MIPS or 88k approaches (both of which use general-purpose
registers for conditions) have not won out over the condition-code
register approach (AMD64, ARM A32, ARM A64).

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

On 2022-01-01, Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>
>> Just like x86 condition codes, POWER compilers will probably do a better
>> job if they can inline bool functions, so that the condition code can be
>> used directly instead of first having to be reified as an int, then
>> tested again in the calling function.
>
> Very much so.
>
> _Bool gt (long int a, long int b)
> {
> return a > b;
> }
>
> long int mymax(long int a,long int b)
> {
> return gt(a,b) ? a : b;
> }
>
> will give you, with -O3 on a current trunk,
>
> cmpd r3,r4
> isellt r3,r4,r3
> blr
>
> for mymax.
>

The MRISC32 version, https://godbolt.org/z/r6rTj5aWv

mymax:
max r1,r1,r2
ret

;-)

Le 01/01/2022 à 18:35, Marcus a écrit :
> On 2022-01-01, Thomas Koenig wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>>
>>> Just like x86 condition codes, POWER compilers will probably do a better
>>> job if they can inline bool functions, so that the condition code can be
>>> used directly instead of first having to be reified as an int, then
>>> tested again in the calling function.
>>
>> Very much so.
>>
>> _Bool gt (long int a, long int b)
>> {
>>    return a > b;
>> }
>>
>> long int mymax(long int a,long int b)
>> {
>>    return gt(a,b) ? a : b;
>> }
>>
>> will give you, with -O3 on a current trunk,
>>
>>     cmpd    r3,r4
>>     isellt  r3,r4,r3
>>     blr
>>
>> for mymax.
>>
>
> The MRISC32 version, https://godbolt.org/z/r6rTj5aWv
>
> mymax:
>         max     r1,r1,r2
>         ret
>
> ;-)

For RISCV, it's:
mymax:
bge a0,a1,.L4
mv a0,a1
..L4:
ret

So, requires a conditional branch...
But, for floating point (if supported), there is the 'fmax' instruction.

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Anton Ertl wrote:
>> What I was getting at was that the code gen point would likely be
>> so far down in the compiler that it would have lost the context necessary
>> to know whether this expression was a non-reified bool or integer,
>
> For that you would have to hide the data flow from the comparison to
> the branch. Even relatively simple compilers will see this for most
> code, and more sophisticated compilers keep track of data flow quite
> far; admittedly, it gets a little tricky if there is a phi function in
> between (but that's pretty rare for the stuff we are discussing here).
>
>>> This is easy to implement in a compiler. E.g., in tree-parsing
>>> instruction selection you would have stuff like:
>>>
>>> grammar rule # generated code
>>> root: Condbranch(cond) # branch on the comparison result
>>> cond: Lt(reg,reg) # generate a comparison
>>> reg: cond # reify the cond as 0/1
>>>
>>> and as long as the conds are consumed only by condbranches, you get no
>>> reification and not negation.
>>>
>>>> (and we give a special dispensation to & and | operators on booleans).
>>> Not sure what you mean by that. You can also optimize & and | with
>>> flags as parameters; assuming a cond is 0/-1 in a register (and not
>>> just something in the condition codes; in that case I would introduce
>>> additional nonterminals):
>> The & and | operators normally act on integral data types and return
>> the same types. It would need special handling so they operate on your
>> cond type and don't trigger reification.
>
> cond is a nonterminal of the tree grammar, not a type. The trick with
> tree grammars is that they typically are ambiguous, and the costs (not
> shown here) of the code generation rules are used to select the
> lowest-cost tree parse. In the present context, reifying will usually
> be more expensive and will not be selected if an alternative exists.
>
>> As you show below.
>>
>>> znz: cond # no code
>>> cond: And(cond,cond) # and
>>> znz: And(cond,reg) # and
>>> znz: And(reg,cond) # and
>>> cond: Or(cond,cond) # or
>>> znz: Or(znz,reg) # or
>>> znz: Or(reg,znz) # or
>>>
>>> znz represents a flag as zero/nonzero value, which is useful in
>>> combination with branch on zero instructions (i.e., if the result is
>>> used by such a branch).
>> Yes, this overloading for & and | would do.
>>
>> The compiler would have to be built to propagate cond as a distinct type.
>
> As mentioned, cond is a nonterminal, not a type (and root, reg, and
> znz are also nonterminals). The rest of the compiler knows nothing
> about these nonterminals, and does not need to concern itself with
> them. It delivers a fully instantiated tree (i.e., only operators and
> terminals) to the tree parser, and the tree parser selects the optimal
> (wrt the tree grammar) parse (and thus code) for the tree. E.g.,
>
> if (a<b) ...
>
> could become the tree
>
> Condbranch(Lt(Reg,Reg))
>
> (note that the terminal "Reg" is different from the nonterminal "reg".)
>
> Tree parsing is just one instruction selection technology, but others
> (e.g., Davidson-Fraser) are just as capable of avoiding reification of
> flags in the common cases. In Davidson-Fraser the conceptual process
> might be along the lines of first generating the reification, and then
> eliminating it through peephole optimization.

I'm looking at some papers on tree parsing peephole optimizers,
built using an LR(0) parser with extra bits to allow shift-reduce
and reduce-reduce conflicts to allow multiple matches.
Where the parse can follow multiple paths, it forks and follows all.

If I was doing this I would add an option to allow a semantic check to be
performed at each fork so you can guide it to choose particular forks
and prune unnecessary forks as soon as possible.

This breadth-wise cost based forking search is similar to how I did
syntax error repair. I also once built a lexical scanner that could
search for many, as in 10's of thousands, of search strings at once,
forking to follow multiple paths (I was thinking it might be useful
as a virus scanner).

On Sunday, January 2, 2022 at 12:55:45 PM UTC-6, Guillaume wrote:
> Le 01/01/2022 à 18:35, Marcus a écrit :
> > On 2022-01-01, Thomas Koenig wrote:
> >> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >>
> >>> Just like x86 condition codes, POWER compilers will probably do a better
> >>> job if they can inline bool functions, so that the condition code can be
> >>> used directly instead of first having to be reified as an int, then
> >>> tested again in the calling function.
> >>
> >> Very much so.
> >>
> >> _Bool gt (long int a, long int b)
> >> {
> >> return a > b;
> >> }
> >>
> >> long int mymax(long int a,long int b)
> >> {
> >> return gt(a,b) ? a : b;
> >> }
> >>
> >> will give you, with -O3 on a current trunk,
> >>
> >> cmpd r3,r4
> >> isellt r3,r4,r3
> >> blr
> >>
> >> for mymax.
> >>
> >
> > The MRISC32 version, https://godbolt.org/z/r6rTj5aWv
> >
> > mymax:
> > max r1,r1,r2
> > ret
> >
> > ;-)
> For RISCV, it's:
> mymax:
> bge a0,a1,.L4
> mv a0,a1
> .L4:
> ret
>
> So, requires a conditional branch...
> But, for floating point (if supported), there is the 'fmax' instruction.
<
Why is there not an IMAX instruction in every modern ISA ??

On 2022-01-02, MitchAlsup wrote:
> On Sunday, January 2, 2022 at 12:55:45 PM UTC-6, Guillaume wrote:
>> Le 01/01/2022 à 18:35, Marcus a écrit :
>>> On 2022-01-01, Thomas Koenig wrote:
>>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>>
>>>>> Just like x86 condition codes, POWER compilers will probably do a better
>>>>> job if they can inline bool functions, so that the condition code can be
>>>>> used directly instead of first having to be reified as an int, then
>>>>> tested again in the calling function.
>>>>
>>>> Very much so.
>>>>
>>>> _Bool gt (long int a, long int b)
>>>> {
>>>> return a > b;
>>>> }
>>>>
>>>> long int mymax(long int a,long int b)
>>>> {
>>>> return gt(a,b) ? a : b;
>>>> }
>>>>
>>>> will give you, with -O3 on a current trunk,
>>>>
>>>> cmpd r3,r4
>>>> isellt r3,r4,r3
>>>> blr
>>>>
>>>> for mymax.
>>>>
>>>
>>> The MRISC32 version, https://godbolt.org/z/r6rTj5aWv
>>>
>>> mymax:
>>> max r1,r1,r2
>>> ret
>>>
>>> ;-)
>> For RISCV, it's:
>> mymax:
>> bge a0,a1,.L4
>> mv a0,a1
>> .L4:
>> ret
>>
>> So, requires a conditional branch...
>> But, for floating point (if supported), there is the 'fmax' instruction.
> <
> Why is there not an IMAX instruction in every modern ISA ??
>

Agree.

Actually, RISC-V has MIN, MAX, MINU, MAXU (just like MRISC32) in the
bitmanip extension (a.k.a. the "add all instructions that should have
been part of the base ISA"-extension ;-) )

It also has VMIN, VMAX, VMINU, VMAXU in the V extension, acting on
vector registers.

....and VFMIN, VFMAX in the V extesions, acting on vector registers.

So in summary, RISC-V has two sets of integer MIN/MAX instructions and
two sets of floating-point MIN/MAX instructions. Different instructions
for different register files, and none of them part of the base
instruction set.

I also note that RISC-V goes against the trend and has *three* register
files (scalar integer + scalar floating-point + vector), with different
instruction sets for each register file. x86 history repeating?

/Marcus

EricP <ThatWouldBeTelling@thevillage.com> writes:
>I'm looking at some papers on tree parsing peephole optimizers,
>built using an LR(0) parser with extra bits to allow shift-reduce
>and reduce-reduce conflicts to allow multiple matches.

LR parsers are string parsers. The Graham-Glanville approach to code
generation used an LR parser on a prefix representation of the tree as
a poor-man's tree parser; of course they did not think about it that
way at the time, but once tree parser generators were developed, the
Graham-Glanville approach vanished.

An early paper on tree parsing is:

@InProceedings{emmelmann+89,
author = {Helmut Emmelmann and Friedrich-Wilhelm Schr\"oer and
Rudolf Landwehr},
title = {{BEG} -- a Generator for Efficient Back Ends},
crossref = "sigplan89",
pages = "227--237"
}

@Proceedings{sigplan89,
key = "SIGPLAN~'89",
booktitle = "SIGPLAN~'89 Conference on
Programming Language Design and Implementation",
title = "SIGPLAN~'89 Conference on
Programming Language Design and Implementation",
year = "1989",
}

Or you can read Section 2 of
<http://www.complang.tuwien.ac.at/papers/thier+18.pdf>, which provides
some background on this technology.

>If I was doing this I would add an option to allow a semantic check to be
>performed at each fork so you can guide it to choose particular forks
>and prune unnecessary forks as soon as possible.

For best code generation speed, the tree grammar is transformed into a
tree-parsing automaton (e.g., with the tool "burg"), where the code
generation speed is independent of the number of rules (and number of
alternative trees) involved.

Concerning semantics checks, in BEG and lburg costs can depend on
semantic things (i.e., things beyond the tree grammar), such as the
values of constants; Thier's constraints disable rules based on
semantic things (again, like the values of constants). But both
features are used for improved modeling of instructions (e.g., the
MIPS addiu instruction allows only a certain range of immediate
values), not pruning forks.

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

On 1/2/2022 2:37 PM, MitchAlsup wrote:
> On Sunday, January 2, 2022 at 12:55:45 PM UTC-6, Guillaume wrote:
>> Le 01/01/2022 à 18:35, Marcus a écrit :
>>> On 2022-01-01, Thomas Koenig wrote:
>>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>>
>>>>> Just like x86 condition codes, POWER compilers will probably do a better
>>>>> job if they can inline bool functions, so that the condition code can be
>>>>> used directly instead of first having to be reified as an int, then
>>>>> tested again in the calling function.
>>>>
>>>> Very much so.
>>>>
>>>> _Bool gt (long int a, long int b)
>>>> {
>>>> return a > b;
>>>> }
>>>>
>>>> long int mymax(long int a,long int b)
>>>> {
>>>> return gt(a,b) ? a : b;
>>>> }
>>>>
>>>> will give you, with -O3 on a current trunk,
>>>>
>>>> cmpd r3,r4
>>>> isellt r3,r4,r3
>>>> blr
>>>>
>>>> for mymax.
>>>>
>>>
>>> The MRISC32 version, https://godbolt.org/z/r6rTj5aWv
>>>
>>> mymax:
>>> max r1,r1,r2
>>> ret
>>>
>>> ;-)
>> For RISCV, it's:
>> mymax:
>> bge a0,a1,.L4
>> mv a0,a1
>> .L4:
>> ret
>>
>> So, requires a conditional branch...
>> But, for floating point (if supported), there is the 'fmax' instruction.
> <
> Why is there not an IMAX instruction in every modern ISA ??

because you don't need it when you have "?:".

gtr(b0, b1), pick(b0, b1, b2), retn(b0);

one bundle, one cycle.

On Monday, January 3, 2022 at 4:01:36 AM UTC-6, Ivan Godard wrote:
> On 1/2/2022 2:37 PM, MitchAlsup wrote:
> > On Sunday, January 2, 2022 at 12:55:45 PM UTC-6, Guillaume wrote:
> >> Le 01/01/2022 à 18:35, Marcus a écrit :
> >>> On 2022-01-01, Thomas Koenig wrote:
> >>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >>>>
> >>>>> Just like x86 condition codes, POWER compilers will probably do a better
> >>>>> job if they can inline bool functions, so that the condition code can be
> >>>>> used directly instead of first having to be reified as an int, then
> >>>>> tested again in the calling function.
> >>>>
> >>>> Very much so.
> >>>>
> >>>> _Bool gt (long int a, long int b)
> >>>> {
> >>>> return a > b;
> >>>> }
> >>>>
> >>>> long int mymax(long int a,long int b)
> >>>> {
> >>>> return gt(a,b) ? a : b;
> >>>> }
> >>>>
> >>>> will give you, with -O3 on a current trunk,
> >>>>
> >>>> cmpd r3,r4
> >>>> isellt r3,r4,r3
> >>>> blr
> >>>>
> >>>> for mymax.
> >>>>
> >>>
> >>> The MRISC32 version, https://godbolt.org/z/r6rTj5aWv
> >>>
> >>> mymax:
> >>> max r1,r1,r2
> >>> ret
> >>>
> >>> ;-)
> >> For RISCV, it's:
> >> mymax:
> >> bge a0,a1,.L4
> >> mv a0,a1
> >> .L4:
> >> ret
> >>
> >> So, requires a conditional branch...
> >> But, for floating point (if supported), there is the 'fmax' instruction.
> > <
> > Why is there not an IMAX instruction in every modern ISA ??
> because you don't need it when you have "?:".
>
> gtr(b0, b1), pick(b0, b1, b2), retn(b0);
>
> one bundle, one cycle.
<
and at least 4 times as much transport energy.

Le 02/01/2022 à 23:37, MitchAlsup a écrit :
> Why is there not an IMAX instruction in every modern ISA ??

Well, I can't say for every modern ISA, but for RISC-V, as Marcus said,
MIN/MAX instructions (and much more) are available in the Bitmanip
extension that has now been ratified recently if I'm not mistaken.

The reason is that the RISC-V ISA is very modular, so they have choosen
to keep the base ISA minimal, and then extend it.

It has benefits of course - you can design cores that are as minimal or
as featureful as needed, while still being compliant - but it also has
drawbacks: it will tend to lead to fragmentation. RISC-V has mitigated
that by defining "supersets" such as RV64GC that contain a number of
extensions, and that are meant for more general-purpose computing, but
fragmentation can still be an issue.

As to why they chose to put the MIN/MAX instructions in the "Bitmanip"
extension, I'm not sure. It looks like this extension contains A LOT of
common instructions that were non-essential, and missing in the base
ISA. Like a big bag of instructions, not all of them being really bit
manipulation-related IMHO. Oh, and the Bitmanip extension is itself
sliced into 4 sub-extensions =). Good luck if you were to implement the
whole extension in its entirety: it's very large.

Don't get me wrong, I do like RISC-V and have designed a RV32/64 core.
The more I've worked with this ISA and the more I've gotten to
understand the choices that were made. But, there's still this point
about fragmentation that I'm concerned with.

On 2022-01-03, Guillaume wrote:
> Le 02/01/2022 à 23:37, MitchAlsup a écrit :
>> Why is there not an IMAX instruction in every modern ISA ??
>
> Well, I can't say for every modern ISA, but for RISC-V, as Marcus said,
> MIN/MAX instructions (and much more) are available in the Bitmanip
> extension that has now been ratified recently if I'm not mistaken.
>
> The reason is that the RISC-V ISA is very modular, so they have choosen
> to keep the base ISA minimal, and then extend it.
>
> It has benefits of course - you can design cores that are as minimal or
> as featureful as needed, while still being compliant - but it also has
> drawbacks: it will tend to lead to fragmentation. RISC-V has mitigated
> that by defining "supersets" such as RV64GC that contain a number of
> extensions, and that are meant for more general-purpose computing, but
> fragmentation can still be an issue.
>
> As to why they chose to put the MIN/MAX instructions in the "Bitmanip"
> extension, I'm not sure. It looks like this extension contains A LOT of
> common instructions that were non-essential, and missing in the base
> ISA. Like a big bag of instructions, not all of them being really bit
> manipulation-related IMHO. Oh, and the Bitmanip extension is itself
> sliced into 4 sub-extensions =). Good luck if you were to implement the
> whole extension in its entirety: it's very large.

Funny thing: I recently discovered that they seem to have dropped the
bit-field instructions from bitmanip (!). I thought that it was one of
the key features of that extension. So I guess we're looking at more
bit-field extensions in the future, adding even more to the fragmentation.

https://github.com/riscv/riscv-bitmanip/issues/169

>
> Don't get me wrong, I do like RISC-V and have designed a RV32/64 core.
> The more I've worked with this ISA and the more I've gotten to
> understand the choices that were made. But, there's still this point
> about fragmentation that I'm concerned with.

I too like RISC-V (it's open, it works and it kind of scales), and at
the same time I dislike it (mostly the over-catering for ultra-small,
leading to some sub-optimal design decisions, and the fragmentation
part).

/Marcus

On Monday, January 3, 2022 at 12:21:44 PM UTC-6, Guillaume wrote:
> Le 02/01/2022 à 23:37, MitchAlsup a écrit :
> > Why is there not an IMAX instruction in every modern ISA ??
> Well, I can't say for every modern ISA, but for RISC-V, as Marcus said,
> MIN/MAX instructions (and much more) are available in the Bitmanip
> extension that has now been ratified recently if I'm not mistaken.
>
> The reason is that the RISC-V ISA is very modular, so they have choosen
> to keep the base ISA minimal, and then extend it.
<
And yet they seem to have nearly 2× the instruction count of My 66000 (59 BTW)
Including single and double FP along with 8 transcendental functions (sin,....)
>
> It has benefits of course - you can design cores that are as minimal or
> as featureful as needed, while still being compliant - but it also has
> drawbacks: it will tend to lead to fragmentation. RISC-V has mitigated
> that by defining "supersets" such as RV64GC that contain a number of
> extensions, and that are meant for more general-purpose computing, but
> fragmentation can still be an issue.
<
Having done many "cores", I can guarantee that adding MAX and MIN takes
more gates in the decoder than in the data path.
<
At one point in time I had ABS as a macro that used MAX as its base
instruction. Later I realized that ABS can be calculated at ¼ the power of
feeding MAX(x,-x) to the MAX/MIN unit.
>
> As to why they chose to put the MIN/MAX instructions in the "Bitmanip"
> extension, I'm not sure. It looks like this extension contains A LOT of
> common instructions that were non-essential, and missing in the base
> ISA. Like a big bag of instructions, not all of them being really bit
> manipulation-related IMHO. Oh, and the Bitmanip extension is itself
> sliced into 4 sub-extensions =). Good luck if you were to implement the
> whole extension in its entirety: it's very large.
>
> Don't get me wrong, I do like RISC-V and have designed a RV32/64 core.
> The more I've worked with this ISA and the more I've gotten to
> understand the choices that were made. But, there's still this point
> about fragmentation that I'm concerned with.