6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-10-21 01:25:20 +00:00
Code Issues Projects Releases Wiki Activity

Add a "Lazy Function Resolution in Jello" section

Browse Source 
Remove some todo's


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@4910 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2002-12-04 16:12:54 +00:00
parent 33ced56edb
commit 504c411e81
1 changed files with 40 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
lib/Target/X86/README.txt
View File

@ -81,9 +81,41 @@ operand, they simply have #operands = #uses. To create them, simply do not
specify a destination register to the BuildMI call.
=======================
III. Source Code Layout
=======================
======================================
III. Lazy Function Resolution in Jello
======================================
Jello is a designed to be a JIT compiler for LLVM code. This implies that call
instructions may be emitted before the function they call is compiled. In order
to support this, Jello currently emits unresolved call instructions to call to a
null pointer. When the call instruction is executed, a segmentation fault will
be generated.
Jello installs a trap handler for SIGSEGV, in order to trap these events. When
a SIGSEGV occurs, first we check to see if it's due to lazy function resolution,
if so, we look up the return address of the function call (which was pushed onto
the stack by the call instruction). Given the return address of the call, we
consult a map to figure out which function was supposed to be called from that
location.
If the function has not been code generated yet, it is at this time. Finally,
the EIP of the process is modified to point to the real function address, the
original call instruction is updated, and the SIGSEGV handler returns, causing
execution to start in the called function. Because we update the original call
instruction, we should only get at most one signal for each call site.
Note that this approach does not work for indirect calls. The problem with
indirect calls is that taking the address of a function would not cause a fault
(it would simply copy null into a register), so we would only find out about the
problem when the indirect call itself was made. At this point we would have no
way of knowing what the intended function destination was. Because of this, we
immediately code generate functions whenever they have their address taken,
side-stepping the problem completely.
======================
IV. Source Code Layout
======================
The LLVM-JIT is composed of source files primarily in the following locations:
@ -128,9 +160,9 @@ This directory contains regression tests for the JIT. Initially it contains a
bunch of really trivial testcases that we should build up to supporting.
===================================================
IV. Strange Things, or, Things That Should Be Known
===================================================
==================================================
V. Strange Things, or, Things That Should Be Known
==================================================
Representing memory in MachineInstrs
------------------------------------
@ -154,7 +186,7 @@ way, in the same order.
==========================
V. TODO / Future Projects
VI. TODO / Future Projects
==========================
There are a large number of things remaining to do. Here is a partial list:
@ -162,13 +194,7 @@ There are a large number of things remaining to do. Here is a partial list:
Critical path:
-------------
0. Finish providing SSA form. This involves keeping track of some information
when instructions are added to the function, but should not affect that API
for creating new MInstructions or adding them to the program.
1. Finish dumb instruction selector
2. Write dumb register allocator
3. Write assembly language emitter
4. Write machine code emitter
Next Phase:
-----------
@ -179,7 +205,7 @@ After this project:
-------------------
1. Implement lots of nifty runtime optimizations
2. Implement a static compiler backend for x86 (might come almost for free...)
3. Implement new spiffy targets: IA64? X86-64? M68k? Who knows...
3. Implement new targets: IA64? X86-64? M68k? Who knows...
Infrastructure Improvements:
----------------------------