ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-01-09 06:23:04 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
2f7356863b
corda/include/avian/codegen/assembler.h

114 lines
3.0 KiB
C
Raw Normal View History

update copyright years
2014-04-21 02:14:48 +00:00
/* Copyright (c) 2008-2014, Avian Contributors
add copyright header to files which don't already have them
2008-06-25 20:53:48 +00:00
Permission to use, copy, modify, and/or distribute this software
for any purpose with or without fee is hereby granted, provided
that the above copyright notice and this permission notice appear
in all copies.
There is NO WARRANTY for this software. See license.txt for
details. */
adjust package structure in codegen (vm -> avian::codegen and avian::codegen::lir) The eventual intent with the lir namespace is to formalize some of the important bits of Assembler interface, to be tested, debug-printed, and potentially, serialized. Also, group arguments to apply(...) in OperandInfos
2013-02-11 15:07:46 +00:00
#ifndef AVIAN_CODEGEN_ASSEMBLER_H
#define AVIAN_CODEGEN_ASSEMBLER_H
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
remove vm from code paths, to match namespacing
2014-02-07 21:24:56 +00:00
#include <avian/system/system.h>
move headers from src to src/avian This is necessary to avoid name conflicts on various platforms. For example, iOS has its own util.h, and Windows has a process.h. By including our version as e.g. "avian/util.h", we avoid confusion with the system version.
2013-02-27 20:25:50 +00:00
#include "avian/zone.h"
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
remove vm from code paths, to match namespacing
2014-02-07 21:24:56 +00:00
#include <avian/codegen/lir.h>
#include <avian/codegen/promise.h>
adjust package structure in codegen (vm -> avian::codegen and avian::codegen::lir) The eventual intent with the lir namespace is to formalize some of the important bits of Assembler interface, to be tested, debug-printed, and potentially, serialized. Also, group arguments to apply(...) in OperandInfos
2013-02-11 15:07:46 +00:00
namespace avian {
namespace codegen {
break Architecture out of Assembler
2013-02-24 06:03:01 +00:00
class Architecture;
begin moving register allocator out of compiler.cpp
2013-02-12 04:31:19 +00:00
adjust package structure in codegen (vm -> avian::codegen and avian::codegen::lir) The eventual intent with the lir namespace is to formalize some of the important bits of Assembler interface, to be tested, debug-printed, and potentially, serialized. Also, group arguments to apply(...) in OperandInfos
2013-02-11 15:07:46 +00:00
class OperandInfo {
public:
const unsigned size;
const lir::OperandType type;
lir::Operand* const operand;
inline OperandInfo(unsigned size, lir::OperandType type, lir::Operand* operand):
size(size),
type(type),
operand(operand)
{ }
};
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
support tail calls and continuations as build options
2009-05-26 05:27:10 +00:00
#ifdef AVIAN_TAILS
const bool TailCalls = true;
#else
const bool TailCalls = false;
#endif
remove powerpc support
2014-04-29 19:26:40 +00:00
#ifdef AVIAN_USE_FRAME_POINTER
support stack unwinding without using a frame pointer Previously, we unwound the stack by following the chain of frame pointers for normal returns, stack trace creation, and exception unwinding. On x86, this required reserving EBP/RBP for frame pointer duties, making it unavailable for general computation and requiring that it be explicitly saved and restored on entry and exit, respectively. On PowerPC, we use an ABI that makes the stack pointer double as a frame pointer, so it doesn't cost us anything. We've been using the same convention on ARM, but it doesn't match the native calling convention, which makes it unusable when we want to call native code from Java and pass arguments on the stack. So far, the ARM calling convention mismatch hasn't been an issue because we've never passed more arguments from Java to native code than would fit in registers. However, we must now pass an extra argument (the thread pointer) to e.g. divideLong so it can throw an exception on divide by zero, which means the last argument must be passed on the stack. This will clobber the linkage area we've been using to hold the frame pointer, so we need to stop using it. One solution would be to use the same convention on ARM as we do on x86, but this would introduce the same overhead of making a register unavailable for general use and extra code at method entry and exit. Instead, this commit removes the need for a frame pointer. Unwinding involves consulting a map of instruction offsets to frame sizes which is generated at compile time. This is necessary because stack trace creation can happen at any time due to Thread.getStackTrace being called by another thread, and the frame size varies during the execution of a method. So far, only x86(_64) is working, and continuations and tail call optimization are probably broken. More to come.
2011-01-17 02:05:05 +00:00
const bool UseFramePointer = true;
#else
const bool UseFramePointer = false;
#endif
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
class Assembler {
public:
allow assembler to acquire and release temporary registers; new machine instruction implementations; bugfixes
2008-03-13 23:43:11 +00:00
class Client {
public:
fix build
2008-05-06 21:13:02 +00:00
virtual int acquireTemporary
(uint32_t mask = ~static_cast<uint32_t>(0)) = 0;
allow assembler to acquire and release temporary registers; new machine instruction implementations; bugfixes
2008-03-13 23:43:11 +00:00
virtual void releaseTemporary(int r) = 0;
various bugfixes; majority of tests now pass
2008-04-27 20:15:18 +00:00
virtual void save(int r) = 0;
allow assembler to acquire and release temporary registers; new machine instruction implementations; bugfixes
2008-03-13 23:43:11 +00:00
};
got a simple arithmetic test working
2008-09-07 20:12:11 +00:00
class Block {
public:
virtual unsigned resolve(unsigned start, Block* next) = 0;
};
snapshot
2008-08-17 19:32:40 +00:00
virtual void setClient(Client* client) = 0;
progress towards refactored JIT compiler to support PowerPC and data flow analysis across control flow boundaries
2008-08-23 18:04:36 +00:00
virtual Architecture* arch() = 0;
more progress on PowerPC build Also, hide frame mapping for stack unwinding (which is still incomplete) in x86.cpp, since no other platform needs it.
2011-01-30 21:14:57 +00:00
virtual void checkStackOverflow(uintptr_t handler,
unsigned stackLimitOffsetFromThread) = 0;
fix ARM stack unwinding We can't rely on the C++ compiler to save the return address in a known location on entry to each function we might call from Java (although GCC 4.5 seems to do so consistently, which is why I hadn't realized the unwinding code was relying on that assumption), so we must store it explicitly in MyThread::ip in each thunk. For PowerPC and x86, we continue saving it on the stack as always, since the calling convention guarantees its location relative to the stack pointer.
2011-02-20 03:33:26 +00:00
virtual void saveFrame(unsigned stackOffset, unsigned ipOffset) = 0;
more progress towards new JIT code - this compiles but won't run properly
2008-09-05 15:00:38 +00:00
virtual void pushFrame(unsigned argumentCount, ...) = 0;
virtual void allocateFrame(unsigned footprint) = 0;
support stack unwinding without using a frame pointer Previously, we unwound the stack by following the chain of frame pointers for normal returns, stack trace creation, and exception unwinding. On x86, this required reserving EBP/RBP for frame pointer duties, making it unavailable for general computation and requiring that it be explicitly saved and restored on entry and exit, respectively. On PowerPC, we use an ABI that makes the stack pointer double as a frame pointer, so it doesn't cost us anything. We've been using the same convention on ARM, but it doesn't match the native calling convention, which makes it unusable when we want to call native code from Java and pass arguments on the stack. So far, the ARM calling convention mismatch hasn't been an issue because we've never passed more arguments from Java to native code than would fit in registers. However, we must now pass an extra argument (the thread pointer) to e.g. divideLong so it can throw an exception on divide by zero, which means the last argument must be passed on the stack. This will clobber the linkage area we've been using to hold the frame pointer, so we need to stop using it. One solution would be to use the same convention on ARM as we do on x86, but this would introduce the same overhead of making a register unavailable for general use and extra code at method entry and exit. Instead, this commit removes the need for a frame pointer. Unwinding involves consulting a map of instruction offsets to frame sizes which is generated at compile time. This is necessary because stack trace creation can happen at any time due to Thread.getStackTrace being called by another thread, and the frame size varies during the execution of a method. So far, only x86(_64) is working, and continuations and tail call optimization are probably broken. More to come.
2011-01-17 02:05:05 +00:00
virtual void adjustFrame(unsigned difference) = 0;
virtual void popFrame(unsigned footprint) = 0;
implement "callee pops arguments" calling convention and refactor tail call code accordingly
2009-04-19 22:36:11 +00:00
virtual void popFrameForTailCall(unsigned footprint, int offset,
int returnAddressSurrogate,
int framePointerSurrogate) = 0;
support stack unwinding without using a frame pointer Previously, we unwound the stack by following the chain of frame pointers for normal returns, stack trace creation, and exception unwinding. On x86, this required reserving EBP/RBP for frame pointer duties, making it unavailable for general computation and requiring that it be explicitly saved and restored on entry and exit, respectively. On PowerPC, we use an ABI that makes the stack pointer double as a frame pointer, so it doesn't cost us anything. We've been using the same convention on ARM, but it doesn't match the native calling convention, which makes it unusable when we want to call native code from Java and pass arguments on the stack. So far, the ARM calling convention mismatch hasn't been an issue because we've never passed more arguments from Java to native code than would fit in registers. However, we must now pass an extra argument (the thread pointer) to e.g. divideLong so it can throw an exception on divide by zero, which means the last argument must be passed on the stack. This will clobber the linkage area we've been using to hold the frame pointer, so we need to stop using it. One solution would be to use the same convention on ARM as we do on x86, but this would introduce the same overhead of making a register unavailable for general use and extra code at method entry and exit. Instead, this commit removes the need for a frame pointer. Unwinding involves consulting a map of instruction offsets to frame sizes which is generated at compile time. This is necessary because stack trace creation can happen at any time due to Thread.getStackTrace being called by another thread, and the frame size varies during the execution of a method. So far, only x86(_64) is working, and continuations and tail call optimization are probably broken. More to come.
2011-01-17 02:05:05 +00:00
virtual void popFrameAndPopArgumentsAndReturn(unsigned frameFootprint,
unsigned argumentFootprint)
implement "callee pops arguments" calling convention and refactor tail call code accordingly
2009-04-19 22:36:11 +00:00
= 0;
support stack unwinding without using a frame pointer Previously, we unwound the stack by following the chain of frame pointers for normal returns, stack trace creation, and exception unwinding. On x86, this required reserving EBP/RBP for frame pointer duties, making it unavailable for general computation and requiring that it be explicitly saved and restored on entry and exit, respectively. On PowerPC, we use an ABI that makes the stack pointer double as a frame pointer, so it doesn't cost us anything. We've been using the same convention on ARM, but it doesn't match the native calling convention, which makes it unusable when we want to call native code from Java and pass arguments on the stack. So far, the ARM calling convention mismatch hasn't been an issue because we've never passed more arguments from Java to native code than would fit in registers. However, we must now pass an extra argument (the thread pointer) to e.g. divideLong so it can throw an exception on divide by zero, which means the last argument must be passed on the stack. This will clobber the linkage area we've been using to hold the frame pointer, so we need to stop using it. One solution would be to use the same convention on ARM as we do on x86, but this would introduce the same overhead of making a register unavailable for general use and extra code at method entry and exit. Instead, this commit removes the need for a frame pointer. Unwinding involves consulting a map of instruction offsets to frame sizes which is generated at compile time. This is necessary because stack trace creation can happen at any time due to Thread.getStackTrace being called by another thread, and the frame size varies during the execution of a method. So far, only x86(_64) is working, and continuations and tail call optimization are probably broken. More to come.
2011-01-17 02:05:05 +00:00
virtual void popFrameAndUpdateStackAndReturn(unsigned frameFootprint,
unsigned stackOffsetFromThread)
adapt native method call code to new calling convention
2009-04-25 17:49:56 +00:00
= 0;
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
adjust package structure in codegen (vm -> avian::codegen and avian::codegen::lir) The eventual intent with the lir namespace is to formalize some of the important bits of Assembler interface, to be tested, debug-printed, and potentially, serialized. Also, group arguments to apply(...) in OperandInfos
2013-02-11 15:07:46 +00:00
virtual void apply(lir::Operation op) = 0;
virtual void apply(lir::UnaryOperation op, OperandInfo a) = 0;
virtual void apply(lir::BinaryOperation op, OperandInfo a, OperandInfo b) = 0;
virtual void apply(lir::TernaryOperation op, OperandInfo a, OperandInfo b, OperandInfo c) = 0;
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
handle long conditional immediate branches properly on PowerPC Due to encoding limitations, the immediate operand of conditional branches can be no more than 32KB forward or backward. Since the JIT-compiled form of some methods can be larger than 32KB, and we also do conditional jumps to code outside the current method in some cases, we must work around this limitation. The strategy of this commit is to provide inline, intermediate jump tables where necessary. A given conditional branch whose target is too far for a direct jump will instead point to an unconditional branch in the nearest jump table which points to the actual target. Unconditional immediate branches are also limited on PowerPC, but this limit is 32MB, which is not an impediment in practice. If it does become a problem, we'll need to encode such branches using multiple instructions.
2011-02-28 06:03:13 +00:00
virtual void setDestination(uint8_t* dst) = 0;
virtual void write() = 0;
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
fix return address code offset calculation on ARM We have to be careful about how we calculate return addresses on ARM due to padding introduced by constant pools interspersed with code. When calculating the offset of code where we're inserting a constant pool, we want the offset of the end of the pool for jump targets, but we want the offset just prior to the beginning of the pool (i.e. the offset of the instruction responsible for jumping past the pool) when calculating a return address.
2010-12-07 22:57:11 +00:00
virtual Promise* offset(bool forTrace = false) = 0;
snapshot
2008-08-30 20:12:27 +00:00
lots of bugfixes and a few instructions added
2008-09-09 00:31:19 +00:00
virtual Block* endBlock(bool startNew) = 0;
snapshot
2008-08-30 20:12:27 +00:00
optimize loads of constant values by using PC-relative addressing on ARM Previously, loading an arbitrary 32-bit constant required up to four instructions (128 bytes), since we did so one byte at a time via immediate-mode operations. The preferred way to load constants on ARM is via PC-relative addressing, but this is challenging because immediate memory offsets are limited to 4096 bytes in either direction. We frequently need to compile methods which are larger than 4096, or even 8192, bytes, so we must intersperse code and data if we want to use PC-relative loads everywhere. This commit enables pervasive PC-relative loads by handling the following cases: 1. Method is shorter than 4096 bytes: append data table to end 2. Method is longer than 4096 bytes, but no basic block is longer than 4096 bytes: insert data tables as necessary after blocks, taking care to minimize the total number of tables 3. Method is longer than 4096 bytes, and some blocks are longer than 4096 bytes: split large basic blocks and insert data tables as above
2010-11-14 02:28:05 +00:00
virtual void endEvent() = 0;
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
optimize loads of constant values by using PC-relative addressing on ARM Previously, loading an arbitrary 32-bit constant required up to four instructions (128 bytes), since we did so one byte at a time via immediate-mode operations. The preferred way to load constants on ARM is via PC-relative addressing, but this is challenging because immediate memory offsets are limited to 4096 bytes in either direction. We frequently need to compile methods which are larger than 4096, or even 8192, bytes, so we must intersperse code and data if we want to use PC-relative loads everywhere. This commit enables pervasive PC-relative loads by handling the following cases: 1. Method is shorter than 4096 bytes: append data table to end 2. Method is longer than 4096 bytes, but no basic block is longer than 4096 bytes: insert data tables as necessary after blocks, taking care to minimize the total number of tables 3. Method is longer than 4096 bytes, and some blocks are longer than 4096 bytes: split large basic blocks and insert data tables as above
2010-11-14 02:28:05 +00:00
virtual unsigned length() = 0;
fix powerpc bootimage build
2009-10-20 14:20:49 +00:00
more progress on PowerPC build Also, hide frame mapping for stack unwinding (which is still incomplete) in x86.cpp, since no other platform needs it.
2011-01-30 21:14:57 +00:00
virtual unsigned footerSize() = 0;
support stack unwinding without using a frame pointer Previously, we unwound the stack by following the chain of frame pointers for normal returns, stack trace creation, and exception unwinding. On x86, this required reserving EBP/RBP for frame pointer duties, making it unavailable for general computation and requiring that it be explicitly saved and restored on entry and exit, respectively. On PowerPC, we use an ABI that makes the stack pointer double as a frame pointer, so it doesn't cost us anything. We've been using the same convention on ARM, but it doesn't match the native calling convention, which makes it unusable when we want to call native code from Java and pass arguments on the stack. So far, the ARM calling convention mismatch hasn't been an issue because we've never passed more arguments from Java to native code than would fit in registers. However, we must now pass an extra argument (the thread pointer) to e.g. divideLong so it can throw an exception on divide by zero, which means the last argument must be passed on the stack. This will clobber the linkage area we've been using to hold the frame pointer, so we need to stop using it. One solution would be to use the same convention on ARM as we do on x86, but this would introduce the same overhead of making a register unavailable for general use and extra code at method entry and exit. Instead, this commit removes the need for a frame pointer. Unwinding involves consulting a map of instruction offsets to frame sizes which is generated at compile time. This is necessary because stack trace creation can happen at any time due to Thread.getStackTrace being called by another thread, and the frame size varies during the execution of a method. So far, only x86(_64) is working, and continuations and tail call optimization are probably broken. More to come.
2011-01-17 02:05:05 +00:00
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
virtual void dispose() = 0;
};
adjust package structure in codegen (vm -> avian::codegen and avian::codegen::lir) The eventual intent with the lir namespace is to formalize some of the important bits of Assembler interface, to be tested, debug-printed, and potentially, serialized. Also, group arguments to apply(...) in OperandInfos
2013-02-11 15:07:46 +00:00
} // namespace codegen
} // namespace avian
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
adjust package structure in codegen (vm -> avian::codegen and avian::codegen::lir) The eventual intent with the lir namespace is to formalize some of the important bits of Assembler interface, to be tested, debug-printed, and potentially, serialized. Also, group arguments to apply(...) in OperandInfos
2013-02-11 15:07:46 +00:00
#endif // AVIAN_CODEGEN_ASSEMBLER_H
Reference in New Issue Copy Permalink