the disingenuous paternalistic altruism of the intellectual and financial and political elite has a way of rapidly metastatizing into unabashed nihilistic egocentrism when their wealth and power surge far past their points of diminishing returns. eventually it's not enough to be the billionaire who smoked a joint on tv and marketed the electric car, you have to be the trillionaire who abolished human empathy and created a genetically-engineered aryan master race.
both ed zitron and dan luu are professional bloggers who earn their living from selling ai sensationalism, zitron using paywalls and luu using patreon. whether the sensationalism is positive or negative, either way it is a very clear conflict of interest.
destructive book scanning is pretty standard, it's the only way to efficiently get a good flat scan of the pages without a tremendous amount of human labor to correct distortion on every individual page. i'm curious about what specific rare books are being destroyed and how rare they really are. and at any rate, anyone can go out and buy books and scan them or destroy them or set them on fire or whatever, they bought the book it's their own property. so now physical books are treated as the public commons while intellectual property is privately owned? are we in topsy-turvy world? i feel like there are much more egregious crimes that people ought to be talking about with ai companies, like impoverished black people having their city water supplies poisoned or the massive financial fraud that will destroy the economy or the massive co2 emissions that will destroy the world or just the fact that it's not even artificial intelligence at all and it's not even a technological innovation, it's just a google hack that dumbed down an existing neural network model enough for it to run on lots of nvidia gpus and produce an impressive-enough tech demo to show to gullible investors who don't know what to do with their massive piles of money.
the significance and allure of risc-v, the reason china is investing heavily in it right now, has little to do with the technical details of how it works under the hood, it's the fact that it is an open standard not encumbered by intellectual property law. even if it isn't technically the best general-purpose processor architecture, it sets an important precedent by proving that it is possible to develop an open public architecture that the world can use to build computing devices without being extorted by a multinational corporation charging licensing fees or a geopolitical superpower enacting tariffs and sanctions.
> it's the fact that it is an open standard not encumbered by intellectual property law.
There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons.
And, as others have mentioned, the ISA doesn't really matter. As long as it's agreed upon, then the CPU vendors can optimize on one side, and the compiler writers on the other side.
Sure, Risc-V has its warts, but you can certainly say the same about all the rest.
> […] 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.
What you find may or may not match reality. In this instance, I don't believe it does.
> We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them.
This, of course, is a silly argument. Yet, it is completely orthogonal to the one I was making, and is 180 degrees away from the complaints leveled at Risc-V which are that it is an overly simplistic, nay childish, specification, written in crayon by kindergartners.
> 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.
I find this statement accurate, yet condescending. Who the fuck thinks that they are? Claiming that this is an "issue" with my statement appears to be a reductive argument that I have not thought it through. To be blunt, this statement reveals a hell of a lot more about your ignorance on this issue than mine.
> It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.
And yet, we have seen this play out in x86, with Intel v. AMD, and it worked exceptionally well.
> An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.
Of course, AMD and Intel were always trying to one-up each other, but that is tempered by the necessity for their improvements to be supported by compilers. By the time an improvement is well-supported, the other side has caught up.
With Risc-V this is even more likely to be the case, because proprietary extensions will simply not be that well supported by major compiler vendors, who have a hard enough time keeping up with the ratified ones.
The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a cheaper / worse CPU all those extra bytes in the instruction stream do add up.
The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*).
Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are:
* Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones.
* Limited in which registers they can use (usually x8..x15).
* Often clobber their input operand instead of giving a free move.
Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture.
I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.
The combined comparison-branch instructions of RISC-V are its only good feature in terms of instruction encoding design.
This allows a significant code size reduction in comparison with ARM Aarch64, but unfortunately for RISC-V this advantage is frequently not enough to compensate its other defects, especially when reliable code is desired, i.e. where overflow detection is necessary.
Despite that from this point of view ARM Aarch64 is weaker, that is not an intrinsic problem. Aarch64 has an unused block of encodings inside the block used for branch instructions. I have verified that in the currently unused block it is possible to encode not only compare-and-branch instructions covering all the conditions that exist in the RISC-V ISA, but also additional conditions that are missing in RISC-V, where their absence is a problem, like testing for overflow.
I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64.
> I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64.
Nope. Again, the primary advantage that RISC-V has over Aarch64 is that it is the agreed-upon open specification.
Also I haven't looked closely but I don't know if you could find space to fit it in the remaining Aarch64 encoding space.
The existing a64 conditional branch instructions use a 19 bit field to hold the offset. Add two registers to compare (10 bits) and 3 bits to choose between EQ, NE, LT, LTU, GE, GEU and you're already at 32 bits before having an "opcode" field to choose "RISC-V style conditional branch".
Of course you could reduce the branch offset size down to RISC-V's ±4k which only needs 11 bits when you only have 4 byte instructions, but that's still a 24 bit chunk of unused
opcode space to find.
Oh .. looks like 0b10xx is still completely unused. We could grab maybe 1/4 of it
Sorry, haven't been following along, but sounds to me that the argument was a valid one seeing how it made the designers add new instructions.
Not sure if there's an impact caused by the late addition as opposed to always having them, but considering this is a fairly core thing what a program does, not sure what degree of fragmentation this causes on the level of compilers and hardware.
x86 effectively killed innovation in the SIMD space by making instruction set support so fragmented, that people had to target the decade-old lowest denominator.
Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ...
But *code size* is a demonstrable fact.
RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23.
Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate.
In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test.
The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.
All the claims of the RISC-V fans that I have seen in the past compared the compressed variant of RISC-V with the uncompressed variants of the other ISAs.
Most other ISAs, like ARM, POWER and MIPS, also have compressed variants and if RISC-V were compared with those, it would lose.
Moreover, if you use safe compilation options with RISC-V, the code size explodes in comparison with any other ISA, because I am not aware of any other ISA introduced after 1974 that lacks hardware overflow detection, which multiplies by 3 or more the number of arithmetic instructions required for any computation.
This is a new claim that I see now, that RISC-V can be more compact than Cortex-M33 (i.e. where both use a compressed encoding), which I find unbelievable, because if I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V and I doubt that the current compilers are so bad that they generate much worse code.
RISC-V is shorter on any code that has a lot of branches and negligible computations, but for anything more complex, with many computations and complex data structures, it loses.
I want to try looking at codesize for -Os builds with the different ISAs including the compressed variants you mentioned.
As well as dynamic icount with overflow checking.
Do you have any specific project in mind that I could use for testing?
I keep seeing comments here saying that a)compressed instruction are awful for pipeline decode, so they aren't used in any ISA on fast speed and b)risc-v loses in code size if you compare against compressed instructions
I don't understand how the two viewpoints fit together
> I don't understand how the two viewpoints fit together
Well, they don't and they do. Linux runs on everything from an $8 generic IP camera to the world's fastest supercomputers.
RISC-V is attempting to achieve the same feat in hardware, so there will be many implementations at many price points.
As with any of the T-shirts that list 3 things and say "Pick two" it's always difficult to reduce cost, increase speed, and decrease code size.
But...
You can pick two.
So if you don't mind spending the money for things like fancy micro-op caches, you don't care about the compressed decode, and you can still make it run like a bat out of hell with compressed instructions.
Or if you don't mind lower performance, you don't worry about fusing operations, and the pipeline implications aren't so bad, so you can still make something cheap that works with compressed instructions.
It's only when you're trying to pick all 3 (compressed instructions, high instruction throughput, and low cost) that the difficulty of decompressing the instructions becomes problematic.
Or look at it this way. x86 decode is infinitely more complicated than RISC-V decode, and still occupies maybe 2% of the die area.
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.
x86 is basically one big cabinet of horrors, but people seem to put up with it because it's "the standard." Then why not with RISC-V? Which is much if not infinitely better.
It's not just China that has an interest. Multinational corporations also hate being charged licensing fees (see Qualcomm vs. ARM). Here's a list of RISC-V members: https://riscv.org/members/
I think the issue is then, if you have the same base lineage and you start extending and fixing things, then it will be easy to overlap with new patents that whomever still holds MIPS IP.
RISC-V is mainly a way to avoid IP conflicts, not as a technical breakthrough. MIPS itself was a boring (this is good) implementation of the original RISC papers, but they asserted a bunch of things legally which eventually, along with the legal work of Arm meant that ISAs were effectively owned by their parent corporations.
I'd assert that much like 3rd parties being able to make replacement car parts, that we should be able to make ISA compatible chips. But here we are, RISC-V needs to exist and does, but for legal reasons, not technical ones.
*edit, I forgot to refresh before posting, what bjornnn said.
even when foundational patents expire, licensing agreements and copyright and trademark and other things remain legally enforceable. chinese companies actually did start investing in mips at one point but ended up getting sued. people tried to open source mips years ago but gave up and just switched to risc-v because it's too much of a legal hassle to try to open source something that was proprietary for decades and has all the legacy baggage of multiple previous owners who want to sue you for any reason they can think of. it was easier to just design a new architecture that was open from the start.
are you asking these questions sincerely or is this just your passive-aggressive way of saying that netbsd is dead and nobody uses it? and why does everything have to be compared to linux? isn't the whole reason we developed free and open-source operating systems is to have lots of different choices and not just one universal corporate-controlled OS that everyone thinks of as the yardstick by which all other OSes are measured?
It was a sincere question and I found your comment quite off-putting.
You're talking to someone who spent a month in college installing every free OS I could get my hands on (including the BSDs). I find alternate operating systems interesting, but haven't played with them much lately. I compare other free Unixes to Linux because I use Linux every day and it's what I know.
It's interesting to think of hypothetical scenarios where an alternative to Linux might be more compelling to me for some reason (eg. is OpenBSD objectively more hardened than Linux? Is NetBSD objectively more portable? etc.)
