Re: is Vax addressing sane today

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.

So why should any hardware include an instruction to trap-on-overflow?

Trap-on-overflow instruction have a hardware cost, of varying severity.
If the ISA isn't already trapping on ALU instructions (such as
divide-by-0), it adds a new class of operations which can take
exceptions.  An ALU functional unit that cannot take exceptions doesn't
have to save "unwinding" info (at minimum, info to recover the PC, and
possibly rollback state), and not needing this can be a nice
simplification.  Branches and LD/ST always needs this info, but not
needing it on ALU ops can be a nice simplification of logic, and makes it
easier to have multiple ALU functional units.  Note that x86 INTO can
be treated as a branch, so it doesn't have the cost of an instruction
like "ADDTO r1,r2,r3" which is a normal ADD but where the ADD itself
traps if it overflows.  ADDTO is particularly what I am arguing against--
it is just a bad idea for the ISA to have ALU instructions take exceptions.

Instruction sets which make detecting overflow difficult (say, RISC-V),
would do well to make branch-on-overflow efficient and easy.  But adding
trap-on-overflow instructions is a waste of effort.

>
No they are a very useful tool for those who need such a tool
because the manual alternative is significantly more expensive
for both size and performance.
>
"I have one example where overflow exceptions would be a poor implementation
choice" does not imply "therefore no one should have them as an option".

Can you share what language, compiler, and hardware you are using which
implements overflow checks using a trap-on-overflow instruction?

Kent