Re: is Vax addressing sane today

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"