Re: is Vax addressing sane today

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.