Path: ...!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:45:44 +0200
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <vc999o$2reaa$1@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>
 <vc8m2o$2n382$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 16 Sep 2024 14:45:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1583d3c65366d20e8e7bb3dd5deb61e";
	logging-data="2996554"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188sINd+gtnmFogTMSYQnAjpgwnuT/c+Nc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:89ALc97uAPvYCQMZJMR7UksmWYQ=
In-Reply-To: <vc8m2o$2n382$2@dont-email.me>
Content-Language: en-GB
Bytes: 4235

On 16/09/2024 09:17, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> 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!).
> 
> It has happened, see the illegal (but sometimes useful)
> 6502 instructions, or the recent RISC-V implementation snafu
> (GhostWrite).

I have seen plenty of undefined behaviour in ISA's over the years.  (A 
very common case is that instruction encodings that are not specified 
are left as UB so that later extensions to the ISA can use them.)  I was 
just thinking of the reactions you'd get if you made an ISA where 
attempting to overflow signed integer arithmetic was UB at the hardware 
level, so that you could get faster and simpler instructions.

> 
>> 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 of course it should!
> 
> But wait, no, the number of apples should become zero if you add
> enough of them.
> 
> But wait... maybe if the pile becomes too large, then the apples
> will no longer be individual apples, but will be crushed under
> their weight, a bit like https://what-if.xkcd.com/4/ .
> 

:-)


>> 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.
> 
> One reason not to use such a wrapping type.

Agreed.

> 
> Although, if you have (R1+R2) addressing and a 32-bit addition, this
> could actually work, but not with a post-increment instruction.

Yes, but assuming you have 64-bit pointers you'd need a 64-bit + 32-bit 
addition.  That could work, but I think you'd end up making your ISA a 
fair bit more complicated for little gain (compared to just using UB 
overflow int types and not going overboard in the software).