Airline pilots rack up a lot of hours but get very little "stick time", and what they do get is extremely sedate flying to not scare the passengers / spill their drinks. Their primary skills are pushing buttons on the autopilot and talking in the radio and transcribing clearances.

A military pilot gets more effective stick time. But aerobatic pilots, ag pilots (but I repeat myself), and glider pilots gain a LOT more experience and skill per hour flown than an airline pilot.

I mean, just look at this glider flying lesson:

https://www.youtube.com/watch?v=MJapUCeDeOI

> we're going to make it very easy for people to produce application specific ICs with a toolbox of accelerators and a core ISA

Yes I know, I was on the SiFive stand at the Embedded Linux Conference in Portland where Yunsup gave this presentation:

https://www.youtube.com/watch?v=pxd93jb1OAk

> It turns out that was hard. Harder than anyone in San Mateo or Milpitas could anticipate.

Was that it?

My impression was that it turned out to be hard to find people who weren't already making high volume custom ASICs but wanted to (and already had the skills to know what they wanted). People who were already had an experienced team making custom chips just wanted to license a core.

And then the PolarFire SoC got you 90% of the way there (and Zynq ten years earlier of course) for $36 for a chip with a 667 MHz HiFive Unleashed plus 23k LEs if you valued rapid hardware iteration over a custom $1 FE-310 variant.

https://www.mouser.com/ProductDetail/Microchip-Technology/MP...

I could be completely wrong of course. You were the Fuel Air Explosive at the customer coal-face, I'm just a programmer.

Qualcomm announced laying off 66 people in San Diego today. And hundreds more at Meta and Oracle. Qualcomm laid off 260 or so in San Diego a year and a half ago in September 2024.

I got laid off from SiFive in February 2020 (one of 80). My boss and my boss's boss (who was the one who called me in for the good news) were themselves gonzo three months later. It seemed to be a pivot away from doing so much general infrastructure software development in-house. Palmer had moved on to Google two months earlier (and Rivos/Meta since) ... had he seen the writing on the wall?

It didn't seem to be personal. The founders seemed to not know the details in advance, only the "professional" management.

- RISC-V is heavily used in embedded applications everywhere, to the point that Arm has announced they're stopping developing the Cortex-M line and sticking with what they currently have

- at least in the case of China and Russia, they already have machines using ISAs they developed and own themselves with higher performance than currently-available RISC-V

- RISC-V is not a "CPU technology" (that is, CPU micro-architecture) or a chipmaking technology. It's just a language for writing recipes, and says nothing at all about the medium or technology used to record and distribute and follow those recipes.

- within the next 12-24 months, RISC-V chips designed and made in the West will match or exceed those designed in China as many top CPU designers joined or founded RISC-V companies around 2021/2 (and Intel's ex "Royal Core" team in 2024).

I can't see any reason why the father of Zen and the designer of the M1 can't make a core for the simpler RISC-V ISA with basically the same (or better) µarch than the M1.

The first question has to be: why?

I don't see any rationale or explanation of the thinking. Is it purely an exercise? Exploration? Is there some algorithm space in which it has an advantage over binary?

Is there a compiler?

How does it compare on Dhrystone or Coremark per LUT compared to a RISC-V core of similar size on the same FPGA?

The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey.

The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged.

"An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains."

pp 4-5 in

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey.

The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged.

"An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains."

pp 4-5 in

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

No, it was released to customers in June 2021, almost five years ago.

https://www.sifive.com/press/sifive-performance-p550-core-se...

It has take a while for this core to appear in an SoC suitable for SBCs, as Intel was originally announced as doing that and got as far as showing a working SoC/Board at the Intel Innovation 2022 event in September 2022.

Someone who attended that event was able to download the source code for my primes benchmark and compile and run it, at the show, and was kind enough to send me the results. They were fine.

For reasons known only to Intel, they subsequently cancelled mass production of the chip.

ESWIN stepped up and made the EIC7700X, as used in the Milk-V Megrez and SiFive HiFive Premier P550, which did indeed ship just over a year ago.

But technically we could have had boards with the Intel chip three years ago.

Heck we should have had the far better/faster Milk-V Oasis with the P670 core (and 16 of them!) two years ago. Again, that was business/politics that prevented it, not technology.

Only U74 and P550, old RV64GC CPUs.

SiFive's RVA23 cores have fast misaligned accesses, as do all THead and SpacemiT cores.

I can't imagine that all the Tenstorrent and Ventana and so forth people doing massively OoO 8-wide cores won't also have fast misaligned accesses.

As a previous poster said: if you're targeting RVA23 then just assume misaligned is fast and if someone one day makes one that isn't then sucks to be them.

Less than 7 years from ratification of the initial RV{32,64}GC spec.

Less than 5 years from the first mass-produced roughly original Raspberry Pi level $100 SBC: AWOL Nezha, shipped June 2021.

It's a good solid reliable board, but over three years old at this point (in a fast-moving industry) and the maximum 8 GB RAM is quite challenging for some builds.

Binutils is fine, but on recent versions of gcc it wants to link four binaries at the same time, with each link using 4 GB RAM. I've found this fails on my 16 GB P550 Megrez with swap disabled, but works quickly and uses maybe 50 or 100 MB of swap if I enable it.

On the VisionFive 2 you'd need to use `-j1` (or `-j2` with swap enabled) which will nearly double or quadruple the build time.

Or use a better linker than `ld`.

At least the LLVM build system lets you set the number of parallel link jobs separately to the number of C/C++ jobs.

http://hoult.org/primes.txt

> newer gcc versions have significantly better optimization passes

So what you're saying is that with a modern compiler RISC-V would win by even more?

TBH I doubt much has changed with register allocation on register-rich RISC ISAs since 2018. On i386, yeah, quite possible.