From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=HfcP=53=rivosinc.com=nelson@sourceware.org>
Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b])
	by sourceware.org (Postfix) with ESMTPS id F3B813858C2D
	for <binutils@sourceware.org>; Mon, 30 Jan 2023 03:03:36 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F3B813858C2D
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com
Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-163bd802238so1336778fac.1
        for <binutils@sourceware.org>; Sun, 29 Jan 2023 19:03:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=rivosinc-com.20210112.gappssmtp.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=55GA0JEdjQRMkulnq7ZndLmbKoLMT7p9RrTOqKDKZxw=;
        b=qu7zAc+xLit/1rMpIjDWLr+j1AT753GD8++7vAucI18sBaD45lFOJ56p/XuiM+tCiL
         6wnbuYfW5ZlylwnJXsiZszMgxaUDuJW+V+/kxfgBGXmvuVCyjMDRvA8fbGt+ekQH9rA6
         Y41bqp41X8pzmvuls71z3T6QTn8/Xyx0JO2i7ZGL+aEr9BKyLgtTLPntKBIMv4NzZTIc
         g1Sa81cUVva3a7oBvfQ+X4ToGSPMWVXH2+Tk/tF6knZ3xki1aBkMYQbTIr7ORkvfcmQ2
         /45bFF5+p259+42/SLMbQPOGhgf71EpkZOs2ujt/+mymom5rf7lda3IjoUsadmVvC66R
         k0hg==
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=55GA0JEdjQRMkulnq7ZndLmbKoLMT7p9RrTOqKDKZxw=;
        b=iPYjxQiONKZ+KjGjGkdFOGZb0Wo4BgTMRn/WB2GEt0WBjeV5nbyeht5Rz4BEmL6wLt
         in2twmuoG2TPBy2AVcDVLY+OTF/DuaIGBe8qP/5GIh6r4P2WKzVXyfcwMrTmitCq73xN
         0Gib4klI3HbT0+K47r6mWzR9A8VAhQB2EbDYCyMa2RvzmA+7lxII6e+1AB3WEGKj+cNt
         mC86hw5RR7CeaoGSRtUH6Fe/UhSrQkI9sTPP2WkrXlubT+Fkt8BEYFeYr0RnEcdIsw03
         2eZ/V9DNvvSd8ENw5+ra4Pmu/FuDpc51bhV0KKEe/j+J040Un+ot9SoIX/fPUG/lqo68
         of3Q==
X-Gm-Message-State: AO0yUKXvKL5nfKI9IXNPgATXaju1jgH/ZoOCuo7207hJPUYRIv9q1vHL
	uqwi2V2v0M93AVWISkU/JErAGeKVjxnHWfk2iX5GwFTp+I/ZwKbd
X-Google-Smtp-Source: AK7set85pClzP7ZMwEvCg34SVB44uKW/I0jagC+0RazNfpj/h+RNz+qVSjWioojSCLILSNVFCalsme6CYK9aXslnJfE=
X-Received: by 2002:a05:6870:f593:b0:163:aadd:a457 with SMTP id
 eh19-20020a056870f59300b00163aadda457mr303585oab.201.1675047816141; Sun, 29
 Jan 2023 19:03:36 -0800 (PST)
MIME-Version: 1.0
References: <dc521fdd-1462-0a4e-6d8e-5fa3f35c82b5@suse.com>
 <CAPpQWtBF+ND85kZ-pZRiYgrnJ95s1gXdgii-gzwsE20o8o_1nA@mail.gmail.com> <alpine.DEB.2.21.2301300149070.55843@angie.orcam.me.uk>
In-Reply-To: <alpine.DEB.2.21.2301300149070.55843@angie.orcam.me.uk>
From: Nelson Chu <nelson@rivosinc.com>
Date: Mon, 30 Jan 2023 11:03:25 +0800
Message-ID: <CAPpQWtAj5xoczt_8YNAwHK4mYNBfrsDqCz7gncX=6YUtWpPHew@mail.gmail.com>
Subject: Re: [PATCH] RISC-V: don't disassemble unrecognized insns as .byte
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Jan Beulich <jbeulich@suse.com>, Binutils <binutils@sourceware.org>, 
	Palmer Dabbelt <palmer@dabbelt.com>, Andrew Waterman <andrew@sifive.com>, 
	Jim Wilson <jim.wilson.gcc@gmail.com>, Kito Cheng <kito.cheng@sifive.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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: <binutils.sourceware.org>

Hi Maciej,

On Mon, Jan 30, 2023 at 9:51 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Mon, 30 Jan 2023, Nelson Chu wrote:
>
> > > Insn width granularity being 16 bits, produce 16 bits of data per output
> > > element for the non-special-cased insn widths. Besides being slightly
> > > more natural (in particular having the first element carry everything
> > > that's needed for determining insn length), this is also slightly more
> > > compact.
> >
> > Sounds reasonable and good, so please commit, thanks.
>
>  Why not `.short' though, the more usual pseudo-op (and documented as
> portable in the GAS manual)?

Not sure if there are any documents mentioning this, but I remember
that there has always been an issue of hoping to distinguish whether
the encodings is an instruction or data  The .<N>byte may not be used
to do that at the beginning (maybe just let dis-assembler dump the
legal formats, https://github.com/bminor/binutils-gdb/commit/6a7f57668afcd841e8fc6b507a27bb20e9209fa9),
but sometimes it has the same effect - For example, .2byte is an
instruction but unrecognized, .short is a data in text.  However, it
isn't good enough, since,

% cat tmp.s
.text
.short 0x1
.insn 0x1
.2byte 0x1
% riscv64-unknown-elf-as tmp.s -o tmp.o
% riscv64-unknown-elf-objdump -d tmp.o
...
Disassembly of section .text:

0000000000000000 <.text>:
   0: 0001                .short 0x0001
   2: 0001                .2byte 0x1
   4: 0001                .short 0x0001
...

The .<N>byte in assembly will also be treated as data to dump, so
ideally, dump these unrecognized instructions as .insn is probably
more reasonable and won't be confused.

Thanks
Nelson