7 ms·
Show HN: v8-riscv — Port of JavaScript V8 engine to RISC-V
- kosolam 6y agoDumb question, but I’m curious what’s the purpose of risc-v? Is it only relevant for experiments or has real applications?
- remexre 6y agoI think that's actually a bit of a contentious question; I think there's a lot of people that'd argue that it's definitely part of the future of open computing, and I think it's extremely likely that it stays a part of computing for low-cost embedded devices. On the other hand, there's a strong argument to be made that it's more difficult to make a RISC-V processor with comparable performance to a desktop-grade amd64 processor than to make an ARMv8 processor that with the same. (Personally, I'm a big fan of AArch64 being a fixed-width encoding, and both programming by hand in it and find writing assemblers and disassemblers is super-easy as a result.)
- nynx 6y agoRiscv is also fixed-width, at least to the same level as aarc64.
- remexre 6y agoMy understanding was that the RISC-V encoding used lengths as decoded in e.g. [0], whereas AArch64 is uniformly 32 bits per instruction; is this incorrect? [0]: https://www.embarcados.com.br/wp-content/uploads/2017/05/RISCV_length.jpg https://www.embarcados.com.br/wp-content/uploads/2017/05/RIS...
- FullyFunctional 6y agoThat's correct, the compressed extension (part of the desktop spec over my loud and persistent protest) is part of the desktop platform. This adds 16-bit instructions to the 32-bit instruction set. There are many reasons why this was a huge and very shortsighted mistake, but the most painful part of this is that you can now have an instruction spanning two cache lines. This has many awful implication and precludes many tricks that would make implementations faster. But it was important for Andrew Waterman to get his thesis work be mandatory part of the Unix platform, so here we are. ADDENDUM: It's near trivial for a linker to pad such that instructions don't span cache lines and that would have made this a lot less painful, but RISC-V refuses to specify the line size (it's implementation dependent), so now we suffer this nightmare.
- farseer 6y agoSo what would the RISC-V foundation do about this problem?
- fwsgonzo 6y agoIt really is the worst and most awful decision that RISC-V absolutely must retract, the sooner the better. We cannot have performance and compressed at the same time. There are other things about the C extension that make it extremely bad for emulators too. The good news is that we can ignore rv64gc completely and just build everything rv64g, if you control everything yourself. Personally for my RISC-V use I actully do control everything and because of this I can pretend the C-extension doesn't exist.
- FullyFunctional 6y agoYou would have to build and maintain your own Linux distribution, that is the problem.
- remexre 6y agoOr just use Gentoo (or presumably Nix), or another distro with support for custom build flags for packages, right?
- FullyFunctional 6y agoI don't know if any of these have RISC-V support, but I would be interested in hearing about it. I would actually love a good distro for RV32G which is arguably a better match for FPGA softcores (and dev boards with > 4 GiB of external memory are rare)
- remexre 6y agoLooks like Gentoo's is experimental [0, 1], and [2] looks relevant for NixOS. [0]: https://wiki.gentoo.org/wiki/Project:RISC-V https://wiki.gentoo.org/wiki/Project:RISC-V [1]: https://dev.gentoo.org/~dilfridge/stages/ https://dev.gentoo.org/~dilfridge/stages/ [2]: https://nitter.net/shlevy/status/965019194759761920?lang=en https://nitter.net/shlevy/status/965019194759761920?lang=en
- jerrysievert 6y agonot necessarily a dumb question. as I see it, it's an open cpu, and does not require licensing fees. a huge amount of devices ship with arm cortex devices, each one low power and with money going back to arm for the licenses. risc-v provides for an open system that is performant and free of license fees.
- spijdar 6y agoIt provides for a open/royalty free system that is potentially performant. RISC-V alone provides little in terms of helping create better CPU implementations. An ARM core could probably be reworked into a RISC-V core and vice-versa -- it's ultimately "just" an instruction set. It benefits the CPU manufacturer, as they don't have to pay licensing fees and can therefore earn a buck more in profit. RISC-V isn't really intrinsically more open (from an end user perspective) than many of its competitors -- it does, however, have a lot of hype and social intertia behind it, which may be enough to propel it to greatness. One benefit of RISC-V is it offers a modular instruction set, where a "RISC-V" CPU can implement a subset of functionality and add new instructions in a well defined way. One downside to this is the possibility for the ISA to be splintered in practice if the major vendors end up not supporting a uniform feature set.
- nickik 6y agoA RISC-V CPU is inherently more open even from an end user perspective. That is not practically relevant for end-users if you consider somebody using for example a USB stick an enduser. However you could take the code on your device and run it on a alternatives providers implementation or on an open implementation. But just like end users of software don't really get practical benefits from open source, its the same for hardware. The advantage is for the industry and developers.
- mhh__ 6y ago> it's an open cpu, Not true. ISA != RTL
- jlokier 6y agoIt's already used in embedded processors commercially, and usage is growing. For example, there are RISC-V processors in some nVidia GPUs. Western Digital is known for using RISC-V in drives.
- wyldfire 6y agoIt probably was born as a practical academic experiment. It will be/has been used as an appealing alternative to cortex microcontrollers that are embedded in SoCs, storage devices, and add-in cards. But there's real commercial work trying to scale it up to bigger workloads too. I think these products are pretty early stage. I think Google is reluctant to push for Android support for a RISC-V applications processor. The nature of the different ISA extensions would mean that they would need to bet on the set of extensions that should be embraced (or a bunch of work to do some 'fat' binaries - or maybe 'obese' if there's a lot of supported combos). Regardless of Android's fate, yes, you can buy a RISC-V board that will boot linux. That's a pretty good bellwether for 'real applications'. But the performance likely pales in comparison with modern ARM or x86_64 alternatives. EDIT: see SiFive's "HiFive Unmatched" [1] for an example - DDR4, gigabit ethernet, 8 lanes of PCIe g3. It wouldn't surprise me if that's one of the best performing generally available RISC-V systems. [1] https://www.crowdsupply.com/sifive/hifive-unmatched https://www.crowdsupply.com/sifive/hifive-unmatched
- saagarjha 6y agoYou could also alter behavior at runtime based on detected features…
- wyldfire 6y agoSure, but that's not the hard bit. The toolchains that I've seen so far all generate code for a static set of RISC-V extensions and that set of extensions become the target platform's identity. Sort of like we've seen variations like 'armhf+gnueabi' before, except with RISC-V several of these 'extensions' are pretty much mandatory to get performance parity. The resolution of these ISA extensions is much higher than other architectures. That's part of the appeal, for sure. You can design a Just Right RISC-V without wasting any power or area supporting features you don't need. But until or unless the extensions stabilize to a canonical popular set (maybe this has already happened, or is happening soon), I wonder if the extension soup will cause some to be hesitant to adopt. Whatever hesitancy I am imagining is not holding back some super swift progress on all kinds of awesome RISC-V stuff.
- mhh__ 6y agoRISC-V was originally a teaching ISA but because of it's licence and open design process it's increasingly being adopted by industry. There are other open ISAs available but they are generally bigger targets (POWER is open now but it's a result of decades of IBM-work so it's not as initially simple as RISC-V). Also one thing that even on HN seems to be missed - RISC-V IS THE ISA not the silicon. All it means is that you don't have to pay the designer of the ISA any royalties to use it a la Arm, the CPU itself is most likely still a black box.
- chrisseaton 6y ago> RISC-V was originally a teaching ISA Where did you read this? I've always heard it started as part of Par Lab, a research project, and was aimed from the very start at being an open-source ISA that academia and then industry could use.
- mhh__ 6y agoI could be wrong, or I'm conflating academia with teaching.
- toinetoine 6y agoSorry if this sounds cringe, complete hardware novice here > RISC-V IS THE ISA not the silicon Doesn't that still require the chip-maker to build the chip with an interface that allows RISC-V instructions to run on it? It's not possible to "flash" a existing intel x86 CPU and run RISC-V instructions on it right?
- kevincox 6y agoYes. That is correct. The expectation is to run these on RISC-V hardware (mostly emulators are used now due to limited hardware availability but that is not the end goal). * Technically it may be possible to run RISC-V on Intel/AMD CPUs by modifying the microcode but not that much is known about what exactly the microcode does and it will likely not be very performant.
- meekrohprocess 6y agoGood question, and the answer is still a matter of opinion. I think the HN crowd is mostly excited because it is an ISA that fits two important criteria: * You can build a RISC-V CPU into your own digital designs for $0. There are also a lot of free designs which use open-source buses like Wishbone if you don't want to build your own. * Linux/GCC/etc. will probably support a compliant RISC-V implementation. And the cynical/realist crowd is harrumph-ing after a few important questions, like: * Many important features are not yet finalized, including things as basic as a nested interrupt controller. So, how compatible will modern RISC-V implementations be with future software? * Will "good enough" performance actually be good enough? It's still not clear whether a RISC-V CPU will be competitive with ARM et al on power and performance on a similar process node. It might be, but the ecosystem needs to mature. So it's one of those things that always seems to be 5 years away, like practical fission or the year of the Linux desktop. But if we ever do get to a point where you can use something like LiteX to generate a RISC-V SoC with N CPUs and driver support for its major peripherals on Linux, that would be exciting. Fabrication on 45-130nm process nodes might also be affordable for small startups by that point, too.
- nickik 6y agoNr.1 reason is that you need a open ISA in order to have an open processor. Therefore you can only have proper OpenHardware movement with an open processor. The RISC-V foundation was only created in 2015 before that it was basically a research project so saying anything RISC-V related is 'always' 5 years away is a strange statement. And I also don't know where you get 'good enough', RISC-V is not a processor, its and ISA and we know that ISA have relatively little impact implementation speeds. We already have RISC-V processors at the same node as ARM processors that beat them in many criteria.
- astrange 6y ago> we know that ISA have relatively little impact implementation speeds But this is not true, decoders cannot make up for everything. ISAs can also do a lot to improve software security, not to mention ease of use. RISC-V is just not well designed. Though it might be good enough… https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...
- antattack 6y agoIt is unencumbered by licensing and patents and offers good enough performance/watt. Chinese have been investing heavily in RISC-V as alternative to ARM and first IoT devices sporting RISC-V architecture should be available later this year.
- FullyFunctional 6y agoIt's an ISA whose purpose is to be an open alternative for people developing microprocessors. It's actually a (large) family of ISAs, suitable for diverse applications. The major advantage over rolling your own is that you don't have to develop the tools, and you can leverage quite a lot of software (still growing daily). The major advantages over going with Arm is that you have the freedom to extended the architecture (in a well-defined manner) and the ISA is completely open and free. You can implement it yourself, use on of many open source implementations, or license the IP from many companies, including SiFive. Nearly all machine learning startups use RISC-V for this reason, including Esperanto Technology. Off the shelf chips are slow to come out, but there's a steady stream. The next generation of the ESP32 is RISC-V based and there's also BL602 in the same class. For desktop (RV64GC)[1], I'm not aware of any chips for sale, but SiFive sells motherboards with their chips. I expect a lot more RISC-V silicon in 2021, including RV64GC capable parts. [1] see my rant elsewhere of why the "C" part is a !@#$ disaster.
- intricatedetail 6y agoThere are IP available for FPGA and whole toolchains. This is great if you need some specialised processing too slow to be implemented in software, you can add your own cpu instructions or map custom data pipelines to the CPU i/o space. The IP are not too performant, so there are trade offs to consider.
- mastrsushi 6y agoI thought a big benefit of compiled languages was that they are architecturally agnostic.
- sitkack 6y agov8 includes a JIT for every platform it runs on. The code itself needs to run on the target platform (memory model, threads, etc) and the output of the JIT needs to target the execution platform. Given how portable V8 already is, probably not a whole lot work needed to get it to compile and run on RISC-V, but the codegen would need to be written. https://github.com/v8-riscv/v8/tree/riscv64/src/codegen https://github.com/v8-riscv/v8/tree/riscv64/src/codegen
- deleted 6y ago[deleted]
- fastball 6y agoNot as far as I'm aware. The benefit of a compiled language is that it is translated to machine code once, not every time you run it, which generally gives perf gains. But machine code, or rather the instruction set that a CPU supports, is still different for different architectures.
- KMag 6y ago> translated to machine code once, not every time you run it, which generally gives perf gains. I think the real dominant factor is that ahead-of-time compilation generally isn't competing for resources with the application. AoT compilation is usually done on a completely different machine, or at least at time other than when the application is run. If your applications were recompiled every night while you slept, you wouldn't mind so much. In fact, that's what the latest Android Runtime does. Running applications dump profile information to the filesystem, and when the phone is plugged in and idle, the runtime goes back and re-optimizes the binaries for your usage pattern. Presumably, there's something like a statistical distance metric[0] to estimate how much the profiles changed since the last compilation, to avoid wasteful recompilation. [0] https://en.wikipedia.org/wiki/Statistical_distance https://en.wikipedia.org/wiki/Statistical_distance