Re: invalid 'asm': invalid operand for code 'H'

["Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>]

On 09/07/18 11:49, Jeffrey Walton wrote:
> On Mon, Jul 9, 2018 at 5:51 AM, Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>> On 09/07/18 10:37, Richard Earnshaw (lists) wrote:
>>> On 08/07/18 06:03, Jeffrey Walton wrote:
>>>> ...
>>>> The guide says this about the modifiers:
>>>>
>>>> L - The lowest-numbered register of a register pair, or the low 16
>>>> bits of an immediate constant.
>>>> H - The highest-numbered register of a register pair, or the high 16
>>>> bits of an immediate constant
>>>> ....
>>>>
>>>> Is this an ARM extension not present in GCC? Or am I doing something wrong?
>>>>
>>> The L and H modifiers are for dealing with 64-bit /register/ quantities
>>> where you need two registers to hold the entire value.  Your example
>>> only has a single 32-bit value.  You don't need qualifiers in this case.
>>>  For an immediate like this, you'll have to hand-code the reduction into
>>> the appropriate fields, either in the operands you pass to the ASM or
>>> within the ASM expansion itself.  Something like:
>>>
>>> asm volatile ("movw %0, %1;movt %0, %2": "=r"(a) : "i"(imm & 0xffff),
>>> "i" (imm & 0xffff0000));
>>>
>> Correction.  Looking at the source code, the L modifier only appears to
>> apply to 32-bit integer immediate values, the H modifier only appears to
>> apply  to 64-bit registers.
>>
>> So the guide is wrong for both cases, but in different ways.  At least
>> when it comes to GCC.
>>
>> Which document are you referring to?
> 
> Thanks Richard.
> 
> The guide I was using is
> http://www.iarsys.co.jp/download/LMS2/arm/7304/ewarm7304doc/arm/doc/EWARM_DevelopmentGuide.ENU.pdf
> (p.147).
> 
> Jeff
> 

There are a number of modifiers (and constraints) in GCC that we
deliberately don't document.  Generally that's because we don't believe
they really serve a useful purpose for folk writing inline assembly
language.  If we documented them then we would create a 'forever'
contract with users for very little real gain.  By keeping them
undocumented we preserve the right to change the implementation or
definition if circumstances require that.

I suspect that's the real reason these are treated as hidden values.
Unfortunately, GCC does not really provide a useful distinction between
uses that are internal and uses that are in inline assembly.

R.