ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-01-09 14:33:30 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
44defda878
corda/include/avian/vm/codegen/assembler.h

206 lines
6.2 KiB
C
Raw Normal View History

update copyright years
2012-05-11 23:43:27 +00:00
/* Copyright (c) 2008-2012, 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
move system.h to include
2013-02-21 03:42:09 +00:00
#include <avian/vm/system/system.h>
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
#include "zone.h"
move codegen headers to include/
2013-02-20 05:12:28 +00:00
#include <avian/vm/codegen/lir.h>
#include <avian/vm/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 {
begin moving register allocator out of compiler.cpp
2013-02-12 04:31:19 +00:00
class RegisterFile;
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
UseFramePointer should always be true on PowerPC The Apple and SYSV ABIs specify that the stack/frame pointer is always saved at the tip of the stack.
2011-03-01 17:59:00 +00:00
#if (defined AVIAN_USE_FRAME_POINTER) || (defined ARCH_powerpc)
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
class Architecture {
public:
snapshot
2009-09-26 19:43:44 +00:00
virtual unsigned floatRegisterSize() = 0;
begin moving register allocator out of compiler.cpp
2013-02-12 04:31:19 +00:00
virtual const RegisterFile* registerFile() = 0;
allow assembler to acquire and release temporary registers; new machine instruction implementations; bugfixes
2008-03-13 23:43:11 +00:00
fix x86->powerpc boot image cross build This fixes the remaining cross-endian translation issues needed to build powerpc boot images on x86.
2011-09-24 04:21:54 +00:00
virtual int scratch() = 0;
snapshot
2008-08-17 19:32:40 +00:00
virtual int stack() = 0;
virtual int thread() = 0;
always return an 8-byte value (or void) from native functions called from Java This is important on the 32-bit OS X PowerPC ABI, since the location of the low 32-bits of a return value change depending on whether the entire value is 64-bits or not.
2009-02-28 21:20:43 +00:00
virtual int returnLow() = 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 int returnHigh() = 0;
early sketch of continuation support
2009-05-03 20:57:11 +00:00
virtual int virtualCallTarget() = 0;
implement "callee pops arguments" calling convention and refactor tail call code accordingly
2009-04-19 22:36:11 +00:00
virtual int virtualCallIndex() = 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
fix endianness issues with 64-bit locals
2009-03-01 19:28:17 +00:00
virtual bool bigEndian() = 0;
snapshot
2009-09-26 19:43:44 +00:00
fix bootimage build for case where the JIT code area is too far from the AOT code area to do immediate-offset jumps between them
2009-10-18 00:18:03 +00:00
virtual uintptr_t maximumImmediateJump() = 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
virtual bool alwaysCondensed(lir::BinaryOperation op) = 0;
virtual bool alwaysCondensed(lir::TernaryOperation op) = 0;
fix endianness issues with 64-bit locals
2009-03-01 19:28:17 +00:00
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 bool reserved(int register_) = 0;
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
adapt native method call code to new calling convention
2009-04-25 17:49:56 +00:00
virtual unsigned frameFootprint(unsigned footprint) = 0;
various bugfixes, especially concerning frame allocation and offset calculation
2009-02-26 03:49:42 +00:00
virtual unsigned argumentFootprint(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 bool argumentAlignment() = 0;
fix argument alignment for Darwin/ARM
2011-08-11 03:33:56 +00:00
virtual bool argumentRegisterAlignment() = 0;
snapshot
2008-08-17 19:32:40 +00:00
virtual unsigned argumentRegisterCount() = 0;
virtual int argumentRegister(unsigned index) = 0;
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
use link register to determine return address when appropriate in getStackTrace On PowerPC and ARM, we can't rely on the return address having already been saved on the stack on entry to a thunk, so we must look for it in the link register instead.
2011-02-21 22:25:52 +00:00
virtual bool hasLinkRegister() = 0;
adapt native method call code to new calling convention
2009-04-25 17:49:56 +00:00
virtual unsigned stackAlignmentInWords() = 0;
more work on tail recursion We now create a unique thunk for each vtable position so as to avoid relying on using the return address to determine what method is to be compiled and invoked, since we will not have the correct return address in the case of a tail call. This required refactoring how executable memory is allocated in order to keep AOT compilation working. Also, we must always use the same register to hold the class pointer when compiling virtual calls, and ensure that the pointer stays there until the call instruction is executed so we know where to find it in the thunk.
2009-04-05 21:42:10 +00:00
virtual bool matchCall(void* returnAddress, void* target) = 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
virtual void updateCall(lir::UnaryOperation op, void* returnAddress,
fix bootimage build for case where the JIT code area is too far from the AOT code area to do immediate-offset jumps between them
2009-10-18 00:18:03 +00:00
void* newTarget) = 0;
adapt compile.cpp to new compiler
2008-02-11 17:21:41 +00:00
progress towards cross-architecture bootimage builds This monster commit is the first step towards supporting cross-architecture bootimage builds. The challenge is to build a heap and code image for the target platform where the word size and endianess may differ from those of the build architecture. That means the memory layout of objects may differ due to alignment and size differences, so we can't just copy objects into the heap image unchanged; we must copy field by field, resizing values, reversing endianess and shifting offsets as necessary. This commit also removes POD (plain old data) type support from the type generator because it added a lot of complication and little value.
2011-08-30 01:00:17 +00:00
virtual void setConstant(void* dst, uint64_t constant) = 0;
fix powerpc bootimage build
2009-03-10 00:52:09 +00:00
snapshot
2008-08-17 19:32:40 +00:00
virtual unsigned alignFrameSize(unsigned sizeInWords) = 0;
more work on frame-pointer-less unwinding This fixes the tails=true build (at least for x86_64) and eliminates the need for a frame table in the tails=false build. In the tails=true build, we still need a frame table on x86(_64) to help determine whether we've caught a thread executing code to do a tail call or pop arguments off the stack. However, I've not yet written the code to actually use this table, and it is only needed to handle asynchronous unwinds via Thread.getStackTrace.
2011-01-26 00:22:43 +00:00
virtual void nextFrame(void* start, unsigned size, unsigned footprint,
fix a couple of subtle Thread.getStackTrace bugs The first problem was that, on x86, we failed to properly keep track of whether to expect the return address to be on the stack or not when unwinding through a frame. We were relying on a "stackLimit" pointer to tell us whether we were looking at the most recently-called frame by comparing it with the stack pointer for that frame. That was inaccurate in the case of a thread executing at the beginning of a method before a new frame is allocated, in which case the most recent two frames share a stack pointer, confusing the unwinder. The solution involves keeping track of how many frames we've looked at while walking the stack. The other problem was that compareIpToMethodBounds assumed every method was followed by at least one byte of padding before the next method started. That assumption was usually valid because we were storing the size following method code prior to the code itself. However, the last method of an AOT-compiled code image is not followed by any such method header and may instead be followed directly by native code with no intervening padding. In that case, we risk interpreting that native code as part of the preceding method, with potentially bizarre results. The reason for the compareIpToMethodBounds assumption was that methods which throw exceptions as their last instruction generate a non-returning call, which nonetheless push a return address on the stack which points past the end of the method, and the unwinder needs to know that return address belongs to that method. A better solution is to add an extra trap instruction to the end of such methods, which is what this patch does.
2012-05-05 00:35:13 +00:00
void* link, bool mostRecent,
more work on frame-pointer-less unwinding This fixes the tails=true build (at least for x86_64) and eliminates the need for a frame table in the tails=false build. In the tails=true build, we still need a frame table on x86(_64) to help determine whether we've caught a thread executing code to do a tail call or pop arguments off the stack. However, I've not yet written the code to actually use this table, and it is only needed to handle asynchronous unwinds via Thread.getStackTrace.
2011-01-26 00:22:43 +00:00
unsigned targetParameterFootprint, void** ip,
void** stack) = 0;
refactor stack walking and visiting code to abstract away certain details of stack layout which are architecture-specific
2008-08-18 15:23:01 +00:00
virtual void* frameIp(void* stack) = 0;
virtual unsigned frameHeaderSize() = 0;
fix stack mapping bugs which broke GC
2008-11-08 22:36:38 +00:00
virtual unsigned frameReturnAddressSize() = 0;
refactor stack walking and visiting code to abstract away certain details of stack layout which are architecture-specific
2008-08-18 15:23:01 +00:00
virtual unsigned frameFooterSize() = 0;
various bugfixes
2009-04-22 01:39:25 +00:00
virtual int returnAddressOffset() = 0;
virtual int framePointerOffset() = 0;
snapshot
2008-08-17 19:32:40 +00:00
virtual void plan
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
(lir::UnaryOperation op,
snapshot
2008-08-17 19:32:40 +00:00
unsigned aSize, uint8_t* aTypeMask, uint64_t* aRegisterMask,
bool* thunk) = 0;
added floating point support, split plan function.
2009-08-06 14:44:15 +00:00
virtual void planSource
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
(lir::BinaryOperation op,
snapshot
2008-08-17 19:32:40 +00:00
unsigned aSize, uint8_t* aTypeMask, uint64_t* aRegisterMask,
added floating point support, split plan function.
2009-08-06 14:44:15 +00:00
unsigned bSize, bool* thunk) = 0;
virtual void planDestination
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
(lir::BinaryOperation op,
snapshot
2009-10-04 19:56:48 +00:00
unsigned aSize, uint8_t aTypeMask, uint64_t aRegisterMask,
added floating point support, split plan function.
2009-08-06 14:44:15 +00:00
unsigned bSize, uint8_t* bTypeMask, uint64_t* bRegisterMask) = 0;
snapshot
2008-08-17 19:32:40 +00:00
snapshot
2009-10-04 19:56:48 +00:00
virtual void planMove
refactor code responsible for moving data in the compiler This is partially to address incorrect code generation for 64-bit floating-point values on x86_32 and partially to reduce unnecessary moves.
2009-11-28 04:15:12 +00:00
(unsigned size, uint8_t* srcTypeMask, uint64_t* srcRegisterMask,
uint8_t* tmpTypeMask, uint64_t* tmpRegisterMask,
uint8_t dstTypeMask, uint64_t dstRegisterMask) = 0;
snapshot
2009-10-04 19:56:48 +00:00
added floating point support, split plan function.
2009-08-06 14:44:15 +00:00
virtual void planSource
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
(lir::TernaryOperation op,
snapshot
2008-08-17 19:32:40 +00:00
unsigned aSize, uint8_t* aTypeMask, uint64_t* aRegisterMask,
unsigned bSize, uint8_t* bTypeMask, uint64_t* bRegisterMask,
added floating point support, split plan function.
2009-08-06 14:44:15 +00:00
unsigned cSize, bool* thunk) = 0;
virtual void planDestination
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
(lir::TernaryOperation op,
snapshot
2009-10-04 19:56:48 +00:00
unsigned aSize, uint8_t aTypeMask, uint64_t aRegisterMask,
unsigned bSize, uint8_t bTypeMask, uint64_t bRegisterMask,
allow codegen targets (Architectures and Assemblers) to co-exist The primary motivation behind this is to allow all the different Assemblers to be built at once, on a single machine. This should dramatically reduce the time required to make sure that a particular change doesn't break the build for one of the not-so-common architectures (arm, powerpc) Simply pass "codegen-targets=all" to make to compile all src/codegen/<arch>/assembler.cpp. Note that while these architectures are built, they will not be fully- functional. Certain stuff is assumed to be the same across the entire build (such as TargetBytesPerWord), but this isn't the case anymore.
2013-02-12 15:15:30 +00:00
unsigned cSize, uint8_t* cTypeMask, uint64_t* cRegisterMask) = 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
virtual Assembler* makeAssembler(vm::Allocator*, vm::Zone*) = 0;
snapshot
2008-08-16 18:46:14 +00:00
refactor stack walking and visiting code to abstract away certain details of stack layout which are architecture-specific
2008-08-18 15:23:01 +00:00
virtual void acquire() = 0;
virtual void release() = 0;
snapshot
2008-08-17 19:32:40 +00:00
};
snapshot
2008-07-05 20:21:13 +00:00
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