Deutsch English Français Italiano |
<918f6840f562b0dce653fe8baf92ce85@www.novabbs.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: is Vax addressing sane today Date: Mon, 23 Sep 2024 22:22:17 +0000 Organization: Rocksolid Light Message-ID: <918f6840f562b0dce653fe8baf92ce85@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> <e290e18a59651f93e4b46f4839713b1c@www.novabbs.org> <jwvfrpqkpcq.fsf-monnier+comp.arch@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="3206088"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$/AyGIVtGnbUBQHN8qk5fmepUL6Gz81Ms9KHix8Ubuvqtb8y59HWHO X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 Bytes: 3331 Lines: 42 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