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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/07/18 11:49, Jeffrey Walton wrote:
> On Mon, Jul 9, 2018 at 5:51 AM, Richard Earnshaw (lists)
> <Richard.Earnshaw@xxxxxxx> 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.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux