Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 8 Sep 2024 00:17:25 +0000
Organization: Rocksolid Light
Message-ID: <494082f2ee00c2ce616c1f95d2a67275@www.novabbs.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1238354"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$o2kDM66FVDhCxmByGzy/kO5y9WMCRPvZVOe2tt7o7eK4bQXUzOSxS
Bytes: 4317
Lines: 62

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);