Re: is Vax addressing sane today

On Mon, 23 Sep 2024 22:00:36 +0000, Stefan Monnier wrote:

Some of the things that minimize the "badness" of taking an exception::
>
a) deliver control to user signal handler without taking an
  excursion through GuestOS. (think 10 cycles)
b) when control arrives, receiving thread is already reentrant.
c) when control arrives, the instruction (bits) and its operand
  values are delivered to the exception handler. So, the exception
  handler has what it needs to deal with the problem at hand.
d) when control returns, the result (R0) is delivered back to the
  destination register.
e) (b, c, d) are performed without handler needing to understand
  how. Handler is just a subroutine that receives arguments (c)
  fixes the problem, and returns a non-excepting value, or abort.
f) return has a way to re-execute the instruction or to skip the
  instruction under control of handler without having access
  to excepting-IP and without knowing the length of the
  instruction.
g) during (a..f) nobody ever has to disable interrupts or
  exceptions or re-enable them later. Priority and privilege
  are inherited automatically from excepting thread.

>
Note that in the case where you want the overflow exception to jump to
some alternate code path (a language-level exception handler, or a code
path that continues with a bigint instead of a register-sized integer),
(d) is useless because you don't want to return to the overflowing
instruction (nor to the immediately following instruction).  Instead you
usually want to lookup a side table indexed with the address of the
overflowing instruction to find the "exception handler" to "return" to.

longjump() returns in such a way that integer ADD code path is never
executed again.

(a) (b) and (c) are still very welcome, of course.

(d) is for the case where the exception handler fixes the problem
and calculates the desired result and skips the instruction on
return (completion) whereas you typical page fault is retried
upon return.

>
>
        Stefan