RISC-V compilers for 64 bit use 32 bit instructions for int/unsigned int and smaller values, and 64 bit for long, size_t, ptrdiff_t, uintptr_t (and of course pointers). i.e. lp64 model.
AFAIK all RV64 standard instructions are 32 bit long (unless they implemented custom instructions which could be longer).
I was talking about the size of data that instructions operate on, not the size of the opcode.
In RV64 all the arithmetic/logical binary opcodes that are present in RV32 operate on 64 bit values instead of 32 bit values. RV64 adds extra ADDW, SUBW, ADDIW instructions that compute a 32 bit result and then sign-extend it into the 64 bit register, and similarly adds W versions of the immediate and dynamic shifts.
When a C program on RV64 adds two "long" values it will use ADD. When it adds two char, short, or int values it should use ADDW. Some compilers may prove that using ADD won't make any difference, and others may simply find it easier to use ADD and then explicitly sign-extend the result using SEXT.W (an assembler alias for ADDIW #0).
Specification allows for implementations with switchable XLEN size if protection modes are implemented though.
I'm not sure there's any need for protection modes to be implemented to have switchable XLEN. The programmer would just need to be careful.
I'm not sure who wanted switchable XLEN in the spec. Obviously x86 and ARM processors do this for compatibility with legacy software, but RISC-V currently has no legacy software. The systems on which end users might want to run random legacy binaries (e.g. Linux) are going with 64 bit right from the start, so there is little need to be able to run RV32 binaries. Maybe it will make sense later if/when people start to get 128 bit systems and want to run legacy 64 bit software on them.
I don't know of any RISC-V cores that currently implement switchable XLEN at runtime . Certainly none of SiFive's cores do, and I believe there are no current plans to implement it. (all the core generators allow you to choose whether you want 32 bit or 64 bit at core instantiation time)
I've seen someone state -- can't remember if it was here on on comp.arch -- that it is *compulsory* to implement switchable XLEN. They were mistaken, as that person so often is.
I'm actually working on my very own RV32 core for FPGA (with potential extension to RV64) - so far implemented I and M extensions, and core runs at 133 MHz on A35T speed grade 2, but I'm working on pipelining it even more to reach 166 MHz (or even 200 MHz).
If you can get that with 1 cycle throughput then that will be very nice!
There are open source cores that run at several hundred MHz in an Arty, but they take 3 or 4 cycles per instruction, so the MIPS is 100 or less.
SiFive's publicly available bitstreams run at 100 MHz in an Arty for simpler ones, or 75 or 50 MHz once you start adding things like MMUs and FPUs, but that RTL is optimised for SoCs not for FPGAs and the reason to put it in an FPGA is just to check that it works, and to run things like SPEC in a cycle-accurate manner before there are test SoCs, not to get the fastest possible core. Even at 50 MHz it's a lot better than Verilator :-)
Home
Help
Search
Login
Register
