phire

7 ms·

31.
by phire 1mo ago
No. Intel and AMD have proven that if you throw enough money at the problem, you can make fast microarchitectures despite a flawed ISA, and in many ways RISC-V is less flawed than x86. The things we are debating here are more along the line
32.
by phire 1mo ago
It's more of the former. Before this, the author has never recommended others stay away from RISC-V, just stated their own distaste for it and a personal preference to use any other ISA if given a choice.
33.
by phire 1mo ago
The two authors also have a very different definition of what "high-end" means. Dmitry is talking about high-end application processors that you might find in a mid-range or better laptop, smartphone or server. Armstrong Subero se
34.
by phire 1mo ago
> That's why it's so bizarre that the RISC-V design is so awful. Not bizarre. The design is a direct result of the biases of its initial designers, and its original intended use-case. And TBH, if you assess it by its original
35.
by phire 1mo ago
Yeah... I more mean that it shouldn't add much design and verification complexity. You are mostly just reusing mechanisms you already need. Nor should it negatively impact FMAX. And I suspect the area cost is reasonably low (but not ze
36.
by phire 1mo ago
2015 is when it started to gain steam as a community run project. But version 1.0 of the spec [1] was released all the way back in May 2011, and the first RISC-V chip was taped out at the same time. This is 5 months before ARMv8 was even an
37.
by phire 1mo ago
> On the other hand, if you want to fuse load pair on RISC-V you have the entire rename stage to figure out which uops can be fused independently of the rename stage That's a good point. If some RISC-V μarch was going to invest th
38.
by phire 1mo ago
You shouldn't be sharing that. Despite my curiosity, I explicitly refused to agree to Apples terms for accessing those documents, because they were very draconian. The terms absolutely forbids using the information for anything other t
39.
by phire 1mo ago
Really? Interesting. Though, I guess fusing after cracking makes things easier because you don't actually have to search for fusion candidates (supported by the fact that Apple's Firestorm doesn't seem to make any effort to f
40.
by phire 1mo ago
If the spec was only arguing that avoiding flags allowed for simpler implementation of minimal in-order pipelines... I might actually agree with it. But the argument in the spec explicitly uses the "added complexity to out-of-order mi
41.
by phire 1mo ago
Well, the revamp I’m suggesting would essentially be implemented as a RISC-V new profile, just with a different instruction encoding.
42.
by phire 1mo ago
But imagine the code density you could get combining both strategies. > Arm uses complex instructions with multiple writeback, that require cracking, to improve code density. While smaller cores have the option of cracking the multiple
43.
by phire 1mo ago
I don't agree with the argument. By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn&#x
44.
by phire 1mo ago
The annoying thing about RVC is that 32-bit instructions can now appear misaligned. I would be far less annoyed about RVC if it didn't break alignment, as you could solve the problem with a bunch of RVC-only decoders at the misaligned
45.
by phire 1mo ago
> and RV64GC already clearly beats x86-64 in .text density. Maybe I'm misremembering. Or maybe the numbers I'm remembering took into account the fact that most compilers unroll more aggressively on x86 than on targets they co
46.
by phire 1mo ago
Don't forget: 3. You are writing a kernel, with large amounts of inline assembly 4. You are writing a compiler, either offline or online 5. You are writing embeddable blobs that don't know what platform they will be running on. 6.
47.
by phire 1mo ago
I agree that 16-bit/32-bit variable length would struggle to beat x86. But I suspect it could have gotten close, simply because x86 wastes a huge amount of its advantage on legacy cruft. The important point is that there is no reason w
48.
by phire 1mo ago
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 le
49.
by phire 1mo ago
The fact that it's only "competitive" with aarch64's code density is a solid black mark against RISC-V. The only reason it's "competitive" is the compressed instructions, which means it's paying all t
50.
by phire 1mo ago
I'm not sure the gate count argument works in RISC-V's favour. While RISC-V is quite optimised for gate count for small cores; In large wide OoO cores the variable length encoding really bulks out the decoders. You basically have
51.
by phire 1mo ago
Yeah, very much legally distinct MIPS, at least as a starting point. The biggest tell is the mnemonics. While RISC-V takes a bunch of ideas from other places, and cleans things up, it copies a lot of mnemonics straight from MIPS. But it als
52.
by phire 1mo ago
And personally, I'm not even sure it crosses that bar. RISC-V somehow manages to be more fragmented than x86 (which is impressive), and just can't compete on instruction density. I think a large part of the issue with RISC-V is t
53.
by phire 1mo ago
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 th
54.
by phire 1mo ago
Not sure about later versions, but c89 doesn't seem to forbid casting a function pointer to a data pointer (it does say that casting pointers has implementation defined aspects, so lisp machines aren't out of spec if they fail). T
55.
by phire 1mo ago
In c89, there doesn't seem to be any distinction between pointer to functions and pointer to data. Do you know what c89 does explicitly say is undefined? Any pointer arithmetic at all (or array subscripting) for pointers are not pointi
56.
by phire 1mo ago
I’m not sure this is the only copy of the data. Sounds like they paid a company to digitise all their old tapes, and store the results. They possibly still have all the tapes (on site) and are just trying to avoid paying the costs to redigi
57.
by phire 1mo ago
I think what the CFTC are arguing is that offering contracts in 49 states (everywhere except New York) is not "Nationwide". So yes, technically the restraining order is preventing Kalshi from offering Nationwide contracts.
58.
by phire 1mo ago
IMO, dicing counts as part of packaging. So before the dicing step of packaging.
59.
by phire 1mo ago
The N64's FPU will usually be faster than doing fixed point on the CPU. You are actually multiplier/divider bound, and the CPU can multiply about 10 bits per cycle and only divide 1 bit per cycle. Since you aren't multiplying
60.
by phire 1mo ago
My understanding is that after Compaq sold the Alpha IP to intel, and quite a lot of the DNA ended up in Nehalem and Sandy Bridge.

More ›