Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 4 Sep 2024 19:41:36 -0500
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <vbauo3$18sj$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me>
 <vb9l7k$3r2c6$2@dont-email.me> <vba26l$3te44$1@dont-email.me>
 <vbag2s$3vhih$1@dont-email.me> <vS3CO.10106$kow1.6330@fx35.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 05 Sep 2024 02:41:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1f25f004199ea0f4099eed49c6b1bb6d";
	logging-data="41875"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/S06nYgU0f9N0zf3A+299xec+QbZx/0iU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:b3r9AiyryUXJScQALAJan+P1JzI=
Content-Language: en-US
In-Reply-To: <vS3CO.10106$kow1.6330@fx35.iad>
Bytes: 5404

On 9/4/2024 3:59 PM, Scott Lurndal wrote:
> Brett <ggtgp@yahoo.com> writes:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 04/09/2024 14:53, jseigh wrote:
>>>> On 9/4/24 06:57, David Brown wrote:
>>>>> On 04/09/2024 09:15, Terje Mathisen wrote:
>>>>>> David Brown wrote:
>>>>
>>>>>> Maybe?
>>>>>>
>>>>>> Rust will _always_ check for such overflow in debug builds, then when
>>>>>> you've determined that they don't occur, the release build falls back
>>>>>> standard CPU behavior, i.e. wrapping around with no panics.
>>>>>
>>>>> But if you've determined that they do not occur (during debugging),
>>>>> then your code never makes use of the results of an overflow - thus
>>>>> why is it defined behaviour?  It makes no sense.  The only time when
>>>>> you would actually see wrapping in final code is if you hadn't tested
>>>>> it properly, and then you can be pretty confident that the whole thing
>>>>> will end in tears when signs change unexpectedly.  It would be much
>>>>> more sensible to leave signed overflow undefined, and let the compiler
>>>>> optimise on that basis.
>>>>>
>>>>
>>>> You absolutely do want defined behavior on overflow.
>>>
>>> No, you absolutely do /not/ want that - for the vast majority of use-cases.
>>>
>>> There are times when you want wrapping behaviour, yes.  More generally,
>>> you want modulo arithmetic rather than a model of mathematical integer
>>> arithmetic.  But those cases are rare, and in C they are easily handled
>>> using unsigned integers.
>>
>> I tried using unsigned for a bunch of my data types that should never go
>> negative, but every time I would have to compare them with an int somewhere
>> and that would cause a compiler warning, because the goal was to also
>> remove unsafe code.
> 
> We use it exclusively for datatypes in the domain [0, 2**n).  It's always
> compared against other unsigned variables or constants.   Works quite well.
> Safer and cleaner than willy-nilly using int.
> 
> This is in a multi-million line C++ application.
> 

FWIW: To me, promoting signed and unsigned of the same size to an 
unsigned type of that size seemed a bit suspect.


In my own BS2 language, these cases would tend to promote to the next 
larger signed type. Say, comparing 'int' and 'uint' would first promote 
to 'long', and 'long' with 'ulong' would promote to 'int128' (int128 
didn't promote further, as it was the largest integer type).


Though, the type-system did differ from C in that in many cases it would 
also often take the destination type into account for type-promotion 
(partly also using inward type propagation rather than strictly outward).

Say:
   long z;
   int x, y;
   ...
   z=x*y;
Would auto-promote to long before the multiply.
Whereas "C tradition" holds that the value remain as int, potentially 
overflow (giving a wrapping value), and then get converted to 'long'.

But, integer overflow edge cases can effect some amount of software 
(mostly the same software that is prone to break if one doesn't give 
"-fwrapv" and similar with GCC).

So, for example, everything smaller than 'int' quietly promotes to 
'int', but 'int' may not quietly promote to long, as some software will 
break.


To a more limited extent, one can do similar in C, but mostly to limit 
cases where C rules would normally require promoting to "double" only to 
immediately truncate to float.
   float x, y;
   ...
   y=x+1.5;
A strict interpretation would promote to double only to immediately 
truncate, but it may be cheaper to just sort of treat it as-if the 
programmer had written:
   y=x+1.5f;
....


>>
>> Complete and udder disaster, went back to plain sized ints.
> 
> s/udder/utter/
> 

This distinction seems MOOOt...
But sometimes you need to milk these things for all they are worth.