Re: is Vax addressing sane today

In article <efXIO.169388$1m96.45507@fx15.iad>,
EricP  <ThatWouldBeTelling@thevillage.com> wrote:

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.

>
For me error detection of all kinds is useful. It just happens
to not be conveniently supported in C so no one tries it in C.
>
GCC's -trapv option is not useful for a variety of reasons.
1) its slow, about 50% performance hit
2) its always on for a compilation unit which is not what programmers need
   as it triggers for many false positives so people turn it off.
>

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.

>
I understand, and I disagree with this conclusion.
I think all forms of software error detection are useful and
HW should make them simple and eliminate cost when possible.

I think I am not explaining the issue well.

I'm not arguing what you want to do with overflow.  I'm trying to show that
for all uses of detecting overflow other than crashing with no recovery,
hardware trapping on overflow is a poor approach.

If you enable hardware traps on integer overflow, then to do anything other
than crash the program would require engineering a very complex set of
data structures, roughly approximately the complexity of adding debug
information to the executable, in order to make this work.  As far as I know,
no one in the history of computers has yet undertaken this task.

This is because each instruction which overflows would need special
handling, and the "debug" information would be needed.  It would be a huge
amount of compiler/linker/runtime complexity.

This is different than most "signal" handlers people have written, where
simple inspection of the instruction which failed and the address involved
allows it to be "handled".  But to do anything other than crash, each
instruction which overflows needs special handling unique to that instruction
and dependent on what the compiler was in the middle of doing when the
overflow happened.  This is why trapping just isn't a good idea.

I'm just explaining why trap-on-overflow has gone away, because it's
almost completely useless:  hardware trap on overflow is only good for the
case that you want to crash on integer overflow.  Branch-on-overflow is the
correct approach--the compiler can branch to either a trapping instruction
(if you just want to crash), or for all other cases of detecting overflow,
the compiler branches to "fixup" code.

And crash-on-overflow just isn't a popular use model, as I use the example
of x86 in 32-bit mode having a 1-byte INTO instruction which crashes,
and no compiler seems to use it.  Especially since branch-on-overflow
is almost as good in every way.

Kent