Posts by Bruce Hoult

Airbus flies new passenger airplane aimed at 'long, thin' routes

Re: Long and thin eh?

Yes, A380 is the best, but you can't always get one.

I would much rather travel in an A320 for 11 hours than in a B777 with 3-4-3 seating. I absolutely hate those things.

I love the 16 hour Dubai-Auckland A380 flights (17 the other way). Far far better than having a stopover and getting back on the same plane.

Sadly it seems this stretched A320 won't even make Perth from Dubai, let alone Melbourne or Sydney. But either Singapore or Bali would serve as a reasonable halfway point to NZ.

It also isn't going to manage Auckland to LAX or SFO. Other than the 747-400 (which have long gone from the route) the best time I've had between NZ and the US was with Air Fiji with their A330s (with a stop in Fiji of course).

I haven't yet had a chance to fly in a 787 so I'll reserve judgement on those.

Just someone kill the 777, please. Or at least make the airlines use 3-3-3 seating as they were designed for.

Will this be one of the world's first RISC-V laptops?

Re: Some serious questions.

Just about everything in your post is wrong.

RISC-V was not introduced 12 years ago, some students and their professor had a crazy idea in a pub to START it 12 years ago. It was essentially introduced to the world a little under 7 years ago.

Dave Patterson invented the term "RISC" and the first RISC I CPU around 1980-1981, not 1990. I can only assume you weren't born at those times and consider them prehistoric.

ARM does NOT allow you to add or remove things from their CPU core or the instruction set. Of course you can add whatever you like else in the SoC, as you don't license that from ARM and ARM doesn't make such IP.

The Raspberry Pi is very far from standard. There are simply a lot of them. (Compared to other SBCs, not compared to phones or tablets)

Re: Cool...

Look up "binfmt_misc". I've been using it for many years to run x86, ARM, RISC-V (and others) binaries transparently on whatever board I'm currently using.

Slower than native, of course, but much faster than Python.

Re: Some serious questions.

I don't know why you think it appropriate to look at what is clearly a personal project of a handful of people and extrapolate that to OoO RISC-V cores from companies such as SiFive, Alibaba, Andes employing experienced CPU designers who have previously worked at ARM, Intel, AMD, Apple ...

It's been known for quite a few years now how to avoid Spectre/Meltdown and that it's pretty easy if you incorporate that into your design from the outset.

Here's something from four years ago: https://www.youtube.com/watch?v=yvaFpNNLkzw

The presenter designed OoO BOOM as a student, later ET-Maxion at Esperanto, and now works as a core designer at Intel.

The ‘substantial contributions’ Intel has promised to boost RISC-V adoption

Re: "vowed to do what it can to make the open-source RISC-V ISA worthy"

It's not like Intel has a choice in that. The best they can do is try to have a cut of it.

Someone -- possibly several someones -- will have RISC-V competitive with x86 and Apple M in 3-5 years. Quite likely including Rivos who Apple are suing for taking too many of their M1 engineers with too much knowledge about how it works. Interestingly Apple isn't trying to stop them -- they're not asking for an injunction or damages, but for royalties.

RISC-V CEO seeks 'world domination' by winning over the likes of Intel

Re: That RISC-V TRS-80 M100....

The DevTerm is an existing product that uses a Raspberry Pi Compute Module as the CPU. They've just substituted a CM3-compatible board with a RISC-V module, which they also sell separately for $28 for if you already have an ARM-based DevTerm or want to use the RISC-V module on another CM-compatible motherboard.

Alibaba Cloud gets more of Android working on RISC-V silicon

Re: Open source hardware (and consequently software) will be the future

There is already a laptop of sorts:

https://www.clockworkpi.com/product-page/devterm-kit-r01

If you already have the ARM version (or any Pi CM3 compatible board) then you can buy just the RISC-V compute module from the same site for $29:

https://www.clockworkpi.com/product-page/copy-of-clockworkpi-core-r-01

Note that this is roughly Pi Zero equivalent.

The board that runs Android (that Android is being developed on) is available here:

https://www.aliexpress.com/item/1005003395978459.html

The C910 cores are roughly Pi 4 speed, though it's got fewer cores than a Pi 4.

>The Xuantie C906 uses Alibaba-designed cores

That's very confused.

Firstly, the Xuantie C906 *is* a core. The AllWinner D1 (external DRAM) and D1s (DRAM in the package) also sometimes called "Nezha" are chips or SoCs that use the C906 core.

The Sipeed "Lichee RV", the AWOL "D1 EVB" (which many called "Nezha" until we learned that refers to the Soc), the MangoPi "Nezha MQ" and "MQ Pro", the ClockworkPi "Core R-01" (a $29 Pi CM3 compatible board designed for the DevTerm laptop) are variously boards with versions of the D1 chip on them.

Similarly the Xuantie C910 is a (much higher performance) core from Alibaba T-Head, roughly comparable to the A72 in the Pi 4. The C910 is available in the "ICE" SoC, used on the "ICE EVB" (Evaluation Board), which is what the RISC-V Android port has been shown on. I have one, incidentally.

> that are – as required for RISC-V users – available on GitHub.

