Message ID | e4e4b80b-794c-7485-1997-685adab8fb27@suse.com |
---|---|
State | New, archived |
Headers |
Return-Path: <binutils-bounces+ouuuleilei=gmail.com@sourceware.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp474698wrs; Wed, 5 Oct 2022 00:24:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM71VKctB0M9Ci6KQKRePmbGkvTXEeZLR+9pNMxAtvxGZrcrmbo3YHbiIQRC7xipvzkb3Z/3 X-Received: by 2002:a05:6402:1911:b0:451:6e0b:7eee with SMTP id e17-20020a056402191100b004516e0b7eeemr27585859edz.170.1664954677171; Wed, 05 Oct 2022 00:24:37 -0700 (PDT) Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id l18-20020a056402255200b004573107a5basi2105226edb.352.2022.10.05.00.24.36 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 00:24:37 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=JaBH4G5F; arc=fail (signature failed); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 88BC4385803F for <ouuuleilei@gmail.com>; Wed, 5 Oct 2022 07:24:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88BC4385803F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1664954674; bh=PnY6+BAmSjTGR/zPEu1AWeS5Zx1lXZA/nSO76OlRM+k=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=JaBH4G5FdPAhPWEDSq2lwYYNXY5xhC+sQLByckYiABiPeg6DNZ0gn9ecqKwUAExOO +dhRZnjvTZaadGjfNXTk0KQ+KsJVcUawD+rB6ncIU0pob7bQuC7Xq0ZMyqnpEfV7rR Prmj6bYUKVnagG0tLM8rZFbNuGeIPwrj9JOHMRko= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2064.outbound.protection.outlook.com [40.107.22.64]) by sourceware.org (Postfix) with ESMTPS id A323538582BE for <binutils@sourceware.org>; Wed, 5 Oct 2022 07:24:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A323538582BE ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PwzM2X7deRE19w9bBJ0Q9BCQsJBrlvYwgC3hA5sDIwGTzEIF1zdzcFSYDK07Q6XwvBt9oOMQOviiW+9NmqkbtlkEHb/CEj74fS+++M6vCZNl1j7TY2Y56+5Kw+IpVkNXyL9g7N//ZLCcPaB/KzIi1yu6HHLiMfvkahTmJqRxueWn9TP5DclAquaEJjDU3iqt1YopDVWyEchcp6gM9VHyRIQt/Tvsv05iMgKwwkO219NY9Pq9+mErqTlk/LLhKSs9gFz2iAtNeMEUt3k3ZR6dyHBN/cjZVav2H2t5wI2Lxs7fAINREAQIqcrXht7U6HdrfsHJwx4+ka/OfmmEb1582w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PnY6+BAmSjTGR/zPEu1AWeS5Zx1lXZA/nSO76OlRM+k=; b=ijX3/aW1LcYZv13Ndd+XEyzhcncMLBk1FiPyQcpq4f6zGI/YyX9HN/LOJC/4EvnyPGQQjQot3aEREAOO2w7KHEBP+4Df3jco+ooEzQmhmj9pXYlXudEVdcihw3SGJbuyZNqBUO4ycUbalcNoImpwCzcDtFNVBrFjsuWlUJ6X68wPE3QrLEPxHGx8oaBrgt02OEZz1UHkEvHp55UwNZhOH8YPk+WfqlsUUIAxK1f6Mop3BEXjTvi1ZXo2nIuEs8ea8WzmNnop7UTBWD7nKLLIIF9PTM7e0VKCbtcNIyZqj2RzSfQTy8kvFd/zcLwy+2lUb0IDh471VCXHAxZAAUQ5mg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Received: from VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) by AS8PR04MB7751.eurprd04.prod.outlook.com (2603:10a6:20b:2a2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.32; Wed, 5 Oct 2022 07:24:23 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::2459:15ae:e6cb:218a]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::2459:15ae:e6cb:218a%7]) with mapi id 15.20.5676.031; Wed, 5 Oct 2022 07:24:23 +0000 Message-ID: <e4e4b80b-794c-7485-1997-685adab8fb27@suse.com> Date: Wed, 5 Oct 2022 09:24:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: [PATCH v3 4/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL Content-Language: en-US To: Binutils <binutils@sourceware.org> References: <20e2773a-2e47-869b-1900-709f8ad4cd6b@suse.com> In-Reply-To: <20e2773a-2e47-869b-1900-709f8ad4cd6b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR0P281CA0042.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:48::9) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|AS8PR04MB7751:EE_ X-MS-Office365-Filtering-Correlation-Id: 80416b2c-78ee-40e7-aa93-08daa6a29f42 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nHb43tdpmy2iyF/INmjy/DTB5wxJyW9HeDSV0kmuC0+3YJVCq9hAfTF6Z9vni51RfozLiG8DpITFWzaMk35HlEP68FkP+ymfj+6mNeR7rclCBQnx6f1X2UF/urhRsGk4Uu1KUxSPU3Kv4r7lh6GNUpA893SU99scKfQjirgKdx8hds0H2DxKz77kxJ2MB+yfnUnjUvOr7m4rXz4oES+dQYndpIalJoLppwZd5fECDnooRbQBfiU58qfPGw5MzKrFDX6I+vYGH/62VdruZ5ju7i0lFxgFpIpoJa4ZVLY+n0mHj3DjTyt+rY+Y+3zsQrGl6xJcpFElHrjEz8PEgpH8AA7W4qq0+B3p41E+Qtdp2kL//EGCRGIm/WO+s4nAdg7nhf6BRr8ulGVuvmOcyvAqmYqUK6HvH4W/iMcpShzrBCVCUYlbXPIIkfUsSxYkMybzoRQG8RuZDMTFnNF8VExusHyW0F4OXiqcxKWy9M1nmWlWtf3EL78nD1QSfOCF+KyIlFnkaqRTnbf6z/AstGjCalMOsRczUTL5I7TLDyFLUZW+oGD6yQKBoOc9v/jtVNpOEydnP613u8H+8a/J5PQT9fPsJRTRMm+BKg41mhnGa9rdz6H6I3Ka9PJwy+ny00movbW0fH2WyC8FrDQY2Fq2KALLYa1XsX1l3t825tf1OCLcKFF6ImNq9XlDB1N8mdX84x5U1HFenXvZr8SnarzwgZEkIsw1LJodiPGIHuWjbn2Rm0X+qlrQZ9H0PTl4tvn6Yiq/K8mZegLXX6eHKYPH2Y+D+41QAlHoklxJLUY/Hcw= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VE1PR04MB6560.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(376002)(136003)(346002)(366004)(396003)(39860400002)(451199015)(31686004)(36756003)(31696002)(2906002)(5660300002)(2616005)(83380400001)(38100700002)(186003)(6506007)(6512007)(6486002)(478600001)(26005)(66946007)(66476007)(4326008)(316002)(86362001)(8676002)(66556008)(41300700001)(8936002)(6916009)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?D3ih/JjdFhYV4TOPzIyzINg4l5xv?= =?utf-8?q?FOgXYyeylpQc+oc3zp44T0t5dMJa7VEAHvjxoTTw7kpgLtr1kUoPN2wug5PAsOc2P?= =?utf-8?q?e160f3xutrwN2tYdjpEjCf2Vb63El//bvY8OKU9RtbhIp1k5pXmExcYH3onq80g/p?= =?utf-8?q?VepgG1R+FUkHs3Oy9h+ILUp/cj9d2Uy/SrA9+2fTpZiYMYhkT5A0rmG0DroEcRMm8?= =?utf-8?q?Ud0m4lLnbJdow2KjvoWfuggpQBZHH+20xfKkVA5+2LXrQj8o9s/hERYpV2X0kq6kG?= =?utf-8?q?TrY2yS4d18UAZlM4ZBdzjCMNiXfaPUxvs6BC4d/jESPN7azzkxWLJEWBLsMTywVb6?= =?utf-8?q?pgR2WAtM4F5+TunmFxiMmREdWmY5ND3hM2lw0YOJ9ty2Kc3weAzFIl4Hm9SMQ9SCJ?= =?utf-8?q?7HkbCRzcVr9Y7jdmrdk4LyxH85V2ZzUZp0iU0HlPY+53BcIX4YrEYPFp0t8R48uLu?= =?utf-8?q?hGM29ng5py+lfGbU0aL0zFkFY9pVBFP3elJlDqmUpDvKdfyGn2PK8627/x2mg70Nw?= =?utf-8?q?yHYRJOvZSf/Mr0Kyp0DbQItsuI03jI17lR+1ZXVUlaJcT+8wHgoBCIKRML5qTf6RF?= =?utf-8?q?Q8n3c1DtJnoUSlfuZ0BuUIKAqfWia/1a8g4P9i06KA08O8exYB8fRBGHMbeXrv5TB?= =?utf-8?q?q51HrMmfQ+k3a0HKyBRZX9htddTZXAF9T7VIURTKttzPvK8IakZfRMFxrKizuPBUA?= =?utf-8?q?wls0SKB8WBHE4UrOgVHhBFlD9JOAK62PNCZEe5xUAFSpdYgC7XbfGpKGQpPDFK+eG?= =?utf-8?q?BvAYu0zxMVMHyxYCpnXcxvkj12YXsPxydWQFRg00ENTgJ7wKU/sEOhMgG59ZSg6xE?= =?utf-8?q?vrGtlwBFaH7BujXFcUORrHxGsJl4lU/rvcwzs+VnATuOVTbc0F/Oo1tx7JK+244uj?= =?utf-8?q?OB0L/N0ThaVi8gOtyeNgfdOEcVLjcZ7d0UTIi3FsNua+xGxVrR/oQaQJXJeejqNr6?= =?utf-8?q?MBKefGRBzcKV6yTOsDyBq2C8/0oGUaF9DN4vO0FF2JpfBVq62z9CR3uUXGUZkBYZo?= =?utf-8?q?7RNWI5tOvnBZGoUEyU0f9PYKgCyGDqTWb4qVv7vY3Ndghiiu4jRIv6um4dHHby6yX?= =?utf-8?q?U7G3WQ3ietvE0jf12A8WdhA83tKxCeq1NlB9nc9s7pgW3873T1tDcHdwL2YIo9Qnb?= =?utf-8?q?/fsl9EguAdfQG9LSkyBlVNoDF+wW2S7yJbBXmXyAf5JEzLa3GIeUO8gc8F6AN2VrN?= =?utf-8?q?Bc+0RiUWun2lkPDET3LmfoYHNl2TAgVF0//lrNY21pHt99wm384gumIBsSOuHlnhF?= =?utf-8?q?0t1i3CwutI1PeIY/5dP/kXs4zCHzIfU8Pk+XkQjelD7hOOgDzITdBhLUK3XHqyA2y?= =?utf-8?q?gdWRBazr7C8PDWP0fq9czEUoWy+QcLDNs8MYOSZj+A5k7sZClDK9zdmih3+57/8x1?= =?utf-8?q?rGpKcSfY68bEeDwrvjWMWow2ty9b4JWSeBf/Vy1lTsMMwxz+cFHuMZV9wfNhrWCUv?= =?utf-8?q?skcFnTxCPRci2DOq/ScLxDMbOFFCLcKAQETRA73ZdKE9DcHXnAR/NKzxAqsoWoch7?= =?utf-8?q?PlSEdqaq57V4?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80416b2c-78ee-40e7-aa93-08daa6a29f42 X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2022 07:24:22.9298 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ASaNB+cCHXhIcu3PdACcG1lSB9D9nl6a2Xp+DqAJbMvA4zAMcGgctJXAvgcYHfnNCDA/xFAi9XVudRBMk0zkvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB7751 X-Spam-Status: No, score=-3029.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> From: Jan Beulich via Binutils <binutils@sourceware.org> Reply-To: Jan Beulich <jbeulich@suse.com> Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org Sender: "Binutils" <binutils-bounces+ouuuleilei=gmail.com@sourceware.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1745831515537430607?= X-GMAIL-MSGID: =?utf-8?q?1745831515537430607?= |
Series |
x86: suffix handling changes
|
|
Commit Message
Jan Beulich
Oct. 5, 2022, 7:24 a.m. UTC
PR gas/29524 In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated to prefix parsing. Utilize i.error just like match_template() does. --- v3: Re-base over changes to earlier patches (incl use of Pass2).
Comments
On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: > > PR gas/29524 > In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and > MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated > to prefix parsing. Utilize i.error just like match_template() does. Since movs{b,w,l,q} are string instructions, integer sign extensions require a suffix to specify the destination size. This is different from other integer instructions. Since only the new assembler allows the implicit suffix, it won't be easy to use. We should improve error messages, but allowing new syntax doesn't help much. > --- > v3: Re-base over changes to earlier patches (incl use of Pass2). > > --- a/gas/config/tc-i386.c > +++ b/gas/config/tc-i386.c > @@ -236,6 +236,8 @@ enum i386_error > unsupported_with_intel_mnemonic, > unsupported_syntax, > unsupported, > + unsupported_on_arch, > + unsupported_64bit, > invalid_sib_address, > invalid_vsib_address, > invalid_vector_register_set, > @@ -4849,6 +4851,15 @@ md_assemble (char *line) > { > if (pass1_mnem != NULL) > goto match_error; > + if (i.error != no_error) > + { > + gas_assert (current_templates != NULL); > + if (current_templates->start->opcode_modifier.pass2 && !i.suffix) > + goto no_match; > + /* No point in trying a 2nd pass - it'll only find the same suffix > + again. */ > + goto match_error; > + } > return; > } > if (current_templates->start->opcode_modifier.pass2) > @@ -4948,12 +4959,21 @@ md_assemble (char *line) > { > line = copy; > copy = NULL; > + no_match: > pass1_err = i.error; > pass1_mnem = current_templates->start->name; > goto retry; > } > - free (copy); > + > + /* If a non-/only-64bit template (group) was found in pass 1, and if > + _some_ template (group) was found in pass 2, squash pass 1's > + error. */ > + if (pass1_err == unsupported_64bit) > + pass1_mnem = NULL; > + > match_error: > + free (copy); > + > switch (pass1_mnem ? pass1_err : i.error) > { > default: > @@ -4986,6 +5006,17 @@ md_assemble (char *line) > as_bad (_("unsupported instruction `%s'"), > pass1_mnem ? pass1_mnem : current_templates->start->name); > return; > + case unsupported_on_arch: > + as_bad (_("`%s' is not supported on `%s%s'"), > + pass1_mnem ? pass1_mnem : current_templates->start->name, > + cpu_arch_name ? cpu_arch_name : default_arch, > + cpu_sub_arch_name ? cpu_sub_arch_name : ""); > + return; > + case unsupported_64bit: > + as_bad (_("`%s' is %s supported in 64-bit mode"), > + pass1_mnem ? pass1_mnem : current_templates->start->name, > + flag_code == CODE_64BIT ? _("not") : _("only")); > + return; > case invalid_sib_address: > err_msg = _("invalid SIB address"); > break; > @@ -5601,16 +5632,13 @@ parse_insn (const char *line, char *mnem > return l; > } > > - if (!(supported & CPU_FLAGS_64BIT_MATCH)) > - as_bad (flag_code == CODE_64BIT > - ? _("`%s' is not supported in 64-bit mode") > - : _("`%s' is only supported in 64-bit mode"), > - current_templates->start->name); > - else > - as_bad (_("`%s' is not supported on `%s%s'"), > - current_templates->start->name, > - cpu_arch_name ? cpu_arch_name : default_arch, > - cpu_sub_arch_name ? cpu_sub_arch_name : ""); > + if (pass1) > + { > + if (supported & CPU_FLAGS_64BIT_MATCH) > + i.error = unsupported_on_arch; > + else > + i.error = unsupported_64bit; > + } > > return NULL; > } > --- a/gas/testsuite/gas/i386/movs.s > +++ b/gas/testsuite/gas/i386/movs.s > @@ -30,4 +30,10 @@ movs: > .ifdef x86_64 > movswq %ax,%rax > movswq (%rax),%rax > + > + movsl %eax,%rax > + movsl (%rax),%rax > + > + movslq %eax,%rax > + movslq (%rax),%rax > .endif > --- a/gas/testsuite/gas/i386/movx64.l > +++ b/gas/testsuite/gas/i386/movx64.l > @@ -241,6 +241,46 @@ > [ ]*[1-9][0-9]*[ ]+movswq %eax, %rcx > [ ]*[1-9][0-9]*[ ]+movswq %rax, %rcx > [ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movsl %al, %cl > +[ ]*[1-9][0-9]*[ ]+movsl %ax, %cl > +[ ]*[1-9][0-9]*[ ]+movsl %eax, %cl > +[ ]*[1-9][0-9]*[ ]+movsl %rax, %cl > +[ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movsl %al, %cx > +[ ]*[1-9][0-9]*[ ]+movsl %ax, %cx > +[ ]*[1-9][0-9]*[ ]+movsl %eax, %cx > +[ ]*[1-9][0-9]*[ ]+movsl %rax, %cx > +[ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movsl %al, %ecx > +[ ]*[1-9][0-9]*[ ]+movsl %ax, %ecx > +[ ]*[1-9][0-9]*[ ]+movsl %eax, %ecx > +[ ]*[1-9][0-9]*[ ]+movsl %rax, %ecx > +[ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movsl %al, %rcx > +[ ]*[1-9][0-9]*[ ]+movsl %ax, %rcx > +[ ]*[1-9][0-9]* \?\?\?\? 4863C8[ ]+movsl %eax, %rcx > +[ ]*[1-9][0-9]*[ ]+movsl %rax, %rcx > +[ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movslq %al, %cl > +[ ]*[1-9][0-9]*[ ]+movslq %ax, %cl > +[ ]*[1-9][0-9]*[ ]+movslq %eax, %cl > +[ ]*[1-9][0-9]*[ ]+movslq %rax, %cl > +[ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movslq %al, %cx > +[ ]*[1-9][0-9]*[ ]+movslq %ax, %cx > +[ ]*[1-9][0-9]*[ ]+movslq %eax, %cx > +[ ]*[1-9][0-9]*[ ]+movslq %rax, %cx > +[ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movslq %al, %ecx > +[ ]*[1-9][0-9]*[ ]+movslq %ax, %ecx > +[ ]*[1-9][0-9]*[ ]+movslq %eax, %ecx > +[ ]*[1-9][0-9]*[ ]+movslq %rax, %ecx > +[ ]*[1-9][0-9]*[ ]* > +[ ]*[1-9][0-9]*[ ]+movslq %al, %rcx > +[ ]*[1-9][0-9]*[ ]+movslq %ax, %rcx > +[ ]*[1-9][0-9]* \?\?\?\? 4863C8[ ]+movslq %eax, %rcx > +[ ]*[1-9][0-9]*[ ]+movslq %rax, %rcx > +[ ]*[1-9][0-9]*[ ]* > [ ]*[1-9][0-9]*[ ]+movzx: > [ ]*[1-9][0-9]*[ ]+movzx %al, %cl > [ ]*[1-9][0-9]*[ ]+movzx %ax, %cl > --- a/gas/testsuite/gas/i386/movx64.s > +++ b/gas/testsuite/gas/i386/movx64.s > @@ -241,6 +241,46 @@ movsx: > movswq %eax, %rcx > movswq %rax, %rcx > > + movsl %al, %cl > + movsl %ax, %cl > + movsl %eax, %cl > + movsl %rax, %cl > + > + movsl %al, %cx > + movsl %ax, %cx > + movsl %eax, %cx > + movsl %rax, %cx > + > + movsl %al, %ecx > + movsl %ax, %ecx > + movsl %eax, %ecx > + movsl %rax, %ecx > + > + movsl %al, %rcx > + movsl %ax, %rcx > + movsl %eax, %rcx > + movsl %rax, %rcx > + > + movslq %al, %cl > + movslq %ax, %cl > + movslq %eax, %cl > + movslq %rax, %cl > + > + movslq %al, %cx > + movslq %ax, %cx > + movslq %eax, %cx > + movslq %rax, %cx > + > + movslq %al, %ecx > + movslq %ax, %ecx > + movslq %eax, %ecx > + movslq %rax, %ecx > + > + movslq %al, %rcx > + movslq %ax, %rcx > + movslq %eax, %rcx > + movslq %rax, %rcx > + > movzx: > movzx %al, %cl > movzx %ax, %cl > --- a/opcodes/i386-opc.tbl > +++ b/opcodes/i386-opc.tbl > @@ -164,9 +164,7 @@ movbe, 0x0f38f0, None, CpuMovbe, D|Modrm > // Move with sign extend. > movsb, 0xfbe, None, Cpu386, Modrm|No_bSuf|No_sSuf|No_ldSuf|Pass2, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 } > movsw, 0xfbf, None, Cpu386, Modrm|No_bSuf|No_wSuf|No_sSuf|No_ldSuf|Pass2, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 } > -// "movslq" must not be converted into "movsl" to avoid conflict with the > -// "movsl" string move instruction. > -movslq, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Size64, { Reg32|Dword|Unspecified|BaseIndex, Reg64 } > +movsl, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|Pass2, { Reg32|Unspecified|BaseIndex, Reg64 } > movsx, 0xfbe, None, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 } > movsx, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 } > movsxd, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 } >
On 11.10.2022 19:44, H.J. Lu wrote: > On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> PR gas/29524 >> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and >> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated >> to prefix parsing. Utilize i.error just like match_template() does. > > Since movs{b,w,l,q} are string instructions, integer sign extensions > require a suffix to specify the destination size. This is different from other > integer instructions. Since only the new assembler allows the implicit suffix, > it won't be easy to use. We should improve error messages, but allowing > new syntax doesn't help much. It is an earlier change making most of this consistent with MOVZ*; it is only logical to extend this to the long-to-quad sign-extending insn. As with any fixes to prior misbehavior - of course one needs to play by the rules of the older assembler for a number of years. But projects raise their baselines, and hence at some point projects with an "avoid suffixes if possible" policy could switch. Jan
On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 11.10.2022 19:44, H.J. Lu wrote: > > On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> PR gas/29524 > >> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and > >> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated > >> to prefix parsing. Utilize i.error just like match_template() does. > > > > Since movs{b,w,l,q} are string instructions, integer sign extensions > > require a suffix to specify the destination size. This is different from other > > integer instructions. Since only the new assembler allows the implicit suffix, > > it won't be easy to use. We should improve error messages, but allowing > > new syntax doesn't help much. > > It is an earlier change making most of this consistent with MOVZ*; it is MOVZ is different. There are no MOVZ string instructions. MOVS has different meanings in ISA. MOVS difference from MOVZ in assembly syntax should be expected. > only logical to extend this to the long-to-quad sign-extending insn. As > with any fixes to prior misbehavior - of course one needs to play by the > rules of the older assembler for a number of years. But projects raise > their baselines, and hence at some point projects with an "avoid suffixes > if possible" policy could switch. > > Jan
On 12.10.2022 19:10, H.J. Lu wrote: > On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 11.10.2022 19:44, H.J. Lu wrote: >>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: >>>> >>>> PR gas/29524 >>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and >>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated >>>> to prefix parsing. Utilize i.error just like match_template() does. >>> >>> Since movs{b,w,l,q} are string instructions, integer sign extensions >>> require a suffix to specify the destination size. This is different from other >>> integer instructions. Since only the new assembler allows the implicit suffix, >>> it won't be easy to use. We should improve error messages, but allowing >>> new syntax doesn't help much. >> >> It is an earlier change making most of this consistent with MOVZ*; it is > > MOVZ is different. There are no MOVZ string instructions. MOVS has > different meanings in ISA. MOVS difference from MOVZ in assembly > syntax should be expected. You've said so before, yes, but I continue to disagree. And as we can see from the series things can be made work consistently (and imo nothing else should have been done right from the beginning). Jan
On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: > > On 12.10.2022 19:10, H.J. Lu wrote: > > On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 11.10.2022 19:44, H.J. Lu wrote: > >>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>> > >>>> PR gas/29524 > >>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and > >>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated > >>>> to prefix parsing. Utilize i.error just like match_template() does. > >>> > >>> Since movs{b,w,l,q} are string instructions, integer sign extensions > >>> require a suffix to specify the destination size. This is different from other > >>> integer instructions. Since only the new assembler allows the implicit suffix, > >>> it won't be easy to use. We should improve error messages, but allowing > >>> new syntax doesn't help much. > >> > >> It is an earlier change making most of this consistent with MOVZ*; it is > > > > MOVZ is different. There are no MOVZ string instructions. MOVS has > > different meanings in ISA. MOVS difference from MOVZ in assembly > > syntax should be expected. > > You've said so before, yes, but I continue to disagree. And as we can see > from the series things can be made work consistently (and imo nothing else > should have been done right from the beginning). > There are inconsistencies in ISA. AT&T syntax makes things more complex. People should either deal with it or leave it to compilers. I don't think we should make assembler more complex.
On 13.10.2022 19:00, H.J. Lu wrote: > On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 12.10.2022 19:10, H.J. Lu wrote: >>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: >>>> >>>> On 11.10.2022 19:44, H.J. Lu wrote: >>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>> >>>>>> PR gas/29524 >>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and >>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated >>>>>> to prefix parsing. Utilize i.error just like match_template() does. >>>>> >>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions >>>>> require a suffix to specify the destination size. This is different from other >>>>> integer instructions. Since only the new assembler allows the implicit suffix, >>>>> it won't be easy to use. We should improve error messages, but allowing >>>>> new syntax doesn't help much. >>>> >>>> It is an earlier change making most of this consistent with MOVZ*; it is >>> >>> MOVZ is different. There are no MOVZ string instructions. MOVS has >>> different meanings in ISA. MOVS difference from MOVZ in assembly >>> syntax should be expected. >> >> You've said so before, yes, but I continue to disagree. And as we can see >> from the series things can be made work consistently (and imo nothing else >> should have been done right from the beginning). >> > > There are inconsistencies in ISA. Sure. But we shouldn't add further ones in the assembler. > AT&T syntax makes things more complex. > People should either deal with it or leave it to compilers. I don't think we > should make assembler more complex. The complexity added here isn't all that bad. You've added far more complexity in the past for things which arguably shouldn't even be dealt with by the assembler (I'm thinking of -malign-branch* and -mlfence-* first of all). Jan
On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 13.10.2022 19:00, H.J. Lu wrote: > > On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 12.10.2022 19:10, H.J. Lu wrote: > >>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>> > >>>> On 11.10.2022 19:44, H.J. Lu wrote: > >>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>> > >>>>>> PR gas/29524 > >>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and > >>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated > >>>>>> to prefix parsing. Utilize i.error just like match_template() does. > >>>>> > >>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions > >>>>> require a suffix to specify the destination size. This is different from other > >>>>> integer instructions. Since only the new assembler allows the implicit suffix, > >>>>> it won't be easy to use. We should improve error messages, but allowing > >>>>> new syntax doesn't help much. > >>>> > >>>> It is an earlier change making most of this consistent with MOVZ*; it is > >>> > >>> MOVZ is different. There are no MOVZ string instructions. MOVS has > >>> different meanings in ISA. MOVS difference from MOVZ in assembly > >>> syntax should be expected. > >> > >> You've said so before, yes, but I continue to disagree. And as we can see > >> from the series things can be made work consistently (and imo nothing else > >> should have been done right from the beginning). > >> > > > > There are inconsistencies in ISA. > > Sure. But we shouldn't add further ones in the assembler. Assembler just follows ISA. Programmers should learn to deal with it or use a compiler. > > AT&T syntax makes things more complex. > > People should either deal with it or leave it to compilers. I don't think we > > should make assembler more complex. > > The complexity added here isn't all that bad. You've added far more > complexity in the past for things which arguably shouldn't even be > dealt with by the assembler (I'm thinking of -malign-branch* and > -mlfence-* first of all). > > Jan
On 14.10.2022 19:07, H.J. Lu wrote: > On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 13.10.2022 19:00, H.J. Lu wrote: >>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: >>>> >>>> On 12.10.2022 19:10, H.J. Lu wrote: >>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>> >>>>>> On 11.10.2022 19:44, H.J. Lu wrote: >>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>> >>>>>>>> PR gas/29524 >>>>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and >>>>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated >>>>>>>> to prefix parsing. Utilize i.error just like match_template() does. >>>>>>> >>>>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions >>>>>>> require a suffix to specify the destination size. This is different from other >>>>>>> integer instructions. Since only the new assembler allows the implicit suffix, >>>>>>> it won't be easy to use. We should improve error messages, but allowing >>>>>>> new syntax doesn't help much. >>>>>> >>>>>> It is an earlier change making most of this consistent with MOVZ*; it is >>>>> >>>>> MOVZ is different. There are no MOVZ string instructions. MOVS has >>>>> different meanings in ISA. MOVS difference from MOVZ in assembly >>>>> syntax should be expected. >>>> >>>> You've said so before, yes, but I continue to disagree. And as we can see >>>> from the series things can be made work consistently (and imo nothing else >>>> should have been done right from the beginning). >>>> >>> >>> There are inconsistencies in ISA. >> >> Sure. But we shouldn't add further ones in the assembler. > > Assembler just follows ISA. Programmers should learn to > deal with it or use a compiler. This is entirely non-constructive. Assembler writers should get things into usable (read: consistent) shape. Plus what ISA are you talking about here? We're talking of mnemonics which aren't spelled out in any ISA document anyway. The only halfway official AT&T doc I'm aware of doesn't provide room for omitting size suffixes [1]. Yet that's a fundamental feature of gas, and elsewhere (recently: CMPccXADD) you're even suggesting to force people to omit suffixes (plus you've previously objected to the disassembler to consistently emit them in suffix-always mode). That same document was also only updated to cover 64-bit code in a half- hearted way, so can't necessarily be used for 64-bit only insns (it doesn't list any form of MOVSXD at all afaics, for example). Where not explicitly mentioned, their intended handling can only be inferred by using analogies. Nor do we support some of the odd (quirky I would say) mnemonics that are listed there, like xchglA or movabsbA (which is even wrongly described as moving an immediate value into the register). Bottom line: May I please ask that you take another (constructive) look at the v4 submission? Jan [1] Really it does, by saying "long" is then implied, which has never been the behavior of gas when a register saying otherwise is also in use.
On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 14.10.2022 19:07, H.J. Lu wrote: > > On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 13.10.2022 19:00, H.J. Lu wrote: > >>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: > >>>> > >>>> On 12.10.2022 19:10, H.J. Lu wrote: > >>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>> > >>>>>> On 11.10.2022 19:44, H.J. Lu wrote: > >>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>>>> > >>>>>>>> PR gas/29524 > >>>>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and > >>>>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated > >>>>>>>> to prefix parsing. Utilize i.error just like match_template() does. > >>>>>>> > >>>>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions > >>>>>>> require a suffix to specify the destination size. This is different from other > >>>>>>> integer instructions. Since only the new assembler allows the implicit suffix, > >>>>>>> it won't be easy to use. We should improve error messages, but allowing > >>>>>>> new syntax doesn't help much. > >>>>>> > >>>>>> It is an earlier change making most of this consistent with MOVZ*; it is > >>>>> > >>>>> MOVZ is different. There are no MOVZ string instructions. MOVS has > >>>>> different meanings in ISA. MOVS difference from MOVZ in assembly > >>>>> syntax should be expected. > >>>> > >>>> You've said so before, yes, but I continue to disagree. And as we can see > >>>> from the series things can be made work consistently (and imo nothing else > >>>> should have been done right from the beginning). > >>>> > >>> > >>> There are inconsistencies in ISA. > >> > >> Sure. But we shouldn't add further ones in the assembler. > > > > Assembler just follows ISA. Programmers should learn to > > deal with it or use a compiler. > > This is entirely non-constructive. Assembler writers should get things into > usable (read: consistent) shape. Plus what ISA are you talking about here? GNU assembler has been this way for a long time and the current GNU assembler will still be in use for the next few years. Assembler writers should know about all these. > We're talking of mnemonics which aren't spelled out in any ISA document > anyway. The only halfway official AT&T doc I'm aware of doesn't provide > room for omitting size suffixes [1]. Yet that's a fundamental feature of gas, > and elsewhere (recently: CMPccXADD) you're even suggesting to force people > to omit suffixes (plus you've previously objected to the disassembler to > consistently emit them in suffix-always mode). > > That same document was also only updated to cover 64-bit code in a half- > hearted way, so can't necessarily be used for 64-bit only insns (it doesn't > list any form of MOVSXD at all afaics, for example). Where not explicitly > mentioned, their intended handling can only be inferred by using analogies. > Nor do we support some of the odd (quirky I would say) mnemonics that are > listed there, like xchglA or movabsbA (which is even wrongly described as > moving an immediate value into the register). > > Bottom line: May I please ask that you take another (constructive) look at > the v4 submission? > > Jan > > [1] Really it does, by saying "long" is then implied, which has never been > the behavior of gas when a register saying otherwise is also in use.
On 18.10.2022 00:36, H.J. Lu wrote: > On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 14.10.2022 19:07, H.J. Lu wrote: >>> On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: >>>> >>>> On 13.10.2022 19:00, H.J. Lu wrote: >>>>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: >>>>>> >>>>>> On 12.10.2022 19:10, H.J. Lu wrote: >>>>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>> >>>>>>>> On 11.10.2022 19:44, H.J. Lu wrote: >>>>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>>>> >>>>>>>>>> PR gas/29524 >>>>>>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and >>>>>>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated >>>>>>>>>> to prefix parsing. Utilize i.error just like match_template() does. >>>>>>>>> >>>>>>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions >>>>>>>>> require a suffix to specify the destination size. This is different from other >>>>>>>>> integer instructions. Since only the new assembler allows the implicit suffix, >>>>>>>>> it won't be easy to use. We should improve error messages, but allowing >>>>>>>>> new syntax doesn't help much. >>>>>>>> >>>>>>>> It is an earlier change making most of this consistent with MOVZ*; it is >>>>>>> >>>>>>> MOVZ is different. There are no MOVZ string instructions. MOVS has >>>>>>> different meanings in ISA. MOVS difference from MOVZ in assembly >>>>>>> syntax should be expected. >>>>>> >>>>>> You've said so before, yes, but I continue to disagree. And as we can see >>>>>> from the series things can be made work consistently (and imo nothing else >>>>>> should have been done right from the beginning). >>>>>> >>>>> >>>>> There are inconsistencies in ISA. >>>> >>>> Sure. But we shouldn't add further ones in the assembler. >>> >>> Assembler just follows ISA. Programmers should learn to >>> deal with it or use a compiler. >> >> This is entirely non-constructive. Assembler writers should get things into >> usable (read: consistent) shape. Plus what ISA are you talking about here? > > GNU assembler has been this way for a long time and the current GNU > assembler will still be in use for the next few years. Assembler writers > should know about all these. Hmm, so after all not any ISA to follow? Plus do you suggest there's only people having written x86 assembler code for many years? And there's no people who would prefer to get their code into more consistent shape, but who are limited by assembler shortcomings? In any event, ... >> We're talking of mnemonics which aren't spelled out in any ISA document >> anyway. The only halfway official AT&T doc I'm aware of doesn't provide >> room for omitting size suffixes [1]. Yet that's a fundamental feature of gas, >> and elsewhere (recently: CMPccXADD) you're even suggesting to force people >> to omit suffixes (plus you've previously objected to the disassembler to >> consistently emit them in suffix-always mode). >> >> That same document was also only updated to cover 64-bit code in a half- >> hearted way, so can't necessarily be used for 64-bit only insns (it doesn't >> list any form of MOVSXD at all afaics, for example). Where not explicitly >> mentioned, their intended handling can only be inferred by using analogies. >> Nor do we support some of the odd (quirky I would say) mnemonics that are >> listed there, like xchglA or movabsbA (which is even wrongly described as >> moving an immediate value into the register). >> >> Bottom line: May I please ask that you take another (constructive) look at >> the v4 submission? ... this request continues to stand. Jan
On Mon, Oct 17, 2022 at 11:31 PM Jan Beulich <jbeulich@suse.com> wrote: > > On 18.10.2022 00:36, H.J. Lu wrote: > > On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 14.10.2022 19:07, H.J. Lu wrote: > >>> On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>> > >>>> On 13.10.2022 19:00, H.J. Lu wrote: > >>>>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>> > >>>>>> On 12.10.2022 19:10, H.J. Lu wrote: > >>>>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>>>> > >>>>>>>> On 11.10.2022 19:44, H.J. Lu wrote: > >>>>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>>>>>> > >>>>>>>>>> PR gas/29524 > >>>>>>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and > >>>>>>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated > >>>>>>>>>> to prefix parsing. Utilize i.error just like match_template() does. > >>>>>>>>> > >>>>>>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions > >>>>>>>>> require a suffix to specify the destination size. This is different from other > >>>>>>>>> integer instructions. Since only the new assembler allows the implicit suffix, > >>>>>>>>> it won't be easy to use. We should improve error messages, but allowing > >>>>>>>>> new syntax doesn't help much. > >>>>>>>> > >>>>>>>> It is an earlier change making most of this consistent with MOVZ*; it is > >>>>>>> > >>>>>>> MOVZ is different. There are no MOVZ string instructions. MOVS has > >>>>>>> different meanings in ISA. MOVS difference from MOVZ in assembly > >>>>>>> syntax should be expected. > >>>>>> > >>>>>> You've said so before, yes, but I continue to disagree. And as we can see > >>>>>> from the series things can be made work consistently (and imo nothing else > >>>>>> should have been done right from the beginning). > >>>>>> > >>>>> > >>>>> There are inconsistencies in ISA. > >>>> > >>>> Sure. But we shouldn't add further ones in the assembler. > >>> > >>> Assembler just follows ISA. Programmers should learn to > >>> deal with it or use a compiler. > >> > >> This is entirely non-constructive. Assembler writers should get things into > >> usable (read: consistent) shape. Plus what ISA are you talking about here? > > > > GNU assembler has been this way for a long time and the current GNU > > assembler will still be in use for the next few years. Assembler writers > > should know about all these. > > Hmm, so after all not any ISA to follow? Plus do you suggest there's > only people having written x86 assembler code for many years? And > there's no people who would prefer to get their code into more > consistent shape, but who are limited by assembler shortcomings? I prefer consistency with existing assemblers and ISA specs. For new instructions, suffixes should be used only when there is an ambiguity. For existing instructions, to support existing assembly codes, suffixes may be optional even when there is an ambiguity. But for integer MOVS instructions, suffixes have always been required. I don't think we should change them now. We can improve documentation if needed. > In any event, ... > > >> We're talking of mnemonics which aren't spelled out in any ISA document > >> anyway. The only halfway official AT&T doc I'm aware of doesn't provide > >> room for omitting size suffixes [1]. Yet that's a fundamental feature of gas, > >> and elsewhere (recently: CMPccXADD) you're even suggesting to force people > >> to omit suffixes (plus you've previously objected to the disassembler to > >> consistently emit them in suffix-always mode). > >> > >> That same document was also only updated to cover 64-bit code in a half- > >> hearted way, so can't necessarily be used for 64-bit only insns (it doesn't > >> list any form of MOVSXD at all afaics, for example). Where not explicitly > >> mentioned, their intended handling can only be inferred by using analogies. > >> Nor do we support some of the odd (quirky I would say) mnemonics that are > >> listed there, like xchglA or movabsbA (which is even wrongly described as > >> moving an immediate value into the register). > >> > >> Bottom line: May I please ask that you take another (constructive) look at > >> the v4 submission? > > ... this request continues to stand. I think we should improve diagnostics and documentation, not add new syntaxes to existing instructions.
On 18.10.2022 23:48, H.J. Lu wrote: > On Mon, Oct 17, 2022 at 11:31 PM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 18.10.2022 00:36, H.J. Lu wrote: >>> On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich <jbeulich@suse.com> wrote: >>>> >>>> On 14.10.2022 19:07, H.J. Lu wrote: >>>>> On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>> >>>>>> On 13.10.2022 19:00, H.J. Lu wrote: >>>>>>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>> >>>>>>>> On 12.10.2022 19:10, H.J. Lu wrote: >>>>>>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>>>> >>>>>>>>>> On 11.10.2022 19:44, H.J. Lu wrote: >>>>>>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> PR gas/29524 >>>>>>>>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and >>>>>>>>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated >>>>>>>>>>>> to prefix parsing. Utilize i.error just like match_template() does. >>>>>>>>>>> >>>>>>>>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions >>>>>>>>>>> require a suffix to specify the destination size. This is different from other >>>>>>>>>>> integer instructions. Since only the new assembler allows the implicit suffix, >>>>>>>>>>> it won't be easy to use. We should improve error messages, but allowing >>>>>>>>>>> new syntax doesn't help much. >>>>>>>>>> >>>>>>>>>> It is an earlier change making most of this consistent with MOVZ*; it is >>>>>>>>> >>>>>>>>> MOVZ is different. There are no MOVZ string instructions. MOVS has >>>>>>>>> different meanings in ISA. MOVS difference from MOVZ in assembly >>>>>>>>> syntax should be expected. >>>>>>>> >>>>>>>> You've said so before, yes, but I continue to disagree. And as we can see >>>>>>>> from the series things can be made work consistently (and imo nothing else >>>>>>>> should have been done right from the beginning). >>>>>>>> >>>>>>> >>>>>>> There are inconsistencies in ISA. >>>>>> >>>>>> Sure. But we shouldn't add further ones in the assembler. >>>>> >>>>> Assembler just follows ISA. Programmers should learn to >>>>> deal with it or use a compiler. >>>> >>>> This is entirely non-constructive. Assembler writers should get things into >>>> usable (read: consistent) shape. Plus what ISA are you talking about here? >>> >>> GNU assembler has been this way for a long time and the current GNU >>> assembler will still be in use for the next few years. Assembler writers >>> should know about all these. >> >> Hmm, so after all not any ISA to follow? Plus do you suggest there's >> only people having written x86 assembler code for many years? And >> there's no people who would prefer to get their code into more >> consistent shape, but who are limited by assembler shortcomings? > > I prefer consistency with existing assemblers and ISA specs. > For new instructions, suffixes should be used only when there is > an ambiguity. For existing instructions, to support existing assembly > codes, suffixes may be optional even when there is an ambiguity. > But for integer MOVS instructions, suffixes have always been required. > I don't think we should change them now. We can improve documentation > if needed. > >> In any event, ... >> >>>> We're talking of mnemonics which aren't spelled out in any ISA document >>>> anyway. The only halfway official AT&T doc I'm aware of doesn't provide >>>> room for omitting size suffixes [1]. Yet that's a fundamental feature of gas, >>>> and elsewhere (recently: CMPccXADD) you're even suggesting to force people >>>> to omit suffixes (plus you've previously objected to the disassembler to >>>> consistently emit them in suffix-always mode). >>>> >>>> That same document was also only updated to cover 64-bit code in a half- >>>> hearted way, so can't necessarily be used for 64-bit only insns (it doesn't >>>> list any form of MOVSXD at all afaics, for example). Where not explicitly >>>> mentioned, their intended handling can only be inferred by using analogies. >>>> Nor do we support some of the odd (quirky I would say) mnemonics that are >>>> listed there, like xchglA or movabsbA (which is even wrongly described as >>>> moving an immediate value into the register). >>>> >>>> Bottom line: May I please ask that you take another (constructive) look at >>>> the v4 submission? >> >> ... this request continues to stand. > > I think we should improve diagnostics and documentation, not add new > syntaxes to existing instructions. I continue to disagree, but to make at least some forward progress: Which parts of this series can I expect an okay for (patches 5-7 already have one, but can't go in ahead)? I would try to re-order the series then to put the controversial patch(es) at the end, such that at least parts can go in and I can make further progress with other work. But there's no promise this re-ordering actually is going to work out if it's more than just this one patch which you continue to object to. Jan
On Tue, Oct 18, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: > > On 18.10.2022 23:48, H.J. Lu wrote: > > On Mon, Oct 17, 2022 at 11:31 PM Jan Beulich <jbeulich@suse.com> wrote: > >> > >> On 18.10.2022 00:36, H.J. Lu wrote: > >>> On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>> > >>>> On 14.10.2022 19:07, H.J. Lu wrote: > >>>>> On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>> > >>>>>> On 13.10.2022 19:00, H.J. Lu wrote: > >>>>>>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>>>> > >>>>>>>> On 12.10.2022 19:10, H.J. Lu wrote: > >>>>>>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>>>>>> > >>>>>>>>>> On 11.10.2022 19:44, H.J. Lu wrote: > >>>>>>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> PR gas/29524 > >>>>>>>>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and > >>>>>>>>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated > >>>>>>>>>>>> to prefix parsing. Utilize i.error just like match_template() does. > >>>>>>>>>>> > >>>>>>>>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions > >>>>>>>>>>> require a suffix to specify the destination size. This is different from other > >>>>>>>>>>> integer instructions. Since only the new assembler allows the implicit suffix, > >>>>>>>>>>> it won't be easy to use. We should improve error messages, but allowing > >>>>>>>>>>> new syntax doesn't help much. > >>>>>>>>>> > >>>>>>>>>> It is an earlier change making most of this consistent with MOVZ*; it is > >>>>>>>>> > >>>>>>>>> MOVZ is different. There are no MOVZ string instructions. MOVS has > >>>>>>>>> different meanings in ISA. MOVS difference from MOVZ in assembly > >>>>>>>>> syntax should be expected. > >>>>>>>> > >>>>>>>> You've said so before, yes, but I continue to disagree. And as we can see > >>>>>>>> from the series things can be made work consistently (and imo nothing else > >>>>>>>> should have been done right from the beginning). > >>>>>>>> > >>>>>>> > >>>>>>> There are inconsistencies in ISA. > >>>>>> > >>>>>> Sure. But we shouldn't add further ones in the assembler. > >>>>> > >>>>> Assembler just follows ISA. Programmers should learn to > >>>>> deal with it or use a compiler. > >>>> > >>>> This is entirely non-constructive. Assembler writers should get things into > >>>> usable (read: consistent) shape. Plus what ISA are you talking about here? > >>> > >>> GNU assembler has been this way for a long time and the current GNU > >>> assembler will still be in use for the next few years. Assembler writers > >>> should know about all these. > >> > >> Hmm, so after all not any ISA to follow? Plus do you suggest there's > >> only people having written x86 assembler code for many years? And > >> there's no people who would prefer to get their code into more > >> consistent shape, but who are limited by assembler shortcomings? > > > > I prefer consistency with existing assemblers and ISA specs. > > For new instructions, suffixes should be used only when there is > > an ambiguity. For existing instructions, to support existing assembly > > codes, suffixes may be optional even when there is an ambiguity. > > But for integer MOVS instructions, suffixes have always been required. > > I don't think we should change them now. We can improve documentation > > if needed. > > > >> In any event, ... > >> > >>>> We're talking of mnemonics which aren't spelled out in any ISA document > >>>> anyway. The only halfway official AT&T doc I'm aware of doesn't provide > >>>> room for omitting size suffixes [1]. Yet that's a fundamental feature of gas, > >>>> and elsewhere (recently: CMPccXADD) you're even suggesting to force people > >>>> to omit suffixes (plus you've previously objected to the disassembler to > >>>> consistently emit them in suffix-always mode). > >>>> > >>>> That same document was also only updated to cover 64-bit code in a half- > >>>> hearted way, so can't necessarily be used for 64-bit only insns (it doesn't > >>>> list any form of MOVSXD at all afaics, for example). Where not explicitly > >>>> mentioned, their intended handling can only be inferred by using analogies. > >>>> Nor do we support some of the odd (quirky I would say) mnemonics that are > >>>> listed there, like xchglA or movabsbA (which is even wrongly described as > >>>> moving an immediate value into the register). > >>>> > >>>> Bottom line: May I please ask that you take another (constructive) look at > >>>> the v4 submission? > >> > >> ... this request continues to stand. > > > > I think we should improve diagnostics and documentation, not add new > > syntaxes to existing instructions. > > I continue to disagree, but to make at least some forward progress: Which > parts of this series can I expect an okay for (patches 5-7 already have > one, but can't go in ahead)? I would try to re-order the series then to > put the controversial patch(es) at the end, such that at least parts can > go in and I can make further progress with other work. But there's no > promise this re-ordering actually is going to work out if it's more than > just this one patch which you continue to object to. > Please submit a new patch set without MOVS changes. Thanks.
On 19.10.2022 23:46, H.J. Lu wrote: > On Tue, Oct 18, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: >> >> On 18.10.2022 23:48, H.J. Lu wrote: >>> On Mon, Oct 17, 2022 at 11:31 PM Jan Beulich <jbeulich@suse.com> wrote: >>>> >>>> On 18.10.2022 00:36, H.J. Lu wrote: >>>>> On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>> >>>>>> On 14.10.2022 19:07, H.J. Lu wrote: >>>>>>> On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>> >>>>>>>> On 13.10.2022 19:00, H.J. Lu wrote: >>>>>>>>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>>>> >>>>>>>>>> On 12.10.2022 19:10, H.J. Lu wrote: >>>>>>>>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 11.10.2022 19:44, H.J. Lu wrote: >>>>>>>>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> PR gas/29524 >>>>>>>>>>>>>> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and >>>>>>>>>>>>>> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated >>>>>>>>>>>>>> to prefix parsing. Utilize i.error just like match_template() does. >>>>>>>>>>>>> >>>>>>>>>>>>> Since movs{b,w,l,q} are string instructions, integer sign extensions >>>>>>>>>>>>> require a suffix to specify the destination size. This is different from other >>>>>>>>>>>>> integer instructions. Since only the new assembler allows the implicit suffix, >>>>>>>>>>>>> it won't be easy to use. We should improve error messages, but allowing >>>>>>>>>>>>> new syntax doesn't help much. >>>>>>>>>>>> >>>>>>>>>>>> It is an earlier change making most of this consistent with MOVZ*; it is >>>>>>>>>>> >>>>>>>>>>> MOVZ is different. There are no MOVZ string instructions. MOVS has >>>>>>>>>>> different meanings in ISA. MOVS difference from MOVZ in assembly >>>>>>>>>>> syntax should be expected. >>>>>>>>>> >>>>>>>>>> You've said so before, yes, but I continue to disagree. And as we can see >>>>>>>>>> from the series things can be made work consistently (and imo nothing else >>>>>>>>>> should have been done right from the beginning). >>>>>>>>>> >>>>>>>>> >>>>>>>>> There are inconsistencies in ISA. >>>>>>>> >>>>>>>> Sure. But we shouldn't add further ones in the assembler. >>>>>>> >>>>>>> Assembler just follows ISA. Programmers should learn to >>>>>>> deal with it or use a compiler. >>>>>> >>>>>> This is entirely non-constructive. Assembler writers should get things into >>>>>> usable (read: consistent) shape. Plus what ISA are you talking about here? >>>>> >>>>> GNU assembler has been this way for a long time and the current GNU >>>>> assembler will still be in use for the next few years. Assembler writers >>>>> should know about all these. >>>> >>>> Hmm, so after all not any ISA to follow? Plus do you suggest there's >>>> only people having written x86 assembler code for many years? And >>>> there's no people who would prefer to get their code into more >>>> consistent shape, but who are limited by assembler shortcomings? >>> >>> I prefer consistency with existing assemblers and ISA specs. >>> For new instructions, suffixes should be used only when there is >>> an ambiguity. For existing instructions, to support existing assembly >>> codes, suffixes may be optional even when there is an ambiguity. >>> But for integer MOVS instructions, suffixes have always been required. >>> I don't think we should change them now. We can improve documentation >>> if needed. >>> >>>> In any event, ... >>>> >>>>>> We're talking of mnemonics which aren't spelled out in any ISA document >>>>>> anyway. The only halfway official AT&T doc I'm aware of doesn't provide >>>>>> room for omitting size suffixes [1]. Yet that's a fundamental feature of gas, >>>>>> and elsewhere (recently: CMPccXADD) you're even suggesting to force people >>>>>> to omit suffixes (plus you've previously objected to the disassembler to >>>>>> consistently emit them in suffix-always mode). >>>>>> >>>>>> That same document was also only updated to cover 64-bit code in a half- >>>>>> hearted way, so can't necessarily be used for 64-bit only insns (it doesn't >>>>>> list any form of MOVSXD at all afaics, for example). Where not explicitly >>>>>> mentioned, their intended handling can only be inferred by using analogies. >>>>>> Nor do we support some of the odd (quirky I would say) mnemonics that are >>>>>> listed there, like xchglA or movabsbA (which is even wrongly described as >>>>>> moving an immediate value into the register). >>>>>> >>>>>> Bottom line: May I please ask that you take another (constructive) look at >>>>>> the v4 submission? >>>> >>>> ... this request continues to stand. >>> >>> I think we should improve diagnostics and documentation, not add new >>> syntaxes to existing instructions. >> >> I continue to disagree, but to make at least some forward progress: Which >> parts of this series can I expect an okay for (patches 5-7 already have >> one, but can't go in ahead)? I would try to re-order the series then to >> put the controversial patch(es) at the end, such that at least parts can >> go in and I can make further progress with other work. But there's no >> promise this re-ordering actually is going to work out if it's more than >> just this one patch which you continue to object to. >> > > Please submit a new patch set without MOVS changes. As said - I'll put those in a separate patch at the end of the series. Not the least because you'll be a little disappointed: The changes to tc-i386.c simply need to move to another patch then. Hence there's not going to be much left to make move-with-sign-extend consistent in that final patch (most of it is then testsuite adjustments/additions). Jan
--- a/gas/config/tc-i386.c +++ b/gas/config/tc-i386.c @@ -236,6 +236,8 @@ enum i386_error unsupported_with_intel_mnemonic, unsupported_syntax, unsupported, + unsupported_on_arch, + unsupported_64bit, invalid_sib_address, invalid_vsib_address, invalid_vector_register_set, @@ -4849,6 +4851,15 @@ md_assemble (char *line) { if (pass1_mnem != NULL) goto match_error; + if (i.error != no_error) + { + gas_assert (current_templates != NULL); + if (current_templates->start->opcode_modifier.pass2 && !i.suffix) + goto no_match; + /* No point in trying a 2nd pass - it'll only find the same suffix + again. */ + goto match_error; + } return; } if (current_templates->start->opcode_modifier.pass2) @@ -4948,12 +4959,21 @@ md_assemble (char *line) { line = copy; copy = NULL; + no_match: pass1_err = i.error; pass1_mnem = current_templates->start->name; goto retry; } - free (copy); + + /* If a non-/only-64bit template (group) was found in pass 1, and if + _some_ template (group) was found in pass 2, squash pass 1's + error. */ + if (pass1_err == unsupported_64bit) + pass1_mnem = NULL; + match_error: + free (copy); + switch (pass1_mnem ? pass1_err : i.error) { default: @@ -4986,6 +5006,17 @@ md_assemble (char *line) as_bad (_("unsupported instruction `%s'"), pass1_mnem ? pass1_mnem : current_templates->start->name); return; + case unsupported_on_arch: + as_bad (_("`%s' is not supported on `%s%s'"), + pass1_mnem ? pass1_mnem : current_templates->start->name, + cpu_arch_name ? cpu_arch_name : default_arch, + cpu_sub_arch_name ? cpu_sub_arch_name : ""); + return; + case unsupported_64bit: + as_bad (_("`%s' is %s supported in 64-bit mode"), + pass1_mnem ? pass1_mnem : current_templates->start->name, + flag_code == CODE_64BIT ? _("not") : _("only")); + return; case invalid_sib_address: err_msg = _("invalid SIB address"); break; @@ -5601,16 +5632,13 @@ parse_insn (const char *line, char *mnem return l; } - if (!(supported & CPU_FLAGS_64BIT_MATCH)) - as_bad (flag_code == CODE_64BIT - ? _("`%s' is not supported in 64-bit mode") - : _("`%s' is only supported in 64-bit mode"), - current_templates->start->name); - else - as_bad (_("`%s' is not supported on `%s%s'"), - current_templates->start->name, - cpu_arch_name ? cpu_arch_name : default_arch, - cpu_sub_arch_name ? cpu_sub_arch_name : ""); + if (pass1) + { + if (supported & CPU_FLAGS_64BIT_MATCH) + i.error = unsupported_on_arch; + else + i.error = unsupported_64bit; + } return NULL; } --- a/gas/testsuite/gas/i386/movs.s +++ b/gas/testsuite/gas/i386/movs.s @@ -30,4 +30,10 @@ movs: .ifdef x86_64 movswq %ax,%rax movswq (%rax),%rax + + movsl %eax,%rax + movsl (%rax),%rax + + movslq %eax,%rax + movslq (%rax),%rax .endif --- a/gas/testsuite/gas/i386/movx64.l +++ b/gas/testsuite/gas/i386/movx64.l @@ -241,6 +241,46 @@ [ ]*[1-9][0-9]*[ ]+movswq %eax, %rcx [ ]*[1-9][0-9]*[ ]+movswq %rax, %rcx [ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movsl %al, %cl +[ ]*[1-9][0-9]*[ ]+movsl %ax, %cl +[ ]*[1-9][0-9]*[ ]+movsl %eax, %cl +[ ]*[1-9][0-9]*[ ]+movsl %rax, %cl +[ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movsl %al, %cx +[ ]*[1-9][0-9]*[ ]+movsl %ax, %cx +[ ]*[1-9][0-9]*[ ]+movsl %eax, %cx +[ ]*[1-9][0-9]*[ ]+movsl %rax, %cx +[ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movsl %al, %ecx +[ ]*[1-9][0-9]*[ ]+movsl %ax, %ecx +[ ]*[1-9][0-9]*[ ]+movsl %eax, %ecx +[ ]*[1-9][0-9]*[ ]+movsl %rax, %ecx +[ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movsl %al, %rcx +[ ]*[1-9][0-9]*[ ]+movsl %ax, %rcx +[ ]*[1-9][0-9]* \?\?\?\? 4863C8[ ]+movsl %eax, %rcx +[ ]*[1-9][0-9]*[ ]+movsl %rax, %rcx +[ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movslq %al, %cl +[ ]*[1-9][0-9]*[ ]+movslq %ax, %cl +[ ]*[1-9][0-9]*[ ]+movslq %eax, %cl +[ ]*[1-9][0-9]*[ ]+movslq %rax, %cl +[ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movslq %al, %cx +[ ]*[1-9][0-9]*[ ]+movslq %ax, %cx +[ ]*[1-9][0-9]*[ ]+movslq %eax, %cx +[ ]*[1-9][0-9]*[ ]+movslq %rax, %cx +[ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movslq %al, %ecx +[ ]*[1-9][0-9]*[ ]+movslq %ax, %ecx +[ ]*[1-9][0-9]*[ ]+movslq %eax, %ecx +[ ]*[1-9][0-9]*[ ]+movslq %rax, %ecx +[ ]*[1-9][0-9]*[ ]* +[ ]*[1-9][0-9]*[ ]+movslq %al, %rcx +[ ]*[1-9][0-9]*[ ]+movslq %ax, %rcx +[ ]*[1-9][0-9]* \?\?\?\? 4863C8[ ]+movslq %eax, %rcx +[ ]*[1-9][0-9]*[ ]+movslq %rax, %rcx +[ ]*[1-9][0-9]*[ ]* [ ]*[1-9][0-9]*[ ]+movzx: [ ]*[1-9][0-9]*[ ]+movzx %al, %cl [ ]*[1-9][0-9]*[ ]+movzx %ax, %cl --- a/gas/testsuite/gas/i386/movx64.s +++ b/gas/testsuite/gas/i386/movx64.s @@ -241,6 +241,46 @@ movsx: movswq %eax, %rcx movswq %rax, %rcx + movsl %al, %cl + movsl %ax, %cl + movsl %eax, %cl + movsl %rax, %cl + + movsl %al, %cx + movsl %ax, %cx + movsl %eax, %cx + movsl %rax, %cx + + movsl %al, %ecx + movsl %ax, %ecx + movsl %eax, %ecx + movsl %rax, %ecx + + movsl %al, %rcx + movsl %ax, %rcx + movsl %eax, %rcx + movsl %rax, %rcx + + movslq %al, %cl + movslq %ax, %cl + movslq %eax, %cl + movslq %rax, %cl + + movslq %al, %cx + movslq %ax, %cx + movslq %eax, %cx + movslq %rax, %cx + + movslq %al, %ecx + movslq %ax, %ecx + movslq %eax, %ecx + movslq %rax, %ecx + + movslq %al, %rcx + movslq %ax, %rcx + movslq %eax, %rcx + movslq %rax, %rcx + movzx: movzx %al, %cl movzx %ax, %cl --- a/opcodes/i386-opc.tbl +++ b/opcodes/i386-opc.tbl @@ -164,9 +164,7 @@ movbe, 0x0f38f0, None, CpuMovbe, D|Modrm // Move with sign extend. movsb, 0xfbe, None, Cpu386, Modrm|No_bSuf|No_sSuf|No_ldSuf|Pass2, { Reg8|Unspecified|BaseIndex, Reg16|Reg32|Reg64 } movsw, 0xfbf, None, Cpu386, Modrm|No_bSuf|No_wSuf|No_sSuf|No_ldSuf|Pass2, { Reg16|Unspecified|BaseIndex, Reg32|Reg64 } -// "movslq" must not be converted into "movsl" to avoid conflict with the -// "movsl" string move instruction. -movslq, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|Size64, { Reg32|Dword|Unspecified|BaseIndex, Reg64 } +movsl, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|Pass2, { Reg32|Unspecified|BaseIndex, Reg64 } movsx, 0xfbe, None, Cpu386, W|Modrm|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg8|Reg16|Unspecified|BaseIndex, Reg16|Reg32|Reg64 } movsx, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 } movsxd, 0x63, None, Cpu64, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Reg32|Unspecified|BaseIndex, Reg32|Reg64 }