Re: Computer architects leaving Intel...

On Fri, 20 Sep 2024 13:52:32 +0000, EricP wrote:

MitchAlsup1 wrote:

On Thu, 19 Sep 2024 19:12:41 +0000, Brett wrote:
>

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Thu, 19 Sep 2024 15:07:11 +0000, EricP wrote:

>
>

- register specifier fields are either source or dest, never both

>
I happen to be wishywashy on this

>
>
This is deeply interesting, can you expound on why it is fine a register
field can be shared by loads and stores, and sometimes both like x86.

>
My 66000 encodes store data register in the same field position as it
encodes "what kind of branch" is being performed, and the same position
as all calculation (and load) results.
>
I started doing this in 1982 with Mc88100 ISA, and never found a problem
with the encoding nor in the decoding nor with the pipelining of it.
>
Let me be clear, I do not support necessarily damaging a source operand
to fit in another destination as::
>
    ADD     SP,SP,#0x40
>
by specifying SP only once in the instruction.
>
So,
>
    +------+-----+-----+----------------+
    | major| Rd  | Rs1 | whatever       |
    +------+-----+-----+----------------+
    |  BC  | cnd | Rs1 | label  offset  |
    +------+-----+-----+----------------+
    |  LD  | Rd  | Rb  | displacement   |
    +------+-----+-----+----------------+
    | ST   | Rs0 | Rb  | displacement   |
    +------+-----+-----+----------------+
>
Is:
a) no burden in encoding
b) no burden in decoding
c) no burden in pipelining
d) no burden in stealing the Store data port late in the pipeline
  {in particular, this saves lots of flip-flops deferring store
   data until after cache hit, TLB hit, and data has arrived at
   cache.}
>
I disagree with things like::
>
    +------+-----+-----+----------------+
    | big OpCode | Rds | whatever       |
    +------+-----+-----+----------------+
>
Where Rds means the specifier is used as both a source and destination.
>
Notice in my encoding one can ALWAYS take the register specification
fields and wire them directly into the RF/renamer decoder ports.
You lose this property the other way around.

>
I assume in your examples that you want to start your register file
read access and or rename register lookup access in the decode stage,
and not wait to start at the end of the decode stage.
Effectively pipelining those accesses.
That's fine.
>
But that's my point - it doesn't make a difference because in both
cases you can wire the reg fields to the reg file or rename directly
and start the access ASAP.

Not when a source field and a destination field are the same
field sometimes but not always. Your thought train adds a
register specifier mux between the destination field and
the overused source field in front of the destination
rename port. It is not a BIG hinderance, but it is not
insignificant is you are doing a "balls to the walls"
design.

In both cases the enable signal determining what to do shows up
later after decode has done its thing. And the critical path for
that decode enable signal is the same both ways.
>
And if you are not doing this early access start but the traditional
of latch the decode output THEN start your RegRd or Rename access
it makes no timing difference at all.
>
By allowing the opcode-Rds style instructions to be *CONSIDERED*
it opens an avenue to potential instructions that cost little or
nothing extra in terms of logic or performance.

The actual calculations are easy, it is the routing of data
to and from the calculation that is hard.

And this is particularly useful with fixed width 32-bit instructions
where one is try to pack as much function into a fixed size space as
possible. Even more so with 16-bit compact instructions.

RISC-V, because of where the various fields ARE, have a mux between
every source field and every register port--simply because their
positions move between non-compressed and compressed.
I agree with the position that if the mux is already there
that one should use it often and greatly.
Where I disagree is that the mux HAS to be there.

For example, a 32-bit fixed format instruction with four 5-bit registers
could do a full width integer multiply wide-accumulate
>
   IMAC (Rsd_hi,Rsd_lo) = (Rsd_hi,Rsd_lo) + Rs1 * Rs2

This violates the RISC tenet where each calculation instruction
produces exactly 1 result. I get around this with the mechanical
definition of the CARRY instruction. The MUL instruction produces
its result, CARRY captures the other, and deposits it in RF when
possible.

with little more logic than the existing MULL,MULH approach.
It still only needs 2 read ports because Rs1,Rs2 are read first to start
the multiply, then (Rsd_hi,Rsd_lo) second as they aren't needed until
late in the multiply-accumulate.