Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 20 Sep 2024 17:39:34 +0000
Organization: Rocksolid Light
Message-ID: <e441bbb92669d424b991cef854cb943f@www.novabbs.org>
References: <vaqgtl$3526$1@dont-email.me> <2024Sep11.123824@mips.complang.tuwien.ac.at> <vbsoro$3ol1a$1@dont-email.me> <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com> <vbuu5n$9tue$1@dont-email.me> <20240915001153.000029bf@yahoo.com> <vc6jbk$5v9f$1@paganini.bofh.team> <20240915154038.0000016e@yahoo.com> <vc70sl$285g2$4@dont-email.me> <vc73bl$28v0v$1@dont-email.me> <OvEFO.70694$EEm7.38286@fx16.iad> <32a15246310ea544570564a6ea100cab@www.novabbs.org> <vc7a6h$2afrl$2@dont-email.me> <50cd3ba7c0cbb587a55dd67ae46fc9ce@www.novabbs.org> <vc8qic$2od19$1@dont-email.me> <fCXFO.4617$9Rk4.4393@fx37.iad> <vcb730$3ci7o$1@dont-email.me> <7cBGO.169512$_o_3.43954@fx17.iad> <vcffub$77jk$1@dont-email.me> <n7XGO.89096$15a6.87061@fx12.iad> <35b8ff2e6baa54c7aa22ec4edf45c3f9@www.novabbs.org> <vcht39$mbru$1@dont-email.me> <790b8efbbbb95a6e56ea52bc004f466a@www.novabbs.org> <17fHO.39328$S9Vb.11276@fx45.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2791334"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$5dTHmlRQEdqwac18IVUGL.6.tVsrw3l2a09buDSi6do1Lg3F7XFga
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 6804
Lines: 124

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.