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: Wed, 25 Sep 2024 17:49:13 +0000 Organization: Rocksolid Light Message-ID: <9f4be1031dad0ee9a01d7e666f516d8f@www.novabbs.org> 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="3461274"; 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$pojdyJS8.Tyfmo2N271HYe.r6ayIm3aLkNLKBtUA5uv8WKS.eyrXG X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 Bytes: 5740 Lines: 97 On Wed, 25 Sep 2024 16:16:59 +0000, EricP wrote: > MitchAlsup1 wrote: >> On Sat, 21 Sep 2024 17:05:02 +0000, EricP wrote: >> >>> 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.... > > It all depends on the frequency that exceptions occur. > It used to be that Page Fault was the only one that occurred with any > frequency, and the code path for the page fault handler was long enough > that any HW overhead was lost in the noise. In all other cases they > indicated a fatal error so the HW cost was the least of your problems. > > But then, risc processors mostly, started using exceptions for > housekeeping > - SPARC for register window sliding, Alpha for byte, word and misaligned > memory access, MIPS and Alpha for software TLB-miss handling. > And suddenly the exceptional becomes the normal. > > The solution for Alpha was to add back the byte and word instructions, > and add misaligned access support to all memory ops. > Sparc stuck with traps for register windows. > No one else used software managed TLB's. > > Then virtual machines come along using exceptions to trigger > trap-and-emulate code, and now the normal becomes frequent. > Not 1 or 10 exceptions per second, but 100,000 or 200,000. High amounts of trap-and-emulate code originate from a "I am a CPU and I decide everything" mindset of ISAs developed before VMs came around. Too many control registers being touched too often, and don't get me started on interrupt "routing". What a VM wants is "I am a virtual CPU and I make choices for virtual me; I do not own interrupts or devices, or control the system--nor am I controlled by a sea of control registers". My 66000 architecture has only 1 instruction with any notion of privilege and when you touch a control register with it you end up changing a cache line size of control register state--dropping the amount of touches nearly an order of magnitude:: 100,000/sec -> 10,000/second. Privilege has been specified in such a way that a p-thread thread can context switch to another p-thread thread within a single application with a single non-privilege-violating instruction. New stack, new translation tables, save/restore the register files, change the ASID, change which exceptions are recognized/ignored, ... In addition, there is no SW overhead wrt interrupt routing when performing a "world switch" making a world switch have the same 10-20 cycle overhead as a context switch. > The solution for VM's is to add the ISA features necessary so that > most exceptions are rare, and when they do happen they are cheap. Exceptions should be rare AND cheap. But I argue against adding instructions to mask the deficiencies of the ISAs that got it wrong oh so long ago. But no-one will listen. I argue to fixe the problem at its source:: the notion of how the machine is controlled, and interrupted; rather than adding zillions of helper instruction to mask the real problem. > Worst case it should cost the same as a branch mispredict pipeline > drain.