Incorrect. There is no requirement for RISC-V cores to be put on Github. There are a number of companies with commercially-developed RISC-V cores for which the source code is not available. Alibaba put the C906 and C910 on github entirely voluntarily.

We take Asahi Linux alpha for a spin on an M1 Mac Mini

Re: 53GB

>i assume you can also run it in a VM using Parallels or similar which for many might be the preferable option?

Mate.

I've been running arm64 Ubuntu in a VM on the M1 Mac Mini since ... checks ... 22 November 2020. That's 16 months. They ere only released on November 17, 2020, so it took all of 5 days to get mine and get Ubuntu working...

Performs *really* nice. But I want it native, so as to not waste 4 GB of RAM on the host OS.

https://twitter.com/BruceHoult/status/1330236899546591235

More benchmarks at...

https://hoult.org/arm64_mini.html

114 billion transistors, one big meh. Apple's M1 Ultra wake-up call

Re: I was there

And I programmed PDP-11s and VAXes and other similar machines ... PR1ME, Data General Eclipse.

>This high performance Apple computer is nice, but, it doesn't run FoldingAtHome, which would possibly take advantage of those GPUs.

It certainly does. I just downloaded and tried FoldingAtHome on my original M1 Mac Mini. It runs. The performance stats seem to be 800 points per day, 3.00 days ETA for a work unit. I have no idea whether that is good or bad, but it runs.

>You can't run 64bit Intel code on this machine.

Of course you can. I do it every single day. Apple includes an x86_64 emulator which runs x86 code and about as fast as the Intel machines they previously sold.

Here's one benchmark I wrote many years ago and run on everything:

https://hoult.org/primes.txt

Note that the Rosetta (x86 emulation) result is faster than a ThreadRipper, a Ryzen 5, or a Xeon Platinum.

You appear to be misinformed.

RISC-V keeps its head down amid global chip war

Re: Genuine question RISC-V / ARM

RISC-V just defines an API right ? Presumably there aren't too many innovative new Assembly Language instructions, especially in RISC, they are supposed to be simple right? (This is based on my doing a few weeks of ARM2 assembler after having learned 6502 as a kid)

Right.

There is deliberately nothing innovative in the base RISC-V instruction set. It set out to learn lessons from 30 years experience with RISC and use the best parts from RISC-I and -II, SPARC, MIPS, ARM, POWER, Alpha and others. Not from Aarch64, which was developed largely in parallel, with the basic RISC-V design being already in place when the Aarch64 ISA was published in late 2012. They *both* took many of the same lessons from experience, though Aarch64 is a bit constrained by having to run (at least up until very recent designs) on the same CPU pipeline as Aarch32, and also ARM don't seem to intend it to ever be used in the smallest devices.

The most innovative part of RISC-V so far is the just ratified Vector extension. Again, it's similar in a lot of ways to ARM's SVE. They may have both had the same influences, though it seems quite likely that SVE was influenced by the Berkeley research into vector processing. RISC-V was actually initially wanted as the scalar control processor for vector processors already in development.

So what's the massive lead of ARM over RISC-V? Obviously the silicon design of an Apple M1 is incredible, but you get this by being Apple+TSMC, not by buying an ARM license. Presumably Apple could have done the same design around a RISC-V instruction set?

Indeed Apple could have. RISC-V didn't yet have all the standardised ISA parts Apple needed at the time they started development of the M1 -- and of course not back when they made their first Aarch64 chip for the iPhone 5s released back in 2013 (and 1.5 years before ARM and their partners had 64 bit CPUs ready for the Android market e.g. Samsung Galaxy S6).

Apple wanted to get Macs on to the same ISA as iPhones and iPads, and for the moment that meant Aarch64.

Personally I think that within five years Apple will switch *everything* to an ISA they have greater control over. I don't know whether that would be RISC-V or something they design themselves.

The lead of ARM over RISC-V is mostly that they started earlier. In the case of the M1, Apple has a lot more money to spend than ARM does.

Currently shipping RISC-V cores that you can buy on an SBC (e.g. SiFive HIFive Unmatched, Starfive VisionFive v1, T-Head ICE RVB) are about 5-6 years behind ARM (e.g. Pi 3).

If you are starting to design a chip today then the RISC-V cores you can license for it e.g. SiFive P650 are about three years behind comparable ARM designs (Cortex A76).

Does ARM supply all the super-scaler / out of order pipeline / branch prediction magic we all rely on - as part of the licence design? Or is it just that there are more optomised ARM core designs out there, more people familiar with them, more tooling, more compilers etc etc ?

ARM supplies the pipeline and branch prediction if you license one of their cores. They don't if you simply license the ISA and implement your own core, as Apple does.

There is no significant difference today between the quality of gcc or LLVM compilers for ARM and RISC-V.

Re: Sorry, what was the problem again?

You apparently aren't aware that the Berkeley RISC-V effort open-sourced in 2015 included not only the ISA itself but also a competent traditional 5-stage pipeline processor design, "Rocket", complete with good MMU, branch prediction, L1 cache, and FPU.

