From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from arjuna.pair.com (arjuna.pair.com [209.68.5.131]) by sourceware.org (Postfix) with ESMTPS id DF96B3858C60 for ; Tue, 30 Jan 2024 04:22:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DF96B3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitrange.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bitrange.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DF96B3858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.68.5.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706588580; cv=none; b=Gkl5NDhVxB3Vn8wmWq5u4UT/9v/sT9DbIRa80j0YvXWtknc2/KCmVIZlZRjzeIrbl9sap7Xh/Ja3uFF80v/yv0ZaQjV7X81GeTarMz04ohoTiEIInjZl+dnlAZV9RgK2+Es3rqxRFWm67N/2LBLk4XqjfUstFKp1kaBs4kLACSw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706588580; c=relaxed/simple; bh=f5MFUFgsvwxMMxcR6T+Xtu4ZnxqdqBf/bpIxqobuOg4=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=rP88Hh6GzrmZsxDR+eLToci045w1QYMZfr32EFq319j1psAFvW5e3a1p0Tbpg1N2n8f+BNHLRzgKHv8nhX+8VL/Zw7iJFTcNZ+LuZXDaIr7pXeXcn1KIsfX11PadHI3dknqnetINFMFxKRwTkety8zDNXOPtxi8FBGNEnXCC1OE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by arjuna.pair.com (Postfix, from userid 3006) id 90B068A649; Mon, 29 Jan 2024 23:22:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id 9012C8A639; Mon, 29 Jan 2024 23:22:54 -0500 (EST) Date: Mon, 29 Jan 2024 23:22:54 -0500 (EST) From: Hans-Peter Nilsson X-X-Sender: hp@arjuna.pair.com To: LIU Hao cc: Jan Beulich , binutils@sourceware.org, GCC Development Subject: Re: RFC: Formalization of the Intel assembly syntax (PR53929) In-Reply-To: <40ae7cb2-c094-4594-859d-470e7a7fce49@126.com> Message-ID: References: <95e373fb-24f3-4b10-9ad1-948597ed9d67@suse.com> <40ae7cb2-c094-4594-859d-470e7a7fce49@126.com> User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: mailmunge 3.11 on 209.68.5.131 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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