Re: My 66000 and High word facility

MitchAlsup1 <mitchalsup@aol.com> wrote:

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

I don’t remember the PlayStation using all registers in an interrupt, it
was only a few lines of code and 8 registers was fine. This would only save
you 3 cycles and is probably not worth the potential hassles.

I have heard programmers complaining that interrupt response was too slow
and so they had to add a second toy CPU just to handle interrupts. Probably
people that made the mistake of upgrading to x86.

Have wondered if having a scratchpad for interrupt code (and critical data)
would solve those problems as memory can be 150 cycles away, plus you can
have 40 pending reads queued ahead of you. Makes servicing interrupts in a
timely matter difficult, even if you are not touching much memory.

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.