Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 09 Sep 2024 05:55:08 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 71
Message-ID: <2024Sep9.075508@mips.complang.tuwien.ac.at>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <2024Sep5.133102@mips.complang.tuwien.ac.at> <vbchiv$cde4$1@dont-email.me> <2024Sep5.174939@mips.complang.tuwien.ac.at> <ljuc4fF86o3U2@mid.individual.net> <2024Sep6.092535@mips.complang.tuwien.ac.at> <20240906135718.00004f84@yahoo.com> <2024Sep6.152642@mips.complang.tuwien.ac.at> <65bc48543e1479699b5b2dff40c4f458@www.novabbs.org> <2024Sep8.173202@mips.complang.tuwien.ac.at> <27e4443119df12dd4588906810b24b32@www.novabbs.org>
Injection-Date: Mon, 09 Sep 2024 08:01:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bff24d76364ca7ea0d223f91191d43fd";
	logging-data="2433219"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19WjiUfQ1t1iIittvJ9fr/z"
Cancel-Lock: sha1:IdEM8D6dzhg726h577Od0LHkPg8=
X-newsreader: xrn 10.11
Bytes: 3411

mitchalsup@aol.com (MitchAlsup1) writes:
>On Sun, 8 Sep 2024 15:32:02 +0000, Anton Ertl wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>And just for fun::
>>>
>>>On Fri, 6 Sep 2024 13:26:42 +0000, Anton Ertl wrote:
>>>> Here we have the three variants:
>>>>
>>>> #include <limits.h>
>>>>
>>>> extern long foo1(long);
>>>> extern long foo2(long);
>>>>
>>>> long bar(long a, long b)
>>>> {
>>>>   long c;
>>>>   if (__builtin_sub_overflow(b,1,&c))
>>>>     return foo1(a);
>>>>   else
>>>>     return foo2(a);
>>>> }
>>>>
>>>> long bar2(long a, long b)
>>>> {
>>>>   if (b < b-1)
>>>>     return foo1(a);
>>>>   else
>>>>     return foo2(a);
>>>> }
>>>>
>>>> long bar3(long a, long b)
>>>> {
>>>>   if (b == LONG_MIN)
>>>>     return foo1(a);
>>>>   else
>>>>     return foo2(a);
>>>> }
>>>
>>>My 66000:
>>>    add    r3,R1,#-1   add  r3,r1,#-1         bepm  r1,.L4
>>>    bge    R3,.L4      bge  r3,.L4
>>>    8-bytes            8-bytes                4-bytes
>>>
>>>I have a direct test for POSMAX in ISA that does not use a constant.
>>
>> How does bge work in the first and second column?  My impression was
>> that you are using an 88k-style flags-in-GPR architecture.
>
>I just copied the RISC-V code

The RISC-V bge has two operands (plus the branch target), the bge in
your code has only one operand.  Here's the RISC-V code:

RV64GC:
addi a5,a1,-1        addi a5,a1,-1          li   a5,-1         
bge  a1,a5,10 <.L4>  bge  a1,a5,28 <.L6>    slli a5,a5,0x3f    
                                            bne  a1,a5,40 <.L8>

>> Concerning the last column, the gcc developer who added the
>> transformation of bar2() into bar3() apparently had My66000 in mind.
....
>BTW I had the comparisons to int-MAX/MIN in since about 2016.

The transformation was added to gcc after gcc-10 was released in 2020,
so my tongue-in-cheek theory is not falsified by the timing of events.

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