More clarification on TLS pseudo instructions

[kito-cheng]

Review comment come from @anderslindgren-iar and Anders Berg(IAR) https://lists.riscv.org/g/tech-toolchain-runtime/message/344

Example assembler load and store of a thread local variable i using the la.tls.ie pseudoinstruction, with the emitted TLS relocations in comments:
...
la.tls.ie a5,i
...

Example assembler load and store of a thread local variable i using the la.tls.gd pseudoinstruction, with the emitted TLS relocations in comments:
...
la.tls.gd a0,i
...

Anders: Reference to its definition/description please!

[jrtc27]

Immediately below each we give the expansion of the instruction, and the references contains the "RISC-V Assembly Programmer’s Manual". I don't get what's missing.

[kito-cheng]

@anderslindgren-iar did you mind give few more word to explain the issue?

[anderslindgren-iar]

Hi! Absolutely, I can explain the background to the issue. I've spent the last four years developing the IAR RISC-V tools. During this time I have often found the reference manuals lacking a lot of information. Simple things like the syntax of instructions are missing from the specification. When it comes to pseudo-instructions, things are even worse. I have several times realized that tools like GCC use undocumented pseudoinstructions, or use standard instructions as pseudo-instructions (such as "add a0, a0, 99"). Without a proper specification it's hard to know what an instructions is supposed to do, and it's even harder to know if we have support for all pseudo-instructions, as new ones tend to pop up in unexpected contexts. In this case, the PS-ABI documentation presents pseudo-instructions like "la.tls.ie" briefly. It doesn't say anything about the purpose, what arguments they support, or in what context they are supposed to work. (From the name, I can guess that "la" means "load address", "tls" is "thread local storage", but it's unclear what "ie" stands for.) Jessica Clarke said that these pseudo-instructions are defined in the "RISC-V Assembly Programmer’s Manual". However, I just checked https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md and they are not mentioned. Of course, I could be looking in the wrong place. If so, please send me a link to where they are properly defined. What I'm really saying that we need a reference manual where all instructions and all pseudo-instructions are properly defined, written from the point of view of a programmer (as opposed to the point of view of the hardware, which is the case of the unpriv. spec used today). Every processor I've worked with over the past 25 years (and this a quite a few) have such manuals, except RISC-V. Furthermore, the manual makes assumptions that GCC or GCC-like tools are used, by specifying GCC-style compiler flags and GCC-style attributes. It is unclear if they are mandatory or if they are presented as an example. Although GCC and Clang are universally used the Unix-like work, it doesn't have that strong position in the embedded industry, which I suppose that the RISC-V world would like to be a part of in the future. Traditionally, there has been a lot more embedded tools, each with their own set of features and command-line conventions -- by writing the specifications so that GCC conventions are mandatory puts up unnecessary obstacles. Hence this is not about whether or not IAR has support for a specific syntax feature -- it's about making it easier for other tools to come onboard in the future, and whether or not RISC-V will make it in the embedded world.     -- Anders Lindgren, Lead engineer for the RISC-V compiler, IAR Systems Den 2022-04-25 kl. 10:01, skrev Kito Cheng:

…

@anderslindgren-iar <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fanderslindgren-iar&data=05%7C01%7Canders.lindgren%40iar.com%7C62547fa43fe84145aeca08da2691e1bb%7C752d689536a34853a00fc9efc645753e%7C1%7C0%7C637864705259743265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1PJJnqiFjU7wfWBqH5QB3ZXl6YhStNvxTlRYl7Ayprg%3D&reserved=0> did you mind give few more word to explain the issue?

[kito-cheng]

I think it's boarder issue than psABI spec, move to post 1.0, e definitely need to improve the asm manual, hopeful we can have resource to improve that in future.