Re: is Vax addressing sane today

On 2024-10-09 5:36 p.m., MitchAlsup1 wrote:

On Wed, 9 Oct 2024 20:12:40 +0000, Robert Finch wrote:
 

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

Kent Dickey wrote:
>
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,

 x86 has seriously distorted peoples view on how much overhead is
associated with a trap*. MIPS had trap handlers measuring in the
17 cycle range both getting to the handler, handling the exception,
and getting back to the instruction that trapped. Since GBOoO windows
have mispredicted branches in this kind of latency, too; then a
properly designed architecture should be able to do similarly to MIPS.
 Whereas x86 may take 1,000 cycles to get to the handler. This is due
to all the Descriptor table stuff, call-gates, protection rings, and
segmentation.
 (*) trap == exception == fault == any unpredicted control flow
cause by the instruction stream itself (SVC-et-al not included
because it is requested by the instruction stream).
 

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.

 What if you want to handle multiply overflow differently than
addition overflow ??

The branch register could be reloaded before the operation with a different handler address. It would be one instruction to load a PC relative address perhaps. Slightly better than having one instruction after every op.
For Q+ there would be room in the instruction to specify a branch register, so multiple handler targets could be supported.