All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cupertino Miranda <Cupertino.Miranda@synopsys.com>
To: Richard Henderson <richard.henderson@linaro.org>,
	Cupertino Miranda <Cupertino.Miranda@synopsys.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Shahab Vahedi <Shahab.Vahedi@synopsys.com>,
	Claudiu Zissulescu <Claudiu.Zissulescu@synopsys.com>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"cupertinomiranda@gmail.com" <cupertinomiranda@gmail.com>
Subject: Re: QEmu ARC port - decoder implementation feedback
Date: Wed, 9 Jun 2021 20:00:45 +0000	[thread overview]
Message-ID: <0a58c2fd-41a8-d496-6aa0-f1a7296bc15b@synopsys.com> (raw)
In-Reply-To: <0c90a8c4-0977-b11b-b543-9eef4d4d14c3@linaro.org>

Hi Richard

> Why would you be maintaining another description?  Your approach below 
> with the simple recursive algorithm appears to be no different.

We initially considered to drop our tables completely replacing it by 
decodetree.

>
>> Also that decodetree alone would not allow us to properly disassembly
>> code, still requiring to keep the initial structure.
>
> Why is that?

By disassembly I am referring to the pretty-print of the instructions 
when using "-d in_asm". Our tables contain information for printing as 
they are the ones used by bintutils assembler.

>
> The current uses of decodetree are quite complex, so I sincerely doubt 
> that it cannot do the job.  You've asked no questions, nor have you 
> described any problems you have encountered.

There where no problems from the perspective of understanding what it 
did or how to use it.
It was just that auto generating of the decodetree seemed more then a 
simple task but a rather elaborated one, since we needed to identify 
common operand style instructions, group similar instruction conflicting 
encodings, etc. And when comparing to the ease of automating the 
creation of the decoding trees, seemed much more complex.

>
> The example is not especially enlightening because you don't show the 
> macro definitions, or the expansion.  Have you a link to a git repo 
> that you can share?
I do have. Please allow me a few days to properly clean it. Considering, 
I wanted to get your opinion before of a greater commitment to the 
solution, it is still in a prototype stage.

Cupertino

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

WARNING: multiple messages have this Message-ID (diff)
From: Cupertino Miranda <Cupertino.Miranda@synopsys.com>
To: Richard Henderson <richard.henderson@linaro.org>,
	Cupertino Miranda <Cupertino.Miranda@synopsys.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Shahab Vahedi <Shahab.Vahedi@synopsys.com>,
	Claudiu Zissulescu <Claudiu.Zissulescu@synopsys.com>,
	"linux-snps-arc@lists.infradead.org"
	<linux-snps-arc@lists.infradead.org>,
	"cupertinomiranda@gmail.com" <cupertinomiranda@gmail.com>
Subject: Re: QEmu ARC port - decoder implementation feedback
Date: Wed, 9 Jun 2021 20:00:45 +0000	[thread overview]
Message-ID: <0a58c2fd-41a8-d496-6aa0-f1a7296bc15b@synopsys.com> (raw)
In-Reply-To: <0c90a8c4-0977-b11b-b543-9eef4d4d14c3@linaro.org>

Hi Richard

> Why would you be maintaining another description?  Your approach below 
> with the simple recursive algorithm appears to be no different.

We initially considered to drop our tables completely replacing it by 
decodetree.

>
>> Also that decodetree alone would not allow us to properly disassembly
>> code, still requiring to keep the initial structure.
>
> Why is that?

By disassembly I am referring to the pretty-print of the instructions 
when using "-d in_asm". Our tables contain information for printing as 
they are the ones used by bintutils assembler.

>
> The current uses of decodetree are quite complex, so I sincerely doubt 
> that it cannot do the job.  You've asked no questions, nor have you 
> described any problems you have encountered.

There where no problems from the perspective of understanding what it 
did or how to use it.
It was just that auto generating of the decodetree seemed more then a 
simple task but a rather elaborated one, since we needed to identify 
common operand style instructions, group similar instruction conflicting 
encodings, etc. And when comparing to the ease of automating the 
creation of the decoding trees, seemed much more complex.

>
> The example is not especially enlightening because you don't show the 
> macro definitions, or the expansion.  Have you a link to a git repo 
> that you can share?
I do have. Please allow me a few days to properly clean it. Considering, 
I wanted to get your opinion before of a greater commitment to the 
solution, it is still in a prototype stage.

Cupertino


  reply	other threads:[~2021-06-09 20:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09  9:58 QEmu ARC port - decoder implementation feedback Cupertino Miranda
2021-06-09  9:58 ` Cupertino Miranda
2021-06-09 16:39 ` Richard Henderson
2021-06-09 16:39   ` Richard Henderson
2021-06-09 20:00   ` Cupertino Miranda [this message]
2021-06-09 20:00     ` Cupertino Miranda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a58c2fd-41a8-d496-6aa0-f1a7296bc15b@synopsys.com \
    --to=cupertino.miranda@synopsys.com \
    --cc=Claudiu.Zissulescu@synopsys.com \
    --cc=Shahab.Vahedi@synopsys.com \
    --cc=cupertinomiranda@gmail.com \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.