RISC-V can support 128-bit (64 object ID + 64 offset) computing, which allows unique identifiers that can allows persistent pointers on a global scale. It may seem excessive, but the world is currently building 4-5 exascale computers, which will require this type of architecture.
With RISC-V, the address space is unique over time and space. Any computer supporting this address space is addressable by the name server. I.E you can have domain wide address space.
64-bit isn't enough for global exascale computing. With the strategy WD is adopting, it will be right there and supporting the technology on day one.
The value of that is really dubious. 64-bit address space with byte addressing IS more than enough for any computer, including "exascale" ones (whatever you mean by that - sounds like a meaningless marketing term). And networks will be IPv6 anyway.
RISC-V is a very dull otherwise, no innovation over the myriad existing RISC instruction sets. Basically, it does not solve a single problem which current instruction sets have, preventing the future development of computing.
Agreed. I hadn't heard about this feature of RISC-V. But, even if it's as you describe, network communication of any kind (even PCIe) is sufficiently high-latency that you don't need ISA-level support for inter-machine addressing. In cases where an object might reside outside of local memory, it's no big deal for software to explicitly keep a 64-bit pointer + some other 64-bit identifier.
The main problem RISC-V solves is no royalties or IP control issues. And that's enough for many (such as WDC). If all it does is break the ARM hegemony over smartphones and much of the embedded space, then it'll be enough. Then, maybe RISC-VI (or an unrelated, open ISA) can be more ambitious and forward-looking.
Open ISA, modular (32,64,128 bits). Governed by an independent foundation, to last 50 years. No ISA license. Very efficient instruction encoding tailored for low complexity decoders (small cores, low power big cores). Base I integer instruction set has ~50 instructions that can boot Linux, lower power than x86 and ARM. Optional modular extensions - Multiply/add, Floating point etc., vector unit (crypto, SIMD floating point unit).Compressed instructions - most used instructions and register combinations take 16 bits instead of 32.
Scalable(small to big cores) and extendable (new instructions, accelerators). From tiny microcontrollers to Linux capable multicores. Simple yet with comparable or higher performance on a given manufacturing node than ARM, let alone x86 (have to wait for OOO cores). Open - no unverifiable NSA blobs :-), what you compile is what you get. No legacy baggage. Security by ability to audit cores. Synthesizable (meaning compiling into your SoC or FPGA project). RV64GC (64 bit instr. set with integer, multiply, float and compressed extension) for off the-shelf shrink-wrapped software like Linux distros and apps. Your first RISC-V silicon will probably be a future nVidia chip or a WD disk :-D
Regarding 128 bit support, multiple nodes mapped in memory is the goal, to shave off latency by going through network adapter APIs of any kind. To be orthogonal (node+local address), the address must be divided into node part and local part as in internet protocol, which is btw also 128bit (IPV6). Hence 64+64 bits.
Non standard extensions like reduced register versions are available and being standardized. RISC-V will do the same Linux did for smartphones, home appliances, router, supercomputers etc.
> Your first RISC-V silicon will probably be a future nVidia chip
This is a bit misleading. They're only using it for an embedded microcontroller - not the actual compute cores.
Also, I've read there are already issues with the number of incompatible extensions that've been added to the ISA. They really need some sort of namespace scheme for the extensions, and then a chip-specific mapping to pack the opcode space.
Extensions are for accelerators, i.e. a special data crunching. basic extensions (it's modular) ale named by a single character (I - integer, M-multiply/add, F- float, D-double precision, A - atomics, V- vector, G=all of IMAFD,C - compressed) and vendor specific BUT standardized start with Z or X alphabet. Ie. Zxxxxx is something developed by some company for machine learning. All extensions are voluntary, it's a way to handle computation to more efficient instructions. Why not.
The base I integer ISA is to be frozen. It's also sufficient for Linux to boot up. Optional basic extensions are here to allow higher performance cores. Small cores, like those embedded in nVidia or WD controller only get extensions they really need.
For general software like Linux distributions and applications (and not to segment the market) the RV64GC is considered a base standard. Therefore the desktop level software can assume that all of the instructions in the RV64IMAFDC(=RV64GC) standard are there.
This modularity allows only subsets of the instructions to be in a cpu for closed designs, and all of the REQUIRED instructions for desktop or server-like cpus. Some companies or university projects add only some instructions from some extensions, for example only multiply instruction, but not all register bit widths combinations. And it's fine, because it's their specific design.
The instruction encoding is well crafted to allow the base instructions to be always in "the same place", in other words, to have always the same instruction format. You can run a program compiled for RV64I standard on any CPU up, because this is the base minimum for all design (embedded and up).
The most expensive part of any CPU are the compilers from various languages. So to allow the 50 years longevity, the encoding of the instructions and register layout has to be frozen.
RISC-V allows instruction encoding - variable length instructions - in multiples of 16 bits. The instruction decoder immediately knows how long the instruction is and can therefore decode other instructions in parallel. x86 has extremely fragmented ISA encoding (thus spending 2/3 of power on just decoding) and ARM or MIPS has fixed 32bit encoding.
Feature seen only on ARM is compressed instructions. Most used ones on RISC-V C extension are packed from 32bits to 16bits and this saves about 25% of code size (useful on small microcontrollers as well as on very complex cores because of smaller cache load). The cpu executes both 32 and 16bit variants, you know. It's 1:1 encoding thus simple to decode.
Whole ISA from 32bit to 128bit fits on a single sheet of paper. On x86 instruction manual is about 5000 pages long and on ARM it's around 5700. For RISC-V it's about 70. Not counting platform specific implementation features - interrupt controller etc. Just the ISA.
And other ecosystem is coming, for example cache coherent protocol in a reference implementation in a Rocket chip and it's off-the chip variant now developed by SiFive.
Last - note that different bit widths of the ISA, i.e. RV32, RV64 and RV128 are different ISAs that assume different register widths. So code for RV32 would not probably run on RV64 machine. Definitely not the other way.
There are 32 integer registers, optionally 32 floating point registers and optionally 32 vector lanes with 4 elements (not 100% sure). There is an extension for only 16 register version, for tiny microcontrollers. Some people from big compute have also raised legitimate questions for standardizing 16 register extension, because the register sets are comparatively big part of the core compared to the other logic ;-) For hundreds of threads on one chip, it really counts.
> x86 has extremely fragmented ISA encoding (thus spending 2/3 of power on just decoding)
This has got to be some kind of worst-case scenario. For one thing, x86 CPUs cache their decoded instructions. And even if they didn't, there's no way decoding uses 2x the power of something like AVX2.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
10 Comments
Back to Article
jimjamjamie - Friday, December 15, 2017 - link
Pretty neat, what are the benefits of using RISC-V over ARM?mode_13h - Friday, December 15, 2017 - link
No royalties, primarily. This cannot be understated, when you're talking about shipping billions of cores/year.Also, less legacy.
andychow - Friday, December 15, 2017 - link
RISC-V can support 128-bit (64 object ID + 64 offset) computing, which allows unique identifiers that can allows persistent pointers on a global scale. It may seem excessive, but the world is currently building 4-5 exascale computers, which will require this type of architecture.With RISC-V, the address space is unique over time and space. Any computer supporting this address space is addressable by the name server. I.E you can have domain wide address space.
64-bit isn't enough for global exascale computing. With the strategy WD is adopting, it will be right there and supporting the technology on day one.
peevee - Monday, December 18, 2017 - link
The value of that is really dubious.64-bit address space with byte addressing IS more than enough for any computer, including "exascale" ones (whatever you mean by that - sounds like a meaningless marketing term). And networks will be IPv6 anyway.
RISC-V is a very dull otherwise, no innovation over the myriad existing RISC instruction sets. Basically, it does not solve a single problem which current instruction sets have, preventing the future development of computing.
mode_13h - Tuesday, December 19, 2017 - link
Agreed. I hadn't heard about this feature of RISC-V. But, even if it's as you describe, network communication of any kind (even PCIe) is sufficiently high-latency that you don't need ISA-level support for inter-machine addressing. In cases where an object might reside outside of local memory, it's no big deal for software to explicitly keep a 64-bit pointer + some other 64-bit identifier.The main problem RISC-V solves is no royalties or IP control issues. And that's enough for many (such as WDC). If all it does is break the ARM hegemony over smartphones and much of the embedded space, then it'll be enough. Then, maybe RISC-VI (or an unrelated, open ISA) can be more ambitious and forward-looking.
lada - Tuesday, December 19, 2017 - link
Open ISA, modular (32,64,128 bits). Governed by an independent foundation, to last 50 years. No ISA license.Very efficient instruction encoding tailored for low complexity decoders (small cores, low power big cores).
Base I integer instruction set has ~50 instructions that can boot Linux, lower power than x86 and ARM. Optional modular extensions - Multiply/add, Floating point etc., vector unit (crypto, SIMD floating point unit).Compressed instructions - most used instructions and register combinations take 16 bits instead of 32.
Scalable(small to big cores) and extendable (new instructions, accelerators).
From tiny microcontrollers to Linux capable multicores.
Simple yet with comparable or higher performance on a given manufacturing node than ARM, let alone x86 (have to wait for OOO cores).
Open - no unverifiable NSA blobs :-), what you compile is what you get.
No legacy baggage. Security by ability to audit cores.
Synthesizable (meaning compiling into your SoC or FPGA project).
RV64GC (64 bit instr. set with integer, multiply, float and compressed extension) for off the-shelf shrink-wrapped software like Linux distros and apps.
Your first RISC-V silicon will probably be a future nVidia chip or a WD disk :-D
Regarding 128 bit support, multiple nodes mapped in memory is the goal, to shave off latency by going through network adapter APIs of any kind. To be orthogonal (node+local address), the address must be divided into node part and local part as in internet protocol, which is btw also 128bit (IPV6). Hence 64+64 bits.
Non standard extensions like reduced register versions are available and being standardized.
RISC-V will do the same Linux did for smartphones, home appliances, router, supercomputers etc.
mode_13h - Tuesday, December 19, 2017 - link
> Your first RISC-V silicon will probably be a future nVidia chipThis is a bit misleading. They're only using it for an embedded microcontroller - not the actual compute cores.
Also, I've read there are already issues with the number of incompatible extensions that've been added to the ISA. They really need some sort of namespace scheme for the extensions, and then a chip-specific mapping to pack the opcode space.
lada - Wednesday, December 20, 2017 - link
Extensions are for accelerators, i.e. a special data crunching. basic extensions (it's modular) ale named by a single character (I - integer, M-multiply/add, F- float, D-double precision, A - atomics, V-vector, G=all of IMAFD,C - compressed) and vendor specific BUT standardized start with Z or X alphabet. Ie. Zxxxxx is something developed by some company for machine learning. All extensions are voluntary, it's a way to handle computation to more efficient instructions. Why not.
The base I integer ISA is to be frozen. It's also sufficient for Linux to boot up. Optional basic extensions are here to allow higher performance cores. Small cores, like those embedded in nVidia or WD controller only get extensions they really need.
For general software like Linux distributions and applications (and not to segment the market) the RV64GC is considered a base standard. Therefore the desktop level software can assume that all of the instructions in the RV64IMAFDC(=RV64GC) standard are there.
This modularity allows only subsets of the instructions to be in a cpu for closed designs, and all of the REQUIRED instructions for desktop or server-like cpus. Some companies or university projects add only some instructions from some extensions, for example only multiply instruction, but not all register bit widths combinations. And it's fine, because it's their specific design.
The instruction encoding is well crafted to allow the base instructions to be always in "the same place", in other words, to have always the same instruction format. You can run a program compiled for RV64I standard on any CPU up, because this is the base minimum for all design (embedded and up).
The most expensive part of any CPU are the compilers from various languages. So to allow the 50 years longevity, the encoding of the instructions and register layout has to be frozen.
RISC-V allows instruction encoding - variable length instructions - in multiples of 16 bits. The instruction decoder immediately knows how long the instruction is and can therefore decode other instructions in parallel. x86 has extremely fragmented ISA encoding (thus spending 2/3 of power on just decoding) and ARM or MIPS has fixed 32bit encoding.
Feature seen only on ARM is compressed instructions. Most used ones on RISC-V C extension are packed from 32bits to 16bits and this saves about 25% of code size (useful on small microcontrollers as well as on very complex cores because of smaller cache load). The cpu executes both 32 and 16bit variants, you know. It's 1:1 encoding thus simple to decode.
Whole ISA from 32bit to 128bit fits on a single sheet of paper. On x86 instruction manual is about 5000 pages long and on ARM it's around 5700. For RISC-V it's about 70. Not counting platform specific implementation features - interrupt controller etc. Just the ISA.
And other ecosystem is coming, for example cache coherent protocol in a reference implementation in a Rocket chip and it's off-the chip variant now developed by SiFive.
Last - note that different bit widths of the ISA, i.e. RV32, RV64 and RV128 are different ISAs that assume different register widths. So code for RV32 would not probably run on RV64 machine. Definitely not the other way.
There are 32 integer registers, optionally 32 floating point registers and optionally 32 vector lanes with 4 elements (not 100% sure). There is an extension for only 16 register version, for tiny microcontrollers. Some people from big compute have also raised legitimate questions for standardizing 16 register extension, because the register sets are comparatively big part of the core compared to the other logic ;-) For hundreds of threads on one chip, it really counts.
mode_13h - Thursday, December 21, 2017 - link
> x86 has extremely fragmented ISA encoding (thus spending 2/3 of power on just decoding)This has got to be some kind of worst-case scenario. For one thing, x86 CPUs cache their decoded instructions. And even if they didn't, there's no way decoding uses 2x the power of something like AVX2.
Threska - Tuesday, December 19, 2017 - link
Wonder how well it would fit in with the move to Infinity Fabric (and the Intel equivalent)?