Meh... utf-8 validation hardware accelerated with _crypto hardware extension_.
We can expect this extension on public servers where the utf-8 validation would be kind of very useful to have in the various 'hardening' of input data from the unsafe internet stage.
What's important is not to fall in the 'using all extensions' extreme... actually it is important to go the other way to maximize code reuse:
While writting rv64 assembly, I am still carefull at using as few as possible extensions, and I push the envelop to the compressed instructions and the assembler "official" pseudo-instructions (yes, I manually load my constants in a way which depends on the hardware context).
Since I am interpreting rv64 instructions on x64(x86_64) (on linux), unfortunately I use the ZACAS extension as a base for the synchronization operations (risc-v atomic operation are too alien to x64). I am carefull at using a preprocessor (I use a basic C preprocessor) holder to be able to switch those synchronization operations to the native atomic operations if needed.
And by doing so, you're sabotaging hardware's efforts, preventing optimizations in the decoder (including but not limited to fusion) that rely on these official pseudo-instructions.
Also note these pseudo-instructions are defined by RISC-V, no the assembler software. They are also emitted by any sane compiler.
You are plain wrong: those pseudo instructions are few and when written "manually", most of the time, you end up with the same machine code.
The main difference is you don't require a 'mini-compiler' for those pseudo-instructions in the assembler, and I will take that.
And it is certain that compilers emmiting those pseudo-instructions are not "sane", actually it is the other way around (I guess the largest compilers will have a switch anyway).
About RISC-V implementation hardware accelerating some machine code patterns, well this expected to be documented properly by any "sane" RISC-V implementation...
5 comments
[ 3.2 ms ] story [ 27.5 ms ] threadWe can expect this extension on public servers where the utf-8 validation would be kind of very useful to have in the various 'hardening' of input data from the unsafe internet stage.
What's important is not to fall in the 'using all extensions' extreme... actually it is important to go the other way to maximize code reuse:
While writting rv64 assembly, I am still carefull at using as few as possible extensions, and I push the envelop to the compressed instructions and the assembler "official" pseudo-instructions (yes, I manually load my constants in a way which depends on the hardware context).
Since I am interpreting rv64 instructions on x64(x86_64) (on linux), unfortunately I use the ZACAS extension as a base for the synchronization operations (risc-v atomic operation are too alien to x64). I am carefull at using a preprocessor (I use a basic C preprocessor) holder to be able to switch those synchronization operations to the native atomic operations if needed.
And by doing so, you're sabotaging hardware's efforts, preventing optimizations in the decoder (including but not limited to fusion) that rely on these official pseudo-instructions.
Also note these pseudo-instructions are defined by RISC-V, no the assembler software. They are also emitted by any sane compiler.
The main difference is you don't require a 'mini-compiler' for those pseudo-instructions in the assembler, and I will take that.
And it is certain that compilers emmiting those pseudo-instructions are not "sane", actually it is the other way around (I guess the largest compilers will have a switch anyway).
About RISC-V implementation hardware accelerating some machine code patterns, well this expected to be documented properly by any "sane" RISC-V implementation...
?!
Best to think about it as a macro you don't need to write or include.
Because what's the point of avoiding the complexity of a compiler if I get it from the preprocessor...