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: References: <09ce1622b872f0b0fa944e868a8c97be@www.novabbs.org> <2024Sep10.094353@mips.complang.tuwien.ac.at> 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 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....