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 02:12:51 +02: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.
|
|
|
|
|
*/
|
2012-12-06 12:15:58 +01:00
|
|
|
#ifndef TCG_TARGET_IA64
|
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 02:12:51 +02:00
|
|
|
#define TCG_TARGET_IA64 1
|
|
|
|
|
|
|
|
|
|
/* We only map the first 64 registers */
|
|
|
|
|
#define TCG_TARGET_NB_REGS 64
|
2011-11-09 09:03:33 +01:00
|
|
|
typedef enum {
|
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 02:12:51 +02:00
|
|
|
TCG_REG_R0 = 0,
|
|
|
|
|
TCG_REG_R1,
|
|
|
|
|
TCG_REG_R2,
|
|
|
|
|
TCG_REG_R3,
|
|
|
|
|
TCG_REG_R4,
|
|
|
|
|
TCG_REG_R5,
|
|
|
|
|
TCG_REG_R6,
|
|
|
|
|
TCG_REG_R7,
|
|
|
|
|
TCG_REG_R8,
|
|
|
|
|
TCG_REG_R9,
|
|
|
|
|
TCG_REG_R10,
|
|
|
|
|
TCG_REG_R11,
|
|
|
|
|
TCG_REG_R12,
|
|
|
|
|
TCG_REG_R13,
|
|
|
|
|
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_R32,
|
|
|
|
|
TCG_REG_R33,
|
|
|
|
|
TCG_REG_R34,
|
|
|
|
|
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_R56,
|
|
|
|
|
TCG_REG_R57,
|
|
|
|
|
TCG_REG_R58,
|
|
|
|
|
TCG_REG_R59,
|
|
|
|
|
TCG_REG_R60,
|
|
|
|
|
TCG_REG_R61,
|
|
|
|
|
TCG_REG_R62,
|
|
|
|
|
TCG_REG_R63,
|
2011-11-09 09:03:33 +01:00
|
|
|
} TCGReg;
|
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 02:12:51 +02:00
|
|
|
|
|
|
|
|
#define TCG_CT_CONST_ZERO 0x100
|
|
|
|
|
#define TCG_CT_CONST_S22 0x200
|
|
|
|
|
|
|
|
|
|
/* used for function call generation */
|
|
|
|
|
#define TCG_REG_CALL_STACK TCG_REG_R12
|
|
|
|
|
#define TCG_TARGET_STACK_ALIGN 16
|
|
|
|
|
#define TCG_TARGET_CALL_STACK_OFFSET 16
|
|
|
|
|
|
|
|
|
|
/* optional instructions */
|
2011-08-17 23:11:46 +02:00
|
|
|
#define TCG_TARGET_HAS_div_i32 0
|
|
|
|
|
#define TCG_TARGET_HAS_div_i64 0
|
|
|
|
|
#define TCG_TARGET_HAS_andc_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_andc_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_bswap16_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_bswap16_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_bswap32_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_bswap32_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_bswap64_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_eqv_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_eqv_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext8s_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext16s_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext8s_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext16s_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext32s_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext8u_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext16u_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext8u_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext16u_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_ext32u_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_nand_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_nand_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_nor_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_nor_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_orc_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_orc_i64 1
|
|
|
|
|
#define TCG_TARGET_HAS_rot_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_rot_i64 1
|
2012-10-09 21:53:55 +02:00
|
|
|
#define TCG_TARGET_HAS_movcond_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_movcond_i64 1
|
2012-10-11 01:01:35 +02:00
|
|
|
#define TCG_TARGET_HAS_deposit_i32 1
|
|
|
|
|
#define TCG_TARGET_HAS_deposit_i64 1
|
|
|
|
|
|
|
|
|
|
#define TCG_TARGET_deposit_i32_valid(ofs, len) ((len) <= 16)
|
|
|
|
|
#define TCG_TARGET_deposit_i64_valid(ofs, len) ((len) <= 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 02:12:51 +02:00
|
|
|
|
|
|
|
|
/* optional instructions automatically implemented */
|
2011-08-17 23:11:46 +02:00
|
|
|
#define TCG_TARGET_HAS_neg_i32 0 /* sub r1, r0, r3 */
|
|
|
|
|
#define TCG_TARGET_HAS_neg_i64 0 /* sub r1, r0, r3 */
|
|
|
|
|
#define TCG_TARGET_HAS_not_i32 0 /* xor r1, -1, r3 */
|
|
|
|
|
#define TCG_TARGET_HAS_not_i64 0 /* xor r1, -1, 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 02:12:51 +02:00
|
|
|
|
|
|
|
|
#define TCG_AREG0 TCG_REG_R7
|
|
|
|
|
|
2012-03-02 23:30:05 +01:00
|
|
|
static inline void flush_icache_range(tcg_target_ulong start,
|
|
|
|
|
tcg_target_ulong stop)
|
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 02:12:51 +02:00
|
|
|
{
|
|
|
|
|
start = start & ~(32UL - 1UL);
|
|
|
|
|
stop = (stop + (32UL - 1UL)) & ~(32UL - 1UL);
|
|
|
|
|
|
|
|
|
|
for (; start < stop; start += 32UL) {
|
|
|
|
|
asm volatile ("fc.i %0" :: "r" (start));
|
|
|
|
|
}
|
|
|
|
|
asm volatile (";;sync.i;;srlz.i;;");
|
|
|
|
|
}
|
2012-12-06 12:15:58 +01:00
|
|
|
|
|
|
|
|
#endif
|