From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by sourceware.org (Postfix) with ESMTPS id D2A7E3858D37 for ; Fri, 3 Mar 2023 16:51:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D2A7E3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb2d.google.com with SMTP id t39so2555694ybi.3 for ; Fri, 03 Mar 2023 08:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677862290; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Vr4MVrWItoHDqIbwAbd4SFyjAU56+Va8nRSLNdDuByw=; b=V8EfExEC/5kStF/dI2jjcxkrcN+h5McAmeJFaHKn7EFvN32z6Me+vNZBy4eOmOSmky 8d7TvG3fBBEM+GfSuj1LZTFcAoYVeR0nefPJv65iKIQL6pGFtDkYHrx7W0iRSltbgdTH CRqcxaDzVZ9FZdcRcAg5NWCKbkIzie0EvJqYThzDzeO3fgQroPW138WtSjV76TocegLa 9fk8D9f76x1TveJNUs4EmPIBqD4b9/n0o7vgwgHUKQaQzSoyl26QVyzklZ9dWPb23HGU ZSI56YZxcy652gQxOq1aqOm2V+rTLw0vEhuJU3og1nr9+j4ifCNBgzejSBiC+IILAA+S 4LGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677862290; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Vr4MVrWItoHDqIbwAbd4SFyjAU56+Va8nRSLNdDuByw=; b=a39GA4XHf5Z34+lIxFquIsPhP8wNzcMugOmy6Y3uTxzGUh5QVuFoGrhLL9wE/eGtV7 dDeR3W1AEWFWRIcMSKGEx5ahDkYjGK/YcM6zO7aPHa1L8HbkSphYl1za9g5bJzKNELsc u3zji4plt/Q6lDmEI5D8bYTVXFbfNs0ZmLOQazsNCT2j2boLvE8j/p1jY68jQ+VyFdBZ vNVgHoJE9g0fQOnyK+dMTRc2ixU7/SGDUZrnT48G2yfqjRYKMZm+hci4G7TSJMP7+EID 50XA3Z5dX/GZpzvmgYihqXmLERZcsot08M1Cl4aIvCLndJjxswVwXyHclyLagCBSN6dB Ivjg== X-Gm-Message-State: AO0yUKVcr825uhvV/Q5NZkhUR8HCoEt2BFA0NRYWJOOmufTka9z41ZDL kJiw/39DuP3F3UkSR5YlPsIZmADXrsGWwRRkesg8x0D1 X-Google-Smtp-Source: AK7set/RH1XLHEJullYzsZh0ROrBj219elQ+BzeydKGbl16VeBNZwkzsLwbEvp7//3/bX1Gs/Ni/I47kpbupCjxsgp8= X-Received: by 2002:a5b:384:0:b0:a65:8cd3:fc4 with SMTP id k4-20020a5b0384000000b00a658cd30fc4mr1380308ybp.5.1677862290112; Fri, 03 Mar 2023 08:51:30 -0800 (PST) MIME-Version: 1.0 References: <764b9e03-18bd-6945-692f-a250522196ca@suse.com> In-Reply-To: <764b9e03-18bd-6945-692f-a250522196ca@suse.com> From: "H.J. Lu" Date: Fri, 3 Mar 2023 08:50:51 -0800 Message-ID: Subject: Re: [PATCH 00/18] x86: new .insn directive To: Jan Beulich Cc: Binutils , "Jiang, Haochen" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3016.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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 List-Id: On Fri, Mar 3, 2023 at 4:55=E2=80=AFAM Jan Beulich wrot= e: > > Especially when instructions which are not known to gas yet also take > register or, yet worse, memory operands, encoding such in code actually > wanting to make use of them is often difficult. Typically people resort > to hard-coding the involved registers, thus being able to express > things via .byte. To overcome this limitation (to a sufficient degree > at least), introduce .insn. This allows users to specify operands in > their "normal" shape (possibly in slightly altered order). Peculiarities > require two small syntax extensions; see the implementation or > documentation for details. > > In order to re-use sufficiently much of the functionality md_assemble() > already uses, some adjustments to existing code were necessary. The one > item to call out here is the partial re-write of build_modrm_byte() > (patch 7), which actually turned out to simplify things. Subsequently > possible further tidying is carried out right away (patches 8 and 9), > even if not strictly related to the .insn work. > > I'm pretty sure there are still corner cases which aren't taken care of > correctly. It's also quite possible that I've overlooked further places > in pre-existing code which need tweaking for .insn. People taking a > close look and/or playing with the new functionality would be much > appreciated. > > The last patch in the series is strictly RFC, as I'm uncertain whether > we actually want this kind of a testcase. > > 01: introduce .insn directive > 02: parse VEX and alike specifiers for .insn > 03: parse special opcode modifiers for .insn > 04: use set_rex_vrex() also for short-form handling > 05: move more disp processing out of md_assemble() > 06: adjust REX-prefix part of SSE2AVX test > 07: re-work build_modrm_byte()'s register assignment > 08: VexVVVV is now merely a boolean > 09: drop "shimm" special case template expansions > 10: AT&T: restrict recognition of the "absolute branch" prefix character > 11: process instruction operands for .insn > 12: decouple broadcast type and bytes fields > 13: handle EVEX Disp8 for .insn > 14: allow for multiple immediates in output_disp() > 15: handle immediate operands for .insn > 16: document .insn > 17: convert testcases to use .insn > 18: .insn example - VEX-encoded instructions of original Xeon Phi > > Jan X86 encoding scheme is quite complex. It may get even more complex in the future. I suggest we wait for a while so that we can get clear picture= s what the future encoding scheme looks like. --=20 H.J.