From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id kHPZE0xLD2DefgAA0tVLHw (envelope-from ) for ; Mon, 25 Jan 2021 22:50:52 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id uL2sD0xLD2B1MQAAbx9fmQ (envelope-from ) for ; Mon, 25 Jan 2021 22:50:52 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A613F940251 for ; Mon, 25 Jan 2021 22:50:51 +0000 (UTC) Received: from localhost ([::1]:51900 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l4Ah8-0007TE-FU for larch@yhetil.org; Mon, 25 Jan 2021 17:50:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l4Adz-0005ff-W2 for guix-devel@gnu.org; Mon, 25 Jan 2021 17:47:36 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:48012) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l4Adw-0004DS-TW; Mon, 25 Jan 2021 17:47:35 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id C23EF3367C25; Mon, 25 Jan 2021 23:47:27 +0100 (CET) Date: Mon, 25 Jan 2021 23:47:23 +0100 From: Danny Milosavljevic To: Paul Sherwood Subject: ARM Unified Assembly Language - GNU as does some weird stuff Message-ID: <20210125234723.319ba85a@scratchpost.org> In-Reply-To: <20210107211058.40e0813a@scratchpost.org> References: <87im8cvdpa.fsf@gnu.org> <36b3777d90af6fa2e1c1778ba183111e@codethink.co.uk> <87lfd5rpr8.fsf@gnu.org> <20210107211058.40e0813a@scratchpost.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/sbxvVrbDx6Fbj0nu/UIbvvx"; protocol="application/pgp-signature"; micalg=pgp-sha512 Received-SPF: none client-ip=85.13.145.193; envelope-from=dannym@scratchpost.org; helo=dd26836.kasserver.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, bootstrappable@freelists.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -4.45 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: A613F940251 X-Spam-Score: -4.45 X-Migadu-Scanner: scn0.migadu.com X-TUID: 1XrcyIqFad3q --Sig_/sbxvVrbDx6Fbj0nu/UIbvvx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello Paul, we are now implementing ARM inline assembly in TinyCC. The traditional ARM inline assembler is finished now. Now we started implementing the Unified Assembly Language dialect. I'd like to have some help which constructs are valid and which are not. (GNU as 2.34 seems to have some bugs with Unified Assembly Language--so I guess we shouldn't use "do what GNU as does" as a yardstick here) The questionable--maybe invalid--constructs follow (the "#" are for clarity= ): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D (1) b #60 It seems that GNU as ignores the immediate entirely and just always encodes #0 (to test, do ".syntax unified" and then "b #60" in GNU as). WTF? Likewise with bl, blx. It seems that the debug info still has the user-specified immediate value--= but the executable object file does not. So in order to test you should strip = the resulting file--otherwise you are gonna be very confused. No error or warning messages are printed by GNU as here. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D (2) push #4 It works in GNU as--but is it specified by ARM to push the register r2 ? I think exposing ISA implementation details like that is a leaky abstractio= n--and no good can come from it. Likewise with pop, stm*, ldm*. No error or warning messages are printed by GNU as here. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D (3) and r3, r4, LSL #5 This doesn't work in unified mode--but does work in non-unified mode. Note that "and r3, r3, r4, LSL #5" always works--both in unified mode and in non-unified mode. I would have thought the LSL token would be a dead giveaway for disambiguat= ing what to do here--but apparently GNU as thinks otherwise. Likewise with ands, eor, eors, sub, subs, sbc, sbcs, rsc, rscs, rsb, rsbs, orr, orrs, bic, bics, cmp, cmns, mov, movs, mvn, mvns (all arithmetic instructions), and with other modifiers (LSR, ASR, ROR, RRX). GNU as fails to assemble these. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D (4) lsl r1, #4, #2 GNU as encodes exactly the same as "lsl r1, #4"--drops the "#2" silently. Likewise with lsr, lsrs, asr, asrs, orr, rors. No error or warning messages are printed by GNU as here. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D (5) vmov.f32 r2, r3, d1 f32 and two 32 bit ARM registers, and one 64 bit VFP register? What does t= his do?! Likewise with "vmov.f32 d1, r2, r3". No error or warning messages are printed by GNU as here. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Which of those are good (and should thus be implemented in the same way) and which of those are bad (and should thus not be implemented the same way)? --Sig_/sbxvVrbDx6Fbj0nu/UIbvvx Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAmAPSnsACgkQ5xo1VCww uqVI+gf+JH6n8xecIJrsvhnvCypjneWm1mUhBXLNfH4rS0Yfz+Uci2PtR8OyH6a+ Ww3VFrpMA12UEgyB9bCmWkf7oN1t/Kd4Pd0YQoubjq5uCM5aAv1vl1VEDg1yXdQv PnO59hf6twV5aJDwCRBOA+VzVLmspnOmAsJX1oaftMQXIiwckP45WmwM7hefb3RF qRsru7fQh0UFQw/6p//IExOieKG+rx93tl5fjenIX4KHzaRzvcISfg6d0rhg8W+L ztSdk8wHt45jUCViE2N8eeLvqJyd6zn1UM4LXlp3k0izKJUg9nNcHd3w/dNxhhHP teCRWceBa+8FbUQww3+bRqvFEOWoGQ== =Dk6y -----END PGP SIGNATURE----- --Sig_/sbxvVrbDx6Fbj0nu/UIbvvx--