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: Sat, 21 Sep 2024 20:39:38 +0000
Organization: Rocksolid Light
Message-ID: <e290e18a59651f93e4b46f4839713b1c@www.novabbs.org>
References: <vbd6b9$g147$1@dont-email.me> <09ce1622b872f0b0fa944e868a8c97be@www.novabbs.org> <vbnisc$2hb59$1@dont-email.me> <2024Sep10.094353@mips.complang.tuwien.ac.at> <vckf9d$178f2$1@dont-email.me> <O2DHO.184073$kxD8.113118@fx11.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2924085"; 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$vyXYqrPZinfhrRMlPSbUsOj4XgRGwCeeCrOxx21zp8Es0N68MHd/2
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3449
Lines: 59

On Sat, 21 Sep 2024 17:05:02 +0000, EricP wrote:

> Kent Dickey wrote:

>> Basically, all a) cases are:
>>
>> 	op_with_might_overflow();
>> 	if(overflow_happened) {
>> 		handle the overflow
>> 	}
>>
>> Trapping-on-overflow instructions are clearly useless for languages
>> which care about overflow.
>
> This conclusion is completely wrong.

In the days before <good> branch prediction having a conditional branch
after each instruction that could have an execution problem was an
extremely poor choice. Thus, exceptions were invented (circa 1958).

Now with good branch prediction, having a branch after each instruction
which could suffer an execution problem is simply a bad was to blow
up the size of the executable.

> Exceptions are an event detection and notification delivery mechanism.

Exceptions are a free (easy to predict) branch.

> It is very efficient if those events are rarely or never supposed to
> occur.

Many (most, nearly all) processor architectures have notoriously
bad exception delivery to a point of control that can deal with
the problem at hand.

But it is not necessary for that bad mechanism to be necessary !!

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.


I know of only 1 ISA with these properties....