Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 18 Sep 2024 18:42:19 +0000
Organization: Rocksolid Light
Message-ID: <7a8a967098cb2558c1bbdda5cb3ce99f@www.novabbs.org>
References: <vaqgtl$3526$1@dont-email.me> <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z> <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> <2024Sep15.194612@mips.complang.tuwien.ac.at> <vc8m5k$2nf2l$1@dont-email.me> <vc8tlj$2od19$3@dont-email.me> <vca209$319ci$1@dont-email.me> <vcbiov$3ecji$3@dont-email.me> <vccmm3$3m42h$1@dont-email.me> <e060fe2e0ee375efff2a9ab1223652f5@www.novabbs.org> <vccv3r$3nfqv$1@dont-email.me> <45fb24ca46af5c388b0a44af2f72ddf6@www.novabbs.org> <vcdjbn$3u259$1@dont-email.me> <77a593b0e8dcb7e4f38c006d3a148cdc@www.novabbs.org> <vcf491$57pi$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="2558328"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$jU.ebhEYUblOiROyGItRD.tnkU4qYchN6/3NLrd9bXuF0iPGfBYDu
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 4538
Lines: 83

On Wed, 18 Sep 2024 17:55:34 +0000, BGB wrote:

> On 9/18/2024 9:27 AM, MitchAlsup1 wrote:
>> On Wed, 18 Sep 2024 4:00:43 +0000, BGB wrote:
>>
>>> On 9/17/2024 6:04 PM, MitchAlsup1 wrote:
>>
>>>> Still limited to 32-bit displacement from IP.
>>>>
>>>> How would you perform the following call::
>>>> current IP = 0x0000000000001234
>>>> target  IP = 0x7FFFFFFF00001234
>>>>
>>>> This is a single (2-word) instruction in my ISA, assuming GOT is
>>>> 32-bit displaceable and 64-bit entries.
>>>>
>>>
>>> Granted, but in plain RISC-V, there is no real better option.
>>>
>>> If one wants to generate 64-bit displacement, and doesn't want to load a
>>> constant from memory:
>>>    LUI X6, Disp20Hi       //20 bits
>>>    ADDI X6, X6, Disp12Hi  //12 bits
>>>    AUIPC X7, Disp20Lo
>>>    ADD X7, Disp12Lo
>>>    SLLI X6, X6, 32
>>>    ADD X7, X7, X6
>>
>> How very much simpler is::
>>
>>      MEM    Rd,[IP,Ri<<s,DISP64]
>>
>> 1 instruction, 3 words, 1 decode cycle, no forwarding, shorter latency.
>
>
> It is simpler, but N/E in RV64G...
>
> This is the whole issue of the idea:
>    Remain backwards compatible with RV64G / RV64GC (in a binary sense).

So, you like sailing with an albatross tied around your neck:: Check.

> *and* try to allow extending it in a way such that performance can be
> less poor...

I should remind you that if you eliminate the compressed parts of
RISC-V you can fit the entire My 66000 ISA in the space remaining.
All the constants, all transcendentals, all the far-control transfers,
the efficient context switching, overhead free world switching,...
---------
>>>
>>> Which is sort of the whole reason I am considering hacking around it
>>> with an alternate encoding scheme.
>>
>> Just put in real constants.
>>>
>>> New encoding scheme can in theory do:
>>>    LEA X7, PC, Disp64
>>> In a single 96-bit instruction.
>>
>> Where is the indexing register?
>
> Generally the use of a displacement and index register are mutually
> exclusive (and, cases that can make use of Disp AND Index are much less
> common than Disp OR Index).

       COMMON ?alpha/ a(100,100), b(300,300),

...

       x = a(i,j)*b(j,i);

I see large displacements with indexing all the time from ASM out
of Brian's compiler.

> I may still consider defining an encoding for this, but not yet. It is
> in a similar boat as auto-increment. Both add resource cost with
> relatively little benefit in terms of overall performance.
> Auto-increment because if one has superscalar, the increment can usually
> be co-executed. And, full [Rb+Ri*Sc+Disp], because it is just too
> infrequent to really justify the extra cost of a 3-way adder even if
> limited mostly to the low-order bits...

Myopathy--look it up.