The design was picked up wholesale in commercial productions such as the SiFive FE310 (which competes well with ARM Cortex M3 and M4) and FU540 (which is close to ARM Cortex A53, despite being only single-issue). It is also used directly in the Kendryte K210, and influenced many others. The FPU design is probably used in a lot more -- fully IEEE 2008 compliant, and with full-speed handling of denorms (which is pretty unusual)

Rocket and its components has since formed the basis for dual-issue in-order and wider out-of-order CPU cores.

Assuming for the moment it's true that open source systhesis and layout pays a 20-30% area and clock penalty -- which I"m not convinced is true of yosys/nextpnr -- that's a MINOR price to pay for having an open source system. Especially when RISC-V cores are consistently 1/3 to 1/2 the size and 1/3 the energy use of otherwise comparable ARM cores.

The instruction set is a very big technical pinch-point because the entire software stack depends on it, and porting all the world's useful important software to a new ISA is a far bigger and more expensive and longer task than designing an SoC.

Re: Sorry, what was the problem again?

Well, no David Patterson didn't invent RISC-V.

He was there in a kind of supervisory role, but in fact the main supervisor was Englishman Krste Asanovic (who, as you might imagine from his name, has recent roots in Eastern Europe), with most of the grunt work done by American Andrew Waterman, and Korean Yunsup Lee (I think Yunsup was born in the US but he speaks Korean fluently and has grandparents there).

That was the initial specification for the basic integer and floating point instructions corresponding to C's built in operators, between 2010 and 2015.

Since 2015 the ISA has been extended in a number of directions by international working groups with participation by experts from every part of the globe.

Geomagnetic storm takes out 40 of 49 brand new Starlink satellites

Re: No loss

I signed up to rent a house that had no internet service possible on January 3 2022, went to the STARLINK site and paid my money, and had the equipment (shipped from California to New Zealand) on January 14, a full week before I actually moved in.

RISC-V CTO: We won't dictate chip design like Arm and x86

There are RISC-V boards similar in performance to Pi Zero through to Pi 4. At the moment they cost more, but that's a market size and mass production problem not a technology problem.

For example the $17 Sipeed LicheeRV is similar to a Pi Zero compute module, and docks giving a good set of I/O connectors start from $5.

https://www.aliexpress.com/item/1005003594875290.html

https://www.aliexpress.com/item/1005003741287162.html

The ICE RVB has similar performance to a Pi 4, though with fewer cores and a much higher price (just as the "Nezha" EVB has the same SoC as the LicheeRV but at a much higher price). Expect to see the same SoC appear on much cheaper boards in the next few months -- I suspect BeagleBoard will be one of the vendors.

https://www.aliexpress.com/item/1005003395978459.html

Re: Viable alternative

That "very basic RISC-V common subset" includes 32 bit and 64 bit ISAs, FPU, SVE-like vectors, cache control, hypervisor, crypto (e.g. SHA, AES, TRNG).

Anyone wishing to use the trademark "RISC-V" with their products must pass conformance tests for the standard parts of the ISA, and therefore correctly run any code from standard compilers such as gcc and LLVM.

If someone adds extensions then all standard software will continue to run correctly. Of course programs using the extensions won't run elsewhere but that's the point -- custom extensions are by nature usually very specialised.

Re: what was wrong with MIPS ?

RISC-V is similar in philosophy to MIPS. The RISC-V assembly language uses many of the same mnemonics as MIPS, but with different semantics and binary encoding. Many of the instructions are completely different, especially around function call and return and conditional branching (though neither uses condition codes). The most recent MIPS specifications (MIPS R6 and NanoMIPS) adopted some of RISC-V's ideas.

RISC-V and MIPS are also both very similar to DEC Alpha, and to a slightly lesser extent ARM Aarch64.

Re: what was wrong with MIPS ?

It's not free to implement your own MIPS core.

MIPS wanting about $5 million for *just* the rights to use the ISA (not even supplying a core) was the reason Berkeley university developed RISC-V instead.

MIPS announced an "open source" program in April 2019. It had pretty awful terms. You had to apply for entry to the program, giving details of what you intended to use the MIPS ISA for, your business plans etc. You were only allowed to do things within very narrow parameters. You had to have your core certified by MIPS. You were not allowed to distribute the design of your core to others.

And then in November 2019 -- just seven months later -- MIPS cancelled the program entirely, long before anyone could have had a chance to ship anything.

Now MIPS has announced they are dumping their own ISA and switching to RISC-V.

RISC-V was never about licensing costs. It's about flexibility and freedom, and the ability to move fast.

Forget the cost, reliable sources say that it typically takes one or two years for the lawyers to simply negotiate the contract with ARM. And that's for an off-the-shelf standard core.

Only a few few of ARM's licensees ("Architecture License") have the right to modify ARM's microarchitecture, or to design their own core. Until the last year NO ONE had the right to add or subtract any instructions from the ARM Instruction Set.

RISC-V core vendors such as SiFive or Andes also change licensing fees. They might or night not be less than ARMs, but they are not zero. If you don't want to pay them (or others) you are free to design your own core -- *everyone* in the world effectively has a free Architecture License -- but you're going to have to hire some expensive people to do that and it will cost you more than licensing a commercial core.

