Proposal for a common convention for synonyms for register ABI names in hand-coded assembler about riscv-asm-manual HOT 8 CLOSED

Thanks for moving your proposal to this repo.

I'd like to echo the comments Paul (riscv/riscv-isa-manual#825 (comment)) and Nick (riscv/riscv-isa-manual#825 (comment)) made.

FWIW, I'm in the camp that the C preprocessor already satisfies this need--elegantly, at that.

from riscv-asm-manual.

The #define solution leaves anybody without a C-based system out in the cold -- see https://github.com/TheThirdOne/rars for instance. Shouldn't RISC-V be independent of C, at least in the long term?

from riscv-asm-manual.

I'm sympathetic to that concern, but in no way is reliance on the C preprocessor reliance on the C language. No one's being left out in the cold (unless they're rejecting use of the C preprocessor for anti-pragmatic reasons).

from riscv-asm-manual.

Okay. How about I create a pull request that states the problem and points to C preprocessor as a software-supported solution in a general way, mentions the above naming scheme as a poor substitute if that is not possible, and then somebody who has more experience with (and appreciation for) the C preprocessor adds some examples and hints for best practices?

from riscv-asm-manual.

Makes sense to me.

from riscv-asm-manual.

@nick-knight Sorry, you had mentioned in another comment that you use the preprocessor method extensively in your code. Might you have any recommendations or even some sort of a style guide based on your experience, or a recommendation of what not to do? Thank you!

from riscv-asm-manual.

I assume most developers that write assembly code use .S files (assembly code that is preprocessed by a C preprocessor). For example glibc and Linux use this approach. But some projects also have their own solutions (OpenSSL uses Perl to generate assembly code). I'm convinced that a RISC-V assembler (as defined by this repository) should not aim to provide equivalent solutions. Instead, I prefer standardizing only a minimal set of RISC-V-specific assembly directives (those which are necessary). Otherwise, we introduce a long list of required features for a RISC-V assembler (include directives, binary includes, conditional compilation, etc.) that nobody wants to implement or use, and that are already available by existing mechanisms.

Also note, that a project like rars could use a stand-alone C pre-processor to be compatible with code form .S files (I recently stumbled over a project that depends on mcpp for a similar purpose).

That all does not mean, that feature-rich assemblers can come up with their own solutions. E.g. GAS supports include directives and conditional compilation. In fact GAS' ARM/AArch64 backends also support register aliases using the .req directive:

.globl return_zero
retval .req w0
return_zero:
        mov     retval, 0
        ret

One last hint: Both, .equ and .eqv, already have defined semantics in GAS. So I would expect objections when trying to implement a support patch for GAS that uses these directives.

from riscv-asm-manual.

Obviously this is a solution that nobody seems to see a problem for. I'm going to close this issue, and if it comes up again in a few years we'll know where to find it. Thank you everybody for your feedback!

from riscv-asm-manual.