191–200 of 350 posts
Earlier quoted context omitted.
It's Global South now. A Global South embedded engineer.
Both the old and new forms are clumsy approximations; Trinidad & Tobago is (are?) in the northern hemisphere.
I think he's kind of speaking past the original author. The original piece is basically about how the author doesn't think that RISC-V will take off outside embedded, because of some design decisions that lead to poor performance compared to ARM64 and because so much of the ISA being optional means that there's too much fragmentation to make binary distribution feasible. Meanwhile, this piece is mainly about how RISC…
Interesting. So I've seen a lot of reviews of RISC-V machines and they seem to be a decade or more behind in terms of performance. I always thought that was a case of "the tech is still catching up",[0] but it sounds like there are fundamental issues that prevent performant implementations? If so... I heard China was investing heavily in RISC-V, which implies that either they're going to have to settle for permanentl…
Riscv took all this information in, and designed a very, very good brick.
> He derives the case for the chip and then spends the rest of the article annoyed that the chip exists. This is almost satirical. His criticisms are entirely valid, because why can't the the thing that has a free spec and will likely dominate that space ... also be good too? Can't we have all the nice things?
The problem is that RISC-V is never going to win at the high end. RISC-V will never have as much money driving it forward as x86 and ARM. As such, the blocks and integration will always lag.
The portion of the market which RISC-V could dominate is the low-end (you know ... the same way ARM climbed up the ladder?) and nobody in charge of RISC-V cares because you have to actually ... SHIP FREAKIN' CHIPS ... and that's, you know, so icky.
And this is the disconnect. Low-end embedded has a bunch of needs and the RISC-V architecture completely whiffs on many of them and has active misfeatures on others while having very little that is actively good in that space.
And many of us are angry about this. It didn't have to be this way.
To me it feels like the difference in positions is "this could be made better" vs. "but this is already so much better than before". Both are right. Maybe I'm missing something important so far...
To me it feels like the difference in positions is "this could be made better" vs. "but this is already so much better than before". Both are right. Maybe I'm missing something important so far...
Maybe. I'm not sure if the original author's intent was to say how risc-v could be better or to say it is bad and people should use other (proprietary) ISAs instead.
I just think that if you were designing something from scratch, you could actually learn from past lessons, rather than publishing a document saying you learned, and then demonstrating conclusively that you didn’t.
I believe there will come a day when RISC-V has comparable or better performance than ARM and x86_64. This is based on history: I remember when x86 performance compared to the DEC Alpha, PA-RISC, SPARC, etc. was a joke. There was a time when, if you wanted real performance, you needed to pony up $20,000-$50,000 for a workstation with a MIPS/PA-RISC/SPARC/Alpha/whatever processor. All these workstations smoked the x86…
Earlier quoted context omitted.
Interesting. So I've seen a lot of reviews of RISC-V machines and they seem to be a decade or more behind in terms of performance. I always thought that was a case of "the tech is still catching up",[0] but it sounds like there are fundamental issues that prevent performant implementations? If so... I heard China was investing heavily in RISC-V, which implies that either they're going to have to settle for permanentl…
the current highest performance RISC-V systems you can buy off a shelf are equivalent to a raspberry pi 5 so they're not terribly behind. in terms of IPC, currently available RISC-V cores are already basically on par with Zen 3 and Apple M1 from what i understand and Jim Keller believes that RISC-V will be the one that leads the way for raw performance.
Earlier quoted context omitted.
the author just focused on his personal experiences regarding RISC-V and what he's been able to see himself as an embedded developer. there's already RISC-V SBCs that are on par with the Raspberry Pi 5 and in terms of IPC the best RISC-V cores are only lagging 5 years or less behind the best x86 and ARM cores.
5 years ago was Apple M1/M2 and AMD Zen 3. What RISC-V cores are remotely competitive with that?
Earlier quoted context omitted.
In the article, he addresses the issue of clones vs 1st party RISC chips on AliExpress. As a mere dabbler, I have been bit by undisclosed errata on an STM-compatible/bootleg/clone/counterfeit Arm chip while using the official STM SDK.
Sure, but that problem should exist for both ARM and RISC-V. And if it doesn't yet, it will once RISC-V becomes more popular.
If Quintauris successfully makes a RISC-V range for automotive use, there'd probably be margin to clone those and sell at a profit, but skirting automotive certification regulations is a high-risk game that (hopefully!) doesn't have many buyers.
If they make an IoT line, again, there might be margin in it, but you'd be trying to fit in between buyers willing and able to engage with Chinese sellers but for some reason unwilling or unable to engage with existing Chinese sellers of existing IoT RISC-V parts. Quintauris is a very, very long way away from being a "household name" along the lines of STM32 or FTDI.
Earlier quoted context omitted.
To add to what you said, I don't see any big issues with high-end prosessors and licenses. Anyone who spends $200 million to develop a completely new high-end processor microarchitecture every 3 to 5 years is not going to complain about an ARM license too much. You get freedom with $$.
If you got “freedom with $$”, there would have been no ARM/Qualcomm lawsuit.
Not as much freedom as they would get with something open like RISC-V, as ARM have strict rules around private ISA extensions (like how Apple doesn't publicly document AMX). But that extra control is generally a good thing for the health of the wider ARM ecosystem.