Re: My 66000 and High word facility

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. ;)

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?

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.

For example, My 66000 current encoding has room for 8 instructions
in the FMAC category (4 in use) with 6-bit register specifiers
I would need 4 major OpCodes instead of 1.
 
For your 98%-ile source code, 32-registers is plenty.
 

Lack of actual significant benefits is irrelevant, as all the programers
are 100% convinced that it will help some of their code. ;)
 

For example a 1-wide machine with a 4-ported register file,
generally operated as 3R1W can be switched to 4R or 4W for
epilogue or prologue uses respectively. Simulation indicates
this gets rid of 47% of the cycles spent in prologue and
epilogue (combined compared to a sequence of stores and loads)
Simulation also indicates that 42% of the power is saved--
mainly from Tag and TLB non-access cycles.