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: Tue, 17 Sep 2024 23:04:52 +0000
Organization: Rocksolid Light
Message-ID: <45fb24ca46af5c388b0a44af2f72ddf6@www.novabbs.org>
References: <vaqgtl$3526$1@dont-email.me> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2456349"; 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-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$oUY4034daT7ZNDLtl3wtgOTgAP1WR.0z9MU1pBsyBCoC3uoA1GdGK
Bytes: 4202
Lines: 70

On Tue, 17 Sep 2024 22:15:12 +0000, BGB wrote:

> On 9/17/2024 3:11 PM, MitchAlsup1 wrote:
>>
>> Modes make testing significantly harder. Each mode adds 1 to the
>> exponent
>> how many test cases it takes to adequately test a part.
>
> Possibly.
>
> But, modes are kinda unavoidable here:
>    CPU only runs RV64GC or similar:
>      Doomed to relative slowness;
>    CPU only does CoEx:
>      Closes off the ability to run binaries that assume RV64GC.
>    CPU only does new ISA:
>      Well, then it can't run RISC-V code, making all this kinda moot.

My 66000 does not have modes (at least yet) it even comes our of
RESET with the MMUs turned on.
-----------
>>> This is assuming an implementation that would want to be able to support
>>> both this ISA and also RV64GC.
>>>
>>> One possibility could be (in native RV notation):
>>> RV64 (Branches if supported, NOP if not):
>>>    LBU X0, Xs, Disp12s  //Dest=RV64GC
>>>    LWU X0, Xs, Disp12s  //Dest=CoEx
>>>    LHU X0, Xs, Disp12s  //Dest=Native
>>> New ISA:
>>>    LBU X0, Xs, Disp10s  //Dest=RV64GC
>>>    LWU X0, Xs, Disp10s  //Dest=CoEx
>>>    LHU X0, Xs, Disp10s  //Dest=Native
>>
>> This only gives 36-bits (top) or 30-bits (bottom) or range. What you are
>> going to want is 64-bits of range -- especially when switching modes--
>> you PROBABLY want to use an entirely different sub-tree of the
>> translation
>> table trees.
>
> Idea here is that 'Xs' will give the base address for the target.
>
> On the RISC-V side, this would mean, say:
>    AUIPC X7, disp
>    LWU X0, X7, disp
> Similar to a normal JALR.

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.

> I could almost interpret X0 as PC, except that on a "standard" RISC-V
> CPU, the non-supported case would be, likely: "program crashes trying to
> access a NULL pointer", which is less useful.
>
>
> Branches in the new ISA would likely be encoded using jumbo prefixes.
>
> Well, partly because the new ISA lacks AUIPC, but the new ISA can encode
> it more directly as, essentially:
>    LWU X0, PC, Disp33s

AUPIC is (and remains) a crutch (like LUI from MIPS)
a) it consumes an instruction (space and time)
b) it consumes a register unnecessarily
c) it consumes power that direct delivery of the constant would not