From: LIU Hao <lh_mouse@126.com>
To: binutils@sourceware.org, GCC Development <gcc@gcc.gnu.org>
Subject: RFC: Formalization of the Intel assembly syntax (PR53929)
Date: Thu, 18 Jan 2024 13:34:09 +0800 [thread overview]
Message-ID: <d3cb6174-caa6-47f3-9b5e-d39222701458@126.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1543 bytes --]
Hello,
There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a dozen years ago, mostly
due to compatibility with MASM. I was told that the ambiguity of Intel syntax should be classified
as its own limitation and disrecommendation.
Notwithstanding, I am proposing a permanent solution to this issue, by banning constructions that
cause ambiguity. This is likely to effect incompatibility with other assemblers, but it should make
GAS parse the output of GCC flawlessly.
PR53929 contains a known ambiguous construction
lea rax, bx[rip]
where `bx` could denote the BX register and causes confusion. The Intel Software Developer Manual
also contains an ambiguous construction
MOV EBX, RAM_START
which would look like loading the offset of `RAM_START`. My proposal is that these two constructions
are ambiguous and should be rejected. The compiler should generate assembly in the unambiguous
subset, and we can start to implement the assembler to reject the ambiguous ones.
Their are formalized as
lea rax, BYTE PTR bx[rip]
mov EBX, DWORD PTR RAM_START
Roughly speaking, anything after `PTR`/`BCST` (and before `[` if any) is considered a symbol even if
it matches a keyword; any identifier between `[` and `]` is a register and not a symbol.
My complete proposal can be found at
<https://github.com/lhmouse/mcfgthread/wiki/Formalized-Intel-Syntax-for-x86>. Some ideas actually
reflect the AT&T syntax. I hope it helps.
--
Best regards,
LIU Hao
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next reply other threads:[~2024-01-18 5:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 5:34 LIU Hao [this message]
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
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=d3cb6174-caa6-47f3-9b5e-d39222701458@126.com \
--to=lh_mouse@126.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
/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).