Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 28 Aug 2024 22:36:44 -0500
Organization: A noiseless patient Spider
Lines: 267
Message-ID: <vaoqcf$3r1u3$1@dont-email.me>
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>
 <2f1a154a34f72709b0a23ac8e750b02b@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 29 Aug 2024 05:36:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bf722ae835a3405e0686f423969f1f06";
	logging-data="4032451"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX194M2QRRXLRIEEOiBgFSmj0lCSD9+MQVoo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:KSAs4HnsPIpnINcduNXOqPEGm/k=
In-Reply-To: <2f1a154a34f72709b0a23ac8e750b02b@www.novabbs.org>
Content-Language: en-US
Bytes: 10927

On 8/28/2024 11:40 AM, MitchAlsup1 wrote:
> 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.
> 

Probably true.


Looks like Qualcomm thought similar:
Apparently they dropped the 'C' extension and added a bunch of stuff 
carried over from ARM and put it in the same space.

Apparently in their version of the RISC-V ISA, there are mostly 32 and 
64 bit instructions (with 48 bit being skipped over), with a mandatory 
32-bit alignment for the instruction stream.

Though, it also appears this decision has been... controversial...


Some stuff also implies there has been sort of a 3 way fight between 
Qualcomm, SiFive, and Google, over a lot of this. But, I don't know the 
specifics (beyond, well, SiFive wanting RV64GC to be the standard).


> 
>>>
>>> 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...
> 

If people can agree as to the encodings, then implementations are more 
free to pick which extensions they want or don't want.

If the encodings conflict with each other, no such free choice is possible.


Well, short of making the CPU modal.
Then one need not care as much about encoding issues, they can glue 
multiple ISA's together if they want.

Or, like, the newer RasPi Pico core:
Rather than having both Cortex-M33 and ThunderX3 RV32IMC cores, they 
could have in premise implemented a single core with both Thumb2 and 
RV32IMC decoders (say, with the CPU pattern matching the entry-point 
instruction at power-up; and requiring the entry point to contain a 
branch instruction in the respective ISA).


>>>> 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.


It likely isn't going to happen because a 1-wide machine isn't going to 
have the needed register ports.

But, if one doesn't have the register ports, there is likely no viable 
way to move 4 registers/cycle to/from memory (and it wouldn't make sense 
for the register file to have a path to memory that is wider than what 
the pipeline has).


If one settles on 2-wide as the minimum, they can load/store 2 registers 
per clock-cycle.

I am leaving out the possibility of 2-way ports mostly because generally 
"inout" ports and tristate logic are seemingly only really allowed on 
external IO pins or as optimization hints to the logic synthesis.


As noted, I was mostly going with a Load/Store instruction that does a 
register pair.

Could maybe do a register triple, but, no... Also, it would likely add 
cost to widen the L1 D$ front-end memory interface to 192 bits (and not 
likely to be worth the wonk this would add).


>>
>>
>>>>
>>>> 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.
>>>
>>>>
========== REMAINDER OF ARTICLE TRUNCATED ==========