3 ms·
>and the assembler "official" pseudo-instructions And by doing so, you're sabotaging hardware's efforts, preventing optimizations in the decoder (including but
by snvzz 2y ago
>and the assembler "official" pseudo-instructions
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.
- sylware 2y agoYou 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...
- snvzz 2y ago>mini-compiler ?! Best to think about it as a macro you don't need to write or include.
- sylware 2y agoConstant loading would require a way too powerful macro preprocessor. I am using the basic core of a C preprocessor only. Because what's the point of avoiding the complexity of a compiler if I get it from the preprocessor...