qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v3 25/30] target/ppc: Move ADDI, ADDIS to decodetree, impleme


From: Luis Fernando Fujita Pires
Subject: RE: [PATCH v3 25/30] target/ppc: Move ADDI, ADDIS to decodetree, implement PADDI
Date: Fri, 30 Apr 2021 11:23:29 +0000

From: Richard Henderson <richard.henderson@linaro.org>
> +&D              rt ra si
> +@D              ...... rt:5 ra:5 si:s16                 &D
> +
> +# If a prefix is allowed, decode with default values.
> +&PLS_D          rt ra si:int64_t r:bool
> +@PLS_D          ...... rt:5 ra:5 si:s16                 &PLS_D r=0
> +
> +### Fixed-Point Arithmetic Instructions
> +
> +ADDI            001110 ..... ..... ................     @PLS_D
> +ADDIS           001111 ..... ..... ................     @D
> diff --git a/target/ppc/insn64.decode b/target/ppc/insn64.decode index
> 9fc45d0614..f4272df724 100644
> --- a/target/ppc/insn64.decode
> +++ b/target/ppc/insn64.decode
> @@ -16,3 +16,18 @@
>  # You should have received a copy of the GNU Lesser General Public  # License
> along with this library; if not, see <http://www.gnu.org/licenses/>.
>  #
> +
> +# Many all of these instruction names would be prefixed by "P", # but
> +we share code with the non-prefixed instruction.
> +
> +# Format MLS:D and 8LS:D
> +&PLS_D          rt ra si:int64_t r:bool  !extern
> +%pls_si         32:s18 0:16
> +@PLS_D          ...... .. ... r:1 .. .................. \
> +                ...... rt:5 ra:5 ................       \
> +                &PLS_D si=%pls_si
> +
> +### Fixed-Point Arithmetic Instructions
> +
> +ADDI            000001 10 0--.-- ..................     \
> +                001110 ..... ..... ................     @PLS_D

I think we should reconsider using the same .decode file for both 32- and 
64-bit instructions, to avoid duplicating argument set definitions, and to keep 
the prefixed instructions close to their non-prefixed counterparts. For 
ADDI/PADDI, something along the lines of:

&PLS_D          rt ra si:int64_t r:bool

%pls_si         32:s18 0:16
@PLS_D          ...... .. ... r:1 .. .................. \
                ...... rt:5 ra:5 ................       \
                &PLS_D si=%pls_si

@PLS_D_32       ...... rt:5 ra:5 si:s16                 &PLS_D r=0

PADDI           000001 10 0--.-- ..................     \
                001110 ..... ..... ................     @PLS_D
ADDI            001110 ..... ..... ................     @PLS_D_32
ADDIS           001111 ..... ..... ................     @D

That's where I was going with the original patch, using the varinsnwidth 
support from decodetree.py.

And, in order to share the trans_PADDI/ADDI implementation, maybe add something 
to decodetree.py to allow us to specify that an instruction shares the 
trans_XX() implementation from another one, such as:
ADDI            001110 ..... ..... ................     @PLS_D_32 !impl=PADDI

This way, we could (and would need to, in fact) keep the 'P' in the prefixed 
instruction names, but at the same time avoid having extra trans_XX functions 
just calling another one without any additional code.

For the load functions, we would then have:

%ds_si          2:s14  !function=times_4
@PLS_DS_32      ...... rt:5 ra:5 .............. ..      &PLS_D si=%ds_si r=0

&X              rt ra rb
@X              ...... rt:5 ra:5 rb:5 .......... .      &X

PLBZ            000001 10 0--.-- .................. \
                100010 ..... ..... ................     @PLS_D
LBZ             100010 ..... ..... ................     @PLS_D_32 !impl=PLBZ
LBZU            100011 ..... ..... ................     @PLS_D_32
LBZX            011111 ..... ..... ..... 0001010111 -   @X
LBZUX           011111 ..... ..... ..... 0001110111 -   @X

PLHZ            000001 10 0--.-- .................. \
                101000 ..... ..... ................     @PLS_D
LHZ             101000 ..... ..... ................     @PLS_D_32 !impl=PLHZ
LHZU            101001 ..... ..... ................     @PLS_D_32
LHZX            011111 ..... ..... ..... 0100010111 -   @X
LHZUX           011111 ..... ..... ..... 0100110111 -   @X

PLHA            000001 10 0--.-- .................. \
                101010 ..... ..... ................     @PLS_D
LHA             101010 ..... ..... ................     @PLS_D_32 !impl=PLHA
LHAU            101011 ..... ..... ................     @PLS_D_32
LHAX            011111 ..... ..... ..... 0101010111 -   @X
LHAXU           011111 ..... ..... ..... 0101110111 -   @X

PLWZ            000001 10 0--.-- .................. \
                100000 ..... ..... ................     @PLS_D
LWZ             100000 ..... ..... ................     @PLS_D_32 !impl=PLWZ
LWZU            100001 ..... ..... ................     @PLS_D_32
LWZX            011111 ..... ..... ..... 0000010111 -   @X
LWZUX           011111 ..... ..... ..... 0000110111 -   @X

PLWA            000001 00 0--.-- .................. \
                101001 ..... ..... ................     @PLS_D
LWA             111010 ..... ..... ..............10     @PLS_DS_32 !impl=PLWA
LWAX            011111 ..... ..... ..... 0101010101 -   @X
LWAUX           011111 ..... ..... ..... 0101110101 -   @X

PLD             000001 00 0--.-- .................. \
                111001 ..... ..... ................     @PLS_D
LD              111010 ..... ..... ..............00     @PLS_DS_32 !impl=PLD
LDU             111010 ..... ..... ..............01     @PLS_DS_32
LDX             011111 ..... ..... ..... 0000010101 -   @X
LDUX            011111 ..... ..... ..... 0000110101 -   @X

--
Luis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]