Re: is Vax addressing sane today

On Mon, 7 Oct 2024 18:55:26 +0000, Kent Dickey wrote:

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 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.

And yet, this is exactly the kind of data C++ needs in order to
use its Try-Throw-Catch exception model. The stack walker needs
to know where on the stack is the list of stuff to free on block
exit, where are the preserved registers and how many, ...

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.
>
Kent