style question: breaking inline assembly lines

[Joel Sherrill]

On Mon, Jun 12, 2023 at 4:50 PM Gedare Bloom <gedare at rtems.org> wrote:

> 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
>
>
Yikes! Does that look ok after clang-format processes it?


> >>
> >>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230612/70258f85/attachment-0001.htm>