Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 8 Sep 2024 08:25:10 +0200
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <vbjg06$1r8bb$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <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> <vbbnf9$8j04$1@dont-email.me>
 <vbbsl4$9hdg$1@dont-email.me> <vbcbob$bd22$3@dont-email.me>
 <vbcob9$dvp4$1@dont-email.me> <vbg0e8$v9mi$2@dont-email.me>
 <a3e7614794a11b67739888bcaa7e734a@www.novabbs.org>
 <vbguhv$18kfl$1@dont-email.me>
 <494082f2ee00c2ce616c1f95d2a67275@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 08 Sep 2024 08:25:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c080d6a1cd9e4f7fc7dbbe9ff4ca6cb9";
	logging-data="1941867"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+fGN7ansmwaI6XCM8Gc6UcUI2VT7iWr1o="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/REF27O97qkTzYE8b8EvglxsMXU=
In-Reply-To: <494082f2ee00c2ce616c1f95d2a67275@www.novabbs.org>
Content-Language: en-GB, nb-NO
Bytes: 4975

On 08/09/2024 02:17, MitchAlsup1 wrote:
> On Sat, 7 Sep 2024 7:15:11 +0000, David Brown wrote:
> 
>> On 07/09/2024 01:10, MitchAlsup1 wrote:
>>> On Fri, 6 Sep 2024 22:41:12 +0000, Chris M. Thomasson wrote:
>>>
>>>> On 9/5/2024 10:04 AM, Terje Mathisen wrote:
>>>>> David Brown wrote:
>>>>>> On 05/09/2024 11:12, Terje Mathisen wrote:
>>>>>>> David Brown wrote:
>>>>>>>> Unsigned types are ideal for "raw" memory access or external data,
>>>>>>>> for anything involving bit manipulation (use of &, |, ^, << and >>
>>>>>>>> on signed types is usually wrong, IMHO), as building blocks in
>>>>>>>> extended arithmetic types, for the few occasions when you want 
>>>>>>>> two's
>>>>>>>> complement wrapping, and for the even fewer occasions when you
>>>>>>>> actually need that last bit of range.
>>>>>>>
>>>>>>> That last paragraph enumerates pretty much all the uses I have for
>>>>>>> integer-type variables, with (like Mitch) a few apis that use 
>>>>>>> (-1) as
>>>>>>> an error signal that has to be handled with special code.
>>>>>>>
>>>>>>
>>>>>> You don't have loop counters, array indices, or integer arithmetic?
>>>>>
>>>>> Loop counters of the for (i= 0; i < LIMIT; i++) type are of course 
>>>>> fine
>>>>> with unsigned i, arrays always use a zero base so in Rust the only 
>>>>> array
>>>>> index type is usize, i.e the largest supported unsigned type in the
>>>>> system, typically the same as u64.
>>>>>
>>>>> unsigned arithmetic is easier than signed integer arithmetic, 
>>>>> including
>>>>> comparisons that would result in a negative value, you just have to 
>>>>> make
>>>>> the test before subtracting, instead of checking if the result was
>>>>> negative.
>>>>>
>>>>> I.e I cannot easily replicate a downward loop that exits when the
>>>>> counter become negative:
>>>>>
>>>>>    for (int i = START; i >= 0; i-- ) {
>>>>>      // Do something with data[i]
>>>>>    }
>>>>
>>>> for (int i = START; i > -1; i-- ) {
>>>>       // Do something with data[i]
>>>> }
>>>>
>>>> ;^)
>>>
>>> # define START 0x80000001
>>>
>>
>> No.
>>
>> The great thing about 32 bit integers is that your numbers are never
>> anywhere close to being too big - or you /know/ you are dealing with
>> very big numbers and you can take that into account such as by using
>> 64-bit integer types.
>>
>> A number that is the start or end of a normal count range is /never/
>> 0x80000001.  Write code that is clear, simple and correct for what you
>> are actually doing.  And if you think such big numbers are realistic,
>> write the same clear, simple and correct code with "int64_t" instead.
> 
> static uint64_t array[1024*1024*512+1]
> static int      SIZE = sizeof(array)/sizeof(uint65_t);

Surely you mean :

static const size_t array_size = sizeof(array) / sizeof(uint64_t);

?

Look, if you want to write such strange code, I certainly can't stop 
you.  But I can tell you that /I/ think it's very poor style, and that 
/I/ would reject it in a code review.