But you get flexibility.

Do you want a very small core like a Cortex M0, but you want it to run faster than 48 MHz? Sorry, ARM won't do that. SiFive will license you an E20 that will run at 1 GHz on 7 nm if you want to - and Andes has something similar. Do you want a very small core like a Cortex M0, but you want it to have 64 bit registers and addresses instead of 32 bit? You can't do that with ARM -- their smallest 64 bit core is much bigger. Do you want to get something like a Cortex M0 but with an FPU, or with a vector processing unit? You can't do that with ARM, but SiFive or Andes will be very happy to license you one.

The same applies up and down the line. RISC-V vendors give you much more flexibility than ARM does -- up to their current upper limit on core performance, which is currently in Cortex A73 to A76 range depending on which vendor. Or if you have a lot of money and think you can do a better job yourself then you are free to -- while still getting the benefit of standard gcc, LLVM, Linux, FreeRTOS, Zephyr etc etc.

Enthusiasts dash for RISC-V computer with GPU

It's not sub Pi 3. The C910 cores are roughly Pi 4 class -- claimed ARM A73 class vs A72 in the Pi 4.

The U54 cores in the 3.5 year old HiFive Unleashed were a little slower than Pi 3. The U74 cores in the HiFive Unmatched (and the now cancelled BeagleV "Starlight") are ARM A55 class, which is significantly better than the A53 in the Pi 3. Benchmarks bare this out -- other than ones that depend on SIMD or crypto instructions, obviously, as that's something coming in RISC-V next year.

Proposed RISC-V vector instructions crank up computing power on small devices

I really like this RISC-V Vector extension. It is one of two "vector length agnostic" vector instruction sets currently on the way between specification and machines normal people buy and use.

The other is ARM's SVE (Scalable Vector Extension). ARM also has more recently announced MVE (M-profile Vector Extension) for microcontrollers.

SVE and RISC-V V extension both give the programmer 32 registers of size that varies from machine to machine. Code is written in a way that doesn't have to know the actual register size, so one machine might have 128 bit registers, another 512 bit registers, and another (in future) 4096 bit registers and the same programs and libraries run efficiently on them all, without rewriting.

SVE allows for vector register sizes between 128 and 4096 bits. ARM's MVE gives the programmer 8 registers of always 128 bits each -- apparently SVE wasn't scalable enough.

RISC-V V (RVV) allows for register sizes between 1 element of the largest size handled (often 32 bits) and 2^31 bits. Version 1.0 of the vector profile for application processors (i.e. something that can run binary distros of Linux or similar) restricts the vector register size to be between 128 bits and 65536 bits. Those who are making embedded processors or supercomputers can choose register sizes outside that range if they wish.

RVV has a feature called "LMUL" that allows the programmer to trade addressable registers for register size. For example if your program loop only need 16 vector variables not 32, then you can use LMUL=2, use only the even numbered registers, and use pairs of registers as if they were a longer register. Similarly if your loop only needs 4 or fewer vector variables then you can use LMUL=8 and use only registers 0, 8, 16, and 24 but they are 8 times bigger than usual.

So a microcontroller with RVV might implement only 32 bit nominal registers, but if the programmer uses LMUL=4 then they get 8 registers of 128 bits each -- the same as MVE.

Both RVV and SVE are going to eliminate that awful situation where you have to rewrite all your SIMD code every few years when your CPUs move from MMX to SSE to AVX to AVX512 -- or a similar but shorter progression for ARM.

Deep neural networks... IN SPAAACE: Vector-enhanced RISC-V chips could give satellites onboard AI

Re: Speed vs. Size

Not really correct, as FPGAs typically have a lot of ALUs in them (referred to as “DSP blocks”) and using them to implement a vector processor makes perfect sense. You’ll usually only get 50-100 million instructions per second from a soft core in an FPGA, but if you have long vectors this doesn’t matter. The RISC-V vector extension lets the exact same code run on machines with vector registers of any length. There are rad-hard FPGAs available off the shelf.

I’d expect to see a scalable open source FPGA implementation of the RISC-V vector extension within the next 12 months.

Intel to put SiFive's latest CPU cores into 7nm dev system to woo customers to RISC-V

I've been running Linux on a quad core 64 bit 1.5 GHz RISC-V board with 8 GB DDR4 RAM for more than three years already. That board only had an SD card to boot off and no video or USB so access was via ssh over gig ethernet.

I now have a board with roughly late Pentium 3 performance CPU but quad core with 16 GB DDR4 RAM, a 500 GB M.2 SSD for storage, and a PCIe video card so in general use it's considerably better than Pentium 3 machines. https://www.youtube.com/watch?v=3o411cQ7XG0

This new P550 core will bring RISC-V to approximately the late Core 2 era in CPU performance. That's a very usable level, especially with more modern peripherals than Core 2 systems had.

Next year Nehalem or Sandy Bridge performance? I wouldn't rule it out -- or even better -- especially if a company with deep pockets such as Intel decides to go for it.

