Where are operand strings used in GCC/Binutils instruction descriptions defined?
Closed this issue · 8 comments
Where are the different operands like s and t being defined?
Can you expand on/clarify your query please?
Maybe with some examples?
If you mean s and t ABI registers then they are described in the ABI specs:
If you are referring to something else then please clarify what it is.
Hi thank you for the response. No i mean the operands like vd, r, t in the custom instructions in binutils/opcode/riscv-opc.c
This is what i meant by operands, here they are d,s and t.
I know this is where some operand constraints are added but i mean the address space itself ie what bit positions will each operand will occupy yet.
What im ultimately trying to do is add new operands into the toolchain myself
This should be covered in the relevant GCC internals documentation and isn't RISC-V or riscv-gnu-toolchain specific stuff:
This should be covered in the relevant GCC internals documentation and isn't RISC-V or
riscv-gnu-toolchainspecific stuff:
Sory - I'm not sure that all of these operand strings are actually explained in the GCC internals docs after all. I struggled to find an authoritative and exhaustive documentation covering all the ones that I can find in the RISC-V related GCC/Binutils opcodes files.
Some of them may be described here but not all the ones that I see in the RISC-V source files:
FWIW here's part of what ChatGPT told me about some of the ones that I found - the usual caveats apply to the trustworthiness of AI generated text!
Operand String Meanings
Here’s what some of these operand strings typically mean:
"d": Destination register. This is the register where the result of the instruction will be stored.
"s": Source register. This represents a register used as a source operand.
"t": Another source register, often the second one in an operation that takes two source registers.
"j": Jump target. Represents the target address for jump or branch instructions.
"o(s)": Offset with a base register. This refers to a memory address calculated by adding an offset o to the value in the base register s.
"Ca", "Cu", "Cv", "Co", "CV", "Cs", "Cw", "Ct": These represent different types of constants or immediate values. Each might correspond to specific ranges, sizes, or special handling rules for immediate values. The exact distinction among these depends on the specific context of the instruction and how the constant is encoded.
"Wif(s)": This implies conditional width or encoding based on the source register s. It typically indicates special encoding behavior, like using a wider field if a specific condition is met.
"Wcf": Indicates a conditional field width, potentially depending on a floating-point operation or condition.
"p": Typically refers to a predicate or condition code, often used in conditional instructions.
"Cz": Represents a specific kind of constant, possibly with special encoding or usage rules.
"I": Immediate value. This can be a general immediate operand that can take a wide range of values depending on the instruction.
"CL": Likely refers to a large constant or a specific class of immediate values with larger bit-width.
"Cc": Could refer to a constant value that is conditionally encoded or used in a specific context, such as a comparison.
"z": May represent a zero register or an operand that should be zero.
"CK": A special constant or immediate value, possibly one that fits within a specific narrow range or condition.
"B": Could represent a base register or another specific operand related to memory operations.
"A": Typically used for an address or an address register.
">": Used to signify a shift or a special operation involving multiple operands. It might be used in combination with other operands to indicate specific encoding behavior.
"Wcb(Cs)", "Wch(Cs)": These likely represent complex encodings where Cs is an operand that needs to be encoded with conditional width (Wcb might imply a conditional byte-width, Wch could imply a conditional half-word width).
Did that help at all @SimSim150?
Did that help at all @SimSim150?
It gave me some context. Thanks!
Im working on adding them on my own, if i succeed ill definitely post the steps here
Can the issue be closed since it's not really a riscv-gnu-toolchain issue but arguably an issue with the GCC/Binutils documentation? If that documentation needs improvement then the issue should be logged and tackled upstream:
Closing the issue.