Re: My 66000 and High word facility

On Sat, 17 Aug 2024 20:57:43 +0000, Brett wrote:

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Sat, 17 Aug 2024 0:24:24 +0000, Brett wrote:
>

MitchAlsup1 <mitchalsup@aol.com> wrote:

>
When HW is doing the saves, it does them in a known order and
can mark the registers "in use" or "busy" instantaneously and
clear that status as data arrives. When SW is doing the same,
SW ahs to wait for the instruction to arrive and then do them
one-to-small numbers at a time. HW is not so constrained.

>
Ok, so the hardware is smart enough.

>
The Instructions and the compiler's use of them were co-developed.
>

But has anyone told the software guys?

>
Use HLLs and you don't have to.

>
>
I looked at interrupts in your manual and it did not say how many
registers
were full of garbage leaking information because they were not saved or
restored to make interrupts faster. ;)

When an ISR[13] returns from handling its exception it ahs a register
file
filled with stuff useful to future running's of ISR[13].
When ISR[13] gains control to handle another interrupt it has a file
filled
with what it was filled with the last time it ran--all 30 of them while
registers R0..R1 contain information about the current interrupt to be
serviced.
SP points at its stack
FP points at its frame or is another register containing whatever it
   contained the previous time
R29..R2 contain the value it had the previous time it ran

>
>

Of course convincing programmers to RTFM is futile. ;(

>
Done with Instructions in HW one has to convince exactly two
people; GCC code generator and LLVM code generator.

>
If so this is the first I have heard that more registers is not bad for
interrupt response time.

>
They are also bad for pipeline stage times.
>

So we are back to finding any downsides for 64 registers in My 66000.

>
Encoding

>
Admittedly painful, extremely so.
>

pipeline staging

>
A longer pipeline is slower to start up, but gets work done faster.
Is this what you mean?

No, I mean the feedback loops take more cycles so apparent latency
is greater.

context switch times

>
Task swapping time is way down in the noise. It’s reloading the L1 and
L2
cache that swamps the time. 64 registers is nothing compared to 32k or
megabytes.

While it is under 1% of all cycles, current x86s take 1,000 cycles
application to application and 10,000 cycles hypervisor to hypervisor.
I want both of these down in the 20-cycle range.