SiFive has gotten to this point on $190 million of funding.

Intel, AMD, and Apple are spending probably several billion dollars on each new CPU generation now.

Docker Desktop for Apple Silicon is here, but probe a little deeper and you'll find Rosetta 2 staring back

One of us is confused.

Aarch64 containers is exactly what Docker for M1 Mac runs, since aarch64 is the M1's native (and only) instruction set.

64 bit OSes and binaries compiled for Raspberry Pi 3/4, Amazon Graviton instances (A1, M6g, M6gd, T4g, 6g, C6gd, C6gn, R6g, R6gd, X2gd) run perfectly under virtualisation, including Docker, on the M1 Macs.

Just a lot faster than they do on their usual hosts.

Beagleboard peeps tease dual-core 64-bit RISC-V computer with GPU, AI acceleration, more for $119

Re: I can understand the ISA

ARM has deprecated conditional execution on 32 bit and never had it on 64 bit ISA.

The U74 core treats a conditional branch over a single instruction, and the following instruction, as a kind of predicated execution with no pipeline flush no matter which way the branch works out.

Re: RPi4 vs Beagle V

We’re still six weeks from the first device with U74 cores shipping to paying customers.

I doubt that the FU740 will be significantly different to the FU540+expansion board in peripherals and drivers.

After ten years, the Google vs Oracle API copyright mega-battle finally hit the Supreme Court – and we listened in

An analogy

Let’s liken an operating system to a house.

A house provides electrical sockets with a certain pin layout and voltage e.g. type A or B at 120 V . Phone sockets RJ11. Internet RJ45. Clothes washer water connections of certain diameter and thread.

It is convenient for an occupier to move their appliances (code) from one house to another if both houses have the same connectors.

Moving your appliances to a house with type G sockets at 230 volts, BT phone sockets, different water connections is inconvenient. You may need to get new appliances, or at the least add some kind of adaptor.

Google wanted to build houses on a newly discovered uninhabited island (or on the Moon) where people could move to with their existing appliances.

What did they do – twist his Arm? Ex-Qualcomm senior veep joins SiFive as CEO, RISC-V PC for devs teased

Re: RISC-V Raspberry Pi

You say you're happy to ssh in to the board and run things automated from your standard PC. Me too, and that's exactly how I use my Pi 3 and Pi 4 and Odroids.

It's also exactly how I've been using my HiFive Unleashed RISC-V board for 2.5 years now. Quad 64 bit CPUs running at 1.4 GHz, 8 GB DDR4-2400, gigE, USB serial console, SD card to boot from, then NFS mount big stuff from the PC, run a RISC-V desktop using the PC as an X server or VNC. It all works great and my $999 got me a (so far) 2.5 year headstart.

However I think that's probably not most people.

I've actually been running a poll on this for the last few days (it ends in 12 hours). More than 50% of people say they want to plug an HDMI monitor, kb&mouse in to the board itself -- as most people do with a Pi.

https://www.reddit.com/r/RISCV/comments/irwumi/if_you_say_you_want_a_riscv_board_that_runs_linux/

Re: Comparison

I'm expecting something definitely faster than the Raspberry Pi 3 or 3+ (the 2.5 year old FU-540 roughly matches the 3+), but probably not *quite* the raw performance of a Pi 4. The MHz will be higher, but the architecture is like the CPU in the Pi 3+. It's also likely be surrounded by higher spec memory, cooling and other bits like that to let the CPU shine.

Something around the last Pentium 3s or PowerPC G4s would be about right.

No problems with the graphics. It will have PCIe. If you add the expansion board to that 2.5 year old HiFive Unleashed then you just plug in a Radeon graphics card and run the open source driver (which is written in C) and accelerated graphics works fine. I've played with a HiFive Unleashed set up with this..

This chip jut brings all that onboard and hopefully sells for a lot less. It should be in the $250 to $500 range I'd think.

Chips that pass in the night: How risky is RISC-V to Arm, Intel and the others? Very

Re: Power ISA?

"Not to mention you can get entire desktops and servers with Power from Raptor Computing Systems. I can't recall seeing an equivalent for RISC-V."

Of course not. It's too new. It's not even five years since the RISC-V Foundation was set up and everything open-sourced. It's only a year and a half since the base instruction set, initial extensions (MAFDC), and privileged architecture were formally ratified and set in stone.

POWER has been going for thirty years.

RISC-V vendors have started with small embedded cores, with only a couple recently starting to get more into CPUs suitable for mobile applications processors let alone desktop or server. The most sophisticated RISC-V core so far -- SiFive's U-84 -- was announced at the end of October and the way these things progress will probably see first silicon around this time next year, and get into products six to twelve months later. The U-84 is competitive with ARM's Cortex A72 which was in the hot phones in 2016 and just found its way into the Raspberry Pi in June/July last year.

"For the 10 years it's been heralded as the saviour of open computing it's still very marginal, sadly."

That's what exponential growth looks like -- not worthy of notice for a long time, and then suddenly it's everywhere.

