On 06/25/2018 02:45 PM, Nathan Sidwell wrote:
> On 06/25/2018 08:25 AM, Tom de Vries wrote:
>
>> If we'd implemented something like this in gas:
>> ...
>> .insn
>> .byte 0x66
>> .endinsn
>> ...
>> we could fix this more generically.
>
> Doesn't arm gas provide this functionality with some target-specific
> pseudo? It'd be good to copy that.
>
> ah, inst:
>
> @cindex @code{.inst} directive, ARM
> @item .inst @var{opcode} [ , @dots{} ]
> @itemx .inst.n @var{opcode} [ , @dots{} ]
> @itemx .inst.w @var{opcode} [ , @dots{} ]
> Generates the instruction corresponding to the numerical value
> @var{opcode}.
> @code{.inst.n} and @code{.inst.w} allow the Thumb instruction size to be
> specified explicitly, overriding the normal encoding rules.
>
>
> (ARM needs to distinguish data from insns to emit the mapping symbols
> needed for be8 endianness xforms).
>
Hmm, thanks for pointing that out. There's also something similar for
s390 and riscv.
For mips there's another form of .insn (
https://sourceware.org/binutils/docs/as/MIPS-insn.html#index-_002einsn
), which is similar to what I was proposing:
...
9.27.8 Directive to mark data as an instruction
The .insn directive tells as that the following data is actually
instructions. This makes a difference in MIPS 16 and microMIPS modes:
when loading the address of a label which precedes instructions, as
automatically adds 1 to the value, so that jumping to the loaded address
will do the right thing.
...
Thanks,
- Tom
