Re: Stealing a Great Idea from the 6600

John Savard wrote:

On Wed, 17 Apr 2024 23:32:20 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

With modern technology allowing 32-128 CPUs on a single die--there is
no reason to limit the width of a PP to 12-bits (1965:: yes there was
ample reason:: 2024 no reason whatsoever.) There is little reason to
even do 32-bit PPs when it cost so little more to get a 64-bit core.

Well, I'm not. The PP instruction set I propose uses 16-bit and 32-bit
instructions, and so uses the same bus as the main instruction set.

As Scott stated:: there does not seem to be any reason to need FP on a
core only doing I/O and kernel queueing services.

That's true.

This isn't about cores, though. Instead, a core running the main ISA
of the processor will simply have the option to replace one
regular-ISA thread by four threads which use 8 registers instead of
32, allowing SMT with more threads.

The hard thing is to run the Operating System in the PPs using the same
compiled code in either a big core or in a little core. The big cores
are on a CPU centric die, the little ones out on device oriented dies.
In 7nm a MIPS R2000 is less than 0.07mm^2 using std cells. At this size
every device can have its own core.

So we're talking about the same core. The additional threads will get
to execute instructions 1/4 as often as regular threads, so their
performance is reduced, matching an ISA that gives them fewer
registers.

I knew you were talking about it that way, I was trying to get you to
change your mind and use the same ISA in the device cores as you use
in the CPU cores so you can run the same OS code and even a bit of the device drivers as well.

Since the design is reminiscent of the 6600 PPs, these threads might
be used for I/O tasks, but nothing stops them from being used for
other purposes for which access to the FP capabilities of the chip may
be relevant.

Yes, exactly, and it is for those other purposes that you want these
device cores to operate on the same ISA as the big cores. This way if
anything goes wrong, you can simply lob the code back to a CPU centric
core and finish the job.

John Savard