Look at the number of hospitals recently saying "we'll worry about coronavirus when we see a case" and then one or two weeks later they're "Our ICU is filled to overflowing and we're having to decide who we just let die, we're running out of beds with oxygen, 10% of our doctors have caught it and the rest are working 18 hour days and aren't allowed to see their families".

If you haven't noticed:

- Samsung has said the new Galaxy S20 has one RISC-V core controlling the camera and another controlling the 5G radio.

- Qualcomm has said every SoC they ship from now will have RISC-V in it somewhere.

- Espressif have said the new version of the ubiquitous ESP32 wifi/Bluetooth chip with main CPU core still Xtensa but an ultra low power RISC-V management core has gone to volume production.

- Microchip / MicroSemi has said the version of their avionics / military-qualified FPGA with embedded penta-core RISC-V FU540 is available to qualified customers for development now, available in volume Q3.

- Western Digital / Sandisk should be shipping their first disks and flash drives with RISC-V in them later this year.

It takes companies like these four or five years to go from "Hey, that looks interesting" to volume production. All those companies started working on RISC-V products years ago -- and it wasn't really available to people outside Berkeley until 2015 -- and you can be sure many many others have started the process in the last couple of years.

As for extensibility. The vast majority of custom instructions I've seen proposed don't affect the rest of the software in the system, don't even require changing compilers. These instructions are usually used in two or three places in a software library to speed up some specialized thing by a factor of five or twenty or whatever. Often it's not even worth modifying the assembler to know about them -- it woudl be easier overall to just encode them in hex with a .word directive where you need them.

But in fact the RISC-V GNU assembler has a special ".insn" directive that lets the user's program source define a new instruction using any of a number of standard instruction encoding formats and then immediately use it -- no modifications to the assembler.

For details see https://embarc.org/man-pages/as/RISC_002dV_002dFormats.html

That covers small, secret, extensions anyone can make.

Larger RISC-V extensions that will be standardized and made available for everyone go through a review process where experts from *many* companies and universities and research organisations look at them, try experimental implementations of them, suggest improvements etc. This process slows things down, but it's quite likely that the end result will be of *better* quality than any one company would do.

A little product renaming here, a little RISC-V magic there, some extra performance, and voila – Imagination's 10th-gen PowerVR is born

RISC-V management core

It's just the system management core, the same as Nvidia are doing, not the actual GPU cores like Think Silicon announced

https://think-silicon.com/2019/12/02/think-silicon-demonstrates-early-preview-of-industrys-first-risc-v-isa-based-3d-gpu-at-the-risc-v-summit/

Still, good to see, and there will be more and more things like this.

RISC-V business: Tech foundation moving to Switzerland because of geopolitical concerns

Re: Swiss Miss Incorporation

> I suggest people look into the deep financial benefits of incorporating in Switzerland.

> While the USA and U.K. have corporate tax rates of 35% and 28% respectively,

>Swiss land is 7.8%. Personal income taxes are very low.

It's a non-profit. There are no profits and therefore no taxes anywhere.

> RISC-V also has serious competition from open-source MIPS architectures which

> have code-size, performance, and existing market presence advantages compared

> to RISC-V.

Existing market presence,yes, I don't think there are a lot of high performance MIPS processors around by modern standards -- but I'd love to be educated. The code size thing is just rubbish. RISC-V has a big code size advantage over MIPS, except for the apparently stillborn NanoMIPS announced in May 2018 which has disappeared without trace.

Also MIPS Open has reportedly been quietly closed down already. I've confirmed that the signup page no longer exists and many others 404.

https://www.hackster.io/news/wave-computing-closes-its-mips-open-initiative-with-immediate-effect-zero-warning-e88b0df9acd0

Talk about a calculated RISC: If you think you can do a better job than Arm at designing CPUs, now's your chance

Re: "I did not know that ARM actually prohibited adding instructions"

Until now ARM absolutely did forbid licensees from altering the ISA in any way whatsoever. I believe the tagged pointer instructions were indeed added at the request of Apple, but you’ll find them documented in the ARMv8.4-A (I think) manual for all ARM licensees to use. ARM themselves haven’t shipped any CPUs implementing them, but then they also haven’t yet shipped any cores implementing SVE and that was announced and documented three years ago.

Re: Illegal instructions

Apple used illegal instructions to call system subroutines in the original MacOS, including many simple library things such as NewPtr() or opening and closing and reading disk files. Every M68000 instruction of the form 0xAnnn is an illegal instruction and Apple eventually used most of them.

Re: "I did not know that ARM actually prohibited adding instructions"

Er … on x86 instructions are up to 15 *bytes* not 15 bits. That’s 120 bits.

IBM hears the RISC-V kids partying next door, decides it will make its Power CPU ISA free, too

Re: Complements the RISC

RISC-V is not an implementation, it is an ISA.

The currently available implementations of RISC-V are low complexity, but you can be sure higher complexity higher performance implementations are in development at a number of companies -- most publicly at present Esperanto Technologies (who picked up Chris Celio of BOOM fame) and Alibaba.

Alibaba sketches world's 'fastest' 'open-source' RISC-V processor yet: 16 cores, 64-bit, 2.5GHz, 12nm, out-of-order exec

