Re: Computer architects leaving Intel...

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.