From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 8FF75385840E for ; Tue, 17 Jan 2023 15:57:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8FF75385840E 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-ot1-x331.google.com with SMTP id r2-20020a9d7cc2000000b006718a7f7fbaso18083066otn.2 for ; Tue, 17 Jan 2023 07:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VLyCDSUoWEN/8QjHI4rv9LwNs/AdHJ5MhKRspOc9qbA=; b=CGoxx5gKFgZiyOyc7Kgd0F+40OM9A1Z36nBvVdXVNQS1ybhHOnBFMG72P5mRNkxzw/ 8Uo/vCWfG+Zl9raCmv5SOw55Ye+MQHdNPdi+HsXRla/Ww08jSmaGISVwdEEbwoO0hBL6 GJD2cThXWwHGDzUxN1GWN7rBTrQRoWGUAcE4HU3EF7Lf3olhKUQD6PlztujqHwKSzJbR HebnoeJG6tglrA5eYS5oGCQDOkTglbi39IFhnfaMTjadtJbwGFrxjKZR3TCZwE2iuxZV TN6IugHXcvdLd4MdKKYMDhZkDpB0QWaUTWrmhp03Ue7DvPGsxyFxqeQ2OIM0pGcAoC7i mtdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=VLyCDSUoWEN/8QjHI4rv9LwNs/AdHJ5MhKRspOc9qbA=; b=CKKBoOuSJZBmiHSNvBlY2JJqE5EBDZgi4QGJO7tBr1BSFUX3a4JtgV3/TG64TF9nUv OYBFZdif3pi41ANZ/XEH1KFwr5AYJ/REbSlV1VCuA8lPxzsI6Dw7opRupWHCY3pVAmAD IPiS9zPE/l1FGnmaEMiilCZqesGutwWnV5692k8XTgoPHaMUzUDOk4tffI1o3OOVE3eQ 1y7wF7Hjr4yHKrXzE2ncyyEKj4W8AqI9GPWzy1acVEldWufFe1YhiNSbUOnnlQ4ofhwr r/YHw0pi4cdlXO7oT/qittDxHTdZbW7p384iqNMuWuo5RK1vVUN1dhFyYPeM5lTGgCMJ T/Tw== X-Gm-Message-State: AFqh2kqcaifSizujKPoW3Qda7mgX+FufIYHFGl3xxDdW9g7HxQMkrowg x1Yxck265ueBQHtiNfly/nUiZi5lDeyyj2P5SxY= X-Google-Smtp-Source: AMrXdXvj53+LDvEySphqIf4RriN/g+TZ+88btyaxKZ2I7XPP+jxxvxdOl3UoM8vmyOihjz7dF+1Qy3tTKVOQ4qV1KHc= X-Received: by 2002:a05:6830:1d94:b0:66e:b992:749f with SMTP id y20-20020a0568301d9400b0066eb992749fmr172631oti.52.1673971019685; Tue, 17 Jan 2023 07:56:59 -0800 (PST) MIME-Version: 1.0 References: <7166b647-c3a3-6103-c4d2-7c59a1520518@suse.com> In-Reply-To: <7166b647-c3a3-6103-c4d2-7c59a1520518@suse.com> From: "H.J. Lu" Date: Tue, 17 Jan 2023 07:56:23 -0800 Message-ID: Subject: Re: [RFC] x86: proposal for a new .insn directive To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3016.8 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, Jan 13, 2023 at 3:58 AM Jan Beulich wrote: > > All, > > certain other architectures (Arm, RISC-V) have such, and x86 would imo > benefit from such even more: It is notoriously difficult to encode new > insns with operands which a certain version of gas doesn't support yet. > This is in particular related to the building of the ModR/M and SIB > bytes as well the VEX/XOP/EVEX prefixes. > > I would appreciate feedback on the proposal (in form of an assembly > source file, providing examples at the same time). Besides pointing > out issues / oversights, thoughts on the various TBDs would be helpful. > > Thanks, Jan > > .text > insn: > > # .insn [] [] [+r|/] [,[,...]] > > # Legacy encoding prefixes altering encoding space (0x0f, 0x0f38, 0x0f3a) > # have to be specified as high byte(s) of . This also extends > # to certain FPU opcodes or sub-spaces like that of major opcode 0x0f01. > > # Legacy encoding prefixes altering meaning (0x66, 0xF2, 0xF3) may be > # specified as high byte of (perhaps already including an > # encoding space prefix). Other prefixes should be spelled out as usual > # ahead of or, for segment overrides, with the memory > # operand. > > # Operand order may not match that of the instruction actually being > # expressed: While for a memory operand (of which there can be only one) it > # is clear how to encode it in the resulting ModR/M byte, register operands > # are encoded strictly in the order > # - ModR/M.rm, ModR/M.reg for 2-operand insns, > # - ModR/M.rm, {E,}VEX.vvvv, ModR/M.reg for 3-operand insns, and > # - Imm{4,5}, ModR/M.rm, {E,}VEX.vvvv, ModR/M.reg for 4-operand insns, > # obviously with the ModR/M.rm slot skipped when there is a memory operand, > # and obviously with the ModR/M.reg slot skipped when there is an extension > # opcode. (For Intel syntax of course all in the opposite order.) > > # Immediate operands (including immediate-like displacements, i.e. when not > # part of ModR/M addressing) should be specified by separate .byte / .word / > # .long / .quad (or alike) directives. > # TBD: How to deal with this for RIP-relative addressing? > # TBD: How to deal with this for 4-operand insns? > > # When register operand size varies for an actual insn (like e.g. for MOVZX or > # VPMOVZX*), registers nevertheless need spelling out in a uniform manner, such > # that any of them could be used to derive operand size attributes (e.g. > # operand size prefix, REX.W, VEX.W, or VEX.L) as well as the EVEX Disp8 > # scaling factor. > # TBD: Could also go from largest operand size, albeit that may end up confusing > # in AT&T mode, where memory operands don't have size, yet the memory > # operand may have larger size than the register one(s) (and would hence be > # the one which the attribute - see below - needs deriving from). > > # For VEX / XOP / EVEX is arranged like this: > # {VEX,XOP,EVEX}[.][.][.][.] > # where > # - can be LIG, 128, 256, or (EVEX only) 512 as well as L0/L1 for > # VEX / XOP and L0-L3 for EVEX, > # - can be NP, 66, F3, or F2, > # - can be > # - 0f, 0f38, 0f3a, or M0...M31 for VEX, > # - 08...3f (hex) for XOP, > # - 0f, 0f38, 0f3a, or M0...M15 for EVEX, > # - can be WIG, W0, or W1. > # Omitted means "infer from operand size" if there is at least one > # sized operand, or LIG otherwise. > # Omitted means NP. > # Omitted implies encoding is taken from . > # Omitted means "infer from GPR operand size" if there is at least > # one GPR operand, or WIG otherwise. > > # TBD: Is operand order being dependent on AT&T vs Intel syntax okay? > > .insn 0x90 # nop > .insn 0xf390 # pause > .insn rep 0x90 # pause > .insn 0xd9c9 # fxch > .insn 0xf30f01d9 # vmgexit > > .insn 0x89, %ecx, %eax # mov %ecx, %eax > .insn 0x89, %ax, %cx # mov %ax, %cx > > .insn 0x8b, (%eax), %ecx # mov (%eax), %ecx > > .insn 0x0fc8+r, %edx # bswap %edx > > .insn lock 0x80/0, %fs:(%eax); .byte 1 # lock addb $1, %fs:(%eax) > > 1: > .insn 0xe2; .byte 1b-.-1 # loop 1b > .insn 0xc7f8; .long 1b-.-4 # xbegin 1b > > .insn 0x0fb6, %ax, %cx # movzx %al, %cx > .insn 0x0fb7, %eax, %ecx # movzx %ax, %ecx > > .insn VEX.66.0F 0x58, %xmm0, %xmm1, %xmm2 # vaddpd %xmm0, %xmm1, %xmm2 > .insn VEX.66 0x0f58, %ymm0, %ymm1, %ymm2 # vaddpd %ymm0, %ymm1, %ymm2 > .insn VEX.LIG.F3.0F 0x58, %xmm0, %xmm1, %xmm2 # vaddss %xmm0, %xmm1, %xmm2 > > .insn VEX.66.0F3A.W0 0x68, %xmm0, %xmm1, (%edx), %xmm3 # vfmaddps %xmm0, %xmm1, (%edx), %xmm3 > .insn VEX.66.0F3A.W1 0x68, %xmm0, %xmm1, (%edx), %xmm3 # vfmaddps %xmm0, %xmm1, %xmm3, (%edx) > .insn VEX.66.0F3A.W1 0x68, %xmm0, %xmm1, %xmm2, (%ebx) # vfmaddps %xmm0, %xmm1, %xmm2, (%ebx) > > .insn VEX.66.0F3A.W0 0x48, $0, %xmm0, %xmm1, (%edx), %xmm3 # vpermil2ps $0, %xmm0, %xmm1, (%edx), %xmm3 > .insn VEX.66.0F3A.W1 0x48, $1, %xmm0, %xmm1, (%edx), %xmm3 # vpermil2ps $1, %xmm0, %xmm1, %xmm3, (%edx) > .insn VEX.66.0F3A.W1 0x48, $2, %xmm0, %xmm1, %xmm2, (%ebx) # vpermil2ps $2, %xmm0, %xmm1, %xmm2, (%ebx) > > .insn VEX.L0.0F.W0 0x93, %eax, %k0 # kmovw %eax, %k0 > > .insn VEX.256.0F.WIG 0x77 # vzeroall > > .insn EVEX.NP.0F.W0 0x58, {rn-sae}, %zmm0, %zmm1, %zmm2 # vaddps {rn-sae}, %zmm0, %zmm1, %zmm2 > .insn EVEX.66.0F.W1 0x58, 8(%eax){1to8}, %zmm1, %zmm2{%k2}{z} # vaddpd 8(%eax){1to8}, %zmm0, %zmm1{%k2}{z} > > # TBD: How to specify the Disp8 scaling factor here? (In Intel syntax we can simply > # use memory operand size.) > .insn EVEX.66.0F38.W0 0x88, 4(%eax), %ymm1 # vexpandps 4(%eax), %ymm1 I think it is a nice feature. But it will be very difficult to support all complex x86 encoding schemes which change over time. We can start with the regular encoding schemes first. -- H.J.