From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D20A5C2D0CE for ; Fri, 24 Jan 2020 23:39:25 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 998BB206D3 for ; Fri, 24 Jan 2020 23:39:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EdRqePel" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 998BB206D3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:49420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iv8Xs-0003mG-QP for qemu-devel@archiver.kernel.org; Fri, 24 Jan 2020 18:39:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37225) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iv8XK-0003L9-2K for qemu-devel@nongnu.org; Fri, 24 Jan 2020 18:38:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iv8XI-0005Xl-Oo for qemu-devel@nongnu.org; Fri, 24 Jan 2020 18:38:50 -0500 Received: from mail-oi1-x244.google.com ([2607:f8b0:4864:20::244]:36030) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iv8XI-0005XS-Jt for qemu-devel@nongnu.org; Fri, 24 Jan 2020 18:38:48 -0500 Received: by mail-oi1-x244.google.com with SMTP id c16so1229605oic.3 for ; Fri, 24 Jan 2020 15:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bobFM9QSLTXtDDyIo/yJYvnJlh1qMX8i5BAB156yWyE=; b=EdRqePelbfFgyHYI6rXtwsGmnUpEKgYZVo/DkK1L9wpPsVv/vEsCCifmg1/GSQDDUm UHOm3p+Ro2lgbxT5qS5eg10U/IfJu3c9L1o4T+zz2PcPaLdaezs/aOCaG/Xzc8cajbGg GQHz9xEyWrZb87OExRnHqTGncBDgdUt+76CieX3FO06YDnW4o0JzakVJrhF/Lp7BhdDJ 7pEeQ5sAZTkNPGIb2FpUP6QHMBQGuuxf8nNutYVEfoog72ZkNNddbl0Hm+tx9MZoZmC8 ein17K4HbdArasvPkrru9/CiaGIkCs0YADMkputfE3r8zeMZC7u7e87ZoHXHnbubWg// Mj/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bobFM9QSLTXtDDyIo/yJYvnJlh1qMX8i5BAB156yWyE=; b=WPhzvGa9wCqmy2bnqrxCSagUHEoW54alpLQFuA42g6WHt6Dy5JshGd6tfWom6VIDnw wjfXw7c2uLhbBNifJv6SiU/pUyC41Heyc6nzNcLOdkG6FMw0LR26TJrONd+9n9Uy4ZFX 7yuf/72/0kFbsVlUAHcndamDVxsVg61n/mihRZ3rMWUldOZsO7L/HlodHiloXJ0+Zh/l qPiqUo+j10+a9fFFTtZOkOdYWtx+8esXDuYKOgqAL8bYygtzKekgkwjXlHPybB2a9SSq pOAURWrL7ZHxA51SQa3GMXyilKJqMMpWJv6SMvhmo1Gh/SKVh83bKoxyjOtycHrIl5xG Rgfw== X-Gm-Message-State: APjAAAWGmYHb8GSn4QgDVoX7FNC4Bg+WEssOKRTl6XWN/ii0VFkzw/7o 5S9hwom5ob4LyXy6E/JN/kp+vnRY2rd336SQlyw= X-Google-Smtp-Source: APXvYqyamQReP1eAINrF7/JpH0NqpXxPD5d1nq/oH3YgatvuNoWgdICGDOvpLd8n3H+cuhWbzNPdD+CGacDeFXTjy9o= X-Received: by 2002:a05:6808:6c5:: with SMTP id m5mr888631oih.106.1579909127579; Fri, 24 Jan 2020 15:38:47 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:d21:0:0:0:0:0 with HTTP; Fri, 24 Jan 2020 15:38:47 -0800 (PST) In-Reply-To: References: <1579883929-1517-1-git-send-email-aleksandar.markovic@rt-rk.com> <1579883929-1517-7-git-send-email-aleksandar.markovic@rt-rk.com> <779b7b35-16a8-0538-ad87-fac218c93e82@linaro.org> From: Aleksandar Markovic Date: Sat, 25 Jan 2020 00:38:47 +0100 Message-ID: Subject: Re: [PATCH v4 6/7] disas: mips: Add micromips R6 disassembler - infrastructure and 16-bit instructions To: Richard Henderson Content-Type: multipart/alternative; boundary="00000000000053ac40059ceb420f" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::244 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aleksandar Markovic , "aurelien@aurel32.net" , "aleksandar.rikalo@rt-rk.com" , "qemu-devel@nongnu.org" , "amarkovic@wavecomp.com" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000053ac40059ceb420f Content-Type: text/plain; charset="UTF-8" On Friday, January 24, 2020, Richard Henderson wrote: > On 1/24/20 10:56 AM, Aleksandar Markovic wrote: > > > > > > On Friday, January 24, 2020, Richard Henderson < > richard.henderson@linaro.org > > > wrote: > > > > On 1/24/20 6:38 AM, Aleksandar Markovic wrote: > > > The basic disassembly logic was obtained by somewhat modified > script > > > decodetree.py, and such output was further manually modified to > > > handle numerous details of micromips 32R6 instruction coding > scheme. > > > > What modifications to the script? > > What manual modifications to the output? > > > > It's been a while since I looked at micromips, but I don't recall > anything so > > odd that it couldn't be handled with the current output of > decodetree.py. > > > > > > I don't have dev setup at hand right now, but I can look it up in few > days. > > Some of the changes are purely of cosmetic nature (like outputing binary > > instead of hex codes), but some are not. I can send you the whole > modified > > script, once I come back to my desk. There are some not-so-obvious > micromips > > oddities, if one delves enough into the coding scheme. > > The thing I'm concerned about here is any future maintenance of this > file. One > would surely prefer to edit the original decodetree input than this output. > > Here is the deal: This dissasembler is meant to reflect the documentation of a particular ISA, and as the documentation largely stays constant (except adding some insignificant errata), the disassembler will stay virtually constant, we wouldn't like even to touch it, and we like it this way. > r~ > --00000000000053ac40059ceb420f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Friday, January 24, 2020, Richard Henderson <richard.henderson@linaro.org> wrote:=
On 1/24/20 10:56 AM, Aleksandar Markovic= wrote:
>
>
> On Friday, January 24, 2020, Richard Henderson <richard.henderson@linaro.org
> <mailto:richard.hen= derson@linaro.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 1/24/20 6:38 AM, Aleksandar Markovic wrote:
>=C2=A0 =C2=A0 =C2=A0> The basic disassembly logic was obtained by so= mewhat modified script
>=C2=A0 =C2=A0 =C2=A0> decodetree.py, and such output was further man= ually modified to
>=C2=A0 =C2=A0 =C2=A0> handle numerous details of micromips 32R6 inst= ruction coding scheme.
>
>=C2=A0 =C2=A0 =C2=A0What modifications to the script?
>=C2=A0 =C2=A0 =C2=A0What manual modifications to the output?
>
>=C2=A0 =C2=A0 =C2=A0It's been a while since I looked at micromips, = but I don't recall anything so
>=C2=A0 =C2=A0 =C2=A0odd that it couldn't be handled with the curren= t output of decodetree.py.
>
>
> I don't have dev setup at hand right now, but I can look it up in = few days.
> Some of the changes are purely of cosmetic nature (like outputing bina= ry
> instead of hex codes), but some are not. I can send you the whole modi= fied
> script, once I come back to my desk. There are some not-so-obvious mic= romips
> oddities, if one delves enough into the coding scheme.

The thing I'm concerned about here is any future maintenance of this fi= le.=C2=A0 One
would surely prefer to edit the original decodetree input than this output.=


Here is the deal: This dissasembler is= meant to reflect the =C2=A0documentation of a particular ISA, and as the d= ocumentation largely stays constant (except adding some insignificant errat= a), the disassembler will stay virtually constant, we wouldn't like eve= n to touch it, and we like it this way.


r~
--00000000000053ac40059ceb420f--