To pop this up a couple of levels for people who don't want to dig deep...

ONE VERSION of Linux runs on all RISC-V hardware. Hardware-specific patches are NOT needed.

All packaged Linux (etc) distributions can assume RV64GC. That is, 64 bit hardware including the extensions for multiply/divide, atomic transactions, single and double precision floating point, and variable length 16/32 bit instructions.

In any particular machine maintenance of caches or TLBs (for example) is either provided directly in the hardware, or else it is the responsibility of the hardware vendor to to provide Machine Mode software that traps and emulates the required functionality. This Machine Mode software must be installed by the boot process before the Linux kernel is invoked. As far as the Supervisor Mode software (e.g. the Linux kernel) is concerned everything Just Works.

The opcode is defined and programs (operating systems) can use it.

It's up to the chip designer whether the instruction is implemented in (as you point out) somewhat complex hardware that does everything OR traps to machine mode where a subroutine of normal instructions might have various logic, loops etc, that manipulate the TLB and/or caches of that particular core by reading and writing CSRs or possibly using some simpler custom instructions.

It's good for CPU designers to have a choice of how they do it, to cover a wide range of design points but with the exact same OS code running on all.

Similarly, the RISC-V architecture specifies the format of page tables in memory, but says NOTHING about what TLB hardware you might have, or whether TLB misses are handled with hardware that walks the page table or by a trap to Machine mode to do page table walking and TLB reload in software, or what.

Re: Right on the expected curve...

Thanks for your reply.

You're correct that the business model aspects of RISC-V are the important thing, not the technical merits or innovation, however it's definitely worth noting that the technical merits are right in the ballpark with things such as ARM or MIPS or SPARC, and better in some ways.

Yes, RISC-V makes a pretty good intermediate language or neutral software distribution format. It's very easy to emulate or JIT -- even the first working version of RISC-V QEMU immediately ran twice as fast as ARM32 or ARM64 versions of QEMU.

I was co-author of a RISC-V simulator and paper showing that if you concentrated on mapping directly to x86_64 you could get about twice the speed of QEMU, or often only about 20% to 30% slower than optimised x86_64 native code.

https://carrv.github.io/2017/papers/clark-rv8-carrv2017.pdf

Some other people have since picked up on this work and applied it to using RISC-V as a high performance method of implementing smart contracts on the Blockchain.

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

You'll see my work referenced at around 17m15s.

I'm sorry but that's simply wrong. Look at the SFENCE.VMA instruction described on p114 of "The RISC-V Reader" or p56 of the reference manual:

https://content.riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf

rs1 optionally specifies the VM page for which the mapping has been changed, and rs2 optionally specifies the address space in which the mapping has been changed. If neither of those is specified (i.e. is set to register x0) then the entire TLB needs to be flushed, but fine grained control is also possible.

Right on the expected curve...

RISC-V is coming from a standing start just a handful of years ago. CPUs such as the Western Digital SweRV and SiFive U74 are dual-issue in-order processors similar to the ARM Cortex A7 or A55 respectively or roughly like a Pentium MMX or PowerPC 603e but with more MHz (and 64 bit for the U74).

It's only a matter of time before many RISC-V companies have Out-of-Order CPU cores. CloudBear in Russia already announced their BI-671, Esperanto Technologies is going directly to OoO CPUs, the SHAKTI project in India are working on their "I Class". It would be surprising if others are not working on OoO cores as well -- especially those who already have dual-issue in-order working.

The Alibaba CPU is right where you'd expect it to be: pretty similar specs on paper to the ARM Cortex A75.

The performance numbers are .. right around what you'd hope you'd get by going to 3-issue OoO from the existing in-order processors.

Of course this is all nowhere near Ryzen or Skylake or Apple's much more aggressive than ARM's ARM designs. Give CPUs like that maybe five more years to start to appear in RISC-V land.

We've Falcon caught it! SpaceX finally nets a fairing half after a successful Heavy launch

Re: "the drone ship Of Course I Still Love You"

Since I’ve got the book in Kindle version … it’s from when the game player is trying to get back in touch with Contact, after refusing them.

“Well, I’ve sent the message to my friends, but—” He had a sudden, paranoid idea. He turned to Chamlis urgently. “These friends of yours are ships.” “Yes,” Chamlis said. “Both of them.” “What are they called?” “The Of Course I Still Love You and the Just Read the Instructions.” “They’re not warships?” “With names like that? They’re GCUs; what else?”

That’s it. If they’re mentioned elsewhere in Banks’ works I’m not aware of it. They’re certainly not in “Player”

Re: "the drone ship Of Course I Still Love You"

Hardly “characters”. Both are mentioned once in the same throw-away sentence, just to get a laugh it seems. They play no actual part in the (pretty darn good) story.

The Lance Arm-strong of performance-enhanced CPUs: Armv8.1-M arch jams vector math into super-microcontrollers

What happened to SVE?

It's interesting that this, MVE, is even necessary.

ARM's previous vector instruction set, SVE (for Scalable Vector Extensions), was announced in August 2016 and I believe is not yet shipping in any of ARM Ltd's cores yet, but only a Fujitsu ARM-based supercomputer processor).

