Re: is Vax addressing sane today

On Wed, 25 Sep 2024 13:56:40 -0400
EricP <ThatWouldBeTelling@thevillage.com> wrote:

Terje Mathisen wrote:

Kent Dickey wrote: 

>
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 

 
On x64 in 64-bit mode INTO is among 21 opcodes reassigned as invalid.
One must use JO to detect signed overflow.
Others were repurposed, 1-byte INC and DEC 40..4F became the REX
prefix.
 
 

Single-byte form of INTO reassigned. Dual-byte form (CD 04) is here.