RISC-V Public review for standard extensions Zc

https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/aTgHkmkPXrw

by snvzz • 4 years ago

94 39 4 years ago

groups.google.com

snvzz5• 4 years ago

Comments here: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/j2x...

RISC-V gets more and more complicated all the time. N different extensions of which almost any subset is a valid combo, so 2**N variants. Meanwhile, nothing about fast integer overflow detection.

Jtsummers• 4 years ago

2^N (I'm guessing you typed two *s, you need to type 4 to get two to show up).

  ** =>

  **** =>

throwaway815235• 4 years ago

Thanks, fixed.

wyldfire2• 4 years ago

I think the RISC-V committees/foundation realized the problem and is endorsing specific combinations of extensions.

snvzz5• 4 years ago

Rather than "realized the problem", it would be more accurate to say that they understood the ramifications of extensions from the very beginning, took adequate steps, and never allowed it to become a problem.

brucehoult4• 4 years ago

It's not a problem because:

- if you're compiling your own software you just tell the compiler what extensions the hardware you're using has.

- if you're running shrink-wrapped software today then you currently know exactly that RV64GC is supported, and next year you'll know there are 2.5 possibilities: RVA20 (RV64GC renamed), and RVA22 with or without V extension. I expect the next one (RVA24 or RVA25 or something) will make V compulsory.

If you actually genuinely care about fast integer overflow detection on RISC-V then make a proposal, analysing the costs and benefits.

As far as most people are concerned, there isn't a problem there in the first place.

throwaway815235• 4 years ago

As far as most people are concerned, there isn't a problem there [fast overflow detection] in the first place.

See, that is the problem. They try to be an architecture for the future but they are only concerned about performance of legacy code that doesn't check overflow either. The result is a zillion CVE's from overflow bugs, to go with the buffer overflows. Idk whether Rust is supposed to check overflow. Ada is supposed to check unless you suppress the check with a pragma, but GNAT sets the pragma by default because doing the check costs too much performance even on x86.

The Ada designers were not being fools when they specified that these checks should be done all the time. So an architecture of the future should support doing that efficiently, just like the CHERI(?) extension supports checking pointers efficiently.

As for the many combinations of features: it will be like x86 I guess, where it is a hassle but ultimately not a crushing one. Usually people just give up some performance by using lowest common denominator (or should that be greatest common factor) executables.

bjourne• 4 years ago

It's a problem because if you are a vendor creating shrink-wrapped software you will have a hard time ensuring that your software supports all plausible extension combinations. Thus you will not bother just like most gaming companies does not bother porting their software to GNU/Linux. Sun basically did the same thing in the early 2000's with all their Java editions and profiles. It didn't work out well.

rwmj• 4 years ago

Have you tried this recently?

  grep ^flags /proc/cpuinfo

dzaima• 4 years ago

Mentioning 2^N variants on this specific proposal is probably the worst place to do so - Zca, Zcf, Zcd are all subsets of the 'c' extension, and Zcmp is incompatible with the 'c' extension, which severely cuts down the combinations - having the 'c' extension, which Linux expects, makes all (but Zcb I think?) extensions here either implicitly supported, or incompatible.

And, given the scope & purpose of these extensions, most things (distributed binary programs, OSes, all but a few compilers) won't need to use nor care about these. The alternative to these extensions, to those that need them, would be either suffering decreased performance/increased ROM size, choosing a different architecture, or making proprietary extensions (at which point you could have multiple vendors with incompatible extensions doing the same thing) - all of which are bad alternatives.

brucehoult4• 4 years ago

Note that these extensions are primarily aimed at tiny embedded systems with code in ROM and no caches, so instruction fetch competing with data load/store is an issue. That was the major justification for load/store multiple in the 1985 ARM ISA, but it's been dropped or deprecated in recent ARM -A ISAs.

Byte and half load/store are also a lot more common in embedded software than in applications processors (especially as they are often handled by SIMD/Vector in larger CPUs)

Note that the B extension already added instructions such as manipulating single bits in registers (Zbs); clz, cpop, byte reverse, rotates (Zbb); and shift-and-add (Zba)

The Zcmp and Zcmt extensions are NOT intended to be added to large applications processors running standard OSes such as Linux or Android.

This is about competing with 8051, AVR, PIC, MSP430, ARMv6-M, ARMv7-M at the lowest end.

wyldfire2• 4 years ago

1985 ARM ISA, but it's been dropped or deprecated in recent ARM -A ISAs

I guess the idea is to recover the opcode space? Or recover the area used to implement it?

Seems like deprecating instructions for an ISA doesn't really have any effect other than giving you more notice for the eventual removal. Unless you sit down and read the new PRM you'd probably never know.

phire• 4 years ago

ARMv8-A (aka 64bit ARM) is a completely different instruction set, with basically zero relation to the instruction encoding of 32bit ARM. They redesigned it from scratch.

And it's an instruction set designed for high-performance application cores (hence the -A) like what you would find as the main processor of a mobile phone, or a laptop or even a server. So they don't want anything optimised for lower-end designs. Plenty of other useful things to do with the encoding space.

For those low-end designs, ARM have a second ISA called ARMv8-M. Which is basically just the old thumb mode of 32bit arm with a few improvements.

The original 32bit arm ISA is basically dead these days (at least for new designs). You can still run some ARMv8-A chips in 32bit ARM mode, for compatibility. But that's actually optional in regards to the spec. Some only support running usermode 32bit ARM code. In the near future, we will see some cores that don't support 32bit arm code at all.

Dylan16807• 4 years ago

I feel like "NOT intended" is even understating it, so I'll quote your other post:

"Code using Zcmp or Zcmt is incompatible with the RV64GC ISA assumed by current Linux etc OSes as it redefines and reuses the 16 bit opcodes for double precision floating point load and store. Full-size instructions must be used instead."

I'm amused that the instructions that get the best compression by far, multi-register push/pop, are also the instructions that are too much of a pain to bother with on large cores.

sylware2• 4 years ago

It seems risc-v is missing the "small and big", "hardware accelerated", equilavent of x86 "rep stosX" and "rep movsX". Basically hardware memcpys and memsets. Heard latest arm ISA has them.

risc-v implementors/experts out there: is this true?

childintime• 4 years ago

not an expert, but it seems to me the vector extension should be able to do this.

sylware2• 4 years ago

Like on ARM with neon and x86 with avx, but even on those, they got direct hardware acceleration without neon/avx of memcpys and memsets (big and small).

RISC-V Public review for standard extensions Zc

Related Stories