From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 72C6D3857BBC for ; Wed, 29 Jun 2022 11:01:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72C6D3857BBC Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-7-AUiP_9X6P1GhyRAicsxS5Q-1; Wed, 29 Jun 2022 07:01:51 -0400 X-MC-Unique: AUiP_9X6P1GhyRAicsxS5Q-1 Received: by mail-wm1-f72.google.com with SMTP id v184-20020a1cacc1000000b0039c7efa3e95so6447912wme.3 for ; Wed, 29 Jun 2022 04:01:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=cPDph87qTd8G7TzfOrQMr4XBFJIwrkokbcfrUMN10m4=; b=ajHZbo5S2PlfzVvJrU/LoPiDEYLUA0Jv40zHhkVVdSCBurZquncgy1cnglbZFK+5to JYBe/zOMF3zrOQ4gVTFTIR3oKBQwmMZTM6rx7SUeYFvOmy0Nxs/EJZiENmzcN3MaaRE+ 0JpsurMi1+IIcYMyJVYRdTJmEZN7h96MoBZVk2xliN55I2ac3XFU2vK7waeuaUzO+/TD pv6PacJAMwUk3vuYfRleuVXE+Nt5j+GZKz9+p6lkeHKVT4k9+SdM94zspprP8orVe9GN isVXLcHodxYKZKEg4DyFwQdWGiTB4ioYQUbeg+1Sp9KMUorA/Ijgvuf/WAWT9qJ2at8z oe1Q== X-Gm-Message-State: AJIora+FShNu/gQkMJdGFtgGndj8eALtgq+N95u3mMChu6XDqPG4HX88 q1WpOQVrM7V9OadRugwv1JXTQ0nKsIG4mOiD72AM8ZAbbbW/A+P1dU679RtZrQZwmCfuOKW9Y8z soZlx+omXeudVEwGS1Q== X-Received: by 2002:a5d:6d0c:0:b0:21b:ccda:fc67 with SMTP id e12-20020a5d6d0c000000b0021bccdafc67mr2561236wrq.246.1656500509774; Wed, 29 Jun 2022 04:01:49 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uuK0R3zkT0NhUJ/VvGBiYTpsQoqtuB80por153i5FXpLooQSOqEAMMiquOXQtDoOp0HT5oSg== X-Received: by 2002:a5d:6d0c:0:b0:21b:ccda:fc67 with SMTP id e12-20020a5d6d0c000000b0021bccdafc67mr2561217wrq.246.1656500509569; Wed, 29 Jun 2022 04:01:49 -0700 (PDT) Received: from localhost (15.72.115.87.dyn.plus.net. [87.115.72.15]) by smtp.gmail.com with ESMTPSA id h5-20020a5d4305000000b00210bac248c8sm16263057wrq.11.2022.06.29.04.01.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jun 2022 04:01:48 -0700 (PDT) From: Andrew Burgess To: Nick Clifton , binutils@sourceware.org Subject: Re: [PATCH 2/2] libopcodes/aarch64: add support for disassembler styling In-Reply-To: <0c1f6276-4e1e-a756-ba21-33855d073b2b@redhat.com> References: <96b9a3395da12da7c5a5ad7d5ae7498f5b81c28f.1655810414.git.aburgess@redhat.com> <0c1f6276-4e1e-a756-ba21-33855d073b2b@redhat.com> Date: Wed, 29 Jun 2022 12:01:47 +0100 Message-ID: <87tu83d97o.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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: Wed, 29 Jun 2022 11:01:56 -0000 Nick Clifton via Binutils writes: > Hi Andrew, > >> I do still have a few questions about how some elements should be >> styled, consider this instruction: >> >> add x1, x2, x3, lsr #1 >> ~~~~~ ~~ ~~ ~~ ~ Plain text. >> ~~~ Mnemonic. >> ~~ ~~ ~~ Register. >> ~~ Immediate. >> ??? What to use here? >> >> The current patch formats the 'lsr' as text, but I wonder if this >> would be better formatted as mnemonic? Or maybe it should be >> considered part of the immediate? > > My $0.02 worth: It is not an immediate - in fact that instruction does > not have any immediates in it - nor is it just plain text. I suppose > that you might consider it as being an extension of the mnemonic, but > that also feels wrong to me. Could you create a new class for this > part of the instruction ? eg 'shifter' or 'sub-mnemonic'. If not then > I would go with mnemonic as that is the closest approximation. IMHO... We can add more styles. There's a small bit of work needed when we pass 16 styles, but that really is trivial. My reluctance is to adding new styles for every single architectural feature, ideally I'd like to map everything to a very small number of styles, enough to highlight different parts of the instruction, but not so many that the output looks like a crazy rainbow of colour. I initially went with mnemonic, but wasn't sure what people would think of having the mnemonic split into multiple parts like this. Adding a sub-mnemonic could be a good solution, it keeps the number of styles low, but allows us to (potentially) style these parts differently in the future. > > >> I have a similar question for how to format 'ge' in: >> >> ccmp x1, x2, #0xa, ge > > The same reasoning applies here I feel. This is "ccmp-ge" instruction > with the condition expressed as a separate field in the disassembled > text. Ideally a "condition-code" class could be used to express its > style, but if that is not possible then mnemonic is the next best > thing. > > >> And how to format 'sxtb' in: >> > adds x0, sp, w0, sxtb > > Ditto. Maybe an "extender" class could be used here ? > > > The patch itself looks good to me, but I would like to wait to see if > anyone else has any comments on the code before approving it. Thanks, I'll merge the first patch from this series, but leave this second one to see what opinions others have. Thanks, Andrew