Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Tue, 24 Sep 2024 07:58:24 +0200
Organization: A noiseless patient Spider
Lines: 131
Message-ID: <vctke1$33me0$1@dont-email.me>
References: <vbd6b9$g147$1@dont-email.me>
 <2024Sep10.094353@mips.complang.tuwien.ac.at> <vckf9d$178f2$1@dont-email.me>
 <O2DHO.184073$kxD8.113118@fx11.iad> <vcso7k$2s2da$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 24 Sep 2024 07:58:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3651a7231ef7da6ad04f9fc6816c0f39";
	logging-data="3267008"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19arbtGRzF4jujojMvrsKoL+U7FZgx761CSrxM6qIm4Mw=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.19
Cancel-Lock: sha1:ijoXsD4+279QV86jzpsetoIG5ts=
In-Reply-To: <vcso7k$2s2da$1@dont-email.me>
Bytes: 6509

Kent Dickey wrote:
> In article <O2DHO.184073$kxD8.113118@fx11.iad>,
> EricP  <ThatWouldBeTelling@thevillage.com> wrote:
>> Kent Dickey wrote:
>>> In article <2024Sep10.094353@mips.complang.tuwien.ac.at>,
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Brett <ggtgp@yahoo.com> writes:
>>>>> Speaking of complex things, have you looked at Swift output, as it checks
>>>>> all operations for overflow?
>>>>>
>>>>> You could add an exception type for that, saving huge numbers of correctly
>>>>> predicted branch instructions.
>>>>>
>>>>> The future of programming languages is type safe with checks, you need to
>>>>> get on that bandwagon early.
>>>> MIPS got on that bandwagon early.  It has, e.g., add (which traps on
>>>> signed overflow) in addition to addu (which performs modulo
>>>> arithmetic).  It has been abandoned and replaced by RISC-V several
>>>> years ago.
>>>>
>>>> Alpha got on that bandwagon early.  It's a descendent of MIPS, but it
>>>> renamed add into addv, and addu into add.  It has been canceled around
>>>> the year 2000.
>>>
>>> [ More details about architectures without trapping overflow instructions ]
>>>
>>> Trapping on overflow is basically useless other than as a debug aid,
>>> which clearly nobody values.  If you take Rust's approach, and only
>>> detect overflow in debug builds, then you already don't care about
>>> performance.
>>
>> Those automatic software correctness checks, of which signed integer
>> overflow detection is one of many, went away because most code was
>> being written in C/C++ and those two languages don't require them.
>>
>> That just makes it more expensive in code size and performance to effect
>> such checks. This overhead leads some to conclude it justifies eliminating
>> the error checks.
>>
>> Eliminating the error event detectors doesn't make errors go away,
>> just your knowledge of them.
>>
>> I gather portions of 16-bit Windows 3.1 were written in Pascal.
>> When Microsoft developed 32-bit WinNT, if instead of C it they had
>> switched their official development language from Pascal to Modula-2
>> which does require signed and unsigned, checked and modulo arithmetic,
>> and array bounds checks, the world would have been a much safer place.
>>
>> But they didn't so it isn't.
>>
>> The x86 designers might then have had an incentive to make all the
>> checks as efficient as possible, and rather than eliminate them,
>> they might have enhanced and more tightly integrated them.
> 
> OK, my post was about how having a hardware trap-on-overflow instruction
> (or a mode for existing ALU instructions) is useless for anything OTHER
> than as a debug aid where you crash the problem on overflow (you can
> have a general exception handler to shut down gracefully, but "patching things
> up and continuing" doesn't work).  I gave details of reasons folks might
> want to try to use trap-on-overflow instructions, and show how the
> other cases don't make sense.
> 
> In no way was I ever arguing that checking for overflow was a bad idea,
> or a language issue, or anything else.  Just that CPUs should not bother
> having trap-on-overflow instructions.
> 
> You then went on to discuss how you want trap-on-overflow instructions
> for stuff like C code, so you can detect code bugs and shut down gracefully.
> 
> And my response to that is we already know compilers don't use it.  x86
> has INTO, which is "trap if the overflow bit is set".  So "ADD r8,r9; INTO"
> would trap if the add overflowed.
> 
> Look at:
> https://godbolt.org/z/oMhW55YsK
> 
> Which is this code:
> 
> int add2(int num, int other) {
>      return num + other;
> }
> 
> Compiled with these options:  -O2 -ftrapv
> (-ftrapv is the GCC argument for detect signed overflows and crash).
> 
> For x86-64 clang 19.1.0:
> 
> add2:
>          add     edi, esi
>          jo      .LBB0_1
>          mov     eax, edi
>          ret
> .LBB0_1:
>          ud1     eax, dword ptr [eax]
> 
> This looks OK: it does a normal add, then branches-on-overflow to
> an undefined instruction.
> 
> But x86 has an instruction to trap on overflow directly: INTO.  It's one byte.
> And it doesn't use it.
> 
> GCC x86-64 14.2 is even worse:
> 
> add2:
>          sub     rsp, 8
>          call    __addvsi3
>          add     rsp, 8
>          ret
> 
> It calls a routine to do all additions which might overflow, and that
> routine calls assert() if an overflow occurs.
> 
> The CPU has a trap-on-overflow instruction exactly for this case (to crash
> on detecting an overflow), and compilers don't even use it.
> 
> So even on architectures which have a trap-on-overflow instruction,
> compilers don't use it.

You can only compile in INTO opcodes if you can guarantee that the INT 4 
(INTO) trap vector will always be set to a proper handler, and since 
that isn't part of the ABI, compilers can't depend on it?

I do agree that it would be nice if it did work, barring that clang is 
doing the best possible alternative, at close to zero cost except for 
the useless branch predictor table entry wastage.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"