RFC: Formalization of the Intel assembly syntax (PR53929)

[Hans-Peter Nilsson]

On Fri, 19 Jan 2024, LIU Hao wrote:

> ? 2024-01-18 20:54, Jan Beulich ??:
> > I'm sorry, but most of your proposal may even be considered for being
> > acceptable only if you would gain buy-off from the MASM guys. Anything
> > MASM treats as valid ought to be permitted by gas as well (within the
> > scope of certain divergence that cannot be changed in gas without
> > risking to break people's code). It could probably be considered to
> > introduce a "strict" mode of Intel syntax, following some / most of
> > what you propose; making this the default cannot be an option.
> 
> Thanks for your reply.
> 
> I have attached the Markdown source for that page, modified a few hours ago. I
> am planning to make some updates according to your advice tomorrow.
> 
> And yes, I am proposing a 'strict' mode, however not for humans, only for
> compilers.
> 
> My first message references a GCC bug report, where the problematic symbol
> `bx` comes from C source. I have been aware of the `/APP` and `/NO_APP`

It's #APP #NO_APP, not /APP /NO_APP, for x86_64-linux, even for 
-masm=intel.

> markers in generated assembly, so I suspect that GAS should be able to tell
> which parts are generated from a compiler and which parts are composed by
> hand.

Since a very long time, none but a very few gcc targets (not 
including i686/x64_64-linux) emit the initial #NO_APP, which 
have to be the very first characters of the generated assembly 
file, without which subsequent #APP/#NO_APP pairs are just for 
show.

That said, I guess you're going to modify gas too.  But please 
don't change the #APP/#NO_APP semantics for non-intel targets.

brgds, H-P