tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
/*
|
|
|
|
* Tiny Code Generator for QEMU
|
|
|
|
*
|
|
|
|
* Copyright (c) 2009-2010 Aurelien Jarno <aurelien@aurel32.net>
|
|
|
|
* Based on i386/tcg-target.c - Copyright (c) 2008 Fabrice Bellard
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Register definitions
|
|
|
|
*/
|
|
|
|
|
2016-04-21 11:48:50 +03:00
|
|
|
#ifdef CONFIG_DEBUG_TCG
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static const char * const tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
|
|
|
|
"r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
|
|
|
|
"r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
|
|
|
|
"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
|
|
|
|
"r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
|
|
|
|
"r32", "r33", "r34", "r35", "r36", "r37", "r38", "r39",
|
|
|
|
"r40", "r41", "r42", "r43", "r44", "r45", "r46", "r47",
|
|
|
|
"r48", "r49", "r50", "r51", "r52", "r53", "r54", "r55",
|
|
|
|
"r56", "r57", "r58", "r59", "r60", "r61", "r62", "r63",
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2015-08-24 02:42:07 +03:00
|
|
|
#ifndef CONFIG_SOFTMMU
|
2010-05-06 19:50:44 +04:00
|
|
|
#define TCG_GUEST_BASE_REG TCG_REG_R55
|
|
|
|
#endif
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
/* Branch registers */
|
|
|
|
enum {
|
|
|
|
TCG_REG_B0 = 0,
|
|
|
|
TCG_REG_B1,
|
|
|
|
TCG_REG_B2,
|
|
|
|
TCG_REG_B3,
|
|
|
|
TCG_REG_B4,
|
|
|
|
TCG_REG_B5,
|
|
|
|
TCG_REG_B6,
|
|
|
|
TCG_REG_B7,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Floating point registers */
|
|
|
|
enum {
|
|
|
|
TCG_REG_F0 = 0,
|
|
|
|
TCG_REG_F1,
|
|
|
|
TCG_REG_F2,
|
|
|
|
TCG_REG_F3,
|
|
|
|
TCG_REG_F4,
|
|
|
|
TCG_REG_F5,
|
|
|
|
TCG_REG_F6,
|
|
|
|
TCG_REG_F7,
|
|
|
|
TCG_REG_F8,
|
|
|
|
TCG_REG_F9,
|
|
|
|
TCG_REG_F10,
|
|
|
|
TCG_REG_F11,
|
|
|
|
TCG_REG_F12,
|
|
|
|
TCG_REG_F13,
|
|
|
|
TCG_REG_F14,
|
|
|
|
TCG_REG_F15,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Predicate registers */
|
|
|
|
enum {
|
|
|
|
TCG_REG_P0 = 0,
|
|
|
|
TCG_REG_P1,
|
|
|
|
TCG_REG_P2,
|
|
|
|
TCG_REG_P3,
|
|
|
|
TCG_REG_P4,
|
|
|
|
TCG_REG_P5,
|
|
|
|
TCG_REG_P6,
|
|
|
|
TCG_REG_P7,
|
|
|
|
TCG_REG_P8,
|
|
|
|
TCG_REG_P9,
|
|
|
|
TCG_REG_P10,
|
|
|
|
TCG_REG_P11,
|
|
|
|
TCG_REG_P12,
|
|
|
|
TCG_REG_P13,
|
|
|
|
TCG_REG_P14,
|
|
|
|
TCG_REG_P15,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Application registers */
|
|
|
|
enum {
|
|
|
|
TCG_REG_PFS = 64,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const int tcg_target_reg_alloc_order[] = {
|
|
|
|
TCG_REG_R35,
|
|
|
|
TCG_REG_R36,
|
|
|
|
TCG_REG_R37,
|
|
|
|
TCG_REG_R38,
|
|
|
|
TCG_REG_R39,
|
|
|
|
TCG_REG_R40,
|
|
|
|
TCG_REG_R41,
|
|
|
|
TCG_REG_R42,
|
|
|
|
TCG_REG_R43,
|
|
|
|
TCG_REG_R44,
|
|
|
|
TCG_REG_R45,
|
|
|
|
TCG_REG_R46,
|
|
|
|
TCG_REG_R47,
|
|
|
|
TCG_REG_R48,
|
|
|
|
TCG_REG_R49,
|
|
|
|
TCG_REG_R50,
|
|
|
|
TCG_REG_R51,
|
|
|
|
TCG_REG_R52,
|
|
|
|
TCG_REG_R53,
|
|
|
|
TCG_REG_R54,
|
|
|
|
TCG_REG_R55,
|
|
|
|
TCG_REG_R14,
|
|
|
|
TCG_REG_R15,
|
|
|
|
TCG_REG_R16,
|
|
|
|
TCG_REG_R17,
|
|
|
|
TCG_REG_R18,
|
|
|
|
TCG_REG_R19,
|
|
|
|
TCG_REG_R20,
|
|
|
|
TCG_REG_R21,
|
|
|
|
TCG_REG_R22,
|
|
|
|
TCG_REG_R23,
|
|
|
|
TCG_REG_R24,
|
|
|
|
TCG_REG_R25,
|
|
|
|
TCG_REG_R26,
|
|
|
|
TCG_REG_R27,
|
|
|
|
TCG_REG_R28,
|
|
|
|
TCG_REG_R29,
|
|
|
|
TCG_REG_R30,
|
|
|
|
TCG_REG_R31,
|
|
|
|
TCG_REG_R56,
|
|
|
|
TCG_REG_R57,
|
|
|
|
TCG_REG_R58,
|
|
|
|
TCG_REG_R59,
|
|
|
|
TCG_REG_R60,
|
|
|
|
TCG_REG_R61,
|
|
|
|
TCG_REG_R62,
|
|
|
|
TCG_REG_R63,
|
|
|
|
TCG_REG_R8,
|
|
|
|
TCG_REG_R9,
|
|
|
|
TCG_REG_R10,
|
|
|
|
TCG_REG_R11
|
|
|
|
};
|
|
|
|
|
|
|
|
static const int tcg_target_call_iarg_regs[8] = {
|
|
|
|
TCG_REG_R56,
|
|
|
|
TCG_REG_R57,
|
|
|
|
TCG_REG_R58,
|
|
|
|
TCG_REG_R59,
|
|
|
|
TCG_REG_R60,
|
|
|
|
TCG_REG_R61,
|
|
|
|
TCG_REG_R62,
|
|
|
|
TCG_REG_R63,
|
|
|
|
};
|
|
|
|
|
2011-09-05 13:06:59 +04:00
|
|
|
static const int tcg_target_call_oarg_regs[] = {
|
|
|
|
TCG_REG_R8
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* opcode formation
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* bundle templates: stops (double bar in the IA64 manual) are marked with
|
|
|
|
an uppercase letter. */
|
|
|
|
enum {
|
|
|
|
mii = 0x00,
|
|
|
|
miI = 0x01,
|
|
|
|
mIi = 0x02,
|
|
|
|
mII = 0x03,
|
|
|
|
mlx = 0x04,
|
|
|
|
mLX = 0x05,
|
|
|
|
mmi = 0x08,
|
|
|
|
mmI = 0x09,
|
|
|
|
Mmi = 0x0a,
|
|
|
|
MmI = 0x0b,
|
|
|
|
mfi = 0x0c,
|
|
|
|
mfI = 0x0d,
|
|
|
|
mmf = 0x0e,
|
|
|
|
mmF = 0x0f,
|
|
|
|
mib = 0x10,
|
|
|
|
miB = 0x11,
|
|
|
|
mbb = 0x12,
|
|
|
|
mbB = 0x13,
|
|
|
|
bbb = 0x16,
|
|
|
|
bbB = 0x17,
|
|
|
|
mmb = 0x18,
|
|
|
|
mmB = 0x19,
|
|
|
|
mfb = 0x1c,
|
|
|
|
mfB = 0x1d,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
OPC_ADD_A1 = 0x10000000000ull,
|
|
|
|
OPC_AND_A1 = 0x10060000000ull,
|
|
|
|
OPC_AND_A3 = 0x10160000000ull,
|
|
|
|
OPC_ANDCM_A1 = 0x10068000000ull,
|
|
|
|
OPC_ANDCM_A3 = 0x10168000000ull,
|
|
|
|
OPC_ADDS_A4 = 0x10800000000ull,
|
|
|
|
OPC_ADDL_A5 = 0x12000000000ull,
|
|
|
|
OPC_ALLOC_M34 = 0x02c00000000ull,
|
|
|
|
OPC_BR_DPTK_FEW_B1 = 0x08400000000ull,
|
|
|
|
OPC_BR_SPTK_MANY_B1 = 0x08000001000ull,
|
2013-09-06 10:06:59 +04:00
|
|
|
OPC_BR_CALL_SPNT_FEW_B3 = 0x0a200000000ull,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
OPC_BR_SPTK_MANY_B4 = 0x00100001000ull,
|
|
|
|
OPC_BR_CALL_SPTK_MANY_B5 = 0x02100001000ull,
|
|
|
|
OPC_BR_RET_SPTK_MANY_B4 = 0x00108001100ull,
|
|
|
|
OPC_BRL_SPTK_MANY_X3 = 0x18000001000ull,
|
2013-09-06 08:38:52 +04:00
|
|
|
OPC_BRL_CALL_SPNT_MANY_X4 = 0x1a200001000ull,
|
2013-09-05 20:11:27 +04:00
|
|
|
OPC_BRL_CALL_SPTK_MANY_X4 = 0x1a000001000ull,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
OPC_CMP_LT_A6 = 0x18000000000ull,
|
|
|
|
OPC_CMP_LTU_A6 = 0x1a000000000ull,
|
|
|
|
OPC_CMP_EQ_A6 = 0x1c000000000ull,
|
|
|
|
OPC_CMP4_LT_A6 = 0x18400000000ull,
|
|
|
|
OPC_CMP4_LTU_A6 = 0x1a400000000ull,
|
|
|
|
OPC_CMP4_EQ_A6 = 0x1c400000000ull,
|
2012-10-09 23:53:55 +04:00
|
|
|
OPC_DEP_I14 = 0x0ae00000000ull,
|
2012-10-11 03:01:35 +04:00
|
|
|
OPC_DEP_I15 = 0x08000000000ull,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
OPC_DEP_Z_I12 = 0x0a600000000ull,
|
|
|
|
OPC_EXTR_I11 = 0x0a400002000ull,
|
|
|
|
OPC_EXTR_U_I11 = 0x0a400000000ull,
|
|
|
|
OPC_FCVT_FX_TRUNC_S1_F10 = 0x004d0000000ull,
|
|
|
|
OPC_FCVT_FXU_TRUNC_S1_F10 = 0x004d8000000ull,
|
|
|
|
OPC_FCVT_XF_F11 = 0x000e0000000ull,
|
|
|
|
OPC_FMA_S1_F1 = 0x10400000000ull,
|
|
|
|
OPC_FNMA_S1_F1 = 0x18400000000ull,
|
|
|
|
OPC_FRCPA_S1_F6 = 0x00600000000ull,
|
|
|
|
OPC_GETF_SIG_M19 = 0x08708000000ull,
|
|
|
|
OPC_LD1_M1 = 0x08000000000ull,
|
|
|
|
OPC_LD1_M3 = 0x0a000000000ull,
|
|
|
|
OPC_LD2_M1 = 0x08040000000ull,
|
|
|
|
OPC_LD2_M3 = 0x0a040000000ull,
|
|
|
|
OPC_LD4_M1 = 0x08080000000ull,
|
|
|
|
OPC_LD4_M3 = 0x0a080000000ull,
|
|
|
|
OPC_LD8_M1 = 0x080c0000000ull,
|
|
|
|
OPC_LD8_M3 = 0x0a0c0000000ull,
|
2016-07-14 23:20:17 +03:00
|
|
|
OPC_MF_M24 = 0x00110000000ull,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
OPC_MUX1_I3 = 0x0eca0000000ull,
|
|
|
|
OPC_NOP_B9 = 0x04008000000ull,
|
|
|
|
OPC_NOP_F16 = 0x00008000000ull,
|
|
|
|
OPC_NOP_I18 = 0x00008000000ull,
|
|
|
|
OPC_NOP_M48 = 0x00008000000ull,
|
|
|
|
OPC_MOV_I21 = 0x00e00100000ull,
|
|
|
|
OPC_MOV_RET_I21 = 0x00e00500000ull,
|
|
|
|
OPC_MOV_I22 = 0x00188000000ull,
|
|
|
|
OPC_MOV_I_I26 = 0x00150000000ull,
|
|
|
|
OPC_MOVL_X2 = 0x0c000000000ull,
|
|
|
|
OPC_OR_A1 = 0x10070000000ull,
|
2013-09-06 01:13:43 +04:00
|
|
|
OPC_OR_A3 = 0x10170000000ull,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
OPC_SETF_EXP_M18 = 0x0c748000000ull,
|
|
|
|
OPC_SETF_SIG_M18 = 0x0c708000000ull,
|
|
|
|
OPC_SHL_I7 = 0x0f240000000ull,
|
|
|
|
OPC_SHR_I5 = 0x0f220000000ull,
|
|
|
|
OPC_SHR_U_I5 = 0x0f200000000ull,
|
|
|
|
OPC_SHRP_I10 = 0x0ac00000000ull,
|
|
|
|
OPC_SXT1_I29 = 0x000a0000000ull,
|
|
|
|
OPC_SXT2_I29 = 0x000a8000000ull,
|
|
|
|
OPC_SXT4_I29 = 0x000b0000000ull,
|
|
|
|
OPC_ST1_M4 = 0x08c00000000ull,
|
|
|
|
OPC_ST2_M4 = 0x08c40000000ull,
|
|
|
|
OPC_ST4_M4 = 0x08c80000000ull,
|
|
|
|
OPC_ST8_M4 = 0x08cc0000000ull,
|
|
|
|
OPC_SUB_A1 = 0x10028000000ull,
|
|
|
|
OPC_SUB_A3 = 0x10128000000ull,
|
|
|
|
OPC_UNPACK4_L_I2 = 0x0f860000000ull,
|
|
|
|
OPC_XMA_L_F2 = 0x1d000000000ull,
|
|
|
|
OPC_XOR_A1 = 0x10078000000ull,
|
2013-09-06 01:13:43 +04:00
|
|
|
OPC_XOR_A3 = 0x10178000000ull,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
OPC_ZXT1_I29 = 0x00080000000ull,
|
|
|
|
OPC_ZXT2_I29 = 0x00088000000ull,
|
|
|
|
OPC_ZXT4_I29 = 0x00090000000ull,
|
2013-09-05 03:00:52 +04:00
|
|
|
|
|
|
|
INSN_NOP_M = OPC_NOP_M48, /* nop.m 0 */
|
|
|
|
INSN_NOP_I = OPC_NOP_I18, /* nop.i 0 */
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_a1(int qp, uint64_t opc, int r1,
|
|
|
|
int r2, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_a3(int qp, uint64_t opc, int r1,
|
|
|
|
uint64_t imm, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x80) << 29) /* s */
|
|
|
|
| ((imm & 0x7f) << 13) /* imm7b */
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_a4(int qp, uint64_t opc, int r1,
|
|
|
|
uint64_t imm, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x2000) << 23) /* s */
|
|
|
|
| ((imm & 0x1f80) << 20) /* imm6d */
|
|
|
|
| ((imm & 0x007f) << 13) /* imm7b */
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_a5(int qp, uint64_t opc, int r1,
|
|
|
|
uint64_t imm, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x200000) << 15) /* s */
|
|
|
|
| ((imm & 0x1f0000) << 6) /* imm5c */
|
|
|
|
| ((imm & 0x00ff80) << 20) /* imm9d */
|
|
|
|
| ((imm & 0x00007f) << 13) /* imm7b */
|
|
|
|
| ((r3 & 0x03) << 20)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_a6(int qp, uint64_t opc, int p1,
|
|
|
|
int p2, int r2, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((p2 & 0x3f) << 27)
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((p1 & 0x3f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_b1(int qp, uint64_t opc, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x100000) << 16) /* s */
|
|
|
|
| ((imm & 0x0fffff) << 13) /* imm20b */
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
2013-09-06 10:06:59 +04:00
|
|
|
static inline uint64_t tcg_opc_b3(int qp, uint64_t opc, int b1, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x100000) << 16) /* s */
|
|
|
|
| ((imm & 0x0fffff) << 13) /* imm20b */
|
|
|
|
| ((b1 & 0x7) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline uint64_t tcg_opc_b4(int qp, uint64_t opc, int b2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((b2 & 0x7) << 13)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_b5(int qp, uint64_t opc, int b1, int b2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((b2 & 0x7) << 13)
|
|
|
|
| ((b1 & 0x7) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_b9(int qp, uint64_t opc, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x100000) << 16) /* i */
|
|
|
|
| ((imm & 0x0fffff) << 6) /* imm20a */
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_f1(int qp, uint64_t opc, int f1,
|
|
|
|
int f3, int f4, int f2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((f4 & 0x7f) << 27)
|
|
|
|
| ((f3 & 0x7f) << 20)
|
|
|
|
| ((f2 & 0x7f) << 13)
|
|
|
|
| ((f1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_f2(int qp, uint64_t opc, int f1,
|
|
|
|
int f3, int f4, int f2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((f4 & 0x7f) << 27)
|
|
|
|
| ((f3 & 0x7f) << 20)
|
|
|
|
| ((f2 & 0x7f) << 13)
|
|
|
|
| ((f1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_f6(int qp, uint64_t opc, int f1,
|
|
|
|
int p2, int f2, int f3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((p2 & 0x3f) << 27)
|
|
|
|
| ((f3 & 0x7f) << 20)
|
|
|
|
| ((f2 & 0x7f) << 13)
|
|
|
|
| ((f1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_f10(int qp, uint64_t opc, int f1, int f2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((f2 & 0x7f) << 13)
|
|
|
|
| ((f1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_f11(int qp, uint64_t opc, int f1, int f2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((f2 & 0x7f) << 13)
|
|
|
|
| ((f1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_f16(int qp, uint64_t opc, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x100000) << 16) /* i */
|
|
|
|
| ((imm & 0x0fffff) << 6) /* imm20a */
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i2(int qp, uint64_t opc, int r1,
|
|
|
|
int r2, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i3(int qp, uint64_t opc, int r1,
|
|
|
|
int r2, int mbtype)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((mbtype & 0x0f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i5(int qp, uint64_t opc, int r1,
|
|
|
|
int r3, int r2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i7(int qp, uint64_t opc, int r1,
|
|
|
|
int r2, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i10(int qp, uint64_t opc, int r1,
|
|
|
|
int r2, int r3, uint64_t count)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((count & 0x3f) << 27)
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i11(int qp, uint64_t opc, int r1,
|
|
|
|
int r3, uint64_t pos, uint64_t len)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((len & 0x3f) << 27)
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((pos & 0x3f) << 14)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i12(int qp, uint64_t opc, int r1,
|
|
|
|
int r2, uint64_t pos, uint64_t len)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((len & 0x3f) << 27)
|
|
|
|
| ((pos & 0x3f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
2012-10-09 23:53:55 +04:00
|
|
|
static inline uint64_t tcg_opc_i14(int qp, uint64_t opc, int r1, uint64_t imm,
|
|
|
|
int r3, uint64_t pos, uint64_t len)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x01) << 36)
|
|
|
|
| ((len & 0x3f) << 27)
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((pos & 0x3f) << 14)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
2012-10-11 03:01:35 +04:00
|
|
|
static inline uint64_t tcg_opc_i15(int qp, uint64_t opc, int r1, int r2,
|
|
|
|
int r3, uint64_t pos, uint64_t len)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((pos & 0x3f) << 31)
|
|
|
|
| ((len & 0x0f) << 27)
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline uint64_t tcg_opc_i18(int qp, uint64_t opc, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x100000) << 16) /* i */
|
|
|
|
| ((imm & 0x0fffff) << 6) /* imm20a */
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i21(int qp, uint64_t opc, int b1,
|
|
|
|
int r2, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x1ff) << 24)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((b1 & 0x7) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i22(int qp, uint64_t opc, int r1, int b2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((b2 & 0x7) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i26(int qp, uint64_t opc, int ar3, int r2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((ar3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_i29(int qp, uint64_t opc, int r1, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_l2(uint64_t imm)
|
|
|
|
{
|
|
|
|
return (imm & 0x7fffffffffc00000ull) >> 22;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_l3(uint64_t imm)
|
|
|
|
{
|
|
|
|
return (imm & 0x07fffffffff00000ull) >> 18;
|
|
|
|
}
|
|
|
|
|
2013-09-05 20:11:27 +04:00
|
|
|
#define tcg_opc_l4 tcg_opc_l3
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline uint64_t tcg_opc_m1(int qp, uint64_t opc, int r1, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_m3(int qp, uint64_t opc, int r1,
|
|
|
|
int r3, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x100) << 28) /* s */
|
|
|
|
| ((imm & 0x080) << 20) /* i */
|
|
|
|
| ((imm & 0x07f) << 13) /* imm7b */
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_m4(int qp, uint64_t opc, int r2, int r3)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r3 & 0x7f) << 20)
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_m18(int qp, uint64_t opc, int f1, int r2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((r2 & 0x7f) << 13)
|
|
|
|
| ((f1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_m19(int qp, uint64_t opc, int r1, int f2)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((f2 & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_m34(int qp, uint64_t opc, int r1,
|
|
|
|
int sof, int sol, int sor)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((sor & 0x0f) << 27)
|
|
|
|
| ((sol & 0x7f) << 20)
|
|
|
|
| ((sof & 0x7f) << 13)
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_m48(int qp, uint64_t opc, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x100000) << 16) /* i */
|
|
|
|
| ((imm & 0x0fffff) << 6) /* imm20a */
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_x2(int qp, uint64_t opc,
|
|
|
|
int r1, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x8000000000000000ull) >> 27) /* i */
|
|
|
|
| (imm & 0x0000000000200000ull) /* ic */
|
|
|
|
| ((imm & 0x00000000001f0000ull) << 6) /* imm5c */
|
|
|
|
| ((imm & 0x000000000000ff80ull) << 20) /* imm9d */
|
|
|
|
| ((imm & 0x000000000000007full) << 13) /* imm7b */
|
|
|
|
| ((r1 & 0x7f) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_x3(int qp, uint64_t opc, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x0800000000000000ull) >> 23) /* i */
|
|
|
|
| ((imm & 0x00000000000fffffull) << 13) /* imm20b */
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
2013-09-05 20:11:27 +04:00
|
|
|
static inline uint64_t tcg_opc_x4(int qp, uint64_t opc, int b1, uint64_t imm)
|
|
|
|
{
|
|
|
|
return opc
|
|
|
|
| ((imm & 0x0800000000000000ull) >> 23) /* i */
|
|
|
|
| ((imm & 0x00000000000fffffull) << 13) /* imm20b */
|
|
|
|
| ((b1 & 0x7) << 6)
|
|
|
|
| (qp & 0x3f);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
/*
|
2014-04-25 21:24:23 +04:00
|
|
|
* Relocations - Note that we never encode branches elsewhere than slot 2.
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
*/
|
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
static void reloc_pcrel21b_slot2(tcg_insn_unit *pc, tcg_insn_unit *target)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2014-04-25 21:24:23 +04:00
|
|
|
uint64_t imm = target - pc;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
pc->hi = (pc->hi & 0xf700000fffffffffull)
|
|
|
|
| ((imm & 0x100000) << 39) /* s */
|
|
|
|
| ((imm & 0x0fffff) << 36); /* imm20b */
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
static uint64_t get_reloc_pcrel21b_slot2(tcg_insn_unit *pc)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2014-04-25 21:24:23 +04:00
|
|
|
int64_t high = pc->hi;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
return ((high >> 39) & 0x100000) + /* s */
|
|
|
|
((high >> 36) & 0x0fffff); /* imm20b */
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
static void patch_reloc(tcg_insn_unit *code_ptr, int type,
|
2013-08-21 02:30:10 +04:00
|
|
|
intptr_t value, intptr_t addend)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2016-04-21 11:48:49 +03:00
|
|
|
tcg_debug_assert(addend == 0);
|
|
|
|
tcg_debug_assert(type == R_IA64_PCREL21B);
|
2014-04-25 21:24:23 +04:00
|
|
|
reloc_pcrel21b_slot2(code_ptr, (tcg_insn_unit *)value);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Constraints
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* parse target specific constraints */
|
|
|
|
static int target_parse_constraint(TCGArgConstraint *ct, const char **pct_str)
|
|
|
|
{
|
|
|
|
const char *ct_str;
|
|
|
|
|
|
|
|
ct_str = *pct_str;
|
|
|
|
switch(ct_str[0]) {
|
|
|
|
case 'r':
|
|
|
|
ct->ct |= TCG_CT_REG;
|
|
|
|
tcg_regset_set(ct->u.regs, 0xffffffffffffffffull);
|
|
|
|
break;
|
|
|
|
case 'I':
|
|
|
|
ct->ct |= TCG_CT_CONST_S22;
|
|
|
|
break;
|
|
|
|
case 'S':
|
|
|
|
ct->ct |= TCG_CT_REG;
|
|
|
|
tcg_regset_set(ct->u.regs, 0xffffffffffffffffull);
|
|
|
|
#if defined(CONFIG_SOFTMMU)
|
|
|
|
tcg_regset_reset_reg(ct->u.regs, TCG_REG_R56);
|
|
|
|
tcg_regset_reset_reg(ct->u.regs, TCG_REG_R57);
|
2013-09-06 08:38:52 +04:00
|
|
|
tcg_regset_reset_reg(ct->u.regs, TCG_REG_R58);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
#endif
|
|
|
|
break;
|
|
|
|
case 'Z':
|
|
|
|
/* We are cheating a bit here, using the fact that the register
|
|
|
|
r0 is also the register number 0. Hence there is no need
|
|
|
|
to check for const_args in each instruction. */
|
|
|
|
ct->ct |= TCG_CT_CONST_ZERO;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
ct_str++;
|
|
|
|
*pct_str = ct_str;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* test if a constant matches the constraint */
|
2014-03-31 08:22:11 +04:00
|
|
|
static inline int tcg_target_const_match(tcg_target_long val, TCGType type,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
const TCGArgConstraint *arg_ct)
|
|
|
|
{
|
|
|
|
int ct;
|
|
|
|
ct = arg_ct->ct;
|
|
|
|
if (ct & TCG_CT_CONST)
|
|
|
|
return 1;
|
|
|
|
else if ((ct & TCG_CT_CONST_ZERO) && val == 0)
|
|
|
|
return 1;
|
|
|
|
else if ((ct & TCG_CT_CONST_S22) && val == ((int32_t)val << 10) >> 10)
|
|
|
|
return 1;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Code generation
|
|
|
|
*/
|
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
static tcg_insn_unit *tb_ret_addr;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
static inline void tcg_out_bundle(TCGContext *s, int template,
|
|
|
|
uint64_t slot0, uint64_t slot1,
|
|
|
|
uint64_t slot2)
|
|
|
|
{
|
|
|
|
template &= 0x1f; /* 5 bits */
|
|
|
|
slot0 &= 0x1ffffffffffull; /* 41 bits */
|
|
|
|
slot1 &= 0x1ffffffffffull; /* 41 bits */
|
|
|
|
slot2 &= 0x1ffffffffffull; /* 41 bits */
|
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
*s->code_ptr++ = (tcg_insn_unit){
|
|
|
|
(slot1 << 46) | (slot0 << 5) | template,
|
|
|
|
(slot2 << 23) | (slot1 >> 18)
|
|
|
|
};
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2013-09-06 02:48:42 +04:00
|
|
|
static inline uint64_t tcg_opc_mov_a(int qp, TCGReg dst, TCGReg src)
|
|
|
|
{
|
|
|
|
return tcg_opc_a4(qp, OPC_ADDS_A4, dst, 0, src);
|
|
|
|
}
|
|
|
|
|
2010-06-03 04:26:55 +04:00
|
|
|
static inline void tcg_out_mov(TCGContext *s, TCGType type,
|
2011-11-09 12:03:34 +04:00
|
|
|
TCGReg ret, TCGReg arg)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mmI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
2013-09-06 02:48:42 +04:00
|
|
|
tcg_opc_mov_a(TCG_REG_P0, ret, arg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2013-09-06 02:56:39 +04:00
|
|
|
static inline uint64_t tcg_opc_movi_a(int qp, TCGReg dst, int64_t src)
|
|
|
|
{
|
2016-04-21 11:48:49 +03:00
|
|
|
tcg_debug_assert(src == sextract64(src, 0, 22));
|
2013-09-06 02:56:39 +04:00
|
|
|
return tcg_opc_a5(qp, OPC_ADDL_A5, dst, src, TCG_REG_R0);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline void tcg_out_movi(TCGContext *s, TCGType type,
|
2011-11-09 12:03:34 +04:00
|
|
|
TCGReg reg, tcg_target_long arg)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mLX,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_l2 (arg),
|
|
|
|
tcg_opc_x2 (TCG_REG_P0, OPC_MOVL_X2, reg, arg));
|
|
|
|
}
|
|
|
|
|
2015-02-14 00:39:54 +03:00
|
|
|
static void tcg_out_br(TCGContext *s, TCGLabel *l)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2014-04-25 21:24:23 +04:00
|
|
|
uint64_t imm;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2011-01-10 20:30:05 +03:00
|
|
|
/* We pay attention here to not modify the branch target by reading
|
|
|
|
the existing value and using it again. This ensure that caches and
|
|
|
|
memory are kept coherent during retranslation. */
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
if (l->has_value) {
|
2014-04-25 21:24:23 +04:00
|
|
|
imm = l->u.value_ptr - s->code_ptr;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
2014-04-25 21:24:23 +04:00
|
|
|
imm = get_reloc_pcrel21b_slot2(s->code_ptr);
|
2015-02-14 00:39:54 +03:00
|
|
|
tcg_out_reloc(s, s->code_ptr, R_IA64_PCREL21B, l, 0);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
2014-04-25 21:24:23 +04:00
|
|
|
|
|
|
|
tcg_out_bundle(s, mmB,
|
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
|
|
|
tcg_opc_b1(TCG_REG_P0, OPC_BR_SPTK_MANY_B1, imm));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
static inline void tcg_out_call(TCGContext *s, tcg_insn_unit *desc)
|
2013-09-05 20:11:27 +04:00
|
|
|
{
|
2014-04-25 21:24:23 +04:00
|
|
|
uintptr_t func = desc->lo, gp = desc->hi, disp;
|
|
|
|
|
2013-09-05 20:11:27 +04:00
|
|
|
/* Look through the function descriptor. */
|
|
|
|
tcg_out_bundle(s, mlx,
|
|
|
|
INSN_NOP_M,
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_opc_l2 (gp),
|
|
|
|
tcg_opc_x2 (TCG_REG_P0, OPC_MOVL_X2, TCG_REG_R1, gp));
|
|
|
|
disp = (tcg_insn_unit *)func - s->code_ptr;
|
2013-09-05 20:11:27 +04:00
|
|
|
tcg_out_bundle(s, mLX,
|
|
|
|
INSN_NOP_M,
|
|
|
|
tcg_opc_l4 (disp),
|
|
|
|
tcg_opc_x4 (TCG_REG_P0, OPC_BRL_CALL_SPTK_MANY_X4,
|
|
|
|
TCG_REG_B0, disp));
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static void tcg_out_exit_tb(TCGContext *s, tcg_target_long arg)
|
|
|
|
{
|
2013-10-31 23:19:23 +04:00
|
|
|
uint64_t imm, opc1;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2013-10-31 23:19:23 +04:00
|
|
|
/* At least arg == 0 is a common operation. */
|
|
|
|
if (arg == sextract64(arg, 0, 22)) {
|
|
|
|
opc1 = tcg_opc_movi_a(TCG_REG_P0, TCG_REG_R8, arg);
|
|
|
|
} else {
|
|
|
|
tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R8, arg);
|
|
|
|
opc1 = INSN_NOP_M;
|
|
|
|
}
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
imm = tb_ret_addr - s->code_ptr;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
tcg_out_bundle(s, mLX,
|
2013-10-31 23:19:23 +04:00
|
|
|
opc1,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_l3 (imm),
|
|
|
|
tcg_opc_x3 (TCG_REG_P0, OPC_BRL_SPTK_MANY_X3, imm));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_goto_tb(TCGContext *s, TCGArg arg)
|
|
|
|
{
|
2016-04-10 23:35:45 +03:00
|
|
|
if (s->tb_jmp_insn_offset) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
/* direct jump method */
|
|
|
|
tcg_abort();
|
|
|
|
} else {
|
|
|
|
/* indirect jump method */
|
|
|
|
tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R2,
|
2016-04-10 23:35:45 +03:00
|
|
|
(tcg_target_long)(s->tb_jmp_target_addr + arg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, OPC_LD8_M1,
|
|
|
|
TCG_REG_R2, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i21(TCG_REG_P0, OPC_MOV_I21, TCG_REG_B6,
|
|
|
|
TCG_REG_R2, 0));
|
|
|
|
tcg_out_bundle(s, mmB,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_b4 (TCG_REG_P0, OPC_BR_SPTK_MANY_B4,
|
|
|
|
TCG_REG_B6));
|
|
|
|
}
|
2016-04-10 23:35:45 +03:00
|
|
|
s->tb_jmp_reset_offset[arg] = tcg_current_code_size(s);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_jmp(TCGContext *s, TCGArg addr)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mmI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i21(TCG_REG_P0, OPC_MOV_I21, TCG_REG_B6, addr, 0));
|
|
|
|
tcg_out_bundle(s, mmB,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_b4(TCG_REG_P0, OPC_BR_SPTK_MANY_B4, TCG_REG_B6));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_ld_rel(TCGContext *s, uint64_t opc_m4, TCGArg arg,
|
|
|
|
TCGArg arg1, tcg_target_long arg2)
|
|
|
|
{
|
|
|
|
if (arg2 == ((int16_t)arg2 >> 2) << 2) {
|
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_a4(TCG_REG_P0, OPC_ADDS_A4,
|
|
|
|
TCG_REG_R2, arg2, arg1),
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_m4, arg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
|
|
|
tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R2, arg2);
|
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1,
|
|
|
|
TCG_REG_R2, TCG_REG_R2, arg1),
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_m4, arg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_st_rel(TCGContext *s, uint64_t opc_m4, TCGArg arg,
|
|
|
|
TCGArg arg1, tcg_target_long arg2)
|
|
|
|
{
|
|
|
|
if (arg2 == ((int16_t)arg2 >> 2) << 2) {
|
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_a4(TCG_REG_P0, OPC_ADDS_A4,
|
|
|
|
TCG_REG_R2, arg2, arg1),
|
|
|
|
tcg_opc_m4 (TCG_REG_P0, opc_m4, arg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
|
|
|
tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R2, arg2);
|
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1,
|
|
|
|
TCG_REG_R2, TCG_REG_R2, arg1),
|
|
|
|
tcg_opc_m4 (TCG_REG_P0, opc_m4, arg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-11-09 12:03:34 +04:00
|
|
|
static inline void tcg_out_ld(TCGContext *s, TCGType type, TCGReg arg,
|
2013-08-21 04:07:26 +04:00
|
|
|
TCGReg arg1, intptr_t arg2)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
|
|
|
if (type == TCG_TYPE_I32) {
|
|
|
|
tcg_out_ld_rel(s, OPC_LD4_M1, arg, arg1, arg2);
|
|
|
|
} else {
|
|
|
|
tcg_out_ld_rel(s, OPC_LD8_M1, arg, arg1, arg2);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-11-09 12:03:34 +04:00
|
|
|
static inline void tcg_out_st(TCGContext *s, TCGType type, TCGReg arg,
|
2013-08-21 04:07:26 +04:00
|
|
|
TCGReg arg1, intptr_t arg2)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
|
|
|
if (type == TCG_TYPE_I32) {
|
|
|
|
tcg_out_st_rel(s, OPC_ST4_M4, arg, arg1, arg2);
|
|
|
|
} else {
|
|
|
|
tcg_out_st_rel(s, OPC_ST8_M4, arg, arg1, arg2);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-20 08:59:13 +03:00
|
|
|
static inline bool tcg_out_sti(TCGContext *s, TCGType type, TCGArg val,
|
|
|
|
TCGReg base, intptr_t ofs)
|
|
|
|
{
|
|
|
|
if (val == 0) {
|
|
|
|
tcg_out_st(s, type, TCG_REG_R0, base, ofs);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-09-06 01:13:43 +04:00
|
|
|
static inline void tcg_out_alu(TCGContext *s, uint64_t opc_a1, uint64_t opc_a3,
|
|
|
|
TCGReg ret, TCGArg arg1, int const_arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2013-09-06 01:13:43 +04:00
|
|
|
uint64_t opc1 = 0, opc2 = 0, opc3 = 0;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
if (const_arg2 && arg2 != 0) {
|
2013-09-06 02:56:39 +04:00
|
|
|
opc2 = tcg_opc_movi_a(TCG_REG_P0, TCG_REG_R3, arg2);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
arg2 = TCG_REG_R3;
|
|
|
|
}
|
2013-09-06 01:13:43 +04:00
|
|
|
if (const_arg1 && arg1 != 0) {
|
|
|
|
if (opc_a3 && arg1 == (int8_t)arg1) {
|
|
|
|
opc3 = tcg_opc_a3(TCG_REG_P0, opc_a3, ret, arg1, arg2);
|
|
|
|
} else {
|
2013-09-06 02:56:39 +04:00
|
|
|
opc1 = tcg_opc_movi_a(TCG_REG_P0, TCG_REG_R2, arg1);
|
2013-09-06 01:13:43 +04:00
|
|
|
arg1 = TCG_REG_R2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (opc3 == 0) {
|
|
|
|
opc3 = tcg_opc_a1(TCG_REG_P0, opc_a1, ret, arg1, arg2);
|
|
|
|
}
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2013-09-05 23:56:44 +04:00
|
|
|
tcg_out_bundle(s, (opc1 || opc2 ? mII : miI),
|
|
|
|
opc1 ? opc1 : INSN_NOP_M,
|
|
|
|
opc2 ? opc2 : INSN_NOP_I,
|
2013-09-06 01:13:43 +04:00
|
|
|
opc3);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2013-09-06 00:15:13 +04:00
|
|
|
static inline void tcg_out_add(TCGContext *s, TCGReg ret, TCGReg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2 && arg2 == sextract64(arg2, 0, 14)) {
|
|
|
|
tcg_out_bundle(s, mmI,
|
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
|
|
|
tcg_opc_a4(TCG_REG_P0, OPC_ADDS_A4, ret, arg2, arg1));
|
|
|
|
} else {
|
2013-09-06 01:13:43 +04:00
|
|
|
tcg_out_alu(s, OPC_ADD_A1, 0, ret, arg1, 0, arg2, const_arg2);
|
2013-09-06 00:15:13 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-06 00:44:18 +04:00
|
|
|
static inline void tcg_out_sub(TCGContext *s, TCGReg ret, TCGArg arg1,
|
|
|
|
int const_arg1, TCGArg arg2, int const_arg2)
|
|
|
|
{
|
2013-09-06 01:13:43 +04:00
|
|
|
if (!const_arg1 && const_arg2 && -arg2 == sextract64(-arg2, 0, 14)) {
|
2013-09-06 00:44:18 +04:00
|
|
|
tcg_out_bundle(s, mmI,
|
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
|
|
|
tcg_opc_a4(TCG_REG_P0, OPC_ADDS_A4, ret, -arg2, arg1));
|
|
|
|
} else {
|
2013-09-06 01:13:43 +04:00
|
|
|
tcg_out_alu(s, OPC_SUB_A1, OPC_SUB_A3, ret,
|
|
|
|
arg1, const_arg1, arg2, const_arg2);
|
2013-09-06 00:44:18 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline void tcg_out_eqv(TCGContext *s, TCGArg ret,
|
|
|
|
TCGArg arg1, int const_arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_XOR_A1, ret, arg1, arg2),
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_ANDCM_A3, ret, -1, ret));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_nand(TCGContext *s, TCGArg ret,
|
|
|
|
TCGArg arg1, int const_arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_AND_A1, ret, arg1, arg2),
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_ANDCM_A3, ret, -1, ret));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_nor(TCGContext *s, TCGArg ret,
|
|
|
|
TCGArg arg1, int const_arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_OR_A1, ret, arg1, arg2),
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_ANDCM_A3, ret, -1, ret));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_orc(TCGContext *s, TCGArg ret,
|
|
|
|
TCGArg arg1, int const_arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_ANDCM_A3, TCG_REG_R2, -1, arg2),
|
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_OR_A1, ret, arg1, TCG_REG_R2));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_mul(TCGContext *s, TCGArg ret,
|
|
|
|
TCGArg arg1, TCGArg arg2)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mmI,
|
|
|
|
tcg_opc_m18(TCG_REG_P0, OPC_SETF_SIG_M18, TCG_REG_F6, arg1),
|
|
|
|
tcg_opc_m18(TCG_REG_P0, OPC_SETF_SIG_M18, TCG_REG_F7, arg2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mmF,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_f2 (TCG_REG_P0, OPC_XMA_L_F2, TCG_REG_F6, TCG_REG_F6,
|
|
|
|
TCG_REG_F7, TCG_REG_F0));
|
|
|
|
tcg_out_bundle(s, miI,
|
|
|
|
tcg_opc_m19(TCG_REG_P0, OPC_GETF_SIG_M19, ret, TCG_REG_F6),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_sar_i32(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i11(TCG_REG_P0, OPC_EXTR_I11,
|
|
|
|
ret, arg1, arg2, 31 - arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_AND_A3,
|
|
|
|
TCG_REG_R3, 0x1f, arg2),
|
|
|
|
tcg_opc_i29(TCG_REG_P0, OPC_SXT4_I29, TCG_REG_R2, arg1),
|
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_I5, ret,
|
|
|
|
TCG_REG_R2, TCG_REG_R3));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_sar_i64(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i11(TCG_REG_P0, OPC_EXTR_I11,
|
|
|
|
ret, arg1, arg2, 63 - arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_I5, ret, arg1, arg2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_shl_i32(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12, ret,
|
|
|
|
arg1, 63 - arg2, 31 - arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_AND_A3, TCG_REG_R2,
|
|
|
|
0x1f, arg2),
|
|
|
|
tcg_opc_i7 (TCG_REG_P0, OPC_SHL_I7, ret,
|
|
|
|
arg1, TCG_REG_R2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_shl_i64(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12, ret,
|
|
|
|
arg1, 63 - arg2, 63 - arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i7 (TCG_REG_P0, OPC_SHL_I7, ret,
|
|
|
|
arg1, arg2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_shr_i32(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i11(TCG_REG_P0, OPC_EXTR_U_I11, ret,
|
|
|
|
arg1, arg2, 31 - arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_AND_A3, TCG_REG_R3,
|
|
|
|
0x1f, arg2),
|
|
|
|
tcg_opc_i29(TCG_REG_P0, OPC_ZXT4_I29, TCG_REG_R2, arg1),
|
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_U_I5, ret,
|
|
|
|
TCG_REG_R2, TCG_REG_R3));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_shr_i64(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i11(TCG_REG_P0, OPC_EXTR_U_I11, ret,
|
|
|
|
arg1, arg2, 63 - arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_U_I5, ret,
|
|
|
|
arg1, arg2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_rotl_i32(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i2 (TCG_REG_P0, OPC_UNPACK4_L_I2,
|
|
|
|
TCG_REG_R2, arg1, arg1),
|
|
|
|
tcg_opc_i11(TCG_REG_P0, OPC_EXTR_U_I11, ret,
|
|
|
|
TCG_REG_R2, 32 - arg2, 31));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i2 (TCG_REG_P0, OPC_UNPACK4_L_I2,
|
|
|
|
TCG_REG_R2, arg1, arg1),
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_AND_A3, TCG_REG_R3,
|
|
|
|
0x1f, arg2));
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_SUB_A3, TCG_REG_R3,
|
|
|
|
0x20, TCG_REG_R3),
|
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_U_I5, ret,
|
|
|
|
TCG_REG_R2, TCG_REG_R3));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_rotl_i64(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i10(TCG_REG_P0, OPC_SHRP_I10, ret, arg1,
|
|
|
|
arg1, 0x40 - arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_SUB_A3, TCG_REG_R2,
|
|
|
|
0x40, arg2),
|
|
|
|
tcg_opc_i7 (TCG_REG_P0, OPC_SHL_I7, TCG_REG_R3,
|
|
|
|
arg1, arg2),
|
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_U_I5, TCG_REG_R2,
|
|
|
|
arg1, TCG_REG_R2));
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_OR_A1, ret,
|
|
|
|
TCG_REG_R2, TCG_REG_R3));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_rotr_i32(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i2 (TCG_REG_P0, OPC_UNPACK4_L_I2,
|
|
|
|
TCG_REG_R2, arg1, arg1),
|
|
|
|
tcg_opc_i11(TCG_REG_P0, OPC_EXTR_U_I11, ret,
|
|
|
|
TCG_REG_R2, arg2, 31));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_AND_A3, TCG_REG_R3,
|
|
|
|
0x1f, arg2),
|
|
|
|
tcg_opc_i2 (TCG_REG_P0, OPC_UNPACK4_L_I2,
|
|
|
|
TCG_REG_R2, arg1, arg1),
|
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_U_I5, ret,
|
|
|
|
TCG_REG_R2, TCG_REG_R3));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_rotr_i64(TCGContext *s, TCGArg ret, TCGArg arg1,
|
|
|
|
TCGArg arg2, int const_arg2)
|
|
|
|
{
|
|
|
|
if (const_arg2) {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i10(TCG_REG_P0, OPC_SHRP_I10, ret, arg1,
|
|
|
|
arg1, arg2));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_a3 (TCG_REG_P0, OPC_SUB_A3, TCG_REG_R2,
|
|
|
|
0x40, arg2),
|
|
|
|
tcg_opc_i5 (TCG_REG_P0, OPC_SHR_U_I5, TCG_REG_R3,
|
|
|
|
arg1, arg2),
|
|
|
|
tcg_opc_i7 (TCG_REG_P0, OPC_SHL_I7, TCG_REG_R2,
|
|
|
|
arg1, TCG_REG_R2));
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_OR_A1, ret,
|
|
|
|
TCG_REG_R2, TCG_REG_R3));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-06 03:13:41 +04:00
|
|
|
static const uint64_t opc_ext_i29[8] = {
|
|
|
|
OPC_ZXT1_I29, OPC_ZXT2_I29, OPC_ZXT4_I29, 0,
|
|
|
|
OPC_SXT1_I29, OPC_SXT2_I29, OPC_SXT4_I29, 0
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline uint64_t tcg_opc_ext_i(int qp, TCGMemOp opc, TCGReg d, TCGReg s)
|
|
|
|
{
|
|
|
|
if ((opc & MO_SIZE) == MO_64) {
|
|
|
|
return tcg_opc_mov_a(qp, d, s);
|
|
|
|
} else {
|
|
|
|
return tcg_opc_i29(qp, opc_ext_i29[opc & MO_SSIZE], d, s);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline void tcg_out_ext(TCGContext *s, uint64_t opc_i29,
|
|
|
|
TCGArg ret, TCGArg arg)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i29(TCG_REG_P0, opc_i29, ret, arg));
|
|
|
|
}
|
|
|
|
|
2013-09-06 03:20:40 +04:00
|
|
|
static inline uint64_t tcg_opc_bswap64_i(int qp, TCGReg d, TCGReg s)
|
|
|
|
{
|
|
|
|
return tcg_opc_i3(qp, OPC_MUX1_I3, d, s, 0xb);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline void tcg_out_bswap16(TCGContext *s, TCGArg ret, TCGArg arg)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12, ret, arg, 15, 15),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, ret, ret));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_bswap32(TCGContext *s, TCGArg ret, TCGArg arg)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12, ret, arg, 31, 31),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, ret, ret));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_bswap64(TCGContext *s, TCGArg ret, TCGArg arg)
|
|
|
|
{
|
2011-01-10 03:39:49 +03:00
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, ret, arg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2012-10-11 03:01:35 +04:00
|
|
|
static inline void tcg_out_deposit(TCGContext *s, TCGArg ret, TCGArg a1,
|
|
|
|
TCGArg a2, int const_a2, int pos, int len)
|
|
|
|
{
|
|
|
|
uint64_t i1 = 0, i2 = 0;
|
|
|
|
int cpos = 63 - pos, lm1 = len - 1;
|
|
|
|
|
|
|
|
if (const_a2) {
|
|
|
|
/* Truncate the value of a constant a2 to the width of the field. */
|
|
|
|
int mask = (1u << len) - 1;
|
|
|
|
a2 &= mask;
|
|
|
|
|
|
|
|
if (a2 == 0 || a2 == mask) {
|
|
|
|
/* 1-bit signed constant inserted into register. */
|
|
|
|
i2 = tcg_opc_i14(TCG_REG_P0, OPC_DEP_I14, ret, a2, a1, cpos, lm1);
|
|
|
|
} else {
|
|
|
|
/* Otherwise, load any constant into a temporary. Do this into
|
|
|
|
the first I slot to help out with cross-unit delays. */
|
2013-09-06 02:56:39 +04:00
|
|
|
i1 = tcg_opc_movi_a(TCG_REG_P0, TCG_REG_R2, a2);
|
2012-10-11 03:01:35 +04:00
|
|
|
a2 = TCG_REG_R2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (i2 == 0) {
|
|
|
|
i2 = tcg_opc_i15(TCG_REG_P0, OPC_DEP_I15, ret, a2, a1, cpos, lm1);
|
|
|
|
}
|
|
|
|
tcg_out_bundle(s, (i1 ? mII : miI),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
i1 ? i1 : INSN_NOP_I,
|
2012-10-11 03:01:35 +04:00
|
|
|
i2);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
static inline uint64_t tcg_opc_cmp_a(int qp, TCGCond cond, TCGArg arg1,
|
|
|
|
TCGArg arg2, int cmp4)
|
|
|
|
{
|
|
|
|
uint64_t opc_eq_a6, opc_lt_a6, opc_ltu_a6;
|
|
|
|
|
|
|
|
if (cmp4) {
|
|
|
|
opc_eq_a6 = OPC_CMP4_EQ_A6;
|
|
|
|
opc_lt_a6 = OPC_CMP4_LT_A6;
|
|
|
|
opc_ltu_a6 = OPC_CMP4_LTU_A6;
|
|
|
|
} else {
|
|
|
|
opc_eq_a6 = OPC_CMP_EQ_A6;
|
|
|
|
opc_lt_a6 = OPC_CMP_LT_A6;
|
|
|
|
opc_ltu_a6 = OPC_CMP_LTU_A6;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (cond) {
|
|
|
|
case TCG_COND_EQ:
|
|
|
|
return tcg_opc_a6 (qp, opc_eq_a6, TCG_REG_P6, TCG_REG_P7, arg1, arg2);
|
|
|
|
case TCG_COND_NE:
|
|
|
|
return tcg_opc_a6 (qp, opc_eq_a6, TCG_REG_P7, TCG_REG_P6, arg1, arg2);
|
|
|
|
case TCG_COND_LT:
|
|
|
|
return tcg_opc_a6 (qp, opc_lt_a6, TCG_REG_P6, TCG_REG_P7, arg1, arg2);
|
|
|
|
case TCG_COND_LTU:
|
|
|
|
return tcg_opc_a6 (qp, opc_ltu_a6, TCG_REG_P6, TCG_REG_P7, arg1, arg2);
|
|
|
|
case TCG_COND_GE:
|
|
|
|
return tcg_opc_a6 (qp, opc_lt_a6, TCG_REG_P7, TCG_REG_P6, arg1, arg2);
|
|
|
|
case TCG_COND_GEU:
|
|
|
|
return tcg_opc_a6 (qp, opc_ltu_a6, TCG_REG_P7, TCG_REG_P6, arg1, arg2);
|
|
|
|
case TCG_COND_LE:
|
|
|
|
return tcg_opc_a6 (qp, opc_lt_a6, TCG_REG_P7, TCG_REG_P6, arg2, arg1);
|
|
|
|
case TCG_COND_LEU:
|
|
|
|
return tcg_opc_a6 (qp, opc_ltu_a6, TCG_REG_P7, TCG_REG_P6, arg2, arg1);
|
|
|
|
case TCG_COND_GT:
|
|
|
|
return tcg_opc_a6 (qp, opc_lt_a6, TCG_REG_P6, TCG_REG_P7, arg2, arg1);
|
|
|
|
case TCG_COND_GTU:
|
|
|
|
return tcg_opc_a6 (qp, opc_ltu_a6, TCG_REG_P6, TCG_REG_P7, arg2, arg1);
|
|
|
|
default:
|
|
|
|
tcg_abort();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-05 20:47:41 +04:00
|
|
|
static inline void tcg_out_brcond(TCGContext *s, TCGCond cond, TCGReg arg1,
|
2015-02-14 00:39:54 +03:00
|
|
|
TCGReg arg2, TCGLabel *l, int cmp4)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2014-04-25 21:24:23 +04:00
|
|
|
uint64_t imm;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
/* We pay attention here to not modify the branch target by reading
|
|
|
|
the existing value and using it again. This ensure that caches and
|
|
|
|
memory are kept coherent during retranslation. */
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
if (l->has_value) {
|
2014-04-25 21:24:23 +04:00
|
|
|
imm = l->u.value_ptr - s->code_ptr;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
2014-04-25 21:24:23 +04:00
|
|
|
imm = get_reloc_pcrel21b_slot2(s->code_ptr);
|
2015-02-14 00:39:54 +03:00
|
|
|
tcg_out_reloc(s, s->code_ptr, R_IA64_PCREL21B, l, 0);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
2014-04-25 21:24:23 +04:00
|
|
|
|
|
|
|
tcg_out_bundle(s, miB,
|
|
|
|
INSN_NOP_M,
|
|
|
|
tcg_opc_cmp_a(TCG_REG_P0, cond, arg1, arg2, cmp4),
|
|
|
|
tcg_opc_b1(TCG_REG_P6, OPC_BR_DPTK_FEW_B1, imm));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void tcg_out_setcond(TCGContext *s, TCGCond cond, TCGArg ret,
|
|
|
|
TCGArg arg1, TCGArg arg2, int cmp4)
|
|
|
|
{
|
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_cmp_a(TCG_REG_P0, cond, arg1, arg2, cmp4),
|
2013-09-06 02:56:39 +04:00
|
|
|
tcg_opc_movi_a(TCG_REG_P6, ret, 1),
|
|
|
|
tcg_opc_movi_a(TCG_REG_P7, ret, 0));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2012-10-09 23:53:55 +04:00
|
|
|
static inline void tcg_out_movcond(TCGContext *s, TCGCond cond, TCGArg ret,
|
|
|
|
TCGArg c1, TCGArg c2,
|
|
|
|
TCGArg v1, int const_v1,
|
|
|
|
TCGArg v2, int const_v2, int cmp4)
|
|
|
|
{
|
|
|
|
uint64_t opc1, opc2;
|
|
|
|
|
|
|
|
if (const_v1) {
|
2013-09-06 02:56:39 +04:00
|
|
|
opc1 = tcg_opc_movi_a(TCG_REG_P6, ret, v1);
|
2012-10-09 23:53:55 +04:00
|
|
|
} else if (ret == v1) {
|
2013-09-05 03:00:52 +04:00
|
|
|
opc1 = INSN_NOP_M;
|
2012-10-09 23:53:55 +04:00
|
|
|
} else {
|
2013-09-06 02:48:42 +04:00
|
|
|
opc1 = tcg_opc_mov_a(TCG_REG_P6, ret, v1);
|
2012-10-09 23:53:55 +04:00
|
|
|
}
|
|
|
|
if (const_v2) {
|
2013-09-06 02:56:39 +04:00
|
|
|
opc2 = tcg_opc_movi_a(TCG_REG_P7, ret, v2);
|
2012-10-09 23:53:55 +04:00
|
|
|
} else if (ret == v2) {
|
2013-09-05 03:00:52 +04:00
|
|
|
opc2 = INSN_NOP_I;
|
2012-10-09 23:53:55 +04:00
|
|
|
} else {
|
2013-09-06 02:48:42 +04:00
|
|
|
opc2 = tcg_opc_mov_a(TCG_REG_P7, ret, v2);
|
2012-10-09 23:53:55 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_cmp_a(TCG_REG_P0, cond, c1, c2, cmp4),
|
|
|
|
opc1,
|
|
|
|
opc2);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
#if defined(CONFIG_SOFTMMU)
|
2013-09-06 03:46:56 +04:00
|
|
|
/* We're expecting to use an signed 22-bit immediate add. */
|
|
|
|
QEMU_BUILD_BUG_ON(offsetof(CPUArchState, tlb_table[NB_MMU_MODES - 1][1])
|
|
|
|
> 0x1fffff)
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
/* Load and compare a TLB entry, and return the result in (p6, p7).
|
2013-09-06 04:32:49 +04:00
|
|
|
R2 is loaded with the addend TLB entry.
|
2013-09-06 03:46:56 +04:00
|
|
|
R57 is loaded with the address, zero extented on 32-bit targets.
|
2013-09-06 04:02:51 +04:00
|
|
|
R1, R3 are clobbered, leaving R56 free for...
|
|
|
|
BSWAP_1, BSWAP_2 and I-slot insns for swapping data for store. */
|
2013-09-06 03:46:56 +04:00
|
|
|
static inline void tcg_out_qemu_tlb(TCGContext *s, TCGReg addr_reg,
|
2016-07-14 22:43:06 +03:00
|
|
|
TCGMemOp opc, int off_rw, int off_add,
|
2013-09-06 04:02:51 +04:00
|
|
|
uint64_t bswap1, uint64_t bswap2)
|
2013-09-06 03:46:56 +04:00
|
|
|
{
|
2016-07-14 22:43:06 +03:00
|
|
|
unsigned s_bits = opc & MO_SIZE;
|
|
|
|
unsigned a_bits = get_alignment_bits(opc);
|
|
|
|
|
|
|
|
/* We don't support unaligned accesses, but overalignment is easy. */
|
|
|
|
if (a_bits < s_bits) {
|
|
|
|
a_bits = s_bits;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-09-06 03:46:56 +04:00
|
|
|
.mii
|
|
|
|
mov r2 = off_rw
|
|
|
|
extr.u r3 = addr_reg, ... # extract tlb page
|
|
|
|
zxt4 r57 = addr_reg # or mov for 64-bit guest
|
|
|
|
;;
|
|
|
|
.mii
|
|
|
|
addl r2 = r2, areg0
|
|
|
|
shl r3 = r3, cteb # via dep.z
|
|
|
|
dep r1 = 0, r57, ... # zero page ofs, keep align
|
|
|
|
;;
|
|
|
|
.mmi
|
|
|
|
add r2 = r2, r3
|
|
|
|
;;
|
|
|
|
ld4 r3 = [r2], off_add-off_rw # or ld8 for 64-bit guest
|
|
|
|
nop
|
|
|
|
;;
|
|
|
|
.mmi
|
|
|
|
nop
|
|
|
|
cmp.eq p6, p7 = r3, r58
|
|
|
|
nop
|
|
|
|
;;
|
2016-07-14 22:43:06 +03:00
|
|
|
*/
|
2013-09-06 03:46:56 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
|
|
|
tcg_opc_movi_a(TCG_REG_P0, TCG_REG_R2, off_rw),
|
|
|
|
tcg_opc_i11(TCG_REG_P0, OPC_EXTR_U_I11, TCG_REG_R3,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
addr_reg, TARGET_PAGE_BITS, CPU_TLB_BITS - 1),
|
2013-09-06 03:13:41 +04:00
|
|
|
tcg_opc_ext_i(TCG_REG_P0,
|
|
|
|
TARGET_LONG_BITS == 32 ? MO_UL : MO_Q,
|
2013-09-06 03:46:56 +04:00
|
|
|
TCG_REG_R57, addr_reg));
|
|
|
|
tcg_out_bundle(s, miI,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1, TCG_REG_R2,
|
2013-09-06 03:46:56 +04:00
|
|
|
TCG_REG_R2, TCG_AREG0),
|
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12, TCG_REG_R3,
|
|
|
|
TCG_REG_R3, 63 - CPU_TLB_ENTRY_BITS,
|
|
|
|
63 - CPU_TLB_ENTRY_BITS),
|
|
|
|
tcg_opc_i14(TCG_REG_P0, OPC_DEP_I14, TCG_REG_R1, 0,
|
2016-07-14 22:43:06 +03:00
|
|
|
TCG_REG_R57, 63 - a_bits,
|
|
|
|
TARGET_PAGE_BITS - a_bits - 1));
|
2013-09-06 03:46:56 +04:00
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1,
|
|
|
|
TCG_REG_R2, TCG_REG_R2, TCG_REG_R3),
|
2010-11-23 01:57:56 +03:00
|
|
|
tcg_opc_m3 (TCG_REG_P0,
|
|
|
|
(TARGET_LONG_BITS == 32
|
2013-09-06 03:46:56 +04:00
|
|
|
? OPC_LD4_M3 : OPC_LD8_M3), TCG_REG_R3,
|
|
|
|
TCG_REG_R2, off_add - off_rw),
|
2013-09-06 04:02:51 +04:00
|
|
|
bswap1);
|
2013-09-06 03:46:56 +04:00
|
|
|
tcg_out_bundle(s, mmI,
|
2013-09-06 04:32:49 +04:00
|
|
|
tcg_opc_m1 (TCG_REG_P0, OPC_LD8_M1, TCG_REG_R2, TCG_REG_R2),
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a6 (TCG_REG_P0, OPC_CMP_EQ_A6, TCG_REG_P6,
|
2013-09-06 03:46:56 +04:00
|
|
|
TCG_REG_P7, TCG_REG_R1, TCG_REG_R3),
|
2013-09-06 04:02:51 +04:00
|
|
|
bswap2);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2013-09-06 10:06:59 +04:00
|
|
|
typedef struct TCGLabelQemuLdst {
|
|
|
|
bool is_ld;
|
|
|
|
TCGMemOp size;
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_insn_unit *label_ptr; /* label pointers to be updated */
|
2014-09-30 18:25:30 +04:00
|
|
|
struct TCGLabelQemuLdst *next;
|
2013-09-06 10:06:59 +04:00
|
|
|
} TCGLabelQemuLdst;
|
|
|
|
|
|
|
|
typedef struct TCGBackendData {
|
2014-09-30 18:25:30 +04:00
|
|
|
TCGLabelQemuLdst *labels;
|
2013-09-06 10:06:59 +04:00
|
|
|
} TCGBackendData;
|
|
|
|
|
|
|
|
static inline void tcg_out_tb_init(TCGContext *s)
|
|
|
|
{
|
2014-09-30 18:25:30 +04:00
|
|
|
s->be->labels = NULL;
|
2013-09-06 10:06:59 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static void add_qemu_ldst_label(TCGContext *s, bool is_ld, TCGMemOp opc,
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_insn_unit *label_ptr)
|
2013-09-06 10:06:59 +04:00
|
|
|
{
|
|
|
|
TCGBackendData *be = s->be;
|
2014-09-30 18:25:30 +04:00
|
|
|
TCGLabelQemuLdst *l = tcg_malloc(sizeof(*l));
|
2013-09-06 10:06:59 +04:00
|
|
|
|
|
|
|
l->is_ld = is_ld;
|
|
|
|
l->size = opc & MO_SIZE;
|
|
|
|
l->label_ptr = label_ptr;
|
2014-09-30 18:25:30 +04:00
|
|
|
l->next = be->labels;
|
|
|
|
be->labels = l;
|
2013-09-06 10:06:59 +04:00
|
|
|
}
|
|
|
|
|
2015-12-03 00:59:59 +03:00
|
|
|
static bool tcg_out_tb_finalize(TCGContext *s)
|
2013-09-06 10:06:59 +04:00
|
|
|
{
|
|
|
|
static const void * const helpers[8] = {
|
|
|
|
helper_ret_stb_mmu,
|
|
|
|
helper_le_stw_mmu,
|
|
|
|
helper_le_stl_mmu,
|
|
|
|
helper_le_stq_mmu,
|
|
|
|
helper_ret_ldub_mmu,
|
|
|
|
helper_le_lduw_mmu,
|
|
|
|
helper_le_ldul_mmu,
|
|
|
|
helper_le_ldq_mmu,
|
|
|
|
};
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_insn_unit *thunks[8] = { };
|
2014-09-30 18:25:30 +04:00
|
|
|
TCGLabelQemuLdst *l;
|
2013-09-06 10:06:59 +04:00
|
|
|
|
2014-09-30 18:25:30 +04:00
|
|
|
for (l = s->be->labels; l != NULL; l = l->next) {
|
2013-09-06 10:06:59 +04:00
|
|
|
long x = l->is_ld * 4 + l->size;
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_insn_unit *dest = thunks[x];
|
2013-09-06 10:06:59 +04:00
|
|
|
|
|
|
|
/* The out-of-line thunks are all the same; load the return address
|
|
|
|
from B0, load the GP, and branch to the code. Note that we are
|
|
|
|
always post-call, so the register window has rolled, so we're
|
2015-09-09 00:45:14 +03:00
|
|
|
using incoming parameter register numbers, not outgoing. */
|
2014-04-25 21:24:23 +04:00
|
|
|
if (dest == NULL) {
|
|
|
|
uintptr_t *desc = (uintptr_t *)helpers[x];
|
|
|
|
uintptr_t func = desc[0], gp = desc[1], disp;
|
2013-09-06 10:06:59 +04:00
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
thunks[x] = dest = s->code_ptr;
|
2013-09-06 10:06:59 +04:00
|
|
|
|
|
|
|
tcg_out_bundle(s, mlx,
|
|
|
|
INSN_NOP_M,
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_opc_l2 (gp),
|
2013-09-06 10:06:59 +04:00
|
|
|
tcg_opc_x2 (TCG_REG_P0, OPC_MOVL_X2,
|
2014-04-25 21:24:23 +04:00
|
|
|
TCG_REG_R1, gp));
|
2013-09-06 10:06:59 +04:00
|
|
|
tcg_out_bundle(s, mii,
|
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
|
|
|
tcg_opc_i22(TCG_REG_P0, OPC_MOV_I22,
|
|
|
|
l->is_ld ? TCG_REG_R35 : TCG_REG_R36,
|
|
|
|
TCG_REG_B0));
|
2014-04-25 21:24:23 +04:00
|
|
|
disp = (tcg_insn_unit *)func - s->code_ptr;
|
2013-09-06 10:06:59 +04:00
|
|
|
tcg_out_bundle(s, mLX,
|
|
|
|
INSN_NOP_M,
|
|
|
|
tcg_opc_l3 (disp),
|
|
|
|
tcg_opc_x3 (TCG_REG_P0, OPC_BRL_SPTK_MANY_X3, disp));
|
|
|
|
}
|
|
|
|
|
2014-04-25 21:24:23 +04:00
|
|
|
reloc_pcrel21b_slot2(l->label_ptr, dest);
|
2015-12-03 00:59:59 +03:00
|
|
|
|
|
|
|
/* Test for (pending) buffer overflow. The assumption is that any
|
|
|
|
one operation beginning below the high water mark cannot overrun
|
|
|
|
the buffer completely. Thus we can test for overflow after
|
|
|
|
generating code without having to check during generation. */
|
|
|
|
if (unlikely((void *)s->code_ptr > s->code_gen_highwater)) {
|
|
|
|
return false;
|
|
|
|
}
|
2013-09-06 10:06:59 +04:00
|
|
|
}
|
2015-12-03 00:59:59 +03:00
|
|
|
return true;
|
2013-09-06 10:06:59 +04:00
|
|
|
}
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
static inline void tcg_out_qemu_ld(TCGContext *s, const TCGArg *args)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2013-09-05 01:24:38 +04:00
|
|
|
static const uint64_t opc_ld_m1[4] = {
|
|
|
|
OPC_LD1_M1, OPC_LD2_M1, OPC_LD4_M1, OPC_LD8_M1
|
|
|
|
};
|
|
|
|
int addr_reg, data_reg, mem_index;
|
2015-05-12 21:51:44 +03:00
|
|
|
TCGMemOpIdx oi;
|
2014-03-04 21:35:30 +04:00
|
|
|
TCGMemOp opc, s_bits;
|
2013-09-06 10:06:59 +04:00
|
|
|
uint64_t fin1, fin2;
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_insn_unit *label_ptr;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
data_reg = args[0];
|
|
|
|
addr_reg = args[1];
|
2015-05-12 21:51:44 +03:00
|
|
|
oi = args[2];
|
|
|
|
opc = get_memop(oi);
|
|
|
|
mem_index = get_mmuidx(oi);
|
2013-09-05 01:24:38 +04:00
|
|
|
s_bits = opc & MO_SIZE;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
/* Read the TLB entry */
|
2016-07-14 22:43:06 +03:00
|
|
|
tcg_out_qemu_tlb(s, addr_reg, opc,
|
2012-03-14 04:38:32 +04:00
|
|
|
offsetof(CPUArchState, tlb_table[mem_index][0].addr_read),
|
2013-09-06 04:02:51 +04:00
|
|
|
offsetof(CPUArchState, tlb_table[mem_index][0].addend),
|
|
|
|
INSN_NOP_I, INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
/* P6 is the fast path, and P7 the slow path */
|
2013-09-06 04:50:54 +04:00
|
|
|
|
2013-09-06 08:38:52 +04:00
|
|
|
fin2 = 0;
|
2013-09-06 04:50:54 +04:00
|
|
|
if (opc & MO_BSWAP) {
|
2013-09-06 08:38:52 +04:00
|
|
|
fin1 = tcg_opc_bswap64_i(TCG_REG_P0, data_reg, TCG_REG_R8);
|
2013-09-06 04:50:54 +04:00
|
|
|
if (s_bits < MO_64) {
|
|
|
|
int shift = 64 - (8 << s_bits);
|
2013-09-06 08:38:52 +04:00
|
|
|
fin2 = (opc & MO_SIGN ? OPC_EXTR_I11 : OPC_EXTR_U_I11);
|
|
|
|
fin2 = tcg_opc_i11(TCG_REG_P0, fin2,
|
|
|
|
data_reg, data_reg, shift, 63 - shift);
|
2013-09-06 04:50:54 +04:00
|
|
|
}
|
2013-09-06 08:38:52 +04:00
|
|
|
} else {
|
|
|
|
fin1 = tcg_opc_ext_i(TCG_REG_P0, opc, data_reg, TCG_REG_R8);
|
2013-09-06 04:50:54 +04:00
|
|
|
}
|
|
|
|
|
2013-09-06 10:06:59 +04:00
|
|
|
tcg_out_bundle(s, mmI,
|
2013-09-06 02:48:42 +04:00
|
|
|
tcg_opc_mov_a(TCG_REG_P7, TCG_REG_R56, TCG_AREG0),
|
2013-09-06 04:32:49 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P6, OPC_ADD_A1, TCG_REG_R2,
|
|
|
|
TCG_REG_R2, TCG_REG_R57),
|
2015-05-13 19:10:33 +03:00
|
|
|
tcg_opc_movi_a(TCG_REG_P7, TCG_REG_R58, oi));
|
2014-04-25 21:24:23 +04:00
|
|
|
label_ptr = s->code_ptr;
|
2013-09-06 10:06:59 +04:00
|
|
|
tcg_out_bundle(s, miB,
|
2013-09-06 04:50:54 +04:00
|
|
|
tcg_opc_m1 (TCG_REG_P6, opc_ld_m1[s_bits],
|
|
|
|
TCG_REG_R8, TCG_REG_R2),
|
2013-09-06 10:06:59 +04:00
|
|
|
INSN_NOP_I,
|
|
|
|
tcg_opc_b3 (TCG_REG_P7, OPC_BR_CALL_SPNT_FEW_B3, TCG_REG_B0,
|
2014-04-25 21:24:23 +04:00
|
|
|
get_reloc_pcrel21b_slot2(label_ptr)));
|
2013-09-06 10:06:59 +04:00
|
|
|
|
|
|
|
add_qemu_ldst_label(s, 1, opc, label_ptr);
|
2013-09-06 08:38:52 +04:00
|
|
|
|
|
|
|
/* Note that we always use LE helper functions, so the bswap insns
|
|
|
|
here for the fast path also apply to the slow path. */
|
|
|
|
tcg_out_bundle(s, (fin2 ? mII : miI),
|
|
|
|
INSN_NOP_M,
|
|
|
|
fin1,
|
|
|
|
fin2 ? fin2 : INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
static inline void tcg_out_qemu_st(TCGContext *s, const TCGArg *args)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2013-09-05 01:24:38 +04:00
|
|
|
static const uint64_t opc_st_m4[4] = {
|
|
|
|
OPC_ST1_M4, OPC_ST2_M4, OPC_ST4_M4, OPC_ST8_M4
|
|
|
|
};
|
2013-09-06 08:38:52 +04:00
|
|
|
TCGReg addr_reg, data_reg;
|
2013-09-06 04:02:51 +04:00
|
|
|
int mem_index;
|
2013-09-06 10:06:59 +04:00
|
|
|
uint64_t pre1, pre2;
|
2015-05-12 21:51:44 +03:00
|
|
|
TCGMemOpIdx oi;
|
2014-03-04 21:35:30 +04:00
|
|
|
TCGMemOp opc, s_bits;
|
2014-04-25 21:24:23 +04:00
|
|
|
tcg_insn_unit *label_ptr;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
data_reg = args[0];
|
|
|
|
addr_reg = args[1];
|
2015-05-12 21:51:44 +03:00
|
|
|
oi = args[2];
|
|
|
|
opc = get_memop(oi);
|
|
|
|
mem_index = get_mmuidx(oi);
|
2013-09-05 01:24:38 +04:00
|
|
|
s_bits = opc & MO_SIZE;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2013-09-06 08:38:52 +04:00
|
|
|
/* Note that we always use LE helper functions, so the bswap insns
|
|
|
|
that are here for the fast path also apply to the slow path,
|
|
|
|
and move the data into the argument register. */
|
|
|
|
pre2 = INSN_NOP_I;
|
2013-09-06 04:02:51 +04:00
|
|
|
if (opc & MO_BSWAP) {
|
2013-09-06 08:38:52 +04:00
|
|
|
pre1 = tcg_opc_bswap64_i(TCG_REG_P0, TCG_REG_R58, data_reg);
|
2013-09-06 04:02:51 +04:00
|
|
|
if (s_bits < MO_64) {
|
|
|
|
int shift = 64 - (8 << s_bits);
|
2013-09-06 08:38:52 +04:00
|
|
|
pre2 = tcg_opc_i11(TCG_REG_P0, OPC_EXTR_U_I11,
|
|
|
|
TCG_REG_R58, TCG_REG_R58, shift, 63 - shift);
|
2013-09-06 04:02:51 +04:00
|
|
|
}
|
2013-09-06 08:38:52 +04:00
|
|
|
} else {
|
|
|
|
/* Just move the data into place for the slow path. */
|
|
|
|
pre1 = tcg_opc_ext_i(TCG_REG_P0, opc, TCG_REG_R58, data_reg);
|
2013-09-06 04:02:51 +04:00
|
|
|
}
|
|
|
|
|
2016-07-14 22:43:06 +03:00
|
|
|
tcg_out_qemu_tlb(s, addr_reg, opc,
|
2012-03-14 04:38:32 +04:00
|
|
|
offsetof(CPUArchState, tlb_table[mem_index][0].addr_write),
|
2013-09-06 04:02:51 +04:00
|
|
|
offsetof(CPUArchState, tlb_table[mem_index][0].addend),
|
2013-09-06 08:38:52 +04:00
|
|
|
pre1, pre2);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
/* P6 is the fast path, and P7 the slow path */
|
2013-09-06 10:06:59 +04:00
|
|
|
tcg_out_bundle(s, mmI,
|
2013-09-06 02:48:42 +04:00
|
|
|
tcg_opc_mov_a(TCG_REG_P7, TCG_REG_R56, TCG_AREG0),
|
2013-09-06 04:32:49 +04:00
|
|
|
tcg_opc_a1 (TCG_REG_P6, OPC_ADD_A1, TCG_REG_R2,
|
|
|
|
TCG_REG_R2, TCG_REG_R57),
|
2015-05-13 19:10:33 +03:00
|
|
|
tcg_opc_movi_a(TCG_REG_P7, TCG_REG_R59, oi));
|
2014-04-25 21:24:23 +04:00
|
|
|
label_ptr = s->code_ptr;
|
2013-09-06 10:06:59 +04:00
|
|
|
tcg_out_bundle(s, miB,
|
2013-09-05 01:24:38 +04:00
|
|
|
tcg_opc_m4 (TCG_REG_P6, opc_st_m4[s_bits],
|
2013-09-06 08:38:52 +04:00
|
|
|
TCG_REG_R58, TCG_REG_R2),
|
2013-09-06 10:06:59 +04:00
|
|
|
INSN_NOP_I,
|
|
|
|
tcg_opc_b3 (TCG_REG_P7, OPC_BR_CALL_SPNT_FEW_B3, TCG_REG_B0,
|
2014-04-25 21:24:23 +04:00
|
|
|
get_reloc_pcrel21b_slot2(label_ptr)));
|
2013-09-06 10:06:59 +04:00
|
|
|
|
|
|
|
add_qemu_ldst_label(s, 0, opc, label_ptr);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* !CONFIG_SOFTMMU */
|
2013-09-06 10:06:59 +04:00
|
|
|
# include "tcg-be-null.h"
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
static inline void tcg_out_qemu_ld(TCGContext *s, const TCGArg *args)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2010-05-06 19:50:44 +04:00
|
|
|
static uint64_t const opc_ld_m1[4] = {
|
|
|
|
OPC_LD1_M1, OPC_LD2_M1, OPC_LD4_M1, OPC_LD8_M1
|
|
|
|
};
|
2013-09-05 01:24:38 +04:00
|
|
|
int addr_reg, data_reg;
|
2014-03-04 21:35:30 +04:00
|
|
|
TCGMemOp opc, s_bits, bswap;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
data_reg = args[0];
|
|
|
|
addr_reg = args[1];
|
|
|
|
opc = args[2];
|
2013-09-05 01:24:38 +04:00
|
|
|
s_bits = opc & MO_SIZE;
|
|
|
|
bswap = opc & MO_BSWAP;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
#if TARGET_LONG_BITS == 32
|
2015-08-24 15:53:54 +03:00
|
|
|
if (guest_base != 0) {
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_opc_i29(TCG_REG_P0, OPC_ZXT4_I29,
|
|
|
|
TCG_REG_R3, addr_reg),
|
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1, TCG_REG_R2,
|
|
|
|
TCG_GUEST_BASE_REG, TCG_REG_R3));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_opc_i29(TCG_REG_P0, OPC_ZXT4_I29,
|
|
|
|
TCG_REG_R2, addr_reg),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
2010-05-06 19:50:44 +04:00
|
|
|
}
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2013-09-05 01:24:38 +04:00
|
|
|
if (!bswap) {
|
|
|
|
if (!(opc & MO_SIGN)) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_ld_m1[s_bits],
|
|
|
|
data_reg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_ld_m1[s_bits],
|
|
|
|
data_reg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
2013-09-06 03:13:41 +04:00
|
|
|
tcg_opc_ext_i(TCG_REG_P0, opc, data_reg, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
2013-09-05 01:24:38 +04:00
|
|
|
} else if (s_bits == MO_64) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_ld_m1[s_bits],
|
|
|
|
data_reg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, data_reg, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
2013-09-05 01:24:38 +04:00
|
|
|
if (s_bits == MO_16) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_ld_m1[s_bits],
|
|
|
|
data_reg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
data_reg, data_reg, 15, 15));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_ld_m1[s_bits],
|
|
|
|
data_reg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
data_reg, data_reg, 31, 31));
|
|
|
|
}
|
2013-09-05 01:24:38 +04:00
|
|
|
if (!(opc & MO_SIGN)) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, data_reg, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, data_reg, data_reg),
|
2013-09-06 03:13:41 +04:00
|
|
|
tcg_opc_ext_i(TCG_REG_P0, opc, data_reg, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#else
|
2015-08-24 15:53:54 +03:00
|
|
|
if (guest_base != 0) {
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_out_bundle(s, MmI,
|
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1, TCG_REG_R2,
|
|
|
|
TCG_GUEST_BASE_REG, addr_reg),
|
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_ld_m1[s_bits],
|
|
|
|
data_reg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
2010-05-06 19:50:44 +04:00
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, mmI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_opc_m1 (TCG_REG_P0, opc_ld_m1[s_bits],
|
|
|
|
data_reg, addr_reg),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
2010-05-06 19:50:44 +04:00
|
|
|
}
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2013-09-05 01:24:38 +04:00
|
|
|
if (bswap && s_bits == MO_16) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
data_reg, data_reg, 15, 15),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, data_reg, data_reg));
|
2013-09-05 01:24:38 +04:00
|
|
|
} else if (bswap && s_bits == MO_32) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
data_reg, data_reg, 31, 31),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, data_reg, data_reg));
|
2013-09-05 01:24:38 +04:00
|
|
|
} else if (bswap && s_bits == MO_64) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, data_reg, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
2013-09-05 01:24:38 +04:00
|
|
|
if (opc & MO_SIGN) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
2013-09-06 03:13:41 +04:00
|
|
|
tcg_opc_ext_i(TCG_REG_P0, opc, data_reg, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
static inline void tcg_out_qemu_st(TCGContext *s, const TCGArg *args)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
2010-05-06 19:50:44 +04:00
|
|
|
static uint64_t const opc_st_m4[4] = {
|
|
|
|
OPC_ST1_M4, OPC_ST2_M4, OPC_ST4_M4, OPC_ST8_M4
|
|
|
|
};
|
2013-09-05 01:24:38 +04:00
|
|
|
int addr_reg, data_reg;
|
2010-05-06 19:50:44 +04:00
|
|
|
#if TARGET_LONG_BITS == 64
|
|
|
|
uint64_t add_guest_base;
|
|
|
|
#endif
|
2014-03-04 21:35:30 +04:00
|
|
|
TCGMemOp opc, s_bits, bswap;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
data_reg = args[0];
|
|
|
|
addr_reg = args[1];
|
|
|
|
opc = args[2];
|
2013-09-05 01:24:38 +04:00
|
|
|
s_bits = opc & MO_SIZE;
|
|
|
|
bswap = opc & MO_BSWAP;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
#if TARGET_LONG_BITS == 32
|
2015-08-24 15:53:54 +03:00
|
|
|
if (guest_base != 0) {
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_opc_i29(TCG_REG_P0, OPC_ZXT4_I29,
|
|
|
|
TCG_REG_R3, addr_reg),
|
|
|
|
tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1, TCG_REG_R2,
|
|
|
|
TCG_GUEST_BASE_REG, TCG_REG_R3));
|
|
|
|
} else {
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_opc_i29(TCG_REG_P0, OPC_ZXT4_I29,
|
2010-11-23 01:57:57 +03:00
|
|
|
TCG_REG_R2, addr_reg),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
2010-05-06 19:50:44 +04:00
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
if (bswap) {
|
2013-09-05 01:24:38 +04:00
|
|
|
if (s_bits == MO_16) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
TCG_REG_R3, data_reg, 15, 15),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0,
|
|
|
|
TCG_REG_R3, TCG_REG_R3));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
data_reg = TCG_REG_R3;
|
2013-09-05 01:24:38 +04:00
|
|
|
} else if (s_bits == MO_32) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
TCG_REG_R3, data_reg, 31, 31),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0,
|
|
|
|
TCG_REG_R3, TCG_REG_R3));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
data_reg = TCG_REG_R3;
|
2013-09-05 01:24:38 +04:00
|
|
|
} else if (s_bits == MO_64) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I,
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, TCG_REG_R3, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
data_reg = TCG_REG_R3;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
tcg_out_bundle(s, mmI,
|
2013-09-05 01:24:38 +04:00
|
|
|
tcg_opc_m4 (TCG_REG_P0, opc_st_m4[s_bits],
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
data_reg, TCG_REG_R2),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
#else
|
2015-08-24 15:53:54 +03:00
|
|
|
if (guest_base != 0) {
|
2010-05-06 19:50:44 +04:00
|
|
|
add_guest_base = tcg_opc_a1 (TCG_REG_P0, OPC_ADD_A1, TCG_REG_R2,
|
|
|
|
TCG_GUEST_BASE_REG, addr_reg);
|
|
|
|
addr_reg = TCG_REG_R2;
|
|
|
|
} else {
|
2013-09-05 03:00:52 +04:00
|
|
|
add_guest_base = INSN_NOP_M;
|
2010-05-06 19:50:44 +04:00
|
|
|
}
|
|
|
|
|
2013-09-05 01:24:38 +04:00
|
|
|
if (!bswap) {
|
2015-08-24 15:53:54 +03:00
|
|
|
tcg_out_bundle(s, (guest_base ? MmI : mmI),
|
2010-05-06 19:50:44 +04:00
|
|
|
add_guest_base,
|
2013-09-05 01:24:38 +04:00
|
|
|
tcg_opc_m4 (TCG_REG_P0, opc_st_m4[s_bits],
|
2010-05-06 19:50:44 +04:00
|
|
|
data_reg, addr_reg),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
} else {
|
2013-09-05 01:24:38 +04:00
|
|
|
if (s_bits == MO_16) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2010-05-06 19:50:44 +04:00
|
|
|
add_guest_base,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
TCG_REG_R3, data_reg, 15, 15),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0,
|
|
|
|
TCG_REG_R3, TCG_REG_R3));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
data_reg = TCG_REG_R3;
|
2013-09-05 01:24:38 +04:00
|
|
|
} else if (s_bits == MO_32) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, mII,
|
2010-05-06 19:50:44 +04:00
|
|
|
add_guest_base,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i12(TCG_REG_P0, OPC_DEP_Z_I12,
|
|
|
|
TCG_REG_R3, data_reg, 31, 31),
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0,
|
|
|
|
TCG_REG_R3, TCG_REG_R3));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
data_reg = TCG_REG_R3;
|
2013-09-05 01:24:38 +04:00
|
|
|
} else if (s_bits == MO_64) {
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
2010-05-06 19:50:44 +04:00
|
|
|
add_guest_base,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
2013-09-06 03:20:40 +04:00
|
|
|
tcg_opc_bswap64_i(TCG_REG_P0, TCG_REG_R3, data_reg));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
data_reg = TCG_REG_R3;
|
|
|
|
}
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 01:24:38 +04:00
|
|
|
tcg_opc_m4 (TCG_REG_P0, opc_st_m4[s_bits],
|
2010-05-06 19:50:44 +04:00
|
|
|
data_reg, addr_reg),
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_I,
|
|
|
|
INSN_NOP_I);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static inline void tcg_out_op(TCGContext *s, TCGOpcode opc,
|
|
|
|
const TCGArg *args, const int *const_args)
|
|
|
|
{
|
|
|
|
switch(opc) {
|
|
|
|
case INDEX_op_exit_tb:
|
|
|
|
tcg_out_exit_tb(s, args[0]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_br:
|
2015-02-14 00:39:54 +03:00
|
|
|
tcg_out_br(s, arg_label(args[0]));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
case INDEX_op_goto_tb:
|
|
|
|
tcg_out_goto_tb(s, args[0]);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case INDEX_op_ld8u_i32:
|
|
|
|
case INDEX_op_ld8u_i64:
|
|
|
|
tcg_out_ld_rel(s, OPC_LD1_M1, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ld8s_i32:
|
|
|
|
case INDEX_op_ld8s_i64:
|
|
|
|
tcg_out_ld_rel(s, OPC_LD1_M1, args[0], args[1], args[2]);
|
|
|
|
tcg_out_ext(s, OPC_SXT1_I29, args[0], args[0]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ld16u_i32:
|
|
|
|
case INDEX_op_ld16u_i64:
|
|
|
|
tcg_out_ld_rel(s, OPC_LD2_M1, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ld16s_i32:
|
|
|
|
case INDEX_op_ld16s_i64:
|
|
|
|
tcg_out_ld_rel(s, OPC_LD2_M1, args[0], args[1], args[2]);
|
|
|
|
tcg_out_ext(s, OPC_SXT2_I29, args[0], args[0]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ld_i32:
|
|
|
|
case INDEX_op_ld32u_i64:
|
|
|
|
tcg_out_ld_rel(s, OPC_LD4_M1, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ld32s_i64:
|
|
|
|
tcg_out_ld_rel(s, OPC_LD4_M1, args[0], args[1], args[2]);
|
|
|
|
tcg_out_ext(s, OPC_SXT4_I29, args[0], args[0]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ld_i64:
|
|
|
|
tcg_out_ld_rel(s, OPC_LD8_M1, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_st8_i32:
|
|
|
|
case INDEX_op_st8_i64:
|
|
|
|
tcg_out_st_rel(s, OPC_ST1_M4, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_st16_i32:
|
|
|
|
case INDEX_op_st16_i64:
|
|
|
|
tcg_out_st_rel(s, OPC_ST2_M4, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_st_i32:
|
|
|
|
case INDEX_op_st32_i64:
|
|
|
|
tcg_out_st_rel(s, OPC_ST4_M4, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_st_i64:
|
|
|
|
tcg_out_st_rel(s, OPC_ST8_M4, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case INDEX_op_add_i32:
|
|
|
|
case INDEX_op_add_i64:
|
2013-09-06 00:15:13 +04:00
|
|
|
tcg_out_add(s, args[0], args[1], args[2], const_args[2]);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
case INDEX_op_sub_i32:
|
|
|
|
case INDEX_op_sub_i64:
|
2013-09-06 00:44:18 +04:00
|
|
|
tcg_out_sub(s, args[0], args[1], const_args[1], args[2], const_args[2]);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case INDEX_op_and_i32:
|
|
|
|
case INDEX_op_and_i64:
|
2013-09-06 01:13:43 +04:00
|
|
|
/* TCG expects arg2 constant; A3 expects arg1 constant. Swap. */
|
|
|
|
tcg_out_alu(s, OPC_AND_A1, OPC_AND_A3, args[0],
|
|
|
|
args[2], const_args[2], args[1], const_args[1]);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
case INDEX_op_andc_i32:
|
|
|
|
case INDEX_op_andc_i64:
|
2013-09-06 01:13:43 +04:00
|
|
|
tcg_out_alu(s, OPC_ANDCM_A1, OPC_ANDCM_A3, args[0],
|
|
|
|
args[1], const_args[1], args[2], const_args[2]);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
case INDEX_op_eqv_i32:
|
|
|
|
case INDEX_op_eqv_i64:
|
|
|
|
tcg_out_eqv(s, args[0], args[1], const_args[1],
|
|
|
|
args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_nand_i32:
|
|
|
|
case INDEX_op_nand_i64:
|
|
|
|
tcg_out_nand(s, args[0], args[1], const_args[1],
|
|
|
|
args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_nor_i32:
|
|
|
|
case INDEX_op_nor_i64:
|
|
|
|
tcg_out_nor(s, args[0], args[1], const_args[1],
|
|
|
|
args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_or_i32:
|
|
|
|
case INDEX_op_or_i64:
|
2013-09-06 01:13:43 +04:00
|
|
|
/* TCG expects arg2 constant; A3 expects arg1 constant. Swap. */
|
|
|
|
tcg_out_alu(s, OPC_OR_A1, OPC_OR_A3, args[0],
|
|
|
|
args[2], const_args[2], args[1], const_args[1]);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
case INDEX_op_orc_i32:
|
|
|
|
case INDEX_op_orc_i64:
|
|
|
|
tcg_out_orc(s, args[0], args[1], const_args[1],
|
|
|
|
args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_xor_i32:
|
|
|
|
case INDEX_op_xor_i64:
|
2013-09-06 01:13:43 +04:00
|
|
|
/* TCG expects arg2 constant; A3 expects arg1 constant. Swap. */
|
|
|
|
tcg_out_alu(s, OPC_XOR_A1, OPC_XOR_A3, args[0],
|
|
|
|
args[2], const_args[2], args[1], const_args[1]);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case INDEX_op_mul_i32:
|
|
|
|
case INDEX_op_mul_i64:
|
|
|
|
tcg_out_mul(s, args[0], args[1], args[2]);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case INDEX_op_sar_i32:
|
|
|
|
tcg_out_sar_i32(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_sar_i64:
|
|
|
|
tcg_out_sar_i64(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_shl_i32:
|
|
|
|
tcg_out_shl_i32(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_shl_i64:
|
|
|
|
tcg_out_shl_i64(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_shr_i32:
|
|
|
|
tcg_out_shr_i32(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_shr_i64:
|
|
|
|
tcg_out_shr_i64(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_rotl_i32:
|
|
|
|
tcg_out_rotl_i32(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_rotl_i64:
|
|
|
|
tcg_out_rotl_i64(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_rotr_i32:
|
|
|
|
tcg_out_rotr_i32(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_rotr_i64:
|
|
|
|
tcg_out_rotr_i64(s, args[0], args[1], args[2], const_args[2]);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case INDEX_op_ext8s_i32:
|
|
|
|
case INDEX_op_ext8s_i64:
|
|
|
|
tcg_out_ext(s, OPC_SXT1_I29, args[0], args[1]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ext8u_i32:
|
|
|
|
case INDEX_op_ext8u_i64:
|
|
|
|
tcg_out_ext(s, OPC_ZXT1_I29, args[0], args[1]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ext16s_i32:
|
|
|
|
case INDEX_op_ext16s_i64:
|
|
|
|
tcg_out_ext(s, OPC_SXT2_I29, args[0], args[1]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_ext16u_i32:
|
|
|
|
case INDEX_op_ext16u_i64:
|
|
|
|
tcg_out_ext(s, OPC_ZXT2_I29, args[0], args[1]);
|
|
|
|
break;
|
2015-07-27 13:41:45 +03:00
|
|
|
case INDEX_op_ext_i32_i64:
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
case INDEX_op_ext32s_i64:
|
|
|
|
tcg_out_ext(s, OPC_SXT4_I29, args[0], args[1]);
|
|
|
|
break;
|
2015-07-27 13:41:45 +03:00
|
|
|
case INDEX_op_extu_i32_i64:
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
case INDEX_op_ext32u_i64:
|
|
|
|
tcg_out_ext(s, OPC_ZXT4_I29, args[0], args[1]);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case INDEX_op_bswap16_i32:
|
|
|
|
case INDEX_op_bswap16_i64:
|
|
|
|
tcg_out_bswap16(s, args[0], args[1]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_bswap32_i32:
|
|
|
|
case INDEX_op_bswap32_i64:
|
|
|
|
tcg_out_bswap32(s, args[0], args[1]);
|
|
|
|
break;
|
|
|
|
case INDEX_op_bswap64_i64:
|
|
|
|
tcg_out_bswap64(s, args[0], args[1]);
|
|
|
|
break;
|
|
|
|
|
2012-10-11 03:01:35 +04:00
|
|
|
case INDEX_op_deposit_i32:
|
|
|
|
case INDEX_op_deposit_i64:
|
|
|
|
tcg_out_deposit(s, args[0], args[1], args[2], const_args[2],
|
|
|
|
args[3], args[4]);
|
|
|
|
break;
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
case INDEX_op_brcond_i32:
|
2015-02-14 00:39:54 +03:00
|
|
|
tcg_out_brcond(s, args[2], args[0], args[1], arg_label(args[3]), 1);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
case INDEX_op_brcond_i64:
|
2015-02-14 00:39:54 +03:00
|
|
|
tcg_out_brcond(s, args[2], args[0], args[1], arg_label(args[3]), 0);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
case INDEX_op_setcond_i32:
|
|
|
|
tcg_out_setcond(s, args[3], args[0], args[1], args[2], 1);
|
|
|
|
break;
|
|
|
|
case INDEX_op_setcond_i64:
|
|
|
|
tcg_out_setcond(s, args[3], args[0], args[1], args[2], 0);
|
|
|
|
break;
|
2012-10-09 23:53:55 +04:00
|
|
|
case INDEX_op_movcond_i32:
|
|
|
|
tcg_out_movcond(s, args[5], args[0], args[1], args[2],
|
|
|
|
args[3], const_args[3], args[4], const_args[4], 1);
|
|
|
|
break;
|
|
|
|
case INDEX_op_movcond_i64:
|
|
|
|
tcg_out_movcond(s, args[5], args[0], args[1], args[2],
|
|
|
|
args[3], const_args[3], args[4], const_args[4], 0);
|
|
|
|
break;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
case INDEX_op_qemu_ld_i32:
|
|
|
|
tcg_out_qemu_ld(s, args);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
2014-03-04 21:35:30 +04:00
|
|
|
case INDEX_op_qemu_ld_i64:
|
|
|
|
tcg_out_qemu_ld(s, args);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
2014-03-04 21:35:30 +04:00
|
|
|
case INDEX_op_qemu_st_i32:
|
|
|
|
tcg_out_qemu_st(s, args);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
2014-03-04 21:35:30 +04:00
|
|
|
case INDEX_op_qemu_st_i64:
|
|
|
|
tcg_out_qemu_st(s, args);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
break;
|
|
|
|
|
2016-07-14 23:20:17 +03:00
|
|
|
case INDEX_op_mb:
|
|
|
|
tcg_out_bundle(s, mmI, OPC_MF_M24, INSN_NOP_M, INSN_NOP_I);
|
|
|
|
break;
|
2014-04-25 23:19:33 +04:00
|
|
|
case INDEX_op_mov_i32: /* Always emitted via tcg_out_mov. */
|
|
|
|
case INDEX_op_mov_i64:
|
|
|
|
case INDEX_op_movi_i32: /* Always emitted via tcg_out_movi. */
|
|
|
|
case INDEX_op_movi_i64:
|
|
|
|
case INDEX_op_call: /* Always emitted via tcg_out_call. */
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
default:
|
|
|
|
tcg_abort();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static const TCGTargetOpDef ia64_op_defs[] = {
|
|
|
|
{ INDEX_op_br, { } },
|
|
|
|
{ INDEX_op_exit_tb, { } },
|
|
|
|
{ INDEX_op_goto_tb, { } },
|
|
|
|
|
|
|
|
{ INDEX_op_ld8u_i32, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld8s_i32, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld16u_i32, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld16s_i32, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld_i32, { "r", "r" } },
|
|
|
|
{ INDEX_op_st8_i32, { "rZ", "r" } },
|
|
|
|
{ INDEX_op_st16_i32, { "rZ", "r" } },
|
|
|
|
{ INDEX_op_st_i32, { "rZ", "r" } },
|
|
|
|
|
2013-09-06 00:15:13 +04:00
|
|
|
{ INDEX_op_add_i32, { "r", "rZ", "rI" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{ INDEX_op_sub_i32, { "r", "rI", "rI" } },
|
|
|
|
|
|
|
|
{ INDEX_op_and_i32, { "r", "rI", "rI" } },
|
|
|
|
{ INDEX_op_andc_i32, { "r", "rI", "rI" } },
|
|
|
|
{ INDEX_op_eqv_i32, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_nand_i32, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_nor_i32, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_or_i32, { "r", "rI", "rI" } },
|
|
|
|
{ INDEX_op_orc_i32, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_xor_i32, { "r", "rI", "rI" } },
|
|
|
|
|
|
|
|
{ INDEX_op_mul_i32, { "r", "rZ", "rZ" } },
|
|
|
|
|
|
|
|
{ INDEX_op_sar_i32, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_shl_i32, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_shr_i32, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_rotl_i32, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_rotr_i32, { "r", "rZ", "ri" } },
|
|
|
|
|
|
|
|
{ INDEX_op_ext8s_i32, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext8u_i32, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext16s_i32, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext16u_i32, { "r", "rZ"} },
|
|
|
|
|
|
|
|
{ INDEX_op_bswap16_i32, { "r", "rZ" } },
|
|
|
|
{ INDEX_op_bswap32_i32, { "r", "rZ" } },
|
|
|
|
|
2013-09-05 20:47:41 +04:00
|
|
|
{ INDEX_op_brcond_i32, { "rZ", "rZ" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{ INDEX_op_setcond_i32, { "r", "rZ", "rZ" } },
|
2012-10-09 23:53:55 +04:00
|
|
|
{ INDEX_op_movcond_i32, { "r", "rZ", "rZ", "rI", "rI" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
{ INDEX_op_ld8u_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld8s_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld16u_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld16s_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld32u_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld32s_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_ld_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_st8_i64, { "rZ", "r" } },
|
|
|
|
{ INDEX_op_st16_i64, { "rZ", "r" } },
|
|
|
|
{ INDEX_op_st32_i64, { "rZ", "r" } },
|
|
|
|
{ INDEX_op_st_i64, { "rZ", "r" } },
|
|
|
|
|
2013-09-06 00:15:13 +04:00
|
|
|
{ INDEX_op_add_i64, { "r", "rZ", "rI" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{ INDEX_op_sub_i64, { "r", "rI", "rI" } },
|
|
|
|
|
|
|
|
{ INDEX_op_and_i64, { "r", "rI", "rI" } },
|
|
|
|
{ INDEX_op_andc_i64, { "r", "rI", "rI" } },
|
|
|
|
{ INDEX_op_eqv_i64, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_nand_i64, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_nor_i64, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_or_i64, { "r", "rI", "rI" } },
|
|
|
|
{ INDEX_op_orc_i64, { "r", "rZ", "rZ" } },
|
|
|
|
{ INDEX_op_xor_i64, { "r", "rI", "rI" } },
|
|
|
|
|
|
|
|
{ INDEX_op_mul_i64, { "r", "rZ", "rZ" } },
|
|
|
|
|
|
|
|
{ INDEX_op_sar_i64, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_shl_i64, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_shr_i64, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_rotl_i64, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_rotr_i64, { "r", "rZ", "ri" } },
|
|
|
|
|
|
|
|
{ INDEX_op_ext8s_i64, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext8u_i64, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext16s_i64, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext16u_i64, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext32s_i64, { "r", "rZ"} },
|
|
|
|
{ INDEX_op_ext32u_i64, { "r", "rZ"} },
|
2015-07-27 13:41:45 +03:00
|
|
|
{ INDEX_op_ext_i32_i64, { "r", "rZ" } },
|
|
|
|
{ INDEX_op_extu_i32_i64, { "r", "rZ" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
{ INDEX_op_bswap16_i64, { "r", "rZ" } },
|
|
|
|
{ INDEX_op_bswap32_i64, { "r", "rZ" } },
|
|
|
|
{ INDEX_op_bswap64_i64, { "r", "rZ" } },
|
|
|
|
|
2013-09-05 20:47:41 +04:00
|
|
|
{ INDEX_op_brcond_i64, { "rZ", "rZ" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{ INDEX_op_setcond_i64, { "r", "rZ", "rZ" } },
|
2012-10-09 23:53:55 +04:00
|
|
|
{ INDEX_op_movcond_i64, { "r", "rZ", "rZ", "rI", "rI" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2012-10-11 03:01:35 +04:00
|
|
|
{ INDEX_op_deposit_i32, { "r", "rZ", "ri" } },
|
|
|
|
{ INDEX_op_deposit_i64, { "r", "rZ", "ri" } },
|
|
|
|
|
2014-03-04 21:35:30 +04:00
|
|
|
{ INDEX_op_qemu_ld_i32, { "r", "r" } },
|
|
|
|
{ INDEX_op_qemu_ld_i64, { "r", "r" } },
|
|
|
|
{ INDEX_op_qemu_st_i32, { "SZ", "r" } },
|
|
|
|
{ INDEX_op_qemu_st_i64, { "SZ", "r" } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2016-07-14 23:20:17 +03:00
|
|
|
{ INDEX_op_mb, { } },
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{ -1 },
|
|
|
|
};
|
|
|
|
|
2016-11-18 11:31:40 +03:00
|
|
|
static const TCGTargetOpDef *tcg_target_op_def(TCGOpcode op)
|
|
|
|
{
|
|
|
|
int i, n = ARRAY_SIZE(ia64_op_defs);
|
|
|
|
|
|
|
|
for (i = 0; i < n; ++i) {
|
|
|
|
if (ia64_op_defs[i].op == op) {
|
|
|
|
return &ia64_op_defs[i];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
/* Generate global QEMU prologue and epilogue code */
|
2010-06-03 04:26:56 +04:00
|
|
|
static void tcg_target_qemu_prologue(TCGContext *s)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
|
|
|
int frame_size;
|
|
|
|
|
|
|
|
/* reserve some stack space */
|
2012-10-09 23:53:55 +04:00
|
|
|
frame_size = TCG_STATIC_CALL_ARGS_SIZE +
|
|
|
|
CPU_TEMP_BUF_NLONGS * sizeof(long);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
frame_size = (frame_size + TCG_TARGET_STACK_ALIGN - 1) &
|
|
|
|
~(TCG_TARGET_STACK_ALIGN - 1);
|
2012-10-09 23:53:55 +04:00
|
|
|
tcg_set_frame(s, TCG_REG_CALL_STACK, TCG_STATIC_CALL_ARGS_SIZE,
|
|
|
|
CPU_TEMP_BUF_NLONGS * sizeof(long));
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
/* First emit adhoc function descriptor */
|
2014-04-25 21:24:23 +04:00
|
|
|
*s->code_ptr = (tcg_insn_unit){
|
|
|
|
(uint64_t)(s->code_ptr + 1), /* entry point */
|
|
|
|
0 /* skip gp */
|
|
|
|
};
|
|
|
|
s->code_ptr++;
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
|
|
|
/* prologue */
|
2012-08-26 01:59:58 +04:00
|
|
|
tcg_out_bundle(s, miI,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_m34(TCG_REG_P0, OPC_ALLOC_M34,
|
2012-08-26 01:59:58 +04:00
|
|
|
TCG_REG_R34, 32, 24, 0),
|
2013-09-05 22:45:54 +04:00
|
|
|
INSN_NOP_I,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i21(TCG_REG_P0, OPC_MOV_I21,
|
2012-08-26 01:59:58 +04:00
|
|
|
TCG_REG_B6, TCG_REG_R33, 0));
|
2010-05-06 19:50:44 +04:00
|
|
|
|
2015-08-24 15:53:54 +03:00
|
|
|
/* ??? If guest_base < 0x200000, we could load the register via
|
2010-05-06 19:50:44 +04:00
|
|
|
an ADDL in the M slot of the next bundle. */
|
2015-08-24 15:53:54 +03:00
|
|
|
if (guest_base != 0) {
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_out_bundle(s, mlx,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
2015-08-24 15:53:54 +03:00
|
|
|
tcg_opc_l2(guest_base),
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_opc_x2 (TCG_REG_P0, OPC_MOVL_X2,
|
2015-08-24 15:53:54 +03:00
|
|
|
TCG_GUEST_BASE_REG, guest_base));
|
2010-05-06 19:50:44 +04:00
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_GUEST_BASE_REG);
|
|
|
|
}
|
|
|
|
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_out_bundle(s, miB,
|
|
|
|
tcg_opc_a4 (TCG_REG_P0, OPC_ADDS_A4,
|
|
|
|
TCG_REG_R12, -frame_size, TCG_REG_R12),
|
2012-08-26 01:59:58 +04:00
|
|
|
tcg_opc_i22(TCG_REG_P0, OPC_MOV_I22,
|
2013-09-05 22:45:54 +04:00
|
|
|
TCG_REG_R33, TCG_REG_B0),
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_b4 (TCG_REG_P0, OPC_BR_SPTK_MANY_B4, TCG_REG_B6));
|
|
|
|
|
|
|
|
/* epilogue */
|
|
|
|
tb_ret_addr = s->code_ptr;
|
|
|
|
tcg_out_bundle(s, miI,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i21(TCG_REG_P0, OPC_MOV_I21,
|
2013-09-05 22:45:54 +04:00
|
|
|
TCG_REG_B0, TCG_REG_R33, 0),
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_a4 (TCG_REG_P0, OPC_ADDS_A4,
|
|
|
|
TCG_REG_R12, frame_size, TCG_REG_R12));
|
|
|
|
tcg_out_bundle(s, miB,
|
2013-09-05 03:00:52 +04:00
|
|
|
INSN_NOP_M,
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_i26(TCG_REG_P0, OPC_MOV_I_I26,
|
2012-08-26 01:59:58 +04:00
|
|
|
TCG_REG_PFS, TCG_REG_R34),
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_opc_b4 (TCG_REG_P0, OPC_BR_RET_SPTK_MANY_B4,
|
|
|
|
TCG_REG_B0));
|
|
|
|
}
|
|
|
|
|
2010-06-03 04:26:56 +04:00
|
|
|
static void tcg_target_init(TCGContext *s)
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
{
|
|
|
|
tcg_regset_set(tcg_target_available_regs[TCG_TYPE_I32],
|
|
|
|
0xffffffffffffffffull);
|
|
|
|
tcg_regset_set(tcg_target_available_regs[TCG_TYPE_I64],
|
|
|
|
0xffffffffffffffffull);
|
|
|
|
|
2010-05-06 19:50:43 +04:00
|
|
|
tcg_regset_clear(tcg_target_call_clobber_regs);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R8);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R9);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R10);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R11);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R14);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R15);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R16);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R17);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R18);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R19);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R20);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R21);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R22);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R23);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R24);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R25);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R26);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R27);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R28);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R29);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R30);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R31);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R56);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R57);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R58);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R59);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R60);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R61);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R62);
|
|
|
|
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_R63);
|
|
|
|
|
|
|
|
tcg_regset_clear(s->reserved_regs);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R0); /* zero register */
|
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R1); /* global pointer */
|
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R2); /* internal use */
|
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R3); /* internal use */
|
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R12); /* stack pointer */
|
2010-05-06 19:50:43 +04:00
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R13); /* thread pointer */
|
2013-09-05 22:45:54 +04:00
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R33); /* return address */
|
2012-08-26 01:59:58 +04:00
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R34); /* PFS */
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
|
2013-09-05 22:45:54 +04:00
|
|
|
/* The following 4 are not in use, are call-saved, but *not* saved
|
2010-05-06 19:50:43 +04:00
|
|
|
by the prologue. Therefore we cannot use them without modifying
|
|
|
|
the prologue. There doesn't seem to be any good reason to use
|
|
|
|
these as opposed to the windowed registers. */
|
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R4);
|
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R5);
|
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R6);
|
2013-09-05 22:45:54 +04:00
|
|
|
tcg_regset_set_reg(s->reserved_regs, TCG_REG_R7);
|
tcg: initial ia64 support
A few words about design choices:
* On IA64, instructions should be grouped by bundle, and dependencies
between instructions declared. A first version of this code tried to
schedule instructions automatically, but was very complex and too
invasive for the current common TCG code (ops not ending at
instruction boundaries, code retranslation breaking already generated
code, etc.) It was also not very efficient, as dependencies between
TCG ops is not available.
Instead the option taken by the current implementation does not try
to fill the bundle by scheduling instructions, but by providing ops
not available as an ia64 instruction, and by offering 22-bit constant
loading for most of the instructions. With both options the bundle are
filled at approximately the same level.
* Up to 128 registers can be affected to a function on IA64, but TCG
limits this number to 64, which is actually more than enough. The
register affectation is the following:
- r0: used to map a constant argument with value 0
- r1: global pointer
- r2, r3: internal use
- r4 to r6: not used to avoid saving them
- r7: env structure
- r8 to r11: free for TCG (call clobbered)
- r12: stack pointer
- r13: thread pointer
- r14 to r31: free for TCG (call clobbered)
- r32: reserved (return address)
- r33: reserved (PFS)
- r33 to r63: free for TCG
* The IA64 architecture has only 64-bit registers and no 32-bit
instructions (the only exception being cmp4). Therefore 64-bit
registers and instructions are used for 32-bit ops. The adopted
strategy is the same as the ABI, that is the higher 32 bits are
undefined. Most ops (and, or, add, shl, etc.) can directly use
the 64-bit registers, while some others have to sign-extend (sar,
div, etc.) or zero-extend (shr, divu, etc.) the register first.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-29 04:12:51 +04:00
|
|
|
}
|