Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Thu, 26 Sep 2024 18:11:56 +0000
Organization: Rocksolid Light
Message-ID: <92da4e9b66e86a7cbdac8720a51ac7e0@www.novabbs.org>
References: <vbd6b9$g147$1@dont-email.me> <2024Sep10.094353@mips.complang.tuwien.ac.at> <vckf9d$178f2$1@dont-email.me> <O2DHO.184073$kxD8.113118@fx11.iad> <vcso7k$2s2da$1@dont-email.me> <efXIO.169388$1m96.45507@fx15.iad> <8f031f2b5082d97582b1231a060f2b9f@www.novabbs.org> <8DgJO.171468$1m96.17060@fx15.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3609136"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$fL0LOpFlqh0Sb7IwftM7xOGf8HnVX75aueVv1MKrdblHHGyzccRMi
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 4317
Lines: 76

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