2011-09-27 06:30:58 +02:00
|
|
|
/*
|
|
|
|
|
* Tiny Code Interpreter for QEMU
|
|
|
|
|
*
|
2016-04-05 22:24:51 +02:00
|
|
|
* Copyright (c) 2009, 2011, 2016 Stefan Weil
|
2011-09-27 06:30:58 +02:00
|
|
|
*
|
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation, either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
*/
|
|
|
|
|
|
2016-01-29 18:50:05 +01:00
|
|
|
#include "qemu/osdep.h"
|
2011-09-27 06:30:58 +02:00
|
|
|
#include "qemu-common.h"
|
2016-05-20 13:57:31 +02:00
|
|
|
#include "tcg/tcg.h" /* MAX_OPC_PARAM_IARGS */
|
2014-03-28 19:42:10 +01:00
|
|
|
#include "exec/cpu_ldst.h"
|
2020-01-01 12:23:00 +01:00
|
|
|
#include "tcg/tcg-op.h"
|
2021-07-27 23:10:22 +02:00
|
|
|
#include "tcg/tcg-ldst.h"
|
cfi: Initial support for cfi-icall in QEMU
LLVM/Clang, supports runtime checks for forward-edge Control-Flow
Integrity (CFI).
CFI on indirect function calls (cfi-icall) ensures that, in indirect
function calls, the function called is of the right signature for the
pointer type defined at compile time.
For this check to work, the code must always respect the function
signature when using function pointer, the function must be defined
at compile time, and be compiled with link-time optimization.
This rules out, for example, shared libraries that are dynamically loaded
(given that functions are not known at compile time), and code that is
dynamically generated at run-time.
This patch:
1) Introduces the CONFIG_CFI flag to support cfi in QEMU
2) Introduces a decorator to allow the definition of "sensitive"
functions, where a non-instrumented function may be called at runtime
through a pointer. The decorator will take care of disabling cfi-icall
checks on such functions, when cfi is enabled.
3) Marks functions currently in QEMU that exhibit such behavior,
in particular:
- The function in TCG that calls pre-compiled TBs
- The function in TCI that interprets instructions
- Functions in the plugin infrastructures that jump to callbacks
- Functions in util that directly call a signal handler
Signed-off-by: Daniele Buono <dbuono@linux.vnet.ibm.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org
Message-Id: <20201204230615.2392-3-dbuono@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-05 00:06:12 +01:00
|
|
|
#include "qemu/compiler.h"
|
2021-01-30 23:24:25 +01:00
|
|
|
#include <ffi.h>
|
2011-09-27 06:30:58 +02:00
|
|
|
|
2021-01-30 23:24:25 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Enable TCI assertions only when debugging TCG (and without NDEBUG defined).
|
|
|
|
|
* Without assertions, the interpreter runs much faster.
|
|
|
|
|
*/
|
|
|
|
|
#if defined(CONFIG_DEBUG_TCG)
|
|
|
|
|
# define tci_assert(cond) assert(cond)
|
2011-09-27 06:30:58 +02:00
|
|
|
#else
|
2021-01-30 23:24:25 +01:00
|
|
|
# define tci_assert(cond) ((void)(cond))
|
2011-09-27 06:30:58 +02:00
|
|
|
#endif
|
|
|
|
|
|
2021-01-24 21:57:01 +01:00
|
|
|
__thread uintptr_t tci_tb_ptr;
|
|
|
|
|
|
2017-07-13 23:10:31 +02:00
|
|
|
static void tci_write_reg64(tcg_target_ulong *regs, uint32_t high_index,
|
|
|
|
|
uint32_t low_index, uint64_t value)
|
2011-09-27 06:30:58 +02:00
|
|
|
{
|
2021-02-03 02:21:27 +01:00
|
|
|
regs[low_index] = (uint32_t)value;
|
2021-02-01 22:30:30 +01:00
|
|
|
regs[high_index] = value >> 32;
|
2011-09-27 06:30:58 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Create a 64 bit value from two 32 bit values. */
|
|
|
|
|
static uint64_t tci_uint64(uint32_t high, uint32_t low)
|
|
|
|
|
{
|
|
|
|
|
return ((uint64_t)high << 32) + low;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 23:55:41 +01:00
|
|
|
/*
|
|
|
|
|
* Load sets of arguments all at once. The naming convention is:
|
|
|
|
|
* tci_args_<arguments>
|
|
|
|
|
* where arguments is a sequence of
|
|
|
|
|
*
|
2021-01-30 09:36:40 +01:00
|
|
|
* b = immediate (bit position)
|
2021-01-30 00:14:11 +01:00
|
|
|
* c = condition (TCGCond)
|
2021-01-30 08:49:24 +01:00
|
|
|
* i = immediate (uint32_t)
|
|
|
|
|
* I = immediate (tcg_target_ulong)
|
2021-01-30 08:18:45 +01:00
|
|
|
* l = label or pointer
|
2021-07-26 00:06:49 +02:00
|
|
|
* m = immediate (MemOpIdx)
|
2021-01-30 23:24:25 +01:00
|
|
|
* n = immediate (call return length)
|
2021-01-29 23:55:41 +01:00
|
|
|
* r = register
|
|
|
|
|
* s = signed ldst offset
|
|
|
|
|
*/
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_l(uint32_t insn, const void *tb_ptr, void **l0)
|
2021-01-30 22:23:02 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
int diff = sextract32(insn, 12, 20);
|
|
|
|
|
*l0 = diff ? (void *)tb_ptr + diff : NULL;
|
2021-01-30 22:23:02 +01:00
|
|
|
}
|
|
|
|
|
|
2021-02-02 20:40:22 +01:00
|
|
|
static void tci_args_r(uint32_t insn, TCGReg *r0)
|
|
|
|
|
{
|
|
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_nl(uint32_t insn, const void *tb_ptr,
|
|
|
|
|
uint8_t *n0, void **l1)
|
2021-01-30 08:18:45 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*n0 = extract32(insn, 8, 4);
|
|
|
|
|
*l1 = sextract32(insn, 12, 20) + (void *)tb_ptr;
|
2021-01-30 08:18:45 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rl(uint32_t insn, const void *tb_ptr,
|
|
|
|
|
TCGReg *r0, void **l1)
|
2021-01-30 23:24:25 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*l1 = sextract32(insn, 12, 20) + (void *)tb_ptr;
|
2021-01-30 23:24:25 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rr(uint32_t insn, TCGReg *r0, TCGReg *r1)
|
2021-02-01 20:41:20 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
2021-02-01 20:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_ri(uint32_t insn, TCGReg *r0, tcg_target_ulong *i1)
|
2021-01-30 00:05:01 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*i1 = sextract32(insn, 12, 20);
|
2021-01-30 00:05:01 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrm(uint32_t insn, TCGReg *r0,
|
2021-07-26 00:06:49 +02:00
|
|
|
TCGReg *r1, MemOpIdx *m2)
|
2021-01-30 08:49:24 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*m2 = extract32(insn, 20, 12);
|
2021-01-30 08:49:24 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrr(uint32_t insn, TCGReg *r0, TCGReg *r1, TCGReg *r2)
|
2021-01-30 08:49:24 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
2021-01-30 08:49:24 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrs(uint32_t insn, TCGReg *r0, TCGReg *r1, int32_t *i2)
|
2021-01-30 09:52:12 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*i2 = sextract32(insn, 16, 16);
|
2021-01-30 09:52:12 +01:00
|
|
|
}
|
|
|
|
|
|
2021-02-03 01:48:48 +01:00
|
|
|
static void tci_args_rrbb(uint32_t insn, TCGReg *r0, TCGReg *r1,
|
|
|
|
|
uint8_t *i2, uint8_t *i3)
|
|
|
|
|
{
|
|
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*i2 = extract32(insn, 16, 6);
|
|
|
|
|
*i3 = extract32(insn, 22, 6);
|
|
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrrc(uint32_t insn,
|
2021-01-30 00:14:11 +01:00
|
|
|
TCGReg *r0, TCGReg *r1, TCGReg *r2, TCGCond *c3)
|
|
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
|
|
|
|
*c3 = extract32(insn, 20, 4);
|
2021-01-30 00:14:11 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrrm(uint32_t insn,
|
2021-07-26 00:06:49 +02:00
|
|
|
TCGReg *r0, TCGReg *r1, TCGReg *r2, MemOpIdx *m3)
|
2021-01-30 09:52:12 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
|
|
|
|
*m3 = extract32(insn, 20, 12);
|
2021-01-30 09:52:12 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrrbb(uint32_t insn, TCGReg *r0, TCGReg *r1,
|
2021-01-30 09:36:40 +01:00
|
|
|
TCGReg *r2, uint8_t *i3, uint8_t *i4)
|
|
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
|
|
|
|
*i3 = extract32(insn, 20, 6);
|
|
|
|
|
*i4 = extract32(insn, 26, 6);
|
2021-01-30 09:36:40 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrrrr(uint32_t insn, TCGReg *r0, TCGReg *r1,
|
|
|
|
|
TCGReg *r2, TCGReg *r3, TCGReg *r4)
|
2021-01-30 09:52:12 +01:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
|
|
|
|
*r3 = extract32(insn, 20, 4);
|
|
|
|
|
*r4 = extract32(insn, 24, 4);
|
2021-01-30 09:52:12 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrrr(uint32_t insn,
|
2021-01-30 09:18:37 +01:00
|
|
|
TCGReg *r0, TCGReg *r1, TCGReg *r2, TCGReg *r3)
|
|
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
|
|
|
|
*r3 = extract32(insn, 20, 4);
|
2021-01-30 09:18:37 +01:00
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrrrrc(uint32_t insn, TCGReg *r0, TCGReg *r1,
|
2021-01-30 08:30:04 +01:00
|
|
|
TCGReg *r2, TCGReg *r3, TCGReg *r4, TCGCond *c5)
|
|
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
|
|
|
|
*r3 = extract32(insn, 20, 4);
|
|
|
|
|
*r4 = extract32(insn, 24, 4);
|
|
|
|
|
*c5 = extract32(insn, 28, 4);
|
2021-01-30 08:30:04 +01:00
|
|
|
}
|
2021-01-30 09:16:05 +01:00
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
static void tci_args_rrrrrr(uint32_t insn, TCGReg *r0, TCGReg *r1,
|
2021-01-30 09:16:05 +01:00
|
|
|
TCGReg *r2, TCGReg *r3, TCGReg *r4, TCGReg *r5)
|
|
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
*r0 = extract32(insn, 8, 4);
|
|
|
|
|
*r1 = extract32(insn, 12, 4);
|
|
|
|
|
*r2 = extract32(insn, 16, 4);
|
|
|
|
|
*r3 = extract32(insn, 20, 4);
|
|
|
|
|
*r4 = extract32(insn, 24, 4);
|
|
|
|
|
*r5 = extract32(insn, 28, 4);
|
2021-01-30 09:16:05 +01:00
|
|
|
}
|
2021-01-30 08:30:04 +01:00
|
|
|
|
2011-09-27 06:30:58 +02:00
|
|
|
static bool tci_compare32(uint32_t u0, uint32_t u1, TCGCond condition)
|
|
|
|
|
{
|
|
|
|
|
bool result = false;
|
|
|
|
|
int32_t i0 = u0;
|
|
|
|
|
int32_t i1 = u1;
|
|
|
|
|
switch (condition) {
|
|
|
|
|
case TCG_COND_EQ:
|
|
|
|
|
result = (u0 == u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_NE:
|
|
|
|
|
result = (u0 != u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LT:
|
|
|
|
|
result = (i0 < i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GE:
|
|
|
|
|
result = (i0 >= i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LE:
|
|
|
|
|
result = (i0 <= i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GT:
|
|
|
|
|
result = (i0 > i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LTU:
|
|
|
|
|
result = (u0 < u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GEU:
|
|
|
|
|
result = (u0 >= u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LEU:
|
|
|
|
|
result = (u0 <= u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GTU:
|
|
|
|
|
result = (u0 > u1);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2021-01-28 07:11:11 +01:00
|
|
|
g_assert_not_reached();
|
2011-09-27 06:30:58 +02:00
|
|
|
}
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool tci_compare64(uint64_t u0, uint64_t u1, TCGCond condition)
|
|
|
|
|
{
|
|
|
|
|
bool result = false;
|
|
|
|
|
int64_t i0 = u0;
|
|
|
|
|
int64_t i1 = u1;
|
|
|
|
|
switch (condition) {
|
|
|
|
|
case TCG_COND_EQ:
|
|
|
|
|
result = (u0 == u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_NE:
|
|
|
|
|
result = (u0 != u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LT:
|
|
|
|
|
result = (i0 < i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GE:
|
|
|
|
|
result = (i0 >= i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LE:
|
|
|
|
|
result = (i0 <= i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GT:
|
|
|
|
|
result = (i0 > i1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LTU:
|
|
|
|
|
result = (u0 < u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GEU:
|
|
|
|
|
result = (u0 >= u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_LEU:
|
|
|
|
|
result = (u0 <= u1);
|
|
|
|
|
break;
|
|
|
|
|
case TCG_COND_GTU:
|
|
|
|
|
result = (u0 > u1);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2021-01-28 07:11:11 +01:00
|
|
|
g_assert_not_reached();
|
2011-09-27 06:30:58 +02:00
|
|
|
}
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2021-05-27 21:21:59 +02:00
|
|
|
static uint64_t tci_qemu_ld(CPUArchState *env, target_ulong taddr,
|
2021-07-26 00:06:49 +02:00
|
|
|
MemOpIdx oi, const void *tb_ptr)
|
2021-05-27 21:21:59 +02:00
|
|
|
{
|
2021-08-04 02:56:51 +02:00
|
|
|
MemOp mop = get_memop(oi);
|
2021-05-27 21:37:57 +02:00
|
|
|
uintptr_t ra = (uintptr_t)tb_ptr;
|
|
|
|
|
|
2021-05-27 21:41:07 +02:00
|
|
|
#ifdef CONFIG_SOFTMMU
|
2021-08-04 02:56:51 +02:00
|
|
|
switch (mop & (MO_BSWAP | MO_SSIZE)) {
|
2021-05-27 21:37:57 +02:00
|
|
|
case MO_UB:
|
|
|
|
|
return helper_ret_ldub_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_SB:
|
|
|
|
|
return helper_ret_ldsb_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_LEUW:
|
|
|
|
|
return helper_le_lduw_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_LESW:
|
|
|
|
|
return helper_le_ldsw_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_LEUL:
|
|
|
|
|
return helper_le_ldul_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_LESL:
|
|
|
|
|
return helper_le_ldsl_mmu(env, taddr, oi, ra);
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_LEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
return helper_le_ldq_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_BEUW:
|
|
|
|
|
return helper_be_lduw_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_BESW:
|
|
|
|
|
return helper_be_ldsw_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_BEUL:
|
|
|
|
|
return helper_be_ldul_mmu(env, taddr, oi, ra);
|
|
|
|
|
case MO_BESL:
|
|
|
|
|
return helper_be_ldsl_mmu(env, taddr, oi, ra);
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_BEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
return helper_be_ldq_mmu(env, taddr, oi, ra);
|
|
|
|
|
default:
|
|
|
|
|
g_assert_not_reached();
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
void *haddr = g2h(env_cpu(env), taddr);
|
2021-08-04 02:56:51 +02:00
|
|
|
unsigned a_mask = (1u << get_alignment_bits(mop)) - 1;
|
2021-05-27 21:37:57 +02:00
|
|
|
uint64_t ret;
|
|
|
|
|
|
2021-05-27 21:41:07 +02:00
|
|
|
set_helper_retaddr(ra);
|
2021-08-04 02:56:51 +02:00
|
|
|
if (taddr & a_mask) {
|
|
|
|
|
helper_unaligned_ld(env, taddr);
|
|
|
|
|
}
|
|
|
|
|
switch (mop & (MO_BSWAP | MO_SSIZE)) {
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_UB:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = ldub_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_SB:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = ldsb_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_LEUW:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = lduw_le_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_LESW:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = ldsw_le_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_LEUL:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = (uint32_t)ldl_le_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_LESL:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = (int32_t)ldl_le_p(haddr);
|
|
|
|
|
break;
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_LEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = ldq_le_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_BEUW:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = lduw_be_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_BESW:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = ldsw_be_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_BEUL:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = (uint32_t)ldl_be_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_BESL:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = (int32_t)ldl_be_p(haddr);
|
|
|
|
|
break;
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_BEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
ret = ldq_be_p(haddr);
|
|
|
|
|
break;
|
2021-05-27 21:21:59 +02:00
|
|
|
default:
|
|
|
|
|
g_assert_not_reached();
|
|
|
|
|
}
|
2021-05-27 21:41:07 +02:00
|
|
|
clear_helper_retaddr();
|
2021-05-27 21:37:57 +02:00
|
|
|
return ret;
|
|
|
|
|
#endif
|
2021-05-27 21:21:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void tci_qemu_st(CPUArchState *env, target_ulong taddr, uint64_t val,
|
2021-07-26 00:06:49 +02:00
|
|
|
MemOpIdx oi, const void *tb_ptr)
|
2021-05-27 21:21:59 +02:00
|
|
|
{
|
2021-08-04 02:56:51 +02:00
|
|
|
MemOp mop = get_memop(oi);
|
2021-05-27 21:37:57 +02:00
|
|
|
uintptr_t ra = (uintptr_t)tb_ptr;
|
|
|
|
|
|
2021-05-27 21:41:07 +02:00
|
|
|
#ifdef CONFIG_SOFTMMU
|
2021-08-04 02:56:51 +02:00
|
|
|
switch (mop & (MO_BSWAP | MO_SIZE)) {
|
2021-05-27 21:37:57 +02:00
|
|
|
case MO_UB:
|
|
|
|
|
helper_ret_stb_mmu(env, taddr, val, oi, ra);
|
|
|
|
|
break;
|
|
|
|
|
case MO_LEUW:
|
|
|
|
|
helper_le_stw_mmu(env, taddr, val, oi, ra);
|
|
|
|
|
break;
|
|
|
|
|
case MO_LEUL:
|
|
|
|
|
helper_le_stl_mmu(env, taddr, val, oi, ra);
|
|
|
|
|
break;
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_LEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
helper_le_stq_mmu(env, taddr, val, oi, ra);
|
|
|
|
|
break;
|
|
|
|
|
case MO_BEUW:
|
|
|
|
|
helper_be_stw_mmu(env, taddr, val, oi, ra);
|
|
|
|
|
break;
|
|
|
|
|
case MO_BEUL:
|
|
|
|
|
helper_be_stl_mmu(env, taddr, val, oi, ra);
|
|
|
|
|
break;
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_BEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
helper_be_stq_mmu(env, taddr, val, oi, ra);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
g_assert_not_reached();
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
void *haddr = g2h(env_cpu(env), taddr);
|
2021-08-04 02:56:51 +02:00
|
|
|
unsigned a_mask = (1u << get_alignment_bits(mop)) - 1;
|
2021-05-27 21:37:57 +02:00
|
|
|
|
2021-05-27 21:41:07 +02:00
|
|
|
set_helper_retaddr(ra);
|
2021-08-04 02:56:51 +02:00
|
|
|
if (taddr & a_mask) {
|
|
|
|
|
helper_unaligned_st(env, taddr);
|
|
|
|
|
}
|
|
|
|
|
switch (mop & (MO_BSWAP | MO_SIZE)) {
|
2021-05-27 21:21:59 +02:00
|
|
|
case MO_UB:
|
2021-05-27 21:37:57 +02:00
|
|
|
stb_p(haddr, val);
|
2021-05-27 21:21:59 +02:00
|
|
|
break;
|
|
|
|
|
case MO_LEUW:
|
2021-05-27 21:37:57 +02:00
|
|
|
stw_le_p(haddr, val);
|
2021-05-27 21:21:59 +02:00
|
|
|
break;
|
|
|
|
|
case MO_LEUL:
|
2021-05-27 21:37:57 +02:00
|
|
|
stl_le_p(haddr, val);
|
2021-05-27 21:21:59 +02:00
|
|
|
break;
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_LEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
stq_le_p(haddr, val);
|
2021-05-27 21:21:59 +02:00
|
|
|
break;
|
|
|
|
|
case MO_BEUW:
|
2021-05-27 21:37:57 +02:00
|
|
|
stw_be_p(haddr, val);
|
2021-05-27 21:21:59 +02:00
|
|
|
break;
|
|
|
|
|
case MO_BEUL:
|
2021-05-27 21:37:57 +02:00
|
|
|
stl_be_p(haddr, val);
|
2021-05-27 21:21:59 +02:00
|
|
|
break;
|
2022-01-06 22:00:51 +01:00
|
|
|
case MO_BEUQ:
|
2021-05-27 21:37:57 +02:00
|
|
|
stq_be_p(haddr, val);
|
2021-05-27 21:21:59 +02:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
g_assert_not_reached();
|
|
|
|
|
}
|
2021-05-27 21:41:07 +02:00
|
|
|
clear_helper_retaddr();
|
2021-05-27 21:37:57 +02:00
|
|
|
#endif
|
2021-05-27 21:21:59 +02:00
|
|
|
}
|
|
|
|
|
|
2021-01-28 06:37:55 +01:00
|
|
|
#if TCG_TARGET_REG_BITS == 64
|
|
|
|
|
# define CASE_32_64(x) \
|
|
|
|
|
case glue(glue(INDEX_op_, x), _i64): \
|
|
|
|
|
case glue(glue(INDEX_op_, x), _i32):
|
|
|
|
|
# define CASE_64(x) \
|
|
|
|
|
case glue(glue(INDEX_op_, x), _i64):
|
|
|
|
|
#else
|
|
|
|
|
# define CASE_32_64(x) \
|
|
|
|
|
case glue(glue(INDEX_op_, x), _i32):
|
|
|
|
|
# define CASE_64(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-09-27 06:30:58 +02:00
|
|
|
/* Interpret pseudo code in tb. */
|
cfi: Initial support for cfi-icall in QEMU
LLVM/Clang, supports runtime checks for forward-edge Control-Flow
Integrity (CFI).
CFI on indirect function calls (cfi-icall) ensures that, in indirect
function calls, the function called is of the right signature for the
pointer type defined at compile time.
For this check to work, the code must always respect the function
signature when using function pointer, the function must be defined
at compile time, and be compiled with link-time optimization.
This rules out, for example, shared libraries that are dynamically loaded
(given that functions are not known at compile time), and code that is
dynamically generated at run-time.
This patch:
1) Introduces the CONFIG_CFI flag to support cfi in QEMU
2) Introduces a decorator to allow the definition of "sensitive"
functions, where a non-instrumented function may be called at runtime
through a pointer. The decorator will take care of disabling cfi-icall
checks on such functions, when cfi is enabled.
3) Marks functions currently in QEMU that exhibit such behavior,
in particular:
- The function in TCG that calls pre-compiled TBs
- The function in TCI that interprets instructions
- Functions in the plugin infrastructures that jump to callbacks
- Functions in util that directly call a signal handler
Signed-off-by: Daniele Buono <dbuono@linux.vnet.ibm.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org
Message-Id: <20201204230615.2392-3-dbuono@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-05 00:06:12 +01:00
|
|
|
/*
|
|
|
|
|
* Disable CFI checks.
|
|
|
|
|
* One possible operation in the pseudo code is a call to binary code.
|
|
|
|
|
* Therefore, disable CFI checks in the interpreter function
|
|
|
|
|
*/
|
2020-10-28 20:05:44 +01:00
|
|
|
uintptr_t QEMU_DISABLE_CFI tcg_qemu_tb_exec(CPUArchState *env,
|
|
|
|
|
const void *v_tb_ptr)
|
2011-09-27 06:30:58 +02:00
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
const uint32_t *tb_ptr = v_tb_ptr;
|
2017-07-13 23:10:31 +02:00
|
|
|
tcg_target_ulong regs[TCG_TARGET_NB_REGS];
|
2021-01-30 23:24:25 +01:00
|
|
|
uint64_t stack[(TCG_STATIC_CALL_ARGS_SIZE + TCG_STATIC_FRAME_SIZE)
|
|
|
|
|
/ sizeof(uint64_t)];
|
|
|
|
|
void *call_slots[TCG_STATIC_CALL_ARGS_SIZE / sizeof(uint64_t)];
|
2011-09-27 06:30:58 +02:00
|
|
|
|
2017-07-13 23:10:31 +02:00
|
|
|
regs[TCG_AREG0] = (tcg_target_ulong)env;
|
2021-01-30 23:24:25 +01:00
|
|
|
regs[TCG_REG_CALL_STACK] = (uintptr_t)stack;
|
|
|
|
|
/* Other call_slots entries initialized at first use (see below). */
|
|
|
|
|
call_slots[0] = NULL;
|
2016-04-05 22:24:51 +02:00
|
|
|
tci_assert(tb_ptr);
|
2011-09-27 06:30:58 +02:00
|
|
|
|
|
|
|
|
for (;;) {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
uint32_t insn;
|
|
|
|
|
TCGOpcode opc;
|
2021-02-03 02:40:12 +01:00
|
|
|
TCGReg r0, r1, r2, r3, r4, r5;
|
2011-09-27 06:30:58 +02:00
|
|
|
tcg_target_ulong t1;
|
|
|
|
|
TCGCond condition;
|
|
|
|
|
target_ulong taddr;
|
2021-01-30 09:36:40 +01:00
|
|
|
uint8_t pos, len;
|
2011-09-27 06:30:58 +02:00
|
|
|
uint32_t tmp32;
|
|
|
|
|
uint64_t tmp64;
|
2021-01-30 08:41:13 +01:00
|
|
|
uint64_t T1, T2;
|
2021-07-26 00:06:49 +02:00
|
|
|
MemOpIdx oi;
|
2021-01-29 23:55:41 +01:00
|
|
|
int32_t ofs;
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
void *ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
insn = *tb_ptr++;
|
|
|
|
|
opc = extract32(insn, 0, 8);
|
2011-09-27 06:30:58 +02:00
|
|
|
|
|
|
|
|
switch (opc) {
|
|
|
|
|
case INDEX_op_call:
|
2021-01-30 23:24:25 +01:00
|
|
|
/*
|
|
|
|
|
* Set up the ffi_avalue array once, delayed until now
|
|
|
|
|
* because many TB's do not make any calls. In tcg_gen_callN,
|
|
|
|
|
* we arranged for every real argument to be "left-aligned"
|
|
|
|
|
* in each 64-bit slot.
|
|
|
|
|
*/
|
|
|
|
|
if (unlikely(call_slots[0] == NULL)) {
|
|
|
|
|
for (int i = 0; i < ARRAY_SIZE(call_slots); ++i) {
|
|
|
|
|
call_slots[i] = &stack[i];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_nl(insn, tb_ptr, &len, &ptr);
|
2021-01-30 23:24:25 +01:00
|
|
|
|
|
|
|
|
/* Helper functions may need to access the "return address" */
|
2021-01-24 21:57:01 +01:00
|
|
|
tci_tb_ptr = (uintptr_t)tb_ptr;
|
2021-01-30 23:24:25 +01:00
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
{
|
|
|
|
|
void **pptr = ptr;
|
|
|
|
|
ffi_call(pptr[1], pptr[0], stack, call_slots);
|
|
|
|
|
}
|
2021-01-30 23:24:25 +01:00
|
|
|
|
|
|
|
|
/* Any result winds up "left-aligned" in the stack[0] slot. */
|
|
|
|
|
switch (len) {
|
|
|
|
|
case 0: /* void */
|
|
|
|
|
break;
|
|
|
|
|
case 1: /* uint32_t */
|
|
|
|
|
/*
|
|
|
|
|
* Note that libffi has an odd special case in that it will
|
|
|
|
|
* always widen an integral result to ffi_arg.
|
|
|
|
|
*/
|
|
|
|
|
if (sizeof(ffi_arg) == 4) {
|
|
|
|
|
regs[TCG_REG_R0] = *(uint32_t *)stack;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/* fall through */
|
|
|
|
|
case 2: /* uint64_t */
|
|
|
|
|
if (TCG_TARGET_REG_BITS == 32) {
|
|
|
|
|
tci_write_reg64(regs, TCG_REG_R1, TCG_REG_R0, stack[0]);
|
|
|
|
|
} else {
|
|
|
|
|
regs[TCG_REG_R0] = stack[0];
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
g_assert_not_reached();
|
|
|
|
|
}
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-30 23:24:25 +01:00
|
|
|
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_br:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_l(insn, tb_ptr, &ptr);
|
2021-01-30 08:18:45 +01:00
|
|
|
tb_ptr = ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
continue;
|
|
|
|
|
case INDEX_op_setcond_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrc(insn, &r0, &r1, &r2, &condition);
|
2021-01-30 00:14:11 +01:00
|
|
|
regs[r0] = tci_compare32(regs[r1], regs[r2], condition);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 01:15:45 +01:00
|
|
|
case INDEX_op_movcond_i32:
|
|
|
|
|
tci_args_rrrrrc(insn, &r0, &r1, &r2, &r3, &r4, &condition);
|
|
|
|
|
tmp32 = tci_compare32(regs[r1], regs[r2], condition);
|
|
|
|
|
regs[r0] = regs[tmp32 ? r3 : r4];
|
|
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
#if TCG_TARGET_REG_BITS == 32
|
|
|
|
|
case INDEX_op_setcond2_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrrc(insn, &r0, &r1, &r2, &r3, &r4, &condition);
|
2021-01-30 08:30:04 +01:00
|
|
|
T1 = tci_uint64(regs[r2], regs[r1]);
|
|
|
|
|
T2 = tci_uint64(regs[r4], regs[r3]);
|
|
|
|
|
regs[r0] = tci_compare64(T1, T2, condition);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#elif TCG_TARGET_REG_BITS == 64
|
|
|
|
|
case INDEX_op_setcond_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrc(insn, &r0, &r1, &r2, &condition);
|
2021-01-30 00:14:11 +01:00
|
|
|
regs[r0] = tci_compare64(regs[r1], regs[r2], condition);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 01:15:45 +01:00
|
|
|
case INDEX_op_movcond_i64:
|
|
|
|
|
tci_args_rrrrrc(insn, &r0, &r1, &r2, &r3, &r4, &condition);
|
|
|
|
|
tmp32 = tci_compare64(regs[r1], regs[r2], condition);
|
|
|
|
|
regs[r0] = regs[tmp32 ? r3 : r4];
|
|
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
#endif
|
2021-01-29 23:29:22 +01:00
|
|
|
CASE_32_64(mov)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
case INDEX_op_tci_movi:
|
|
|
|
|
tci_args_ri(insn, &r0, &t1);
|
2021-01-30 08:49:24 +01:00
|
|
|
regs[r0] = t1;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
case INDEX_op_tci_movl:
|
|
|
|
|
tci_args_rl(insn, tb_ptr, &r0, &ptr);
|
|
|
|
|
regs[r0] = *(tcg_target_ulong *)ptr;
|
|
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
|
|
|
|
|
/* Load/store operations (32 bit). */
|
|
|
|
|
|
2021-01-28 06:37:55 +01:00
|
|
|
CASE_32_64(ld8u)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
regs[r0] = *(uint8_t *)ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-28 06:39:39 +01:00
|
|
|
CASE_32_64(ld8s)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
regs[r0] = *(int8_t *)ptr;
|
2019-04-10 21:48:38 +02:00
|
|
|
break;
|
2021-01-28 06:41:17 +01:00
|
|
|
CASE_32_64(ld16u)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
regs[r0] = *(uint16_t *)ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-28 06:42:42 +01:00
|
|
|
CASE_32_64(ld16s)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
regs[r0] = *(int16_t *)ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_ld_i32:
|
2021-01-28 06:44:01 +01:00
|
|
|
CASE_64(ld32u)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
regs[r0] = *(uint32_t *)ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-28 06:47:02 +01:00
|
|
|
CASE_32_64(st8)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
*(uint8_t *)ptr = regs[r0];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-28 06:49:37 +01:00
|
|
|
CASE_32_64(st16)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
*(uint16_t *)ptr = regs[r0];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_st_i32:
|
2021-01-28 06:53:59 +01:00
|
|
|
CASE_64(st32)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
*(uint32_t *)ptr = regs[r0];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
|
2021-01-29 23:15:58 +01:00
|
|
|
/* Arithmetic operations (mixed 32/64 bit). */
|
2011-09-27 06:30:58 +02:00
|
|
|
|
2021-01-29 23:15:58 +01:00
|
|
|
CASE_32_64(add)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] + regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
CASE_32_64(sub)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] - regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
CASE_32_64(mul)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] * regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
CASE_32_64(and)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] & regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
CASE_32_64(or)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] | regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
CASE_32_64(xor)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] ^ regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 01:29:18 +01:00
|
|
|
#if TCG_TARGET_HAS_andc_i32 || TCG_TARGET_HAS_andc_i64
|
|
|
|
|
CASE_32_64(andc)
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
regs[r0] = regs[r1] & ~regs[r2];
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_orc_i32 || TCG_TARGET_HAS_orc_i64
|
|
|
|
|
CASE_32_64(orc)
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
regs[r0] = regs[r1] | ~regs[r2];
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_eqv_i32 || TCG_TARGET_HAS_eqv_i64
|
|
|
|
|
CASE_32_64(eqv)
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
regs[r0] = ~(regs[r1] ^ regs[r2]);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_nand_i32 || TCG_TARGET_HAS_nand_i64
|
|
|
|
|
CASE_32_64(nand)
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
regs[r0] = ~(regs[r1] & regs[r2]);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_nor_i32 || TCG_TARGET_HAS_nor_i64
|
|
|
|
|
CASE_32_64(nor)
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
regs[r0] = ~(regs[r1] | regs[r2]);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:15:58 +01:00
|
|
|
|
|
|
|
|
/* Arithmetic operations (32 bit). */
|
|
|
|
|
|
|
|
|
|
case INDEX_op_div_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (int32_t)regs[r1] / (int32_t)regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
case INDEX_op_divu_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (uint32_t)regs[r1] / (uint32_t)regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
case INDEX_op_rem_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (int32_t)regs[r1] % (int32_t)regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-29 23:15:58 +01:00
|
|
|
case INDEX_op_remu_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (uint32_t)regs[r1] % (uint32_t)regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 02:01:57 +01:00
|
|
|
#if TCG_TARGET_HAS_clz_i32
|
|
|
|
|
case INDEX_op_clz_i32:
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
tmp32 = regs[r1];
|
|
|
|
|
regs[r0] = tmp32 ? clz32(tmp32) : regs[r2];
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_ctz_i32
|
|
|
|
|
case INDEX_op_ctz_i32:
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
tmp32 = regs[r1];
|
|
|
|
|
regs[r0] = tmp32 ? ctz32(tmp32) : regs[r2];
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_ctpop_i32
|
|
|
|
|
case INDEX_op_ctpop_i32:
|
|
|
|
|
tci_args_rr(insn, &r0, &r1);
|
|
|
|
|
regs[r0] = ctpop32(regs[r1]);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
2011-09-27 06:30:58 +02:00
|
|
|
|
|
|
|
|
/* Shift/rotate operations (32 bit). */
|
|
|
|
|
|
|
|
|
|
case INDEX_op_shl_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (uint32_t)regs[r1] << (regs[r2] & 31);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_shr_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (uint32_t)regs[r1] >> (regs[r2] & 31);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_sar_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (int32_t)regs[r1] >> (regs[r2] & 31);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#if TCG_TARGET_HAS_rot_i32
|
|
|
|
|
case INDEX_op_rotl_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = rol32(regs[r1], regs[r2] & 31);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_rotr_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = ror32(regs[r1], regs[r2] & 31);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2012-09-18 22:52:14 +02:00
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_deposit_i32
|
|
|
|
|
case INDEX_op_deposit_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrbb(insn, &r0, &r1, &r2, &pos, &len);
|
2021-01-30 09:36:40 +01:00
|
|
|
regs[r0] = deposit32(regs[r1], pos, len, regs[r2]);
|
2012-09-18 22:52:14 +02:00
|
|
|
break;
|
2021-02-03 01:48:48 +01:00
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_extract_i32
|
|
|
|
|
case INDEX_op_extract_i32:
|
|
|
|
|
tci_args_rrbb(insn, &r0, &r1, &pos, &len);
|
|
|
|
|
regs[r0] = extract32(regs[r1], pos, len);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_sextract_i32
|
|
|
|
|
case INDEX_op_sextract_i32:
|
|
|
|
|
tci_args_rrbb(insn, &r0, &r1, &pos, &len);
|
|
|
|
|
regs[r0] = sextract32(regs[r1], pos, len);
|
|
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
#endif
|
|
|
|
|
case INDEX_op_brcond_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rl(insn, tb_ptr, &r0, &ptr);
|
2021-02-01 20:41:20 +01:00
|
|
|
if ((uint32_t)regs[r0]) {
|
2021-01-30 08:41:13 +01:00
|
|
|
tb_ptr = ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
}
|
|
|
|
|
break;
|
2021-02-03 02:40:12 +01:00
|
|
|
#if TCG_TARGET_REG_BITS == 32 || TCG_TARGET_HAS_add2_i32
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_add2_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrrr(insn, &r0, &r1, &r2, &r3, &r4, &r5);
|
2021-01-30 09:16:05 +01:00
|
|
|
T1 = tci_uint64(regs[r3], regs[r2]);
|
|
|
|
|
T2 = tci_uint64(regs[r5], regs[r4]);
|
|
|
|
|
tci_write_reg64(regs, r1, r0, T1 + T2);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 02:40:12 +01:00
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_REG_BITS == 32 || TCG_TARGET_HAS_sub2_i32
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_sub2_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrrr(insn, &r0, &r1, &r2, &r3, &r4, &r5);
|
2021-01-30 09:16:05 +01:00
|
|
|
T1 = tci_uint64(regs[r3], regs[r2]);
|
|
|
|
|
T2 = tci_uint64(regs[r5], regs[r4]);
|
|
|
|
|
tci_write_reg64(regs, r1, r0, T1 - T2);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 02:40:12 +01:00
|
|
|
#endif
|
2021-02-03 02:21:27 +01:00
|
|
|
#if TCG_TARGET_HAS_mulu2_i32
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_mulu2_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrr(insn, &r0, &r1, &r2, &r3);
|
2021-02-03 02:21:27 +01:00
|
|
|
tmp64 = (uint64_t)(uint32_t)regs[r2] * (uint32_t)regs[r3];
|
|
|
|
|
tci_write_reg64(regs, r1, r0, tmp64);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 02:21:27 +01:00
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_muls2_i32
|
|
|
|
|
case INDEX_op_muls2_i32:
|
|
|
|
|
tci_args_rrrr(insn, &r0, &r1, &r2, &r3);
|
|
|
|
|
tmp64 = (int64_t)(int32_t)regs[r2] * (int32_t)regs[r3];
|
|
|
|
|
tci_write_reg64(regs, r1, r0, tmp64);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:21:18 +01:00
|
|
|
#if TCG_TARGET_HAS_ext8s_i32 || TCG_TARGET_HAS_ext8s_i64
|
|
|
|
|
CASE_32_64(ext8s)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = (int8_t)regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-06-13 21:34:30 +02:00
|
|
|
#if TCG_TARGET_HAS_ext16s_i32 || TCG_TARGET_HAS_ext16s_i64 || \
|
|
|
|
|
TCG_TARGET_HAS_bswap16_i32 || TCG_TARGET_HAS_bswap16_i64
|
2021-01-29 23:21:18 +01:00
|
|
|
CASE_32_64(ext16s)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = (int16_t)regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:21:18 +01:00
|
|
|
#if TCG_TARGET_HAS_ext8u_i32 || TCG_TARGET_HAS_ext8u_i64
|
|
|
|
|
CASE_32_64(ext8u)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = (uint8_t)regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:21:18 +01:00
|
|
|
#if TCG_TARGET_HAS_ext16u_i32 || TCG_TARGET_HAS_ext16u_i64
|
|
|
|
|
CASE_32_64(ext16u)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = (uint16_t)regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:27:20 +01:00
|
|
|
#if TCG_TARGET_HAS_bswap16_i32 || TCG_TARGET_HAS_bswap16_i64
|
|
|
|
|
CASE_32_64(bswap16)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = bswap16(regs[r1]);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:27:20 +01:00
|
|
|
#if TCG_TARGET_HAS_bswap32_i32 || TCG_TARGET_HAS_bswap32_i64
|
|
|
|
|
CASE_32_64(bswap32)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = bswap32(regs[r1]);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:29:22 +01:00
|
|
|
#if TCG_TARGET_HAS_not_i32 || TCG_TARGET_HAS_not_i64
|
|
|
|
|
CASE_32_64(not)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = ~regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
2021-01-29 23:29:22 +01:00
|
|
|
#if TCG_TARGET_HAS_neg_i32 || TCG_TARGET_HAS_neg_i64
|
|
|
|
|
CASE_32_64(neg)
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = -regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_REG_BITS == 64
|
|
|
|
|
/* Load/store operations (64 bit). */
|
|
|
|
|
|
|
|
|
|
case INDEX_op_ld32s_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
regs[r0] = *(int32_t *)ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_ld_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
regs[r0] = *(uint64_t *)ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_st_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &ofs);
|
2021-01-29 23:55:41 +01:00
|
|
|
ptr = (void *)(regs[r1] + ofs);
|
|
|
|
|
*(uint64_t *)ptr = regs[r0];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
/* Arithmetic operations (64 bit). */
|
|
|
|
|
|
|
|
|
|
case INDEX_op_div_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (int64_t)regs[r1] / (int64_t)regs[r2];
|
2021-01-28 07:30:00 +01:00
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_divu_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (uint64_t)regs[r1] / (uint64_t)regs[r2];
|
2021-01-28 07:30:00 +01:00
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_rem_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (int64_t)regs[r1] % (int64_t)regs[r2];
|
2021-01-28 07:30:00 +01:00
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_remu_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (uint64_t)regs[r1] % (uint64_t)regs[r2];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-02-03 02:01:57 +01:00
|
|
|
#if TCG_TARGET_HAS_clz_i64
|
|
|
|
|
case INDEX_op_clz_i64:
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
regs[r0] = regs[r1] ? clz64(regs[r1]) : regs[r2];
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_ctz_i64
|
|
|
|
|
case INDEX_op_ctz_i64:
|
|
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
|
|
|
|
regs[r0] = regs[r1] ? ctz64(regs[r1]) : regs[r2];
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_ctpop_i64
|
|
|
|
|
case INDEX_op_ctpop_i64:
|
|
|
|
|
tci_args_rr(insn, &r0, &r1);
|
|
|
|
|
regs[r0] = ctpop64(regs[r1]);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
2021-02-03 02:21:27 +01:00
|
|
|
#if TCG_TARGET_HAS_mulu2_i64
|
|
|
|
|
case INDEX_op_mulu2_i64:
|
|
|
|
|
tci_args_rrrr(insn, &r0, &r1, &r2, &r3);
|
|
|
|
|
mulu64(®s[r0], ®s[r1], regs[r2], regs[r3]);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_muls2_i64
|
|
|
|
|
case INDEX_op_muls2_i64:
|
|
|
|
|
tci_args_rrrr(insn, &r0, &r1, &r2, &r3);
|
|
|
|
|
muls64(®s[r0], ®s[r1], regs[r2], regs[r3]);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
2021-02-03 02:40:12 +01:00
|
|
|
#if TCG_TARGET_HAS_add2_i64
|
|
|
|
|
case INDEX_op_add2_i64:
|
|
|
|
|
tci_args_rrrrrr(insn, &r0, &r1, &r2, &r3, &r4, &r5);
|
|
|
|
|
T1 = regs[r2] + regs[r4];
|
|
|
|
|
T2 = regs[r3] + regs[r5] + (T1 < regs[r2]);
|
|
|
|
|
regs[r0] = T1;
|
|
|
|
|
regs[r1] = T2;
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_add2_i64
|
|
|
|
|
case INDEX_op_sub2_i64:
|
|
|
|
|
tci_args_rrrrrr(insn, &r0, &r1, &r2, &r3, &r4, &r5);
|
|
|
|
|
T1 = regs[r2] - regs[r4];
|
|
|
|
|
T2 = regs[r3] - regs[r5] - (regs[r2] < regs[r4]);
|
|
|
|
|
regs[r0] = T1;
|
|
|
|
|
regs[r1] = T2;
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
2011-09-27 06:30:58 +02:00
|
|
|
|
|
|
|
|
/* Shift/rotate operations (64 bit). */
|
|
|
|
|
|
|
|
|
|
case INDEX_op_shl_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] << (regs[r2] & 63);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_shr_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = regs[r1] >> (regs[r2] & 63);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_sar_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = (int64_t)regs[r1] >> (regs[r2] & 63);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#if TCG_TARGET_HAS_rot_i64
|
|
|
|
|
case INDEX_op_rotl_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = rol64(regs[r1], regs[r2] & 63);
|
2013-09-12 21:13:11 +02:00
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_rotr_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-30 00:10:28 +01:00
|
|
|
regs[r0] = ror64(regs[r1], regs[r2] & 63);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2012-09-18 22:52:14 +02:00
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_deposit_i64
|
|
|
|
|
case INDEX_op_deposit_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrbb(insn, &r0, &r1, &r2, &pos, &len);
|
2021-01-30 09:36:40 +01:00
|
|
|
regs[r0] = deposit64(regs[r1], pos, len, regs[r2]);
|
2012-09-18 22:52:14 +02:00
|
|
|
break;
|
2021-02-03 01:48:48 +01:00
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_extract_i64
|
|
|
|
|
case INDEX_op_extract_i64:
|
|
|
|
|
tci_args_rrbb(insn, &r0, &r1, &pos, &len);
|
|
|
|
|
regs[r0] = extract64(regs[r1], pos, len);
|
|
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#if TCG_TARGET_HAS_sextract_i64
|
|
|
|
|
case INDEX_op_sextract_i64:
|
|
|
|
|
tci_args_rrbb(insn, &r0, &r1, &pos, &len);
|
|
|
|
|
regs[r0] = sextract64(regs[r1], pos, len);
|
|
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
#endif
|
|
|
|
|
case INDEX_op_brcond_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rl(insn, tb_ptr, &r0, &ptr);
|
2021-02-01 20:41:20 +01:00
|
|
|
if (regs[r0]) {
|
2021-01-30 08:41:13 +01:00
|
|
|
tb_ptr = ptr;
|
2011-09-27 06:30:58 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case INDEX_op_ext32s_i64:
|
2015-07-27 12:41:45 +02:00
|
|
|
case INDEX_op_ext_i32_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = (int32_t)regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
case INDEX_op_ext32u_i64:
|
2015-07-27 12:41:45 +02:00
|
|
|
case INDEX_op_extu_i32_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = (uint32_t)regs[r1];
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#if TCG_TARGET_HAS_bswap64_i64
|
|
|
|
|
case INDEX_op_bswap64_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-30 00:05:01 +01:00
|
|
|
regs[r0] = bswap64(regs[r1]);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
|
|
|
|
#endif
|
|
|
|
|
#endif /* TCG_TARGET_REG_BITS == 64 */
|
|
|
|
|
|
|
|
|
|
/* QEMU specific operations. */
|
|
|
|
|
|
|
|
|
|
case INDEX_op_exit_tb:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_l(insn, tb_ptr, &ptr);
|
2021-01-30 09:01:11 +01:00
|
|
|
return (uintptr_t)ptr;
|
|
|
|
|
|
2011-09-27 06:30:58 +02:00
|
|
|
case INDEX_op_goto_tb:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_l(insn, tb_ptr, &ptr);
|
2021-01-30 09:11:43 +01:00
|
|
|
tb_ptr = *(void **)ptr;
|
2021-01-30 22:23:02 +01:00
|
|
|
break;
|
2021-01-30 09:11:43 +01:00
|
|
|
|
2021-02-02 20:40:22 +01:00
|
|
|
case INDEX_op_goto_ptr:
|
|
|
|
|
tci_args_r(insn, &r0);
|
|
|
|
|
ptr = (void *)regs[r0];
|
|
|
|
|
if (!ptr) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
tb_ptr = ptr;
|
|
|
|
|
break;
|
|
|
|
|
|
2014-05-27 05:59:16 +02:00
|
|
|
case INDEX_op_qemu_ld_i32:
|
2021-01-30 09:52:12 +01:00
|
|
|
if (TARGET_LONG_BITS <= TCG_TARGET_REG_BITS) {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrm(insn, &r0, &r1, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = regs[r1];
|
|
|
|
|
} else {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrm(insn, &r0, &r1, &r2, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = tci_uint64(regs[r2], regs[r1]);
|
|
|
|
|
}
|
2021-05-27 21:21:59 +02:00
|
|
|
tmp32 = tci_qemu_ld(env, taddr, oi, tb_ptr);
|
2021-01-30 09:52:12 +01:00
|
|
|
regs[r0] = tmp32;
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-30 09:52:12 +01:00
|
|
|
|
2014-05-27 05:59:16 +02:00
|
|
|
case INDEX_op_qemu_ld_i64:
|
2021-01-30 09:52:12 +01:00
|
|
|
if (TCG_TARGET_REG_BITS == 64) {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrm(insn, &r0, &r1, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = regs[r1];
|
|
|
|
|
} else if (TARGET_LONG_BITS <= TCG_TARGET_REG_BITS) {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrm(insn, &r0, &r1, &r2, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = regs[r2];
|
|
|
|
|
} else {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrr(insn, &r0, &r1, &r2, &r3, &r4);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = tci_uint64(regs[r3], regs[r2]);
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
oi = regs[r4];
|
2014-05-27 05:59:16 +02:00
|
|
|
}
|
2021-05-27 21:21:59 +02:00
|
|
|
tmp64 = tci_qemu_ld(env, taddr, oi, tb_ptr);
|
2014-05-27 05:59:16 +02:00
|
|
|
if (TCG_TARGET_REG_BITS == 32) {
|
2021-01-30 09:52:12 +01:00
|
|
|
tci_write_reg64(regs, r1, r0, tmp64);
|
|
|
|
|
} else {
|
|
|
|
|
regs[r0] = tmp64;
|
2014-05-27 05:59:16 +02:00
|
|
|
}
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-30 09:52:12 +01:00
|
|
|
|
2014-05-27 05:59:16 +02:00
|
|
|
case INDEX_op_qemu_st_i32:
|
2021-01-30 09:52:12 +01:00
|
|
|
if (TARGET_LONG_BITS <= TCG_TARGET_REG_BITS) {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrm(insn, &r0, &r1, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = regs[r1];
|
|
|
|
|
} else {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrm(insn, &r0, &r1, &r2, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = tci_uint64(regs[r2], regs[r1]);
|
|
|
|
|
}
|
|
|
|
|
tmp32 = regs[r0];
|
2021-05-27 21:21:59 +02:00
|
|
|
tci_qemu_st(env, taddr, tmp32, oi, tb_ptr);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-30 09:52:12 +01:00
|
|
|
|
2014-05-27 05:59:16 +02:00
|
|
|
case INDEX_op_qemu_st_i64:
|
2021-01-30 09:52:12 +01:00
|
|
|
if (TCG_TARGET_REG_BITS == 64) {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrm(insn, &r0, &r1, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = regs[r1];
|
|
|
|
|
tmp64 = regs[r0];
|
|
|
|
|
} else {
|
|
|
|
|
if (TARGET_LONG_BITS <= TCG_TARGET_REG_BITS) {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrm(insn, &r0, &r1, &r2, &oi);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = regs[r2];
|
|
|
|
|
} else {
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrr(insn, &r0, &r1, &r2, &r3, &r4);
|
2021-01-30 09:52:12 +01:00
|
|
|
taddr = tci_uint64(regs[r3], regs[r2]);
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
oi = regs[r4];
|
2021-01-30 09:52:12 +01:00
|
|
|
}
|
|
|
|
|
tmp64 = tci_uint64(regs[r1], regs[r0]);
|
|
|
|
|
}
|
2021-05-27 21:21:59 +02:00
|
|
|
tci_qemu_st(env, taddr, tmp64, oi, tb_ptr);
|
2011-09-27 06:30:58 +02:00
|
|
|
break;
|
2021-01-30 09:52:12 +01:00
|
|
|
|
2016-07-14 22:20:22 +02:00
|
|
|
case INDEX_op_mb:
|
|
|
|
|
/* Ensure ordering for all kinds */
|
|
|
|
|
smp_mb();
|
|
|
|
|
break;
|
2011-09-27 06:30:58 +02:00
|
|
|
default:
|
2021-01-28 07:11:11 +01:00
|
|
|
g_assert_not_reached();
|
2011-09-27 06:30:58 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-01-31 02:48:19 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Disassembler that matches the interpreter
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static const char *str_r(TCGReg r)
|
|
|
|
|
{
|
|
|
|
|
static const char regs[TCG_TARGET_NB_REGS][4] = {
|
|
|
|
|
"r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
|
|
|
|
|
"r8", "r9", "r10", "r11", "r12", "r13", "env", "sp"
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
QEMU_BUILD_BUG_ON(TCG_AREG0 != TCG_REG_R14);
|
|
|
|
|
QEMU_BUILD_BUG_ON(TCG_REG_CALL_STACK != TCG_REG_R15);
|
|
|
|
|
|
|
|
|
|
assert((unsigned)r < TCG_TARGET_NB_REGS);
|
|
|
|
|
return regs[r];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *str_c(TCGCond c)
|
|
|
|
|
{
|
|
|
|
|
static const char cond[16][8] = {
|
|
|
|
|
[TCG_COND_NEVER] = "never",
|
|
|
|
|
[TCG_COND_ALWAYS] = "always",
|
|
|
|
|
[TCG_COND_EQ] = "eq",
|
|
|
|
|
[TCG_COND_NE] = "ne",
|
|
|
|
|
[TCG_COND_LT] = "lt",
|
|
|
|
|
[TCG_COND_GE] = "ge",
|
|
|
|
|
[TCG_COND_LE] = "le",
|
|
|
|
|
[TCG_COND_GT] = "gt",
|
|
|
|
|
[TCG_COND_LTU] = "ltu",
|
|
|
|
|
[TCG_COND_GEU] = "geu",
|
|
|
|
|
[TCG_COND_LEU] = "leu",
|
|
|
|
|
[TCG_COND_GTU] = "gtu",
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert((unsigned)c < ARRAY_SIZE(cond));
|
|
|
|
|
assert(cond[c][0] != 0);
|
|
|
|
|
return cond[c];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Disassemble TCI bytecode. */
|
|
|
|
|
int print_insn_tci(bfd_vma addr, disassemble_info *info)
|
|
|
|
|
{
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
const uint32_t *tb_ptr = (const void *)(uintptr_t)addr;
|
2021-01-31 02:48:19 +01:00
|
|
|
const TCGOpDef *def;
|
|
|
|
|
const char *op_name;
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
uint32_t insn;
|
2021-01-31 02:48:19 +01:00
|
|
|
TCGOpcode op;
|
2021-02-03 02:40:12 +01:00
|
|
|
TCGReg r0, r1, r2, r3, r4, r5;
|
2021-01-31 02:48:19 +01:00
|
|
|
tcg_target_ulong i1;
|
|
|
|
|
int32_t s2;
|
|
|
|
|
TCGCond c;
|
2021-07-26 00:06:49 +02:00
|
|
|
MemOpIdx oi;
|
2021-01-31 02:48:19 +01:00
|
|
|
uint8_t pos, len;
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
void *ptr;
|
2021-01-31 02:48:19 +01:00
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
/* TCI is always the host, so we don't need to load indirect. */
|
|
|
|
|
insn = *tb_ptr++;
|
2021-01-31 02:48:19 +01:00
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
info->fprintf_func(info->stream, "%08x ", insn);
|
2021-01-31 02:48:19 +01:00
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
op = extract32(insn, 0, 8);
|
2021-01-31 02:48:19 +01:00
|
|
|
def = &tcg_op_defs[op];
|
|
|
|
|
op_name = def->name;
|
|
|
|
|
|
|
|
|
|
switch (op) {
|
|
|
|
|
case INDEX_op_br:
|
|
|
|
|
case INDEX_op_exit_tb:
|
|
|
|
|
case INDEX_op_goto_tb:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_l(insn, tb_ptr, &ptr);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %p", op_name, ptr);
|
|
|
|
|
break;
|
|
|
|
|
|
2021-02-02 20:40:22 +01:00
|
|
|
case INDEX_op_goto_ptr:
|
|
|
|
|
tci_args_r(insn, &r0);
|
|
|
|
|
info->fprintf_func(info->stream, "%-12s %s", op_name, str_r(r0));
|
|
|
|
|
break;
|
|
|
|
|
|
2021-01-30 23:24:25 +01:00
|
|
|
case INDEX_op_call:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_nl(insn, tb_ptr, &len, &ptr);
|
|
|
|
|
info->fprintf_func(info->stream, "%-12s %d, %p", op_name, len, ptr);
|
2021-01-30 23:24:25 +01:00
|
|
|
break;
|
|
|
|
|
|
2021-01-31 02:48:19 +01:00
|
|
|
case INDEX_op_brcond_i32:
|
|
|
|
|
case INDEX_op_brcond_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rl(insn, tb_ptr, &r0, &ptr);
|
2021-02-01 20:41:20 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, 0, ne, %p",
|
|
|
|
|
op_name, str_r(r0), ptr);
|
2021-01-31 02:48:19 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_setcond_i32:
|
|
|
|
|
case INDEX_op_setcond_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrc(insn, &r0, &r1, &r2, &c);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s, %s",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), str_r(r2), str_c(c));
|
|
|
|
|
break;
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
case INDEX_op_tci_movi:
|
|
|
|
|
tci_args_ri(insn, &r0, &i1);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, 0x%" TCG_PRIlx,
|
|
|
|
|
op_name, str_r(r0), i1);
|
|
|
|
|
break;
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
case INDEX_op_tci_movl:
|
|
|
|
|
tci_args_rl(insn, tb_ptr, &r0, &ptr);
|
|
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %p",
|
|
|
|
|
op_name, str_r(r0), ptr);
|
2021-01-31 02:48:19 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_ld8u_i32:
|
|
|
|
|
case INDEX_op_ld8u_i64:
|
|
|
|
|
case INDEX_op_ld8s_i32:
|
|
|
|
|
case INDEX_op_ld8s_i64:
|
|
|
|
|
case INDEX_op_ld16u_i32:
|
|
|
|
|
case INDEX_op_ld16u_i64:
|
|
|
|
|
case INDEX_op_ld16s_i32:
|
|
|
|
|
case INDEX_op_ld16s_i64:
|
|
|
|
|
case INDEX_op_ld32u_i64:
|
|
|
|
|
case INDEX_op_ld32s_i64:
|
|
|
|
|
case INDEX_op_ld_i32:
|
|
|
|
|
case INDEX_op_ld_i64:
|
|
|
|
|
case INDEX_op_st8_i32:
|
|
|
|
|
case INDEX_op_st8_i64:
|
|
|
|
|
case INDEX_op_st16_i32:
|
|
|
|
|
case INDEX_op_st16_i64:
|
|
|
|
|
case INDEX_op_st32_i64:
|
|
|
|
|
case INDEX_op_st_i32:
|
|
|
|
|
case INDEX_op_st_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrs(insn, &r0, &r1, &s2);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %d",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), s2);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_mov_i32:
|
|
|
|
|
case INDEX_op_mov_i64:
|
|
|
|
|
case INDEX_op_ext8s_i32:
|
|
|
|
|
case INDEX_op_ext8s_i64:
|
|
|
|
|
case INDEX_op_ext8u_i32:
|
|
|
|
|
case INDEX_op_ext8u_i64:
|
|
|
|
|
case INDEX_op_ext16s_i32:
|
|
|
|
|
case INDEX_op_ext16s_i64:
|
|
|
|
|
case INDEX_op_ext16u_i32:
|
|
|
|
|
case INDEX_op_ext32s_i64:
|
|
|
|
|
case INDEX_op_ext32u_i64:
|
|
|
|
|
case INDEX_op_ext_i32_i64:
|
|
|
|
|
case INDEX_op_extu_i32_i64:
|
|
|
|
|
case INDEX_op_bswap16_i32:
|
|
|
|
|
case INDEX_op_bswap16_i64:
|
|
|
|
|
case INDEX_op_bswap32_i32:
|
|
|
|
|
case INDEX_op_bswap32_i64:
|
|
|
|
|
case INDEX_op_bswap64_i64:
|
|
|
|
|
case INDEX_op_not_i32:
|
|
|
|
|
case INDEX_op_not_i64:
|
|
|
|
|
case INDEX_op_neg_i32:
|
|
|
|
|
case INDEX_op_neg_i64:
|
2021-02-03 02:01:57 +01:00
|
|
|
case INDEX_op_ctpop_i32:
|
|
|
|
|
case INDEX_op_ctpop_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rr(insn, &r0, &r1);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s",
|
|
|
|
|
op_name, str_r(r0), str_r(r1));
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_add_i32:
|
|
|
|
|
case INDEX_op_add_i64:
|
|
|
|
|
case INDEX_op_sub_i32:
|
|
|
|
|
case INDEX_op_sub_i64:
|
|
|
|
|
case INDEX_op_mul_i32:
|
|
|
|
|
case INDEX_op_mul_i64:
|
|
|
|
|
case INDEX_op_and_i32:
|
|
|
|
|
case INDEX_op_and_i64:
|
|
|
|
|
case INDEX_op_or_i32:
|
|
|
|
|
case INDEX_op_or_i64:
|
|
|
|
|
case INDEX_op_xor_i32:
|
|
|
|
|
case INDEX_op_xor_i64:
|
2021-02-03 01:29:18 +01:00
|
|
|
case INDEX_op_andc_i32:
|
|
|
|
|
case INDEX_op_andc_i64:
|
|
|
|
|
case INDEX_op_orc_i32:
|
|
|
|
|
case INDEX_op_orc_i64:
|
|
|
|
|
case INDEX_op_eqv_i32:
|
|
|
|
|
case INDEX_op_eqv_i64:
|
|
|
|
|
case INDEX_op_nand_i32:
|
|
|
|
|
case INDEX_op_nand_i64:
|
|
|
|
|
case INDEX_op_nor_i32:
|
|
|
|
|
case INDEX_op_nor_i64:
|
2021-01-31 02:48:19 +01:00
|
|
|
case INDEX_op_div_i32:
|
|
|
|
|
case INDEX_op_div_i64:
|
|
|
|
|
case INDEX_op_rem_i32:
|
|
|
|
|
case INDEX_op_rem_i64:
|
|
|
|
|
case INDEX_op_divu_i32:
|
|
|
|
|
case INDEX_op_divu_i64:
|
|
|
|
|
case INDEX_op_remu_i32:
|
|
|
|
|
case INDEX_op_remu_i64:
|
|
|
|
|
case INDEX_op_shl_i32:
|
|
|
|
|
case INDEX_op_shl_i64:
|
|
|
|
|
case INDEX_op_shr_i32:
|
|
|
|
|
case INDEX_op_shr_i64:
|
|
|
|
|
case INDEX_op_sar_i32:
|
|
|
|
|
case INDEX_op_sar_i64:
|
|
|
|
|
case INDEX_op_rotl_i32:
|
|
|
|
|
case INDEX_op_rotl_i64:
|
|
|
|
|
case INDEX_op_rotr_i32:
|
|
|
|
|
case INDEX_op_rotr_i64:
|
2021-02-03 02:01:57 +01:00
|
|
|
case INDEX_op_clz_i32:
|
|
|
|
|
case INDEX_op_clz_i64:
|
|
|
|
|
case INDEX_op_ctz_i32:
|
|
|
|
|
case INDEX_op_ctz_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrr(insn, &r0, &r1, &r2);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), str_r(r2));
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_deposit_i32:
|
|
|
|
|
case INDEX_op_deposit_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrbb(insn, &r0, &r1, &r2, &pos, &len);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s, %d, %d",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), str_r(r2), pos, len);
|
|
|
|
|
break;
|
|
|
|
|
|
2021-02-03 01:48:48 +01:00
|
|
|
case INDEX_op_extract_i32:
|
|
|
|
|
case INDEX_op_extract_i64:
|
|
|
|
|
case INDEX_op_sextract_i32:
|
|
|
|
|
case INDEX_op_sextract_i64:
|
|
|
|
|
tci_args_rrbb(insn, &r0, &r1, &pos, &len);
|
|
|
|
|
info->fprintf_func(info->stream, "%-12s %s,%s,%d,%d",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), pos, len);
|
|
|
|
|
break;
|
|
|
|
|
|
2021-02-03 01:15:45 +01:00
|
|
|
case INDEX_op_movcond_i32:
|
|
|
|
|
case INDEX_op_movcond_i64:
|
2021-01-31 02:48:19 +01:00
|
|
|
case INDEX_op_setcond2_i32:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrrc(insn, &r0, &r1, &r2, &r3, &r4, &c);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s, %s, %s, %s",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), str_r(r2),
|
|
|
|
|
str_r(r3), str_r(r4), str_c(c));
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_mulu2_i32:
|
2021-02-03 02:21:27 +01:00
|
|
|
case INDEX_op_mulu2_i64:
|
|
|
|
|
case INDEX_op_muls2_i32:
|
|
|
|
|
case INDEX_op_muls2_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrr(insn, &r0, &r1, &r2, &r3);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s, %s",
|
|
|
|
|
op_name, str_r(r0), str_r(r1),
|
|
|
|
|
str_r(r2), str_r(r3));
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_add2_i32:
|
2021-02-03 02:40:12 +01:00
|
|
|
case INDEX_op_add2_i64:
|
2021-01-31 02:48:19 +01:00
|
|
|
case INDEX_op_sub2_i32:
|
2021-02-03 02:40:12 +01:00
|
|
|
case INDEX_op_sub2_i64:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrrr(insn, &r0, &r1, &r2, &r3, &r4, &r5);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s, %s, %s, %s",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), str_r(r2),
|
|
|
|
|
str_r(r3), str_r(r4), str_r(r5));
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case INDEX_op_qemu_ld_i64:
|
|
|
|
|
case INDEX_op_qemu_st_i64:
|
|
|
|
|
len = DIV_ROUND_UP(64, TCG_TARGET_REG_BITS);
|
|
|
|
|
goto do_qemu_ldst;
|
|
|
|
|
case INDEX_op_qemu_ld_i32:
|
|
|
|
|
case INDEX_op_qemu_st_i32:
|
|
|
|
|
len = 1;
|
|
|
|
|
do_qemu_ldst:
|
|
|
|
|
len += DIV_ROUND_UP(TARGET_LONG_BITS, TCG_TARGET_REG_BITS);
|
|
|
|
|
switch (len) {
|
|
|
|
|
case 2:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrm(insn, &r0, &r1, &oi);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %x",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), oi);
|
|
|
|
|
break;
|
|
|
|
|
case 3:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrm(insn, &r0, &r1, &r2, &oi);
|
2021-01-31 02:48:19 +01:00
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s, %x",
|
|
|
|
|
op_name, str_r(r0), str_r(r1), str_r(r2), oi);
|
|
|
|
|
break;
|
|
|
|
|
case 4:
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
tci_args_rrrrr(insn, &r0, &r1, &r2, &r3, &r4);
|
|
|
|
|
info->fprintf_func(info->stream, "%-12s %s, %s, %s, %s, %s",
|
2021-01-31 02:48:19 +01:00
|
|
|
op_name, str_r(r0), str_r(r1),
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
str_r(r2), str_r(r3), str_r(r4));
|
2021-01-31 02:48:19 +01:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
g_assert_not_reached();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
case 0:
|
|
|
|
|
/* tcg_out_nop_fill uses zeros */
|
|
|
|
|
if (insn == 0) {
|
|
|
|
|
info->fprintf_func(info->stream, "align");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/* fall through */
|
|
|
|
|
|
2021-01-31 02:48:19 +01:00
|
|
|
default:
|
|
|
|
|
info->fprintf_func(info->stream, "illegal opcode %d", op);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
tcg/tci: Change encoding to uint32_t units
This removes all of the problems with unaligned accesses
to the bytecode stream.
With an 8-bit opcode at the bottom, we have 24 bits remaining,
which are generally split into 6 4-bit slots. This fits well
with the maximum length opcodes, e.g. INDEX_op_add2_i32, which
have 6 register operands.
We have, in previous patches, rearranged things such that there
are no operations with a label which have more than one other
operand. Which leaves us with a 20-bit field in which to encode
a label, giving us a maximum TB size of 512k -- easily large.
Change the INDEX_op_tci_movi_{i32,i64} opcodes to tci_mov[il].
The former puts the immediate in the upper 20 bits of the insn,
like we do for the label displacement. The later uses a label
to reference an entry in the constant pool. Thus, in the worst
case we still have a single memory reference for any constant,
but now the constants are out-of-line of the bytecode and can
be shared between different moves saving space.
Change INDEX_op_call to use a label to reference a pair of
pointers in the constant pool. This removes the only slightly
dodgy link with the layout of struct TCGHelperInfo.
The re-encode cannot be done in pieces.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-02 08:27:41 +01:00
|
|
|
return sizeof(insn);
|
2021-01-31 02:48:19 +01:00
|
|
|
}
|