3 ms·
I'm optimistic but not particularly bothered as long as X86 goes the way of the dodo i.e. people have argued that ARM could be the better ISA for the processor
by mhh__ 5y ago
I'm optimistic but not particularly bothered as long as X86 goes the way of the dodo i.e. people have argued that ARM could be the better ISA for the processor in your laptop.
One thing that we will have to see about is whether the extension model they have now actually holds in the future e.g. will we see a high performance fork of RISCV in the future, or simply (say) a chinese-only company who don't particularly care using parts of the instruction encoding space for their own purposes.
- cable2600 5y agoIt is the Post-X86 era now. That doesn't mean that X86 is gone, it means that alternatives to it exist and are on the rise.
- FullyFunctional 5y agoHigh performance RISC-V is orthogonal to those extensions. There is nothing stopping an M1-class implementation with the existing ISA.
- nine_k 5y agoDoes e.g. the memory model allow for a highly parallel architecture, with a ton of execution units and possible OoO execution? If it does, would it be a pain to program for (see Cell)?
- FullyFunctional 5y agoYes. By design (1), RISC-V removes much of what makes OoO harder. Most instructions have very regular and clean semantics, communicating only through registers, with a straight forward [up to] two register operands, at-most one destination. The memory model by default is the same as Arms, a fairly weak model. Basically code that works on Arm will port over trivially (vector and special functions excluded). (1) Unfortunately compressed instructions were included in the Unix profile which causes a lot of pain and makes it mostly impossible to do any partial predecode at I$ fill time. Ironically Arm64 wised up and removed the Thumb variants. (Preempting the code density crowd: there are other ways to deal with this). EDIT: Pain includes dealing with instructions that crosses cacheline or even page boundaries (hello double fault), but worse, not being able to tell what might be an instruction in the I$. It was a sad day when RISC-V with essentially no input from the higher-end concerns decided to force it on us.
- brucehoult 5y agoThat only applies if you want to run binary distros and applications such as Fedora or Ubuntu. If you're running a supercomputer and don't want to implement the C extension then you can build your own kernel and programs. If you do that then anything from RV32IA and up can be used. You can also use a QEMU or Valgrind-like thing to JIT the C away. Or you can do what modern x86 does and annotate your cache lines the first time they are actually decoded instead of at cache fill time. That's just a little slower for cold code but the same for hot code. Having the C extension keeps 40% more of your code hot for any given cache size. There might be some implementation point at which Aarch64 wins by having bigger but fixed length code, but it's not at the low end and I don't think it's at the very high end either.
- mhh__ 5y agoDon't the compressed instructions immediately put more pressure on the decoder than aarch64?
- brucehoult 5y agoTwo instruction lengths makes it slightly harder than one length, but we're not talking x86 15 lengths here. More compact code takes pressure off icache size and refill rates, and transfer rates from icache to fetch buffer. And ROM size in embedded, sich as on FPGA.