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: Wed, 28 Aug 2024 16:40:24 +0000
Organization: Rocksolid Light
Message-ID: <2f1a154a34f72709b0a23ac8e750b02b@www.novabbs.org>
References: <vajo7i$2s028$1@dont-email.me> <memo.20240827205925.19028i@jgd.cix.co.uk> <valki8$35fk2$1@dont-email.me> <2644ef96e12b369c5fce9231bfc8030d@www.novabbs.org> <vam5qo$3bb7o$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="45152"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$MGQ9tXPn/1jbsi2GIT8YhurwdMzim.znMn4MZGngof7SiNI0Upkby
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 5065
Lines: 112

On Wed, 28 Aug 2024 3:33:40 +0000, BGB wrote:

> On 8/27/2024 6:50 PM, MitchAlsup1 wrote:
>> On Tue, 27 Aug 2024 22:39:02 +0000, BGB wrote:
>>
>>> On 8/27/2024 2:59 PM, John Dallman wrote:
>>>> In article <vajo7i$2s028$1@dont-email.me>, tkoenig@netcologne.de (Thomas
>>>> Koenig) wrote:
>>>>
>>>>> Just read that some architects are leaving Intel and doing their own
>>>>> startup, apparently aiming to develop RISC-V cores of all things.
>>>>
>>>> They're presumably intending to develop high-performance cores, since
>>>> they have substantial experience in doing that for x86-64. The question
>>>> is if demand for those will develop.
>>>>
>>>
>>> Making RISC-V "not suck" in terms of performance will probably at least
>>> be easier than making x86-64 "not suck".
>>>
>> Yet, these people have decades of experience building complex things
>> that
>> made x86 (also() not suck. They should have the "drawing power" to get
>> more people with similar experiences.
>>
>> The drawback is that they are competing with "everyone else in
>> RISC-V-land,
>> and starting several years late.
>
> Though, if anything, they probably have the experience to know how to
> make things like the fabled "opcode fusion" work without burning too
> many resources.
>
>
>>>
>>>> Android is apparently waiting for a new RISC-V instruction set
>>>> extension; >> you can run various Linuxes, but I have not heard
>>> about anyone wanting to do so on a large scale.
>>>>
>>>
>>> My thoughts for "major missing features" is still:
>>> Needs register-indexed load;
>>> Needs an intermediate size constant load (such as 17-bit sign extended)
>>> in a 32-bit op.
>>
>> Full access to constants.
>>
>
> That would be better, but is unlikely within the existing encoding
> constraints.
>
> But, say, if one burned one of the remaining unused "OP Rd, Rs, Imm12s"
> encodings as an Imm17s, well then...

Dropping compressed instructions gives enough OpCode room to put the
entire My 66000 ISA in what remains.


>>
>> With the OpCode space already 98% filled there does not need to
>> be such a list.
>>
>
> One would still need it if multiple parties want to be able to define an
> extension independently of each other and not step on the same
> encodings.
>
And what kind of code compatibility would you have between different
designs...

>>> The closest we have on the latter point is the "Composable Extensions"
>>> extension by Jan Gray, which seems to be mostly that part of the ISA's
>>> encoding space can be banked out based on a CSR or similar.
>>>
>>>
>>> Though, bigger immediate values and register-indexed loads do arguably
>>> better belong in the base ISA encoding space.
>>
>> Agreed, but there is so much more.
>>
>>      FCMP    Rt,#14,R19        // 32-bit instruction
>>      ENTER   R16,R0,#400       // 32-bit instruction
>> ..
>>
>
> These are likely a bit further down the priority list.
>
>
> Prolog/Epilog happens once per function, and often may be skipped for
> small leaf functions, so seems like a lower priority. More so, if one
> lacks a good way to optimize it much beyond the sequence of load/store
> ops which is would be replacing (and maybe not a way to do it much
> faster than however can be moved in a single clock cycle with the
> available register ports).

My 1-wide machines does ENTER and EXIT at 4 registers per cycle.
Try doing 4 LDs or 4 STs per cycle on a 1-wide machine.
>
>
>>>
>>> At present, I am still on the fence about whether or not to support the
>>> C extension in RISC-V mode in the BJX2 Core, mostly because the encoding
>>> scheme just sucks bad enough that I don't really want to deal with it.
>>
>>>
>>> Realistically, can't likely expect anyone else to adopt BJX2 though.
>>
>> Captain Obvious strikes again.
>>
>
> This is likely the fate of nearly every hobby class ISA.
>
Time to up your game to an industrial quality ISA.