RISC-V: They Should Have Known Better

That's sort of orthogonal to what I'm saying.

And the M5 doesn't have 500B transistors. We're well into the beginning of the ossification. Hell, it arguably started ~2006 with the end of dennard scaling leaving us with Tomasulo OoO cores being the design that makes the most sense for application cores, just getting wider over time as we get more gates.

I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... . With the FPU enabled at compile time, that's > 128 memory ops per interrupt. That's insane, especially without an NVIC and chaining and all that. My latency was astronomical, and my maximum interrupt frequency was pitiful. Ended up doing the work (sw and hardware options) to get it to operate more like arm-m, but arm-m doesn't need that work to be done. NVIC is always NVIC, and NVIC is good

Yes... but then you are kind of wasting a pipeline stage on nothing more than length decoding.

I suspect a design with a full decoder every 16-bits might actually win on everything but gate count, mostly because it can deal with variable length instructions and variable number of μops per instruction in the same step. A decoder that doesn't output a μop because it was clobbered by a previous instruction, can be handled the same was as a decoder that didn't output a μop because of μop fusion.

Actually, that approach might actually eliminate the need for the extra pipeline stage (just at the cost of gates).

It's certainly not a deal breaker. But it's a valid criticism of the ISA.

> […] then the CPU vendors can optimize on one side […]

I find the statement ironic and somewhat amusing (or bemusing – depending on the perspective) for reasons entirely unrelated to CPU's and/or RISC-V.

I keep hearing the phrase «we shall leave that to the vendors» every now and then. Only a few days ago, whilst attending a working-group session on an emerging data exchange standard, precisely the very much same argument was bluntly stated: «We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them».

The issue is that «the vendors» are not a single mythical intelligence or force possessed of infinite technical wisdom, unlimited, cosmic scale engineering resources and an relentless desire to right the wrongs.

They are businesses. They have narrow commercial objectives, conflicting priorities, disparities in the engineering talent and resourcing and, quite properly, incentives to advance their own products – you are right, to compete with other vendors. Where an opportunity appears to increase market share, lock customers in, differentiate their platforms and products or shift implementation burden elsewhere, one should expect them to notice it. It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.

So with «the vendors will do X», at best, we may hope that vendors will deliver an interpretation of the specification – to a degree, provided that doing so aligns sufficiently well with their commercial interests. An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.

> You do realize that Linux got basic SMP support 3 years after NT?

Linux started about three years after NT did. And NT could only support 64 processors for a long time when Linux could support thousands.

> It still does not have reliable sleep-wake.

Neither does NT really. Both depend on ACPI for the systems you're talking about, and it's the platform interface that's ultimately fucked.

> And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993

And has beaten NT on IO throughput for decades, and even now windows ships with a linux kernel integration because running Linux on a hypervisor is far batter for filesystem ops than running those on NT.

And the new async I/O API was so good that NT adopted it wholesale and didn't even bother changing the name. https://learn.microsoft.com/en-us/windows/win32/api/ioringap...

> So.. i'll expect an in-order core with an IPC south of 0.5 that cannot exit low power sleep 30% of the time in a decade or so.

There are already open source OoO RISC-V cores.

But the point originally isn't to be some Linux fan boy (I've written a decent amount of NT kernel code, and have a lot of respect for NT and the things it did right). It's to point out how the upcoming changes inherent to how chips are made and the latencies between gate count targets will better support open collaboration. And once that's supported properly, open source has a tendency to kind of snowball.