[PATCH v2 00/65] gas: whitespace handling

[Hans-Peter Nilsson]

> Date: Tue, 28 Jan 2025 08:40:02 +0100
> From: Jan Beulich <jbeulich@suse.com>

> On 28.01.2025 03:50, Hans-Peter Nilsson wrote:
> As per your comment on the cris-specific patch I can't help the
> impression that gcc avoiding to emit TABs for this target isn't
> "happenstance" as you called it, but simply attributed to gas'es past
> behavior.

No, it's deliberate.  IMHO \\t (the literally characters)
makes for less readable code in the .md, and a literal TAB
looks indention-wise weird (not sure if it was always valid.
Compare "adcs%?\\t%0, %1, #0" to "adcs%? %0,%1,#0" (random
example from arm.md).  In the generated code, I guess it
depends on your preference; whether columns lining up is
better than the slightly extra horizontal distance.

> > Does that work also clean up gcc-generated code, like
> > dropping space after comma or multiple spaces or whatever is
> > judged the #NO_APP behavior of "x86 assembly"?  I don't see
> > such patches but maybe they're not posted yet.  It doesn't
> > just happen to be specified as what gcc generates on the
> > master branch of today?
> 
> Well, what gcc presently emits needs to be accepted anyway. A goal is
> specifically to get -f / #NO_APP working without needing to touch target
> specific code in gcc, whenever possible.

...and putting the burden on the assembler to do the
post-scrubber processing in your patches.  IOW, while it's
nice if more targets can skip the scrubbing (and joining
#NO_APP actually being in effect), it's more processing once
that state is entered.

> And btw - why would you apply different criteria to cris and x86? For
> cris you said what gcc emits is unwritten but de-fact standard. Yet then
> you question that same pre-condition to be applied to x86?

Different criterias for "tier-1" versus "tier-N", (N > 2)
targets isn't exactly a new concept.

> > I can't help but thinking this is going ever so slightly in
> > the wrong direction with regards to #NO_APP: this change-set
> > is making that mode more lenient towards formatting;
> > allowing more types of space characters.  With the few
> > targets that have #NO_APP active in gcc-generated code, you
> > have the chance of making that mode more strict.
> 
> Have you ever wondered why it is only so few targets?

Only once.  Then I looked and found out, some 30+ years ago. :)

> Permitting TABs
> in compiler generated output is, as indicated in the reply to the
> cris-specific patch, a readability aid.

To that I'll just say: "\\t"! :-)

I'll admit that's the gcc "input" - but which you seem to
overlook in your readability argumentation!  And with that,
I see the discussion derails...

> That's certainly a personal
> view, but one I happen to know is shared by many other people. That
> said, I'm also aware that for various targets gcc presently avoids to
> make use of TABs. Of the architectures I'm half-way familiar with it's
> actually a minority, though (PPC and ia64 vs aarch64, Arm, RISC-V, and
> x86).

...with this "argumentum ad populum".  Let's please drop the
TAB vs space part of the discussion and "agree to disagree".

brgds, H-P