Re: is Vax addressing sane today

On 2024-10-09 2:16 p.m., EricP wrote:

Kent Dickey wrote:

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

Kent Dickey wrote:

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.

 VAX/VMS 1.0 in 1979 had stack-based Structured Exception Handling (SEP).
And of course carried it over onto Alpha/VMS.
WinNT had SEP in its first version in 1992 for MIPS and 386
supported both by the C compiler and OS. Win95 had support too.
In WinNT MS added __try __except keywords to the C language to support
it for both themselves inside the OS and for users.
 Some languages like C++ and Ada have native support for SEP.
There can be differences in what behaviors languages expect to be supported,
like can one continue from an exception, or pass arguments to a handler.
 

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.

 General structured exception handling is not as complex or expensive
as you think. It's in the multiple 1000's of instructions range
(so don't use it gratuitously).
 WinNT implemented it differently on 32-bit x86 and 64-bit x64,
with the x64 method being more efficient because the compiler
does most of the work. On x64 the compiler just needs to supply
bounding low and high RIP's for *just the exception handler code*.
 The cost of delivering a structured exception is the OS basically
delivers an exception to a thread dispatcher similar to a signal,
but for structured exceptions that dispatcher code acts differently.
The thread's frame pointer is the head of a single linked list of
stack frames. It starts at the bottom of stack pointed to by the
frame pointer and scans backward, taking the RIP for each context
and looking in a small table of handler bounds to see if it is in range.
If there is a handler, it is called. If it handles it, great.
Otherwise it continues to scan backwards through the stack frames.
If it gets to the top of stack and there is no handler, it invokes the
thread's last chance handler, and if that doesn't intercept the exception,
it terminates the thread.
 

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.

 Except you keep missing the point:
no one has a handler for integer overflow because it should never happen.
Just like no one has a handler for memory read parity errors.
 When you wrote C code using signed integers, *YOU* guarenteed to the
compiler that your code would never overflow. Overflow checking just
detects when you have made an error, just like array bounds checking,
or divide by zero checking.
 This is not something being done *to you* against your will,
this is something that you *ask for* because it helps detect your errors.
Doing it in hardware just makes it efficient.
 A better exception usage example might be a routine that enables exceptions
for floating point underflow where the FPU traps to a handler that zeros
the value and logs where it happened so someone can look at it later,
then continues with its calculation.
 

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.

 But crash on overflow *IS* the correct behavior in 99.999% of cases.
Branch on overflow is ALSO needed in certain rare cases and I showed how
it is easily detected.
 

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

 Because C doesn't require it. That does not make the capability useless.
 Removing error detectors does not make the errors go away,
just your knowledge of them.
 

Slightly confused on trap versus branch. Trapping on overflow is not a good solution, but a branch on overflow is? A trap is just a slow branch. The reason for trapping was to improve code density and non-exceptional performance.
If it is the overhead of performing a trap operation that is the issue, then a special register could be dedicated to holding the overflow handler address, and instructions defined to automatically jump through the overflow handler address register (a branch target address register).
Overflow detecting instructions are just a fusion of the instruction and the following branch on overflow operation.
addjo r1,r2,r3 <- does a jump (instead of a trap) to branch register #7 for instance, on overflow.
Having an overflow branch register might be better for code density / performance.