Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 28 Aug 2024 02:55:56 -0400
Organization: A noiseless patient Spider
Lines: 299
Message-ID: <vamhm0$3cs7q$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 28 Aug 2024 08:56:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fb60f876e94244a67034116828b706a9";
	logging-data="3567866"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+qHP7uK2rEaYMLqxAmHKS2alNI0xasVNk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ocmEmcr4lwv/2IeIPimQ76RfuNs=
Content-Language: en-US
In-Reply-To: <vam5qo$3bb7o$1@dont-email.me>
Bytes: 13149

On 2024-08-27 11:33 p.m., 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...
> 
> There were a few holes in this space. Like, for example, there are no 
> ANDW/ORW/XORW ops with Imm12s, so these spots could be reclaimed and 
> used for such a purpose, treating the Imm12 and Rs as a combined 17-bit 
> field.
> 
> 
> But, arguably, LUI+ADD, or LUI+ADD+LUI+ADD+SLLI+ADD, may not matter as 
> much if one can afford the pattern-matching logic to turn 2 (or 6) 
> operations into a fused operation...
> 
> 
>>> Where, there is a sizeable chunk of constants between 12 and 17 bits,
>>> but not quite as many between 17 and 32 (and 32-64 bits is comparably
>>> infrequent).
>>
>> Except in in "math codes".
>>
>> But 64-bit memory reference displacements means one does not have to
>> even bother to have a strategy of what to do when you need a single
>> FORTRAN common block to be 74GB in size in order to run 5-decade old
>> FEM codes.
>>
> 
> I don't assume that RISC-V would be getting a 64-bit FPU immediate 
> anytime soon.
> 
> 
>>> I could also make a case for an instruction to load a Binary16 value and
>>> convert to Binary32 or Binary64 in an FPR, but this is arguably a bit
>>> niche (but, would still beat out using a memory load).
>>
>> Most of these are covered by something like::
>>
>>      CVTSD   Rd,#1     // 32-bit instruction
>>
> 
> My case, I have:
>    FLDCH Imm16f, Rn  //also a 32-bit instruction
> Which can cover a significant majority of typical FP constants.
> 
> 
> In RISC-V, one needs to use a memory load, and store in memory using the 
> full 64-bits if one needs the value as "double". This kinda sucks.
> 
> Though, arguably still not as bad as it was on SH-4 (where constant 
> loading in general was a PITA; and loading a FP constant typically 
> involved multiple memory loads, and an address generation).
> 
> Eg:
>    MOVA    @(PC, Disp8), R3
>    FMOV.S  @R3+, FR5
>    FMOV.S  @R3+, FR4
> AKA: Suck...
> 
> 
>>>
>>> Big annoying thing with it, is that to have any hope of adoption, one
>>> needs an "actually involved" party to add it. There doesn't seem to be
>>> any sort of aggregated list of "known in-use" opcodes, or any real
>>> mechanism for "informal" extensions.
>>
>> 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.
> 
> 
> Well, or it becomes like the file-extension space where there are 
> seemingly pretty much no unused 2 or 3 letter filename extensions.
> 
> So, for some recent formats I went and used ".GTF" and ".UPI", which 
> while not unused, were not used by anything I had reason to care about 
> (medical research and banks).
> 
> 
> Though, with file extensions and names, at least one can web-search them 
> (which is more than one can do to check whether or not a part of the 
> RISC-V opcode map is used by a 3rd party extension).
> 
> What provisions have been made, don't scale much beyond "specific SoC 
> provides extensions within a block generally provisioned for SoC 
> specific extensions".
> 
> 
>>> 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.
> 
> High priority cases would likely be things that happen often enough to 
> significantly effect performance.
> 
> 
> As I see it, array loads/stores, and integer constant values in the 
> 12-17 bit range, are common enough to justify this.
> 
> 
> 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).
> 
> 
>>>
>>> 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
========== REMAINDER OF ARTICLE TRUNCATED ==========