style question: breaking inline assembly lines

Gedare Bloom gedare at rtems.org
Mon Jun 12 21:50:33 UTC 2023


On Mon, Jun 12, 2023 at 2:28 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Mon, Jun 12, 2023 at 3:10 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> We have a mix of ways to write inline assembly. It would be convenient
>> to choose one way. The prevailing options are based on breaking around
>> the colons (reg/field separators), either to break at colons if the
>> line length > 80, or to always break at colons.
>>
>> I personally find it is easier to read inline assembly that has broken
>> at the colons. But we have these options:
>> 1. Always break at the colon
>> 2. Only break when the line length is exceeded
>
>
> I lean to (1).
>>
>>
>> With #2, we also can break as usual, or we can force breaks at the
>> colons. I have seen examples of both in the source tree. Any strong
>> opinions one way or another?
>
>
> There may also be cases of multiple assembly instructions on the
> same line or split across multiple with line continuation. I don't know
> of one offhand though.
A complicated example of that would be
https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/armv7m-exception-default.c#n60

>>
>>
>> here's a line broken because of line lengths, that has not split the
>> arguments at the colons:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/aarch32-system-registers.h#n69
>>
>> Here's a line broken because of line lengths:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/arm/include/rtems/score/cpu.h#n501
>>
>> Here's a line broken always:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/aarch64/cpu.c#n153
>>
>> And for good measure, here's an unbroken line that should be broken:
>> https://git.rtems.org/rtems/tree/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h#n206
>>
>> With the newest version of clang-format we will be able to accommodate
>> always breaking the lines. It currently is inconsistent with whether
>> it puts the first argument on its own line, or keeps it with the
>> "__asm__ volatile (" that I could probably make consistent if we
>> decide we need it to be.
>>
>> Gedare
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel


More information about the devel mailing list