Yeah, I think it was my misconception that this was going to be (at least also) targeted for a new platform for consumer computers. And yeah about the registers, that's pretty standard. I was commenting more of the diagram on wikipedia (below) where all the registers have a 'name'/roll except for like six of them t1 through t6
And now that I look at it... why are they calling registers x0-x32 rather than r0-r32
That seems like ABI not hardware? Passing/returning by register is common in ABIs and
is done in both x86-64 and aarch64.
Yes, I'm familiar with assembly programming. It just seems like there's a lot of "open" stuff in their chart for there to be an "existing software ecosystem"... including the talk about custom and extensions. I'm really not trying to poopoo on it, just trying to understand what their goal is...
That just seems like reasonable practice for outlining future functionality in such a way as to not cause backwards compatibility problems. Taking steps early on like reserving opcode space can save a lot of trouble later on.
granted, I was misunderstanding a bit starting out - thinking that it was aiming for a general purpose commodity processor to potentially compete with Intel/AMD.
That is a possible outcome, but it's also not necessary right this second to be feature complete wrt Intel/AMD. They can defer that until it's actually needed, which seems reasonable because when it's needed there will be concrete requirements to design against.
Of course, the other obvious advantage is that its open rather than paying licensing fees for ARM, etc. I was thinking back to my experiences in embedded computing (not tiny stuff, but stuff like from Sky, CSPI, Mercury, etc.) where they'd pull off-the-shelf parts like PPC 403, 603e, 603ev, etc. to make various boards and wondering if there were groups making off the shelf processors (like Snapdragon) that others would use rather than buy an ARM, etc.
To whatever extent an open source project can be said to have a business model, I believe RISC-V's value proposition is hedging against IP risks with ARM and other architectures, not a small point with ARMH being aquired by Nvidia. I've also seem comments attributed to someone from AMD where they mention they have dozens of cores embedded across their products where they get IP blocks from various vendors. One might have an ARM core, another might have a MIPS or PPC core, etc. This all ends up paying royalties and drags in different tool chains to support each. Rather than being antagonistic to AMD, RISC-V allows them to consolidate their vendors and various internal teams on an ISA with all the same tooling and no royalties. I believe a lot of hardware companies potentially benefit from that use case. Obviously those cores will be tiny and not useful for servers/PCs, but it's a solid foundation to justify real hardware implementations.
There's also a lot of interest from China which is understandable given US steps to cut their access to CPU IP from eg ARM. I think that's where the beefier implementations are starting to come from. For example Alibaba recently open sourced a relatively high performance RISC-V implementation.
Looking forward, once we hit The Last Node and we aren't redesigning things every couple years I think a lot of people are going to be asking why pay these giant margins/royalties to ARMH/Nvidiarm/AMD/Intel when we can do a transition once and be able to use a royalty free implementation with only minor updates for 20+ years. This is possibly not that useful in consumer facing devices but I think it potentially acts like Linux as a common infrastructure layer.
