From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 1DC663858400 for ; Mon, 11 Jul 2022 01:01:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1DC663858400 Received: by mail-pj1-x102b.google.com with SMTP id o5-20020a17090a3d4500b001ef76490983so3541438pjf.2 for ; Sun, 10 Jul 2022 18:01:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vbLqBUtAhhLkzJOxCxiAl+M3csk/3x78JGRNRE9PpbU=; b=6vAJan2w02mVErNdLrpb354PD+RZrx2wyoOkoEtmlsylrvxPcfjoqtoqqmnspTwsrz HydcOQG4WSJnMrZRaWwc/HsBurUHMvMcDUaJaSThmU/AeFgkTGApULYrWvcuInM1Y+Th Nbm8kmf2GdVCD9uqU2UNV8BQpZkclECyo7bn6DpuoygwbvONRFhoFCG9czJ3goWrn1cH mgFssOX5JFYkR5hKDxQjPEi5SnPPqESOTM0HsCU6DZdgqLp9shXSQHgmKtG8v9uOacan nZ/jAUPP/LgOfl++LV8KSbmJcSFV+qhvOuDUGWNfLyQXwhywYjJP3dbCWETYWefeXzZ6 eIcg== X-Gm-Message-State: AJIora/kedaqkeqxPQ752r5/uZeU66OLlJwX8ROvEBChyOrRBZSz0wPS +cwdNn5c1+aW/qMlYLei7uQ= X-Google-Smtp-Source: AGRyM1uDYNk8vX9jkBPlEGGd/UFBcb5/ImdPyRbrXQwT5bC8k109VX/PUe8JXboDiTeiVZ0EyThUsw== X-Received: by 2002:a17:902:b207:b0:16b:a6cc:d06a with SMTP id t7-20020a170902b20700b0016ba6ccd06amr16527516plr.113.1657501276820; Sun, 10 Jul 2022 18:01:16 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id z1-20020a170903018100b0016bfafffa0esm3261132plg.227.2022.07.10.18.01.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Jul 2022 18:01:16 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 571DC1140044; Mon, 11 Jul 2022 10:31:13 +0930 (ACST) Date: Mon, 11 Jul 2022 10:31:13 +0930 From: Alan Modra To: Dmitry Selyutin Cc: Binutils , Luke Kenneth Casson Leighton Subject: Re: Teaching expression() to treat some operations specially Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3030.9 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, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 01:01:20 -0000 On Sat, Jul 09, 2022 at 07:47:26PM +0300, Dmitry Selyutin wrote: > Hi folks, I'm still working on SVP64 extension support[0]. I'm now > checking the SVP64 predicates[1]. > Recently I stumbled upon the need to be able to resolve some complex > expressions as a single entity. > Here's the exhaustive list we're going to support: 1< r10, ~r10, r30, ~r30, lt, nl, ge, gt, ng, le, eq, ne, so, un, ns, nu. > All of these can be represented as macros. For example, let's consider > the instruction `sv.setb/dm=~r3/sm=1< When SVP64 parsing code sees dm= or sm=, it simply iterates over the > possible arguments[2]. > However, we'd also like to have macros support here, like: > > .set DM, ~r3 > .set SM, 1< sv.setb/dm=DM/sm=SM 5, 31 > > The obvious candidate was expression() routine, which I already > re-used for a simpler case when the value is always a constant[3]. > However, things like 1< how to handle these. > expression() would, as it seems, defer the calculation, since r3 is a symbol. > Instead, I'd like to teach expression() the knowledge that 1< combination is special. > > Two places I've been thinking of are ppc_parse_name() and register_name(). > The first one "hooks" the name lookup algorithm, but it unsurprizingly > only gets "r3" from "1< The second one seems like a minor hack, substituting expression() > logic (in fact, expression() is a fallback for it). PowerPC register operands are normally just plain numbers, or expressions that resolve to a number. "r3" is normally just a symbol, in fact people often use a bunch of defines to have a preprocessor replace "r3" with plain "3". That said, the assembler does recognise "%r3" as a register via register_name(), and plain "r3" if you pass -mregnames to gas. However, it only does that at the start of an operand expression. There's a good reason for that: We don't want to confuse the gas lexing code into smashing '%' into following alphas. We'd like '%' to have its normal meaning in a modulus expression. ppc_parse_name is a hook as you say (translating a register name to an O_register expression) but only for CR regs and condition expresions like "4*cr7+so". It is only enabled in contexts where such an expression is expected, again because gas lexing is simplistic. > To be honest, I'm not sure how to achieve the goal. In fact, I must > teach expression() to treat some operations specially in some > contexts. It seems to me you will firstly need to parse your example "sv.setb/dm=~r3/sm=1< Could you, please, recommend me options to achieve the goal? I want to > keep the logic clear to anyone potentially reading this code later. > > Thank you! > > [0] https://libre-soc.org/ > [1] https://libre-soc.org/openpower/sv/svp64/appendix/ > [2] https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc-svp64.c;h=9dfafa20347f5085653439f7bd4d70c1710a205d;hb=refs/heads/svp64-ng#l144 > [3] https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc-svp64.c;h=9dfafa20347f5085653439f7bd4d70c1710a205d;hb=refs/heads/svp64-ng#l349 > > -- > Best regards, > Dmitry Selyutin -- Alan Modra Australia Development Lab, IBM