Re: is Vax addressing sane today

On Thu, 26 Sep 2024 17:13:02 +0000, EricP wrote:

MitchAlsup1 wrote:

On Wed, 25 Sep 2024 16:54:18 +0000, EricP wrote:

IIRC it was enabled by default in all DEC languages, Fortran77, Pascal,
Ada, Cobol, and disabled by default for C. But it could be toggled with
a runtime library call.

>
Similar--but library call does not have to "gain privilege" to flip the
bit's state.

>
The library routine didn't need a privilege change.

Most architectures do not allow the unpriviledged to access or modify
PSW (except the IP via branch instructions and CC via arithmetic).
My 66000 ISA allows unprivileged to access and modify PSW state
that only effects how the application acts. So, unprivileged can
modify:
a) IEEE flags
b) exception enablement
c) rounding mode
but not
d) Translation Tables
e) ASID
f) Dispatcher
g) call stack pointer
..
Even though they are stored in the same cache line.
<snip>

>
The problem is mostly due to the fact that expressions are
*mixtures of signed and unsigned, checked and modulo arithmetic*.
If overflow checks are enabled by status flag then the program has to
keep switching between modes for individual arithmetic operations.
This leads to a slew of enable and disable instructions which could
be serializing.

And often are.

This is because array index value expressions are calculated using
signed,
checked arithmetic, then the result is range checked against the bounds.
However addresses are calculated using modulo arithmetic.
Since most OS define address 0 to be the start of user space,
and locate the OS at FF...FF, addresses are unsigned modulo numbers.
>
If checks are not disabled for the address calculation
and the address not calculated using modulo arithmetic,
it is easy to trigger false overflow exceptions with arrays
that do not have base-0 or base-1 array bounds as many compilers
use bias-base array buffer pointers.
>
This is why one wants separate instructions for ADD and ADDV - there is
no overhead to switching between modulo and checked linear arithmetic.
>
Second, if there is a control register, it becomes part of the ABI.
It can either be
- undefined on calls, in which case each routine must save the current
   flags state on *each* entry and set a value, and restore the original
   state on return,
- or defined to have a particular enable/disable value on call and
   callee's are required toggle it if needed but restore it to default
   for all calls and returns.
>
Third, there is no reason to have overflow as a dynamic enable/disable
because the kind of arithmetic, modulo or linear, is fixed by what the
programmer writes and does not change dynamically.
>
Dynamic overflow enable results in a continuous overhead managing it
which does not occur with explicit fault testing instructions.

Where it consumes valuable OpCode space which is sometimes not available
{{3-operand 1-result instructions are notoriously "tight" in encoding:
± on 2 operands, int/float/double, FMAC<->INSert, attached
constant,...}}