Deutsch   English   Français   Italiano  
<9f4be1031dad0ee9a01d7e666f516d8f@www.novabbs.org>

View for Bookmarking (what is this?)
Look up another Usenet article

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: <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> <dfXIO.169387$1m96.107616@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="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.