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: Thu, 19 Sep 2024 20:21:20 +0000
Organization: Rocksolid Light
Message-ID: <790b8efbbbb95a6e56ea52bc004f466a@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2687126"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$PclYTbCZEgSJZ87ROTrF.uYjQ/IIPPReT6nYWhc4j9I7jFmxc1gi.
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4064
Lines: 70

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.

> Classic RISC says the loads are critical, but no one is one wide today,

SiFive disagrees with you.

> so
> stores matter for deconfliction…. And does stuff just fall out right to
> allow both?

Can you restate what you wanted to say using different words or perhaps
give an example ??