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: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 14:48:50 +0200
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <vc99fi$2re3k$2@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <vbcob9$dvp4$1@dont-email.me> <vbd6ia$e0ld$2@dont-email.me>
 <UxpCO.174965$Hld5.7714@fx15.iad> <vc41rl$1fhjd$1@dont-email.me>
 <2024Sep14.152652@mips.complang.tuwien.ac.at>
 <d93c1dc0455692767c89ea9f7bd47ed1@www.novabbs.org>
 <vc4o0l$1kuqf$1@dont-email.me> <vc6vno$285g2$1@dont-email.me>
 <vc8qor$2od9v$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 Sep 2024 14:48:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1583d3c65366d20e8e7bb3dd5deb61e";
	logging-data="2996340"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EoEVQcj28e27yQo5THGVjKHMQh0nlV8s="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:Tm1T2sNlJqqI8Etgg+iyaFyXlXc=
In-Reply-To: <vc8qor$2od9v$1@dont-email.me>
Content-Language: en-GB
Bytes: 3598

On 16/09/2024 10:37, Terje Mathisen wrote:
> David Brown wrote:
>> On 14/09/2024 21:26, Thomas Koenig wrote:
>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>
>>>> In many cases int is slower now than long -- which violates the notion
>>>> of int from K&R days.
>>>
>>> That's a designers's choice, I think.  It is possible to add 32-bit
>>> instructions which should be as fast (or possibly faster) than
>>> 64-bit instructions, as AMD64 and ARM have shown.
>>>
>>
>> For some kinds of instructions, that's true - for others, it's not so 
>> easy without either making rather complicated instructions or having 
>> assembly instructions with undefined behaviour (imagine the terror 
>> that would bring to some people!).
>>
>> A classic example would be for "y = p[x++];" in a loop.  For a 64-bit 
>> type x, you would set up one register once with "p + x", and then have 
>> a load with post-increment instruction in the loop.  You can also do 
>> that with x as a 32-bit int, unless you are of the opinion that enough 
>> apples added to a pile should give a negative number of apples.  But 
>> with a wrapping type for x - such as unsigned int in C or modulo types 
>> in Ada, you have little choice but to hold "p" and "x" separately in 
>> registers, add them for every load, and do the increment and modulo 
>> operation.  I really can't see this all being handled by a single 
>> instruction.
> 
> This becomes much simpler in Rust where usize is the only legal index type:
> 
> Yeah, you have to actually write it as
> 
>    y = p[x];
>    x += 1;
> 
> instead of a single line, but this makes zero difference to the 
> compiler, right?
> 

I don't care much about the compiler - but I don't think this is an 
improvement for the programmer.  (In general, I dislike trying to do too 
much in a single expression or statement, but some C constructs are 
common enough that I am happy with them.  It would be hard to formulate 
concrete rules here.)

And the resulting object code is less efficient than you get with signed 
int and "y = p[x++];" (or "y = p[x]; x++;") in C.