And yet here we are with yet another vector processing instruction set announced.

Perhaps SVE didn't prove to be so scalable?

Meanwhile, the RISC-V Foundation's "Vector Extension Working Group" has been (frustratingly) slowly hammering out differences between microcontroller people and supercomputer people (and everyone in between) and since since earlier this month have a draft spec that probably several member companies will have available in silicon this year.

It looks as if the RISC-V V spec (with stable draft completed before anyone heard about MVE) scales to cover the whole ground covered by both MVE and SVE, as well as legacy SIMD ISAs such as NEON, AVX, SSE, MMX, while being very easy to use.

It's very interesting that in the MVE documents ARM talks about concepts such as executing vector instructions in beats, and chaining successive vector instructions together, because the RISC-V V spec is built with exactly the same (Cray-inspired) concepts in mind, as was the earlier "Hwacha" vector processor work at Berkeley six or eight years ago that RISC-V originally emerged out of.

Two out of five Silicon Valley techies complain Trump's H-1B crackdown has hit 'em hard

Re: H1-B abuse

I’m 56, have a job offer from a hot Silicon Valley startup for … well … a lot more than it costs to live there (not to mention of course more than the proposed future $130k minimum salary), and I’m waiting nine months and counting for them to even look at my application. Good thing I’m working for them as a remote contractor in the meantime, from wherever I want, which so far has included Moscow, Paihia NZ, Queensland Australia, and currently Fiji.

Linux lobby org joins with RISC-V bods to promote open chip spec

Re: There is Another Open Source CPU...

That would be an FAQ; https://riscv.org/faq/

Also: https://riscv.org/2014/10/why-not-build-on-openrisc/

OpenPOWER is not so open. I believe you have to pay substantial license fees to build a processor? Also, like MIPS and SPARC (and OpenRISC) the opcode encoding space is pretty much full, with little room for future standard or experimental extensions.

In RISC-V you can build a very simple CPU with fixed-length 32 bit opcodes and fewer than 50 instructions, taking very little space on an SoC or in an FPGA, and gcc and llvm will happily target that.

But at the same time, RISC-V supports instructions of any length from 16 bits to (at the moment) 176 bits (22 bytes) in multiples of 16 bits, with a standardised encoding that lets you know the length from looking at just the first 16 bits of the instruction. So you can do superscalar dispatch much more easily than for variable-length instruction sets such as x86.

I don't know of anyone using instructions of 48 bits or longer at the moment, but there is a standard extension that uses 16 bit opcodes to provide aliases for the most common 32 bit instructions, such as arithmetic where the destination register is the same as the first source register, or for loads and stores at small offsets from the stack pointer or another register, or for short program branches. This is course much the same idea as ARM Thumb or more recent MIPS and PowerPC features, but unlike the original Thumb doesn't require changing modes -- 16 bit and 32 bit (and longer) instructions can be freely mixed, as with Thumb2 or the new NanoMIPS.

Up in arms! Arm kills off its anti-RISC-V smear site after own staff revolt

Re: It bears repeating: Building a CPU that runs C fast considered harmful.

I find it amusing that my perfectly factual post ... and from someone helping design RISC-V CPUs and working on RISC-V compilers to run C fast ... got 30 downvotes here. Apparently a lot of people are half-educated. Oh well, lol etc.

Re: All publicity is good publicity.

RISC-V compilers are certainly newer and less optimised than ARM ones.

Despite this, SiFive's new E20 and E21 cores outperform ARM's Cortex-M0+ and Coptex-M4 on a Dhrystone MIPS/MHz and Coremarks/MHz basis, when both are compiled with gcc.

https://hackadaycom.files.wordpress.com/2018/06/coremarks.png

The ARM chips benchmark higher than the SiFive ones when using the IAD compiler. IAD has promised a beta of a RISC-V compiler for around the end of the year.

The RISC-V standard suggests that all but the very smallest RISC-V systems should include a "device tree" description of themselves in an onboard ROM.

The Raspberry Pi and other similar boards use obsolete SoCs that have already shipped in the millions in phones or other devices. For example the Odroid XU4 uses the same Samsung Exynos 5422 SoC as was in the Galaxy S5 phone. The Odroid C2 uses an Amlogic S905 SoC that was designed for set-top boxes. (I highly recommend both these boards over Raspberry Pi btw if you do want a high performance ARM board at a good price)

As RISC-V is new, it will be a while before there are obsolete SoCs that have already had their costs amortised in consumer products. What you have now in the Sifive HiFive1 ($59 320 MHz Arduino-compatable) and HiFive Unleashed ($999 quad core 1.5 GHz Linux board) are development boards aimed at professional engineers to evaluate the technology and prototype their software and products before they get their own hardware made. While $999 is expensive compared to a Pi or Odroid it's a drop in the bucket if you're paying an engineer $100k+ to work with it. Not to mention that the HiFive Unleashed has a lot of expensive stuff on it ... the 8 GB of DDR4 costs a lot more all by itself than the the Pi or Odroid (which have 1 or 2 GB of DDR3) retail for.