From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 960453858C50 for ; Tue, 12 Jul 2022 08:50:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 960453858C50 Received: by mail-ej1-x629.google.com with SMTP id b11so13058731eju.10 for ; Tue, 12 Jul 2022 01:50:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VdOM3gZOB4s4f8YgoI4JHd5FgLyqJhG++UyhJd4O4Y0=; b=pHK9DBs9D9n1xtmDgk7/HRChOrnvKAZlcKh/s1t9RH6fuoG7CcCCRm7hFARqLv2Zke jrnvb9mnJSWgQFiwTO5DTBOT2YsdAWTRyhK437YBaZTyPrNgn1tI05DS6R7zaii69+/W yV3I10n0LRIJflDUbiV0J5vBpdAlZQBhVnmTz72dVWmT/2ScB7/TJoggUVHNU187encY 45IMQAOmafjf0Oht46inX1b7LnAb64i3qiUVky0f0PMp5XdSc1lRRYjz/tK0aWb4x5T5 X03iKWK6qkrDU57RE114Pr0UHTQYJIopmD1F6D3LxpkoAYJfd6EuVYpUYd5F0njTbWxL 6pSw== X-Gm-Message-State: AJIora8RbrMAdCU9vxy72UcBBqI87joBq4uMTXkQmicVVlN+SIGTGxy1 WnkLIMPrfvk6VAEEorfv3qDzl1j/HzxwY9gqVQ4= X-Google-Smtp-Source: AGRyM1stix8IGp6Ew1JDrbvvGao76cyNeD4dfWxbtv6QAvzT/QUixaV8fVj0ud2e09YZw2H9nL9gPgz8fws1+ut6GPU= X-Received: by 2002:a17:906:8301:b0:6e4:896d:59b1 with SMTP id j1-20020a170906830100b006e4896d59b1mr22945337ejx.396.1657615843472; Tue, 12 Jul 2022 01:50:43 -0700 (PDT) MIME-Version: 1.0 References: <2A99A5EA-C863-465C-A983-244A48D2E3C3@gmail.com> <473de1ae-ab00-357c-56e1-a12e2eab779a@suse.com> <6ede8e90-9db2-3676-3749-58382dd74e40@suse.com> In-Reply-To: <6ede8e90-9db2-3676-3749-58382dd74e40@suse.com> From: Dmitry Selyutin Date: Tue, 12 Jul 2022 11:50:06 +0300 Message-ID: Subject: Re: Teaching expression() to treat some operations specially To: Jan Beulich Cc: lkcl , Binutils , Alan Modra Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.7 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: Tue, 12 Jul 2022 08:50:46 -0000 On Tue, Jul 12, 2022 at 9:57 AM Jan Beulich wrote: > x86 uses it only for identifier-like unary operators. So it may > indeed be that * doesn't presently have a way to make it to > md_operator() when used in unary way. Frankly speaking, md_operator is somewhat confusing. What kind of arguments does it expect? I tried defining both -- ppc_parse_name, ppc_operand and ppc_operator. The exact sequence of how these are called depends on many conditions. Let's consider this code: .set REG, %r0 extsw REG, 2 By default, I don't see any calls to ppc_operator at all, only calls to ppc_operand. If I update tc-ppc.h with `#define LEX_PCT (LEX_BEGIN_NAME)`, ppc_operator is called before ppc_operand. internals.texi lacks any information on ppc_operator, so I'm unsure how to use it. Also, it's especially confusing to see this call: `md_operator (NULL, 2, NULL)`. Is there any documentation on how md_operator works? i386_operator doesn't really explain it. I think that, to make it work, lex_type must be updated with LEX_BEGIN_NAME with % and * symbols. But, considering the current depths of my knowledge for this code, these are mostly guesses. -- Best regards, Dmitry Selyutin