Some stats on an aarch64 binary of my current main project (1.6MB .text, 6600 symbols as per whatever "nm the-binary | wc -l" includes, from "objdump -d the-binary"):
19546 /tbn?z/
18029 /tbn?z.*, #0x0/ (but this includes boolean checks)
224 /tbn?z.*, #0x1f/ (i.e. 32-bit x<0)
1139 /tbn?z.*, #0x3f/ (i.e. 64-bit x<0)
154 other immediates
Said project doesn't do fixed bitfields much (there are some, but a chunk of those test multiple bits) so unsurprisingly not much. (I could imagine that the kernel has significantly more, but it's an edge-case (though perhaps an important one) of being basically massive amounts of fixed configurable glue)
That is quite a good bit more evenly-spread (the "..." is 5159 instrs).
Wonder what's up with bit 21; if whatever uses it so much is repositionable (and not an aarch64-specific thing), could save like 2KB on x86-64 via putting it in the low 8 bits instead.
There is very cool history as to why. In armv5 the BL was two separate instructions. You could take an interrupt in between. And it was documented what each did. Veeery cool. Then they wanted more range. And now that they redefined the two halves as one instruction that could not be in halves, they also redefined a few bits that were always 1 before, to allow the second half of the instruction to be recognized right without a “previous instruction was first half of BL” flag somewhere that would need to be context switched and all that.
No, RISC-V code is much more compact than Amd64. This is easily demonstrated on any real application, such as those in your favourite Linux distribution.
Linux is decent for its core use cases, but it is far from a solid pro-grade OS in a lot of areas... and in the areas it did get there, it took a long time to get there.
If those people build cores like linux kernel is built design-wise, i will PAY to watch the spectacle.
You do realize that Linux got basic SMP support 3 years after NT, and it was shaky for a while after? It still does not have reliable sleep-wake. And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993? 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.
> 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.
> 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.
What does this have to do with anything? You do know that a bunch of American corporations are shipping RISC-V cores, right? Including Jim Keller's current company, Tenstorrent.
Chinese scale is one way RISC-V could win. If China suddenly starts reaching <5nm process nodes at scale and uses RISC-V, they'd flood the market with cheap high performance RISC-V chips and probably start using them in their domestic Android phone market.
I mean, Apple is different from pretty much every other manufacturer here. They collborated in the design of aarch64, and a rumored to own a lot of the base IP themselves which they've cross licensed with ARM. It's very close to AMD:Intel::Apple:ARM when it comes to aarch64. That heavily changes the licensing costs. My point isn't that RISC-V is markedly better, but instead that it's equivalent from a perf achievable from in the same nexus of PPA and NRE effort. So there's no reason for Apple to take the pain of a leap with no real gain, but NRE losses.
I would expect to see RISC-V Android phones (probably initially out of China, despite ARM China) within the next few years. They've been busy bees since RVA23 was ratified with a bunch of Chinese companies making changes to optimize AOSP for RVA23. I've also heard on the grapevine that NT already has a RISC-V port internally, but take that with whatever grain of salt you feel like. But Microsoft has already been contributing to the RISC-V specs (they contributed to Ztso for instance).
There is zero chance that Apple doesn't have MacOS and iOS running on RISC-V in the lab.
They did that with x86 and Arm half a decade before any announcement about a switch, not to mention a number of other ISAs that didn't make it to shipping (e.g. M88k) and probably ones that word has never leaked about. IA64, anyone?
They're too large and rich and risk-averse to *not* do it.
Not me for sure. I have no idea about you. Of household name companies I've only worked at Mozilla and Samsung R&D. And SiFive if you count people in threads such as this.
I could of course be wrong but I think the publicly known history sets the pattern pretty reliably for the speculation.
The future set of people who once would have "work(ed) for free to design you a state-of-the-art kernel"? If the tail is long enough passionate hobbyists will do it because they love it...eventually.
Honestly, I would feel uncomfortable if I were designing an instruction encoding and came up with some addressing mode format where there are two bits for a displacement. I would pull myself aside and have a word with myself. That's just me, though.
Considering just how many of the problems seem to come from RISC-V being a clean-sheet design, I suspect we would be better off not doing another.
What I am interested in is the idea doing an AArch64 style revamp of the ISA, were much of the non-encoding semantic stuff is kept, but the entire instruction encoding (plus all the CSRs, and other things) are reworked to be sane.
You might even do two reworkings in parallel, with one variable-width encoding optimised for microcontrollers, thumb-style; And the other being a fixed-width encoding optimised for wide out-of-order cores.
And at the same time, you make a bunch of extensions mandatory, and unify others into bigger chunks; Code compiled to one of these two encodings would know it had access to a much wider range of instructions.
The idea would be that any C code targeting RISC-V can be compiled to this encoding with close to zero changes, and that mechanical translation of exiting RISC-V binary code should be "possible", as none of the underlying semantics have changed. And the same would help any core wanting to natively support both (or all three) encodings, you would only need a front-end translator.
I feel like that's largely mitigated by profiles. RVA23 is really looking like it'll be the modern base target used for high performance application processors and it makes mandatory pretty much everything you'd want for those use cases, and other comments by people familiar with designing RISC-V CPUs mention that the variable length encoding can be dealt with in a very simple manner that doesn't even add another pipeline stage so it doesn't seem like it's all that big of a deal while also bringing in benefits in code size reduction. Not everyone is adopting it, but several major players have set the stage by mandating it.
This and exactly this. If there is anything I learned in the past 15 to 20 years, I doubt it will be any different. The mentality of development is just different.
I want the iteration of the product that is in its 2nd or 3rd official iteration. Where you have a lot of learning done and battle tested. Preferably without the backward compatibility to create something truly beautiful. Would it be perfect? Of course not. But it will be Great.
I so wish ARM had some counter offering. They might as well give away their their low end design for free.
reply