From: Hans-Peter Nilsson <hp@bitrange.com>
To: LIU Hao <lh_mouse@126.com>
Cc: Jan Beulich <jbeulich@suse.com>,
binutils@sourceware.org, GCC Development <gcc@gcc.gnu.org>
Subject: Re: RFC: Formalization of the Intel assembly syntax (PR53929)
Date: Mon, 29 Jan 2024 23:22:54 -0500 (EST) [thread overview]
Message-ID: <alpine.BSF.2.20.16.2401292307170.2620@arjuna.pair.com> (raw)
In-Reply-To: <40ae7cb2-c094-4594-859d-470e7a7fce49@126.com>
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
next prev parent reply other threads:[~2024-01-30 4:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 5:34 LIU Hao
2024-01-18 9:02 ` Fangrui Song
2024-01-18 12:54 ` Jan Beulich
2024-01-18 16:40 ` LIU Hao
2024-01-19 9:13 ` Jan Beulich
2024-01-20 12:40 ` LIU Hao
2024-01-22 8:39 ` Jan Beulich
2024-01-23 1:27 ` LIU Hao
2024-01-23 8:38 ` Jan Beulich
2024-01-23 9:00 ` LIU Hao
2024-01-23 9:03 ` Jan Beulich
2024-01-23 9:21 ` LIU Hao
2024-01-23 9:37 ` Jan Beulich
2024-01-30 4:22 ` Hans-Peter Nilsson [this message]
2024-01-31 10:11 ` LIU Hao
[not found] ` <DS7PR12MB5765DBF9500DE323DB4A8E29CB712@DS7PR12MB5765.namprd12.prod.outlook.com>
2024-01-19 1:42 ` LIU Hao
2024-01-19 7:41 ` Jan Beulich
2024-01-19 8:19 ` Fangrui Song
[not found] ` <DS7PR12MB5765654642BE3AD4C7F54E05CB702@DS7PR12MB5765.namprd12.prod.outlook.com>
2024-01-20 12:32 ` LIU Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.BSF.2.20.16.2401292307170.2620@arjuna.pair.com \
--to=hp@bitrange.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=jbeulich@suse.com \
--cc=lh_mouse@126.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).