[PATCH] arm: drop stray newlines

[Richard Earnshaw (lists)]

On 30/04/2025 15:00, Jan Beulich wrote:
> On 30.04.2025 15:46, Richard Earnshaw (lists) wrote:
>> On 30/04/2025 14:33, Jan Beulich wrote:
>>> Both as_bad() and as_warn() already emit a newline; having extra ones
>>> leads to somewhat distorted diagnostics.
>>> ---
>>> The context I noticed this in was an attempt to use ".arch all". Is
>>> there a reason -march= accepts "all", but .arch doesn't? 
>>
>> This is... complicated.
>>
>> Once upon a time the arm architecture was a simple chain of extensions to a previous architecture.  Then the architecture introduced thumb-only processors which didn't have A32 instructions at all, then 'profiles' were added; and then it introduced a feature-based approach so that there is no-longer a linear architecture chain.  Now there are extensions that only exist on specific profiles so there really is no concept of a linear chain at all.
> 
> Are there conflicting extensions, though? If not, the concept of "all" would
> still make sense.

It depends what you mean by conflicting.  Neon and MVE interpret some opcodes very differently, though they do share some others.  I don't think there are any mnemonics where the opcode translation needs to change between architectures, but please don't quote me on that :) 

On early Arm chips there was no NOP instruction, the assembler supported it as an alias for MOV r0, r0.  But then Thumb came along and there was no MOV r0, r0 in that ISA, so in Thumb it generated MOV r8, r8.  And finally, a real NOP was added to the architecture (around Armv7, IIRC), and NOP in the assembler was expected to assemble to that, rather than the legacy operation.  I guess in a way that is a conflicting change, but the legacy NOP will still execute correctly, just not as efficiently as a pure NOP on some implementations, since it really will execute the instruction rather than eliding it in the pipeline.

> 
>> -march=all, which is, essentially, the default if you don't specify anything else on the command line means try to work it out by analysing the contents of the file you're reading.  It's very hit-and-miss these days though and it may not guess correctly in some cases.
> 
> Good to know that one better wouldn't use this then.
> 
>> I don't think it makes much sense to support this in .arch.  If it's written in the file, then the file really should know which ISA variant it is targetting.
> 
> Even if it's, say, part of a generic (source) library?

Possibly, for example, binary code that runs on cortex-m0 is 100% incompatible with code that could run on an Arm6 (though the latter is essentially obsolete now) as cortex-m0 only supports the Thumb1 ISA, while Arm6 only support the A32 original Arm ISA.

It is mostly possible to write assembly instructions that could be assembled as either thumb1 or as Arm, but then you need to tell the assembler, somehow, which to do.  It can't just guess; well, it would default to generating A32 (arm) code.

> 
>>> Then again
>>> "all" isn't even documented as valid for -march= ... Yet the same is
>>> true for -mcpu= vs .cpu.
>>
>> I don't think it would be a good idea to document it either, for the reasons given above.  Whilst it might work much of the time there's no guarantee, given the evolution of the architecture, that it will continue to do so even for code that assembles OK today.
> 
> Well, what should I say ...

I would just add a comment in the code to explain (briefly) that *all* is deprecated, so not documented.  We will do our best to support it while we still can, but it may disappear some day.

> 
>> The patch is OK.
> 
> Thanks.
> 
> Jan