qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	 Sebastian Mitterle <smitterl@redhat.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Laurent Vivier <laurent@vivier.eu>
Subject: Re: [risu PATCH 1/2] risugen: allow instructions with length > 32 bit
Date: Tue, 31 Oct 2023 15:34:14 +0000	[thread overview]
Message-ID: <CAFEAcA8NjMw2qPUeEs4U5zfdxq4H=Lb8-iW6QKohO76eZDUHjA@mail.gmail.com> (raw)
In-Reply-To: <20231027100441.375223-2-thuth@redhat.com>

On Fri, 27 Oct 2023 at 11:05, Thomas Huth <thuth@redhat.com> wrote:
>
> RISU currently only supports instructions with a length of
> 16 bit or 32 bit, however classical CISC systems like s390x
> also have instructions that are longer than 32 bit. Thus let's
> change the generator to support longer instructions, too.
>
> This adds support for 48-bit instructions on s390x, while
> the other architectures are just minimally changed to preserve
> the current state.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  risugen                | 48 +++++++++++++++++++++++++++++-------------
>  risugen_arm.pm         |  6 +++---
>  risugen_common.pm      |  2 +-
>  risugen_loongarch64.pm |  4 ++--
>  risugen_m68k.pm        |  6 +++---
>  risugen_ppc64.pm       |  4 ++--
>  risugen_s390x.pm       | 17 +++++++++++----
>  7 files changed, 57 insertions(+), 30 deletions(-)
>
> diff --git a/risugen b/risugen
> index fa94a39..833b459 100755
> --- a/risugen
> +++ b/risugen
> @@ -105,6 +105,16 @@ sub read_tokenised_line(*)
>      return @tokens;
>  }
>
> +sub check_bitmask($$)
> +{
> +    my ($fixedbits, $fixedbitmask) = @_;
> +
> +    if ((($fixedbits & $fixedbitmask) != $fixedbits)
> +        || (($fixedbits & ~$fixedbitmask) != 0)) {
> +        die "internal error: fixed bits not lined up with mask";
> +    }
> +}
> +
>  sub parse_config_file($)
>  {
>      # Read in the config file defining the instructions we can generate
> @@ -160,10 +170,11 @@ sub parse_config_file($)
>              exit(1);
>          }
>
> -        my $fixedbits = 0;
> -        my $fixedbitmask = 0;
> +        my @fixedbits = (0, 0, 0, 0);
> +        my @fixedbitmask = (0, 0, 0, 0);

I wonder if rather than turning these into arrays of integers, we
should use Perl bit vectors (see 'perldoc -f vec'). You can use those
to create arbitrary length bit-strings, and they directly support
the usual bitwise logical operators.

It's probably a bit of a bigger conversion job, though (and I
haven't needed to use them before, so there might be awkwardnesses
I haven't anticipated).

>          my $bitpos = 32;
> -        my $insnwidth = 32;
> +        my $wordpos = 0;
> +        my $insnwidth = 0;
>          my $seenblock = 0;
>
>          while (@bits) {
> @@ -217,36 +228,43 @@ sub parse_config_file($)
>
>              my $bitmask = oct("0b". '1' x $bitlen);
>              $bitpos -= $bitlen;
> +            $insnwidth += $bitlen;
>              if ($bitpos < 0) {
>                  print STDERR "$file:$.: ($insn $enc) too many bits specified\n";
>                  exit(1);
>              }
>
>              if (defined $bitval) {
> -                $fixedbits |= ($bitval << $bitpos);
> -                $fixedbitmask |= ($bitmask << $bitpos);
> +                $fixedbits[$wordpos] |= ($bitval << $bitpos);
> +                $fixedbitmask[$wordpos] |= ($bitmask << $bitpos);
>              } else {
> -                push @fields, [ $var, $bitpos, $bitmask ];
> +                push @fields, [ $var, $bitpos, $bitmask, $wordpos ];
> +            }
> +
> +            if ($bitpos == 0) {
> +                check_bitmask($fixedbits[$wordpos], $fixedbitmask[$wordpos]);
> +
> +                $wordpos += 1;
> +                if (@bits) {
> +                    $bitpos = 32;
> +                }
>              }
>          }
>          if ($bitpos == 16) {
>              # assume this is a half-width thumb instruction
>              # Note that we don't fiddle with the bitmasks or positions,
>              # which means the generated insn will be in the high halfword!

I suspect the process of conversion to bit-vectors will probably
imply fixing this bit of ugliness en route, incidentally.

> -            $insnwidth = 16;
> -        } elsif ($bitpos != 0) {
> -            print STDERR "$file:$.: ($insn $enc) not enough bits specified\n";
> +            check_bitmask($fixedbits[$wordpos], $fixedbitmask[$wordpos]);
> +        } elsif ($bitpos != 0 && $bitpos != 32) {
> +            print STDERR "$file:$.: ($insn $enc) not enough bits specified ($bitpos)\n";
>              exit(1);
>          }

thanks
-- PMM


  reply	other threads:[~2023-10-31 15:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-27 10:04 [risu PATCH 0/2] Add support for instructions with length > 32 bit Thomas Huth
2023-10-27 10:04 ` [risu PATCH 1/2] risugen: allow " Thomas Huth
2023-10-31 15:34   ` Peter Maydell [this message]
2023-10-27 10:04 ` [risu PATCH 2/2] s390x.risu: Add some instructions with a length of 48 bits Thomas Huth

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='CAFEAcA8NjMw2qPUeEs4U5zfdxq4H=Lb8-iW6QKohO76eZDUHjA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=iii@linux.ibm.com \
    --cc=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=smitterl@redhat.com \
    --cc=thuth@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).