Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Wed, 9 Oct 2024 16:12:40 -0400
Organization: A noiseless patient Spider
Lines: 159
Message-ID: <ve6o3p$2on4l$1@dont-email.me>
References: <vbd6b9$g147$1@dont-email.me> <O2DHO.184073$kxD8.113118@fx11.iad>
 <vcso7k$2s2da$1@dont-email.me> <efXIO.169388$1m96.45507@fx15.iad>
 <ve1aqu$1qjrq$2@dont-email.me> <KNzNO.209961$EEm7.115549@fx16.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 09 Oct 2024 22:12:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="dd81d13d0ab1bf3b665bd74f11eee582";
	logging-data="2907285"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+q+tGZj+ZHeVUscLE9wR3ZMMtWEtesu+0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MYhZM8typotZWyiwLUyU9GXFKOM=
Content-Language: en-US
In-Reply-To: <KNzNO.209961$EEm7.115549@fx16.iad>
Bytes: 8783

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.