7 ms·
RISC-V announces first new specifications of 2022 adding to 16 ratified in 2021
- messe 4y agoWhile it's great that we've started to standardize across architectures on a firmware for servers and workstations, I really wish it hadn't been UEFI. It's well documented, but in my (admittedly limited) experience, a pain to program for with one of the ugliest APIs I've ever used.
- snvzz 4y agoIf you absolutely hate it, it is still fortunately possible to have SBI without UEFI.
- bpye 4y agoI’ve played around with some toy kernel stuff on RISC-V - SBI is refreshingly simple.
- panick21_ 4y agoAs long as there is any kind of standard you will get good open source that works. Linuxboot and co.
- MisterTea 4y agoCoreboot could be a standard if people stopped ignoring it.
- MisterTea 4y agoI too am disappointed as it feels like were just bolting on Intel baggage to appease commercial interests who could care less about openness or maintainability. On one hand I want RISC-V to have a firmware standard for their applications processors so we don't have the vendor specific situation we have with Arm. On the other, I do not want Microsoft approved, overly complex Intel contraptions making a mess of an open architecture.
- messe 4y agoARM64 is moving more and more toward UEFI as well.
- gjsman-1000 4y agoUEFI is a mess, admittedly, with a large attack surface, bad API surface, DOS-like command syntax, it's all pretty bad. However, it's not as bad as the total free-for-all that booting most Android or ARM devices is. They're like a box of chocolates - you never know what you're going to get. Standardization, even if the standard is poor, is much better in this case than no standard.
- panick21_ 4y agoUEFI is just huge. As long as there is a standard for UEFI Interfaces you can only use a small subset of the API and avoid everything else. Basically you use minimal UEFI and then just jump into Linuxboot and implement everything else there.
- MisterTea 4y ago>Standardization, even if the standard is poor, is much better in this case than no standard. Have you heard of Coreboot? UEFI isn't the only game in town but it happens to be the only game that boots modern Microsoft products. MS is a technological burden that needs to go away.
- snvzz 4y agoCoreboot would overlap, role-wise, with SBI. UEFI (like Tianocore) is just payload from coreboot pov.
- ncmncm 4y agoSeems like they could have specified that only the "good parts" of UEFI are required. I.e., the minimal, simplest part actually used. After all, on x86,that is the only part that can actually be counted on to work. The rest is shovelware.
- throw0101a 4y agoOpen Firmware, used by Sun and Apple in the past, always seemed pretty decent to me: * https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware Having an honest-to-God / proper serial console, without any kludgey (BIOS) redirects, was something I liked having as a sysadmin of SPARC systems.
- messe 4y agoYep, I still love it on my SPARC64/PowerPC systems. My favourite aspect of coding for it is the fact that you can write bootsectors in forth[1]. [1]: https://cvsweb.openbsd.org/src/sys/arch/sparc64/stand/bootblk/bootblk.fth?rev=1.10&content-type=text/x-cvsweb-markup https://cvsweb.openbsd.org/src/sys/arch/sparc64/stand/bootbl...
- throw0101a 4y agoPlatform-independent drivers is also clever.
- phendrenad2 4y agoNot to mention overengineered. In 99.9% of cases it just gets used by the bootloader to find the kernel on disk, just like BIOS.
- R0b0t1 4y agoMotherboard firmware usually exceeds to size of the Linux kernel it's loading.
- seoaeu 4y ago“On disk” really downplays the amount of code required to implement drivers for loading off USB, SATA, NVMe, etc.
- phendrenad2 4y agoMy toyota prius is an insanely complex machine, and yet all it has to do is go forward when I press the accelerator. A UEFI-style over-engineered solution would require me to iterate over AcceleratorProviderProtocols in case someone implemented an acceleration pedal that works differently.
- tenebrisalietum 4y agoU-Boot seems to do the same and is a lot simpler than UEFI.
- seoaeu 4y agoU-Boot is over 2 million lines of code. I don’t know off hand exactly what functionality that does and doesn’t include, but I think it is fair to argue that neither one is especially simple
- coldacid 4y agoI have to admit, as useful as some of these extension specs may be, it makes me feel like the RISC part of RISC-V is slowly falling by the wayside.
- brucehoult 4y agoThree of these four are software-only changes, and the 4th is hardware but doesn't affect the ISA as seen by a user.
- monocasa 4y agoAnd particularly, the 4th is an optional removal of instructions on systems that don't require it.
- panick21_ 4y agoIt was always the goal to support everything from micro to hpc. So more extensions were always expected. However the R in RISC revers to the how many instruction you have to implement to get a job done. If you write for a microcontroller, RISC-V is just as small now as it was when it started.
- andrekandre 4y ago> However the R in RISC revers to the how many instruction you have to implement to get a job done. right, the way i always understood it was, in many situations there are different riscs that are appropriate (e.g i only need 32-bit integer and atomic instructions for job x) so instead of accumulating larger and larger single spec, you can pick and choose whats needed: you can have still have your risc (fewer, simpler, efficient instruction) cake and eat it (deploy it in various divergent situations and still be standard) too
- NobodyNada 4y agoRISC isn't about the number of total instructions, but the complexity of the individual instructions. Consider the ARM "JavaScript instruction" people love to make fun of. FJCVTZS sure sounds like a ridiculous instruction name right out of x86 -- but in reality, it performs a very simple task that greatly speeds up JavaScript code, and it's trivial to implement in hardware but painful in software. If you're going to be doing a task like that frequently it absolutely makes sense to have an instruction for it, and RISC vs. CISC doesn't change that. What makes an architecture CISC is when the instructions start to do too many things at once. For instance, on x86 you can write something like ‘ADD [rax + 0x1234 + 8*rbx], rcx'. This one instruction involves a bit shift, two additions, a memory load, a third addition, and a memory store (and you can stick on prefix bytes to do even more things). Whereas on a RISC you'd split this operation into four or five separate instructions. Crucially, the work that the processor has to do doesn't actually change -- the CISC processor is just going to split the instruction apart into RISCy microoperations anyway. So the RISC processor has to do a little more memory access to read all the instructions, but much less decoding work to lower them into the same microcode.
- londons_explore 4y agoI want to see every extension be forwards and backwards compatible. Ie. a binary should run fine with or without a processor extension. To make that happen, every processor extension should either be implemented in hardware, or be emulated by software. None of these extensions to the ISA have software implementations. Sure, someone could write one, but I don't think the RISC-V standards group should allow any extensions to make it into silicon without a software implementation being published and freely available. The RISC-V group should publish an official binary (and source) which can trap and emulate every possible extension.
- adgjlsfhk1 4y agoYou can't allow for forward compatibility without sacrificing performance. If a chip knows that there is a fixed set of opcodes, it can specialize decoding to only decode the opcodes it knows about.
- colejohnson66 4y ago> If a chip knows that there is a fixed set of opcodes, it can specialize decoding to only decode the opcodes it knows about. What does that mean? The CPU still needs to trap on undefined ones. I don't think the spec even allows non-trapping behavior[a]. So there's still some kind of decode happening. And if each instruction is 32 bits, you don't need any logic to find the instruction boundary on an undefined one. [a]: By "non-trapping", I mean behavior akin to what old processors would do where every opcode would do something because of gaps in the PLAs (such as 0xAF on the 6502 performing 0xAD (LDA abs) and 0xAE (LDX abs) at the same time)
- dzaima 4y agoThe spec contains "The behavior upon decoding a reserved instruction is unspecified." which to me sounds like that the CPU can do whatever it wants.
- colejohnson66 4y ago
- prettyStandard 4y ago4 new specs 1. UEFI 2. Supervisor Binary Interface 3. Efficient Trace/Debug 4. Zmul only. This is the one that confused me. > “For many microcontroller applications, division operations are too infrequent to justify the cost of divider hardware,” explained Himelstein. “The RISC-V Zmmul extension will benefit simple FPGA soft cores in particular.” This doesn't look like bloat to me. But I have no experience in RISC V.
- brucehoult 4y agoIt's always been legal to say you implement the M extension, but only actually implement multiply in hardware, and provide a trap and emulate solution for the division instructions. There has long been a -mno-div flag for gcc and clang to tell them not to generate divide instructions (i.e. call a library divide function directly, to save trap overhead) even though the M extension is present. This just provides a way to express that commonly-used functionality via an ISA string instead.
- pclmulqdq 4y agoYes, except that's one more trap handler to implement. And it's a lot slower than inlining the division code when you need it.
- prettyStandard 4y agoYes but this is better than not implementing the trap.
- pclmulqdq 4y agoWait, having no DIV instruction will result in faster code than having a DIV that traps. The compiler picks up the code that happens in the trap and can optimize it. For example, the code for an 8-bit division can be a lot faster than a 32-bit DIV on a microcontroller.
- 4y ago
- cosmiccatnap 4y agoLove or hate UEFI it's the defacto standard for booting modern hardware and the added support gets us closer to a viable desktop platform. The success of M1 has shown the advantages of a consumer risc platform but the holy grail for many of us is a totally open platform with similar power/performance advantages to arm. It's a small step but an important one.
- bpye 4y agoUEFI doesn’t have to be so unwieldy either. You can have UEFI with device tree instead of ACPI, and if that’s sufficient then u-boot will give you a working UEFI environment.
- sydthrowaway 4y agoTake that ARM!