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: Tue, 17 Sep 2024 11:15:36 +0200
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <vcbhbo$3ecjh$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> <vc999o$2reaa$1@dont-email.me>
 <vca3lv$31g5l$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 Sep 2024 11:15:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e52a47a8c62d553adb0a23714e2b020";
	logging-data="3617393"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Socgrbw86RK5073I1stsqqgghMn0sHCM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:nM1ULGxxTzRiG9LLKtmkPjzgKVs=
Content-Language: en-GB
In-Reply-To: <vca3lv$31g5l$2@dont-email.me>
Bytes: 3590

On 16/09/2024 22:15, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> 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.)
> 
> A much better idea is to raise an exception, that way you can
> be sure that nobody uses it for nefarious purposes.

Sure.  But not all processors are big enough to support such exceptions 
- many of those I have used are really small.  (An "unimplemented 
instruction" exception also lets you use it for non-nefarious purposes, 
such as supporting binary compatibility with other members of the 
processor family, or as convenient user extensions.)

>   
>> 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.
> 
> Hard to see how this would be possible... but I realize this
> is a hypothetical example.

Yes.