Phew, I was surprised when looking at the common extensions that there is no such spec for the MMU, so it's great that there is this SBI thing. There's so many microcontrollers in the space, but few general purpose CPUs. I'm a bit let down that this talk completely glossed over the CHERI clones, but I get the impression it was mostly outside his wheelhouse. It's actually what i wanted to hear more about when clicking the thumbnail, as CHERI is a genuine quantum leap.
The RISC-V spec includes the format of page tables in RAM and telling the hardware where the current page table is or if you've made changes to it. The spec does *not* include anything about what the hardware does with that information. The hardware could walk the page table for every memory access (not a good idea), or cache that information in a TLB of arbitrary design. That's up to the hardware designer. Software doesn't care. It will work on any hardware design that meets the spec.
So what we need here is a Linux running RISC V based board in the style of the Raspberry Pi. Is that concept a thing on some agenda somewhere given the links between Lowrisc and the Raspberry Pi ?
"HiFive Unleashed HiFive Unleashed is the ultimate RISC‑V development board. Featuring the Freedom U540-the world’s first-and-only Linux-capable, multi-core, RISC‑V processor-the HiFive Unleashed ushers in a brand-new era for RISC‑V." -from sifive(dot)com/boards Idk if this is truly the only linux capable SBC with RISC-V and at a starting price of $999 (Source:wikipedia) a bit much, but worth looking into. HiFive has cheaper SBCs with RISC-V meant for use as dev'ing boards but one shouldn't expect the same user experience as tried-and-tested boards like Raspberry Pis where the user base has been debugging cross-compilations for years
@@zoeycassandra4291 it's different things. Raspberry Pi is a consumer toy built using semi-obsolete (or at least previous generation) chips that have had their engineering costs paid for by shipping in millions of other devices such as smartphones or set-top boxes. The HiFive Unleashed on the other hand is a board for professional commercial developers to get a head start on software and/or hardware interfaces for other chips that don't exist yet. For hobbyists $999 is a lot (especially for something that performs roughly like a Raspberry Pi 3+), but as a tool for an engineer you're paying $10k a month in salary it's a blip. Note that ARM's corresponding A72 and A53 dev board is $10k.
Kendryte K210 is available already with AI acceleration, loads of RAM and flash, 400MHz, dual RISC-V cores. You can buy a SiPeed development board for $20 and micropython runs on it already. Gigadevices just launched their MCU too. Expect to see that in a lot of Chinese stuff in future, especially with Trump restricting Chinese access to American technology - Arm is going to suffer badly. I suppose the next big thing would be a HiSilicon RISC-V based SoC.
The problem with people being able to add their own instructions is that the "standard" will disintegrate into dozens of "standards". That may not matter for embedded applications, but it will never be able to drive a PC, where software houses expect to be able to develop for a standard, and mostly unchanging, architecture.
That's not true at all. What will happen is that Microsoft, Apple, and Google will work with ARM, AMD, and Intel (and maybe even OEMs) to define an instruction set for the chips they manufacture. Likely, MS and Google will work jointly to define their own, while Apple will likely develop a modified version of what MS and Google create. Note that this is ALREADY how it's been working in videogame consoles since the 80's. The only reason this might not happen is that ARM and Intel will fight this tooth and nail. But times are a-changing. And it's WELL past time that all consumer level software is inter-operable. Damn all the emulators, recompilations, and whatnot.
@@Noisy_Cricket except these companies are now all irrelevant and monopolistic. The FOSS world is powerful enough to work with say Linus to defined a new extended instruction set that is FOSOH with extensions based on something that was already supported and out of patent like 68040, or get a planet wide license for MIPS or SPARC. Something there is a full open toolchain for already, so compiler adjustment is less.
What you want is an agreed FOSOH standard for wearables. Basically get them out of the proprietary world so no one is wearing uninspectable hardware. Phones can use it too, and tablets, but there are hardware switching approaches (PinePhone, etc) to turn off the inherently invasive devices like mics. Not easy for anything worn.
As someone who is a 20 year Plan9 user, the barriers to adoption are myriad. The GPL was Linux' USP, not architectural superiority. Ask Ron Minnich his real opinion of Linux !
Does RISC V bring with it a potential for cross platform implementaions of softwares and programs? So we write a piece of code (in C/C++ lets say) and it can run on any OS/kernel? Because that would be sick. But sad case for Java developers though, because that language would become obsolete imo.
The "reduced" part of RISC is relative to ISAs like the ones Intel and Motorola (and predecessors) were making at the time, for a given use case. The idea is that the instruction set could be reduced and (at the time) improve performance for equivalent conventional code. It's not just about having fewer instructions overall, forever, in all contexts, regardless of the value they offer.
RISC is more about reducing the complexity of each instruction so that they can pass smoothly through an execution pipeline with the majority of instructions taking one clock cycle. The actual number of possible instructions is less of an issue. PowerPC famously is a RISC with a huge number of available instructions, and so is ARM's Aarch64 (despite being a considerably more pure RISC than its 32 bit ARM predecessor). RISC-V does happen to have a very small number of base instructions, with RV32I having 37 instructions that a C compiler would generate. That is sufficient to run *any* program, but depending on the nature of a particular program it might be an advantage to add extra instructions for integer multiply and divide (the M extension) or single or double precision floating point arithmetic (F and D extensions). Other specialized programs can likewise sometimes benefit from adding usually a handful of specialized instructions -- it's always possible to do without them, but sometimes you can increase speed and lower energy use considerably by adding a few highly specialized instructions.
One of the best RISC-V talks I've seen. Thanks, Alex!
Phew, I was surprised when looking at the common extensions that there is no such spec for the MMU, so it's great that there is this SBI thing. There's so many microcontrollers in the space, but few general purpose CPUs. I'm a bit let down that this talk completely glossed over the CHERI clones, but I get the impression it was mostly outside his wheelhouse. It's actually what i wanted to hear more about when clicking the thumbnail, as CHERI is a genuine quantum leap.
The RISC-V spec includes the format of page tables in RAM and telling the hardware where the current page table is or if you've made changes to it. The spec does *not* include anything about what the hardware does with that information. The hardware could walk the page table for every memory access (not a good idea), or cache that information in a TLB of arbitrary design. That's up to the hardware designer. Software doesn't care. It will work on any hardware design that meets the spec.
So what we need here is a Linux running RISC V based board in the style of the Raspberry Pi.
Is that concept a thing on some agenda somewhere given the links between Lowrisc and the Raspberry Pi ?
"HiFive Unleashed
HiFive Unleashed is the ultimate RISC‑V development board. Featuring the Freedom U540-the world’s first-and-only Linux-capable, multi-core, RISC‑V processor-the HiFive Unleashed ushers in a brand-new era for RISC‑V."
-from sifive(dot)com/boards
Idk if this is truly the only linux capable SBC with RISC-V and at a starting price of $999 (Source:wikipedia) a bit much, but worth looking into. HiFive has cheaper SBCs with RISC-V meant for use as dev'ing boards but one shouldn't expect the same user experience as tried-and-tested boards like Raspberry Pis where the user base has been debugging cross-compilations for years
@@zoeycassandra4291 it's different things. Raspberry Pi is a consumer toy built using semi-obsolete (or at least previous generation) chips that have had their engineering costs paid for by shipping in millions of other devices such as smartphones or set-top boxes. The HiFive Unleashed on the other hand is a board for professional commercial developers to get a head start on software and/or hardware interfaces for other chips that don't exist yet. For hobbyists $999 is a lot (especially for something that performs roughly like a Raspberry Pi 3+), but as a tool for an engineer you're paying $10k a month in salary it's a blip. Note that ARM's corresponding A72 and A53 dev board is $10k.
@@BruceHoult I don't think Raspberry Pi is a toy. Many people use it for production purposes.
RISC-V is more or less like a hardware version of Linux.
Kendryte K210 is available already with AI acceleration, loads of RAM and flash, 400MHz, dual RISC-V cores. You can buy a SiPeed development board for $20 and micropython runs on it already.
Gigadevices just launched their MCU too. Expect to see that in a lot of Chinese stuff in future, especially with Trump restricting Chinese access to American technology - Arm is going to suffer badly. I suppose the next big thing would be a HiSilicon RISC-V based SoC.
Kendryte K230 is even better!
I am curious to know about serialized TileLink.
please put time stamps, this is gold
Wish there was a OpenFirmware boot loader?
beautiful
The problem with people being able to add their own instructions is that the "standard" will disintegrate into dozens of "standards". That may not matter for embedded applications, but it will never be able to drive a PC, where software houses expect to be able to develop for a standard, and mostly unchanging, architecture.
That's not true at all. What will happen is that Microsoft, Apple, and Google will work with ARM, AMD, and Intel (and maybe even OEMs) to define an instruction set for the chips they manufacture. Likely, MS and Google will work jointly to define their own, while Apple will likely develop a modified version of what MS and Google create. Note that this is ALREADY how it's been working in videogame consoles since the 80's.
The only reason this might not happen is that ARM and Intel will fight this tooth and nail. But times are a-changing. And it's WELL past time that all consumer level software is inter-operable. Damn all the emulators, recompilations, and whatnot.
@@Noisy_Cricket except these companies are now all irrelevant and monopolistic. The FOSS world is powerful enough to work with say Linus to defined a new extended instruction set that is FOSOH with extensions based on something that was already supported and out of patent like 68040, or get a planet wide license for MIPS or SPARC. Something there is a full open toolchain for already, so compiler adjustment is less.
What you want is an agreed FOSOH standard for wearables. Basically get them out of the proprietary world so no one is wearing uninspectable hardware. Phones can use it too, and tablets, but there are hardware switching approaches (PinePhone, etc) to turn off the inherently invasive devices like mics. Not easy for anything worn.
HarveyOS and HelenOS may be the next Linux story. Microkernels were catching on just when Linux ate everything in the 90s.
As someone who is a 20 year Plan9 user, the barriers to adoption are myriad. The GPL was Linux' USP, not architectural superiority. Ask Ron Minnich his real opinion of Linux !
NT (ReactOS) may be a better Microkernel.
Does RISC V bring with it a potential for cross platform implementaions of softwares and programs? So we write a piece of code (in C/C++ lets say) and it can run on any OS/kernel? Because that would be sick. But sad case for Java developers though, because that language would become obsolete imo.
Currently Windows and MacOS don't support RISC V, only Linux does.
@@leezhieng No one needs either. Thankfully they can both be emulated easily even without x86 hardware as Apple proved with M1
@@leezhieng freebsd does give some support to riscv64
Reduced instruction set, says adding more instructions is totally fine. Pick one?
Hybrid instruction set doesn't come to mind?
The "reduced" part of RISC is relative to ISAs like the ones Intel and Motorola (and predecessors) were making at the time, for a given use case. The idea is that the instruction set could be reduced and (at the time) improve performance for equivalent conventional code.
It's not just about having fewer instructions overall, forever, in all contexts, regardless of the value they offer.
RISC is more about reducing the complexity of each instruction so that they can pass smoothly through an execution pipeline with the majority of instructions taking one clock cycle. The actual number of possible instructions is less of an issue. PowerPC famously is a RISC with a huge number of available instructions, and so is ARM's Aarch64 (despite being a considerably more pure RISC than its 32 bit ARM predecessor). RISC-V does happen to have a very small number of base instructions, with RV32I having 37 instructions that a C compiler would generate. That is sufficient to run *any* program, but depending on the nature of a particular program it might be an advantage to add extra instructions for integer multiply and divide (the M extension) or single or double precision floating point arithmetic (F and D extensions). Other specialized programs can likewise sometimes benefit from adding usually a handful of specialized instructions -- it's always possible to do without them, but sometimes you can increase speed and lower energy use considerably by adding a few highly specialized instructions.