Re: Computer architects leaving Intel...

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.

>

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.

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

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

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

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

>
Though, bigger issue might be how to make it able to access hardware
devices (seems like part of the physical address space is used for as a
PCI Config space, and would need to figure out what sorts of devices the
Linux kernel expects to be there in such a scenario).

It is reasons like this that cause My 66000 to have four 64-bit address
spaces {DRAM, MMI/O, configuration, ROM}. PCIe MMI/O space can easily
exceed 42-bits before one throws MR-IOV at the problem. Configuration
headers in My 66000 contain all the information CPUID has in x86-land.