[svn:parrot] r41349 - in branches/kill_jit/docs: . book/draft dev
darbelo at svn.parrot.org
darbelo at svn.parrot.org
Sat Sep 19 01:15:52 UTC 2009
Author: darbelo
Date: Sat Sep 19 01:15:51 2009
New Revision: 41349
URL: https://trac.parrot.org/parrot/changeset/41349
Log:
Remove JIT references from the docs.
Deleted:
branches/kill_jit/docs/dev/jit_i386.pod
branches/kill_jit/docs/jit.pod
branches/kill_jit/docs/native_exec.pod
Modified:
branches/kill_jit/docs/book/draft/appc_command_line_options.pod
branches/kill_jit/docs/debug.pod
branches/kill_jit/docs/dev/events.pod
branches/kill_jit/docs/parrot.pod
branches/kill_jit/docs/porting_intro.pod
branches/kill_jit/docs/running.pod
branches/kill_jit/docs/tests.pod
Modified: branches/kill_jit/docs/book/draft/appc_command_line_options.pod
==============================================================================
--- branches/kill_jit/docs/book/draft/appc_command_line_options.pod Sat Sep 19 00:59:42 2009 (r41348)
+++ branches/kill_jit/docs/book/draft/appc_command_line_options.pod Sat Sep 19 01:15:51 2009 (r41349)
@@ -152,11 +152,6 @@
to check various optimizations when you run Parrot with the C<-Op>
switch.
-If the extension is F<.o> or equivalent, Parrot generates an object
-file from the JITed program code, which can be used to create a
-standalone executable program. This isn't available on all platforms
-yet; see F<PLATFORMS> for which platforms support this.
-
=item -r,--run-pbc
Immediately execute bytecode. This is the default unless C<-o> is
@@ -269,31 +264,14 @@
Run the I<computed goto core> (CGoto).
-=item -R jit
-
-Run with the I<JIT core> if available.
-
=item -R cgp
Run with the I<CGoto-Prederefed> core.
-=item -R cgp-jit
-
-Run with the I<CGoto-Prederefed with jit> core.
-
=item -R switch
Run with the I<Switched core>.
-=item -R switch-jit
-
-Run with the I<Switched core with jit>.
-
-=item -R exec
-
-Run with the I<exec core>
-(uses JIT at compile time to generate native code)
-
=item -R gcdebug
Performs a full GC run before every op dispatch
Modified: branches/kill_jit/docs/debug.pod
==============================================================================
--- branches/kill_jit/docs/debug.pod Sat Sep 19 00:59:42 2009 (r41348)
+++ branches/kill_jit/docs/debug.pod Sat Sep 19 01:15:51 2009 (r41349)
@@ -80,76 +80,6 @@
One possible tool is C<parrot_debugger>, the Parrot Debugger.
See F<docs/debugger.pod> for details on it.
-=head2 stabs
-
-If you are running on a jit-capable machine, you can also try using C<gdb> by
-having the JIT compiler generate C<stabs> metadata and then stepping through
-the code with C<gdb> as if it were any other language.
-
-To use this, you'll want to use C<parrot> to generate your bytecode (.pbc
-file). It is not strictly necessary, but you'll get more information into the
-bytecode this way.
-
-Let's say your file is named C<test.pasm>. (Note: these instructions will also
-work if you use C<test.pir> everywhere C<test.pasm> occurs.)
-
-Step 1: Generate the .pbc file with extra debugging information.
-
- shell> parrot -d -o test.pbc test.pasm
-
-Step 2: Start up C<parrot> under C<gdb>
-
- % gdb parrot
-
-or
-
- % emacs &
- (in emacs) M-x gdb
- (in emacs) type "parrot" so it says "gdb parrot"
-
-Step 3: Set a breakpoint on runops_jit
-
- gdb> b runops_jit
-
-Step 4: Run your program under C<gdb> with JIT and debugging on
-
- gdb> run -R jit -D4 test.pbc
-
-Step 5: C<gdb> will stop at the beginning of runops_jit. Step through the lines
-until just before the JITed code is executed (the line will be something like
-C<(jit_code)(interpreter,pc)>.
-
- gdb> n
- gdb> n
- .
- .
- .
-
-Step 6: load in the debugging information from the symbol file that the jit
-just generated.
-
- gdb> add-symbol-file test.o 0
-
-Step 7: Step into the JITed code
-
- gdb> s
-
-At this point, you can step through the instructions, or print out the
-various Parrot registers. FIXME: C<gdb> will know about I0-I31,
-N0-N31, S0-S31, and P0-P31.
-
-
-WARNING: Stepping too far
-
-One thing to watch out for is that C<gdb> gets confused when attempting to step
-over certain instructions. The only ones that I have noticed having problems is
-keyed operations. With my version of C<gdb>, if I do 'n' to step over the
-instruction, C<gdb> will start running and only stop when the entire parrot
-program has finished. To work around this, do 'si' twice just before executing
-any keyed op. For some reason, C<gdb> can then figure out when it's supposed to
-stop next. If you know of a better technique, please let the mailing list know
-(C<parrot-dev at lists.parrot.org>).
-
=head1 PIR CODE GENERATION
The C<parrot> binary has a bunch of debugging flags for spewing out information
Modified: branches/kill_jit/docs/dev/events.pod
==============================================================================
--- branches/kill_jit/docs/dev/events.pod Sat Sep 19 00:59:42 2009 (r41348)
+++ branches/kill_jit/docs/dev/events.pod Sat Sep 19 01:15:51 2009 (r41349)
@@ -82,15 +82,13 @@
handler replaces backward branches in the opcode image with the
B<check_events__> opcode.
-The JIT core doesn't handle events yet.
-
After all events are popped off and handled, the opcode dispatch table is
restored to its original, and the B<check_events__> reexecutes the same
instruction again, which is now the real one and thus normal execution flow
continues.
This scheme has zero overhead in the absence of scheduled events for all cores
-except switched and JIT.
+except switched.
=head1 Missing
Deleted: branches/kill_jit/docs/dev/jit_i386.pod
==============================================================================
--- branches/kill_jit/docs/dev/jit_i386.pod Sat Sep 19 01:15:51 2009 (r41348)
+++ /dev/null 00:00:00 1970 (deleted)
@@ -1,299 +0,0 @@
-# Copyright (C) 2001-2006, Parrot Foundation.
-# $Id$
-
-=head1 NAME
-
-docs/dev/jit_i386.pod - Parrot JIT (i386/gcc)
-
-=head1 ABSTRACT
-
-This PDD describes the i386 gcc JIT implementation.
-
-=head1 DESCRIPTION
-
-JIT i386/gcc is a combination of unrolled assembly instructions and the
-Computed Goto Predereferenced (CGP) run loop. For branch instructions the
-function implementation in the standard core is called.
-
-Another difference of JIT/i386 is that most vtable functions are JITed
-instructions which use register mappings.
-
-For a better understanding of the control flow between these basically 3 run
-loop cores, an example shows the gory details.
-
-=head1 EXAMPLE
-
-Given the following PASM program, the righthand three columns show where each
-opcode gets executed:
-
- PASM JIT ops Normal CGP ops
-
-=begin PASM
- # (call cgp_core) (jmp back)
-
- set I0, 10 # set_i_ic
- print I0 # (call) print_i
- print "\n" # print_sc
- new P1, 'ResizableIntegerArray'
- local_branch P0, inc # (call) local_branch_p_ic cpu_ret
- end # (jmp) HALT end (ret)
- # end (ret)
- inc:
- inc I0 # inc_i
- new P0, 'String' # new_p_sc
- set P0, I0 # set_p_i
- print P0 # (call) print_p
- print "\n" # print_sc
- local_return P1 # (call) local_return_p cpu_ret
-
-=end PASM
-
-=head2 Startup sequence
-
-In B<runops_jit> a prederefed copy of the opcode stream is built by
-B<init_prederef>. Then B<build_asm> generates the assembler code sequence as
-usual. This generated code (shown as B<runops_jit> in B<ddd>) is then executed.
-
-Generate minimal stack frame, save %ebx
-
- 0x812c510 <jit_func>: push %ebp
- 0x812c511 <jit_func+1>: mov %esp,%ebp
- 0x812c513 <jit_func+3>: push %ebx
-
-Get the program counter to %ebx
-
- 0x812c514 <jit_func+4>: mov 0xc(%ebp),%ebx
-
-Push B<interpreter> and B<(opcode_t*) 1> and call B<cgp_core>
-
- 0x812c517 <jit_func+7>: push $0x8113db8
- 0x812c51c <jit_func+12>: push $0x1
- 0x812c521 <jit_func+17>: mov $0x1,%eax
- 0x812c526 <jit_func+22>: call 0x80b5830 <cgp_core>
-
-In B<cgp_core> all callee saved registers are saved.
-
- 0x80b5830 <cgp_core>: push %ebp
- 0x80b5831 <cgp_core+1>: mov %esp,%ebp
- 0x80b5833 <cgp_core+3>: sub $0xdc,%esp
- 0x80b5839 <cgp_core+9>: lea 0x8(%ebp),%eax
- 0x80b583c <cgp_core+12>: push %edi
- 0x80b583d <cgp_core+13>: push %esi
- 0x80b583e <cgp_core+14>: push %ebx
-
-In B<%eax> the init flag is set to B<-1>
-
- 0x80b583f <cgp_core+15>: mov %eax,0xfffffff
-
-The parameter B<*cur_op> (the program counter) is put into B<%esi> and ...
-
- 0x80b5842 <cgp_core+18>: mov 0x8(%ebp),%esi
- 0x80b5845 <cgp_core+21>: test %esi,%esi
- 0x80b5847 <cgp_core+23>: jne 0x80b5853 <cgp_core+35>
- 0x80b5849 <cgp_core+25>: mov $0x810ca60,%eax
- 0x80b584e <cgp_core+30>: jmp 0x80bb470 <cgp_core+23616>
-
-... compared to B<1>
-
- 0x80b5853 <cgp_core+35>: cmp $0x1,%esi
- 0x80b5856 <cgp_core+38>: jne 0x80b5860 <cgp_core+48>
-
-If true, the program jumps to the return address of above function call, i.e.
-it jumps back again to JIT code.
-
- 0x80b5858 <cgp_core+40>: jmp *0x4(%ebp)
-
-Back again in JIT code, the init flag is checked
-
- 0x812c52b <jit_func+27>: test %eax,%eax
- 0x812c52d <jit_func+29>: jne 0x812c536 <jit_func+38>
-
-... and if zero, the function would be left.
-
- [ 0x812c52f <jit_func+31>: pop %ebx ]
- [ 0x812c531 <jit_func+33>: mov %ebp,%esp ]
- [ 0x812c533 <jit_func+35>: pop %ebp ]
- [ 0x812c535 <jit_func+37>: ret ]
-
-When coming from the init sequence, program flow continues by checking the
-B<resume_offset> and jumping to the desired instruction
-
- 0x812c536 <jit_func+38>: mov %ebx,%eax
- 0x812c538 <jit_func+40>: sub $0x400140c0,%eax
- 0x812c53e <jit_func+46>: mov $0x812c4a8,%edx
- 0x812c543 <jit_func+51>: jmp *(%edx,%eax,1)
-
-B<set I0, 10> and save_registers
-
- 0x812c546 <jit_func+54>: mov $0xa,%ebx
- 0x812c54b <jit_func+59>: mov %ebx,0x8113db8
-
-Now non-JITed code follows -- get the address from the prederefed op_func_table
-and call it:
-
- 0x812c551 <jit_func+65>: mov $0x812ac0c,%esi
- 0x812c556 <jit_func+70>: call *(%esi)
-
- inline op print(in INT) {
- printf(INTVAL_FMT, (INTVAL)$1);
- goto NEXT();
- }
-
-where the B<goto NEXT()> is a simple:
-
- 0x80b5b49 <cgp_core+793>: jmp *(%esi)
-
- op print(in STR) {
- ...
- goto NEXT();
- }
-
-As the last instruction of the non-JITed code sequence is a branch, this is not
-executed in CGP, but the opcode:
-
- inline op cpu_ret() {
- #ifdef __GNUC__
- # ifdef I386
- asm("ret")
-
-is executed. This opcode is patched into the prederefed code stream by
-Parrot_jit_normal_op at the end of a non-JITed code sequence. This returns to
-JIT code again, where the next instruction gets called as a function in the
-standard core ...
-
- 0x812c558 <jit_func+72>: push $0x8113db8
- 0x812c55d <jit_func+77>: push $0x400140dc
- 0x812c562 <jit_func+82>: call 0x805be60 <Parrot_bsr_ic>
- 0x812c567 <jit_func+87>: add $0x8,%esp
-
-... and from the return result in B<%eax>, the new code position in JIT is
-calculated and gets jumped to:
-
- 0x812c56a <jit_func+90>: sub $0x400140c0,%eax
- 0x812c570 <jit_func+96>: mov $0x812c4a8,%edx
- 0x812c575 <jit_func+101>: jmp *(%edx,%eax,1)
-
-Now in the subroutine B<inc>:
-
- 0x812c580 <jit_func+112>: mov 0x8113db8,%ebx
- 0x812c586 <jit_func+118>: inc %ebx
-
-Save register and arguments and call B<pmc_new_noinit>:
-
- 0x812c587 <jit_func+119>: push %edx
- 0x812c588 <jit_func+120>: push $0x11
- 0x812c58d <jit_func+125>: push $0x8113db8
- 0x812c592 <jit_func+130>: call 0x806fc60 <pmc_new_noinit>
-
-put the PMC* into Parrot's register:
-
- 0x812c597 <jit_func+135>: mov %eax,0x8113fb8
-
-and prepare arguments for a VTABLE call:
-
- 0x812c59d <jit_func+141>: push %eax
- 0x812c59e <jit_func+142>: push $0x8113db8
- 0x812c5a3 <jit_func+147>: mov 0x10(%eax),%eax
- 0x812c5a6 <jit_func+150>: call *0x18(%eax)
- 0x812c5a9 <jit_func+153>: add $0x10,%esp
- 0x812c5ac <jit_func+156>: pop %edx
-
-and another one:
-
- 0x812c5ae <jit_func+158>: push %edx
-
-Here, with the mapped register in B<%ebx>, push B<I0>, the PMC and the
-interpreter:
-
- 0x812c5af <jit_func+159>: push %ebx
- 0x812c5b0 <jit_func+160>: mov 0x8113fb8,%eax
- 0x812c5b6 <jit_func+166>: push %eax
- 0x812c5b7 <jit_func+167>: push $0x8113db8
-
-and call the vtable:
-
- 0x812c5bc <jit_func+172>: mov 0x10(%eax),%eax
- 0x812c5bf <jit_func+175>: call *0xdc(%eax)
- 0x812c5c5 <jit_func+181>: add $0xc,%esp
- 0x812c5c8 <jit_func+184>: pop %edx
-
-As this ends the JITed section, used registers are saved back to Parrot's
-register:
-
- 0x812c5ca <jit_func+186>: mov %ebx,0x8113db8
-
-and again the code in B<cgp_core> gets called:
-
- 0x812c5d0 <jit_func+192>: mov $0x812ac48,%esi
- 0x812c5d5 <jit_func+197>: call *(%esi)
-
-which after executing the B<print> returns back here in JIT, where the B<ret>
-is called:
-
- 0x812c5d7 <jit_func+199>: push $0x8113db8
- 0x812c5dc <jit_func+204>: push $0x40014118
- 0x812c5e1 <jit_func+209>: call 0x805d5e0 <Parrot_ret>
- 0x812c5e6 <jit_func+214>: add $0x8,%esp
-
-From the returned PC a JIT address is calculated, which gets executed:
-
- 0x812c5e9 <jit_func+217>: sub $0x400140c0,%eax
- 0x812c5ef <jit_func+223>: mov $0x812c4a8,%edx
- 0x812c5f4 <jit_func+228>: jmp *(%edx,%eax,1)
-
-Now at the B<end> opcode, the CGP code for HALT() gets jumped to:
-
- 0x812c578 <jit_func+104>: mov $0x80b5877,%esi
- 0x812c57d <jit_func+109>: jmp *%esi
-
-which is:
-
- inline op end() {
- HALT();
- }
-
-or, set return result:
-
- 0x80b8b6f <cgp_core+13119>: xor %eax,%eax
- ...
-
-and clean up stack frame and ret:
-
- 0x80bb470 <cgp_core+23616>: lea 0xffffff18(%ebp),%esp
- 0x80bb476 <cgp_core+23622>: pop %ebx
- 0x80bb477 <cgp_core+23623>: pop %esi
- 0x80bb478 <cgp_core+23624>: pop %edi
- 0x80bb479 <cgp_core+23625>: mov %ebp,%esp
- 0x80bb47b <cgp_core+23627>: pop %ebp
- 0x80bb47c <cgp_core+23628>: ret
-
-This returns after the position where B<cgp_core> was called during the init
-sequence, but now the return value B<%eax> is zero and the..
-
- 0x812c52b <jit_func+27>: test %eax,%eax
- 0x812c52d <jit_func+29>: jne 0x812c536 <jit_func+38>
- 0x812c52f <jit_func+31>: pop %ebx
- 0x812c531 <jit_func+33>: mov %ebp,%esp
- 0x812c533 <jit_func+35>: pop %ebp
- 0x812c535 <jit_func+37>: ret
-
-... whole story ends here, we are back again in B<runops_jit>.
-
-So this is rather simple once it gets going.
-
-=head1 BUGS
-
-The floating point registers do not get saved to Parrot before vtable calls.
-This assumes that external routines preserve the FP stack pointer and don't use
-more the 4 floating point registers at once.
-
-=head1 AUTHOR
-
-Leopold Toetsch C<lt at toetsch.at>
-
-=head1 VERSION
-
-=head2 CURRENT
-
-14.02.2003 by Leopold Toetsch
-
Deleted: branches/kill_jit/docs/jit.pod
==============================================================================
--- branches/kill_jit/docs/jit.pod Sat Sep 19 01:15:51 2009 (r41348)
+++ /dev/null 00:00:00 1970 (deleted)
@@ -1,587 +0,0 @@
-# Copyright (C) 2001-2006, Parrot Foundation.
-# $Id$
-
-=head1 NAME
-
-docs/jit.pod - Parrot JIT Subsystem
-
-=head1 ABSTRACT
-
-This PDD describes the Parrot Just In Time compilation subsystem.
-
-=head1 DESCRIPTION
-
-The Just In Time, or JIT, subsystem converts a bytecode file to native machine
-code instructions and executes the generated instruction sequence directly.
-
-=head1 IMPLEMENTATION
-
-Currently works on B<ALPHA>, B<Arm>, B<Intel x86>, B<PPC>, and B<SPARC version
-8> processor systems, on most operating systems. Currently only 32-bit INTVALs
-are supported.
-
-The initial step in generating native code is to invoke B<Parrot_jit_begin>,
-which generally provides architecture specific preamble code. For each parrot
-opcode in the bytecode, either a generic or opcode specific sequence of native
-code is generated. The F<.jit> files provide functions that generate native
-code for specific opcode functions, for a given instruction set architecture.
-If a function is not provided for a specific opcode, a generic sequence of
-native code is output which calls the interpreter C function that implements
-the opcode. Such opcode are handled by B<Parrot_jit_normal_op>.
-
-If the opcode can cause a control flow change, as in the case of a branch or
-call opcode, an extended or modified version of this generic code is used that
-tracks changes in the bytecode program counter with changes in the hardware
-program counter. This type of opcode is handled by B<Parrot_jit_cpcf_op>.
-
-While generating native code, certain offsets and absolute addresses may not be
-available. This occurs with forward opcode branches, as the native code
-corresponding to the branch target has not yet been generated. On some
-platforms, function calls are performed using program-counter relative
-addresses. Since the location of the buffer holding the native code may move
-as code is generated (due to growing of the buffer), these relative addresses
-may only be calculated once the buffer is guaranteed to no longer move. To
-handle these instances, the JIT subsystem uses "fixups", which record locations
-in native code where adjustments to the native code are required.
-
-=head1 FILES
-
-=over 4
-
-=item jit/${jitcpuarch}/jit_emit.h
-
-This file defines B<Parrot_jit_begin>, B<Parrot_jit_dofixup>,
-B<Parrot_jit_normal_op>, B<Parrot_jit_cpcf_op>, B<Parrot_jit_restart_op> and
-optionally B<Parrot_jit_vtable*_op>. In addition, this file defines the macros
-and static functions used in F<.jit> files to produce binary representations of
-native instructions.
-
-For moving registers from processor to parrot and vice versa, the
-B<Parrot_jit_emit_mov*> functions have to be implemented.
-
-=item jit/${jitcpuarch}/core.jit
-
-The functions to generate native code for core parrot opcodes are specified
-here. To simplify the maintenance of these functions, they are specified in a
-format that is pre-processed by F<jit2c.pl> to produce a valid C source file,
-F<jit_cpu.c>. See L<Format of .jit Files> below.
-
-=item src/jit.h
-
-This file contains definitions of generic structures used by the JIT subsystem.
-
-The B<op_jit> array of B<jit_fn_info_t> structures, provides for each opcode, a
-pointer to the function that generates native code for the opcode, whether the
-generic B<Parrot_jit_normal_op> or B<Parrot_jit_cpcf_op> functions or an opcode
-specific function. B<Parrot_jit_restart_op> is like B<Parrot_jit_cpcf_op> with
-the addition to check for a zero program counter. The B<Parrot_jit_vtable*_op>
-functions are defined as B<Parrot_jit_normal_op> or B<Parrot_jit_cpcf_op> and
-may be implemented to do native vtable calls (s. F<jit/i386/jit_emit.h> for an
-example).
-
-The B<Parrot_jit_fixup> structure records the offset in native code where a
-fixup must be applied, the type of fixup required and the specific information
-needed to perform the parameters of the fixup. Currently, a fixup parameter is
-either an B<opcode_t> value or a function pointer.
-
-The B<Parrot_jit_info> structure holds data used while producing and executing
-native code. An important piece of data in this structure is the B<op_map>
-array, which maps from opcode addresses to native code addresses.
-
-=item src/jit.c
-
-B<parrot_build_asm>() is the main routine of the code generator, which loops
-over the parrot bytecode, calling the code generating routines for each opcode
-while filling in the B<op_map> array. This array is used by the JIT subsystem
-to perform certain types of fixups on native code, as well as by the native
-code itself to convert bytecode program counters values (opcode_t *'s) to
-hardware program counter values.
-
-The bytecode is considered an array of B<opcode_t> sized elements, with
-parallel entries in B<op_map>. B<op_map> is initially populated with the
-offsets into the native code corresponding to the opcodes in the bytecode. Once
-code generation is complete and fixups have been applied, the native code
-offsets are converted to absolute addresses. This trades the low up-front cost
-of converting all offsets once, for the unknown cost of repeatedly converting
-these offsets while executing native code.
-
-See F<src/jit/skeleton/jit_emit.h> for details.
-
-=item tools/build/jit2c.pl
-
-Preprocesses the .jit files to produce F<jit_cpu.c>.
-
-=back
-
-=head1 Defines in jit_emit.h
-
-The architecture specific F<jit_emit.h> file communicates some defines and
-tables with F<jit.c> and F<languages/imcc/imc.c>. The structure of the file and
-the defines must therefore follow a specific syntax.
-
-=head2 Overall structure
-
- #if JIT_EMIT
-
- ... emit code
-
- #else
-
- ... defines
- static const jit_arch_info arch_info = {
- ... initialization of maps
- ... and possibly private static functions
- }
-
- #endif
-
-See F<src/jit/skeleton/jit_emit.h> for a more detailed explanation.
-
-=head2 Defines
-
-XXX most are moved into C<jit_arch_info> now.
-
-=over 4
-
-=item INT_REGISTERS_TO_MAP
-
-This is the amount of integer registers to be mapped to processor registers.
-The corresponding B<intval_map[]> has to have exactly this amount of register
-numbers. A register with the value of zero can not be in the list.
-
-=item FLOAT_REGISTERS_TO_MAP
-
-When this is defined, it works like above for floating point registers.
-
-=item PRESERVED_INT_REGS
-
-When this is defined, it's the amount of integer registers, that are preserved
-over function calls. These preserved registers have to be first in
-B<intval_map>. When this is not defined, it is assumed that B<all> registers
-are preserved over function calls.
-
-=item PRESERVED_FLOAT_REGS
-
-Same for floating point registers.
-
-=item jit_emit_noop(pc)
-
-=item JUMP_ALIGN
-
-If these are defined, B<JUMP_ALIGN> should be a small number stating the
-desired alignment of jump targets is B<1 << JUMP_ALIGN>. The B<jit_emit_noop>
-gets called with the unaligned B<pc> repeatedly, until the B<pc> has the
-desired alignment. So the function can either emit a one byte B<noop>
-instruction, or a B<noop> like instruction (sequence) with the desired size, to
-achieve the necessary padding. The emitted code must not have any side
-effects.
-
-=item ALLOCATE_REGISTERS_PER_SECTION
-
-Normally F<jit.c> does register allocation per section, but there is a somewhat
-experimental feature, to allocate registers per basic block.
-
-=item MAP
-
-Jit code generated by the F<imcc> JIT optimizer used negative numbers for
-mapped registers and positive numbers for non mapped parrot registers. To use
-this feature, the definition of mapped registers can be redefined like so:
-
- #define MAP(i) OMAP(i)
- #undef MAP
- #define MAP(i) (i) >= 0 ? 0 : OMAP(i)
-
-=item Parrot_jit_emit_get_base_reg_no(pc)
-
-This macro should return the register number of the register
-base pointer.
-
-=back
-
-See F<src/jit/i386/jit_emit.h> for actual usage of these defines.
-
-=head1 Format of .jit Files
-
-Jit files are interpreted as follows:
-
-=over 4
-
-=item I<op-name> { \n I<body> \n }
-
-Where I<op-name> is the name of the Parrot opcode, and I<body> consists of C
-syntax code which may contain any of the identifiers listed in the following
-section.
-
-The closing curly brace has to be in the first column.
-
-=item Comment lines
-
-Comments are marked with a I<;> in the first column. These and empty lines are
-ignored.
-
-=item Identifiers
-
-In general, prefixing an identifier with I<&> yields an address. The I<*>
-prefix specifies a value. Since Parrot register values vary during code
-execution, their values can not be obtained through identifier substitution
-alone, therefore offsets are used for accessing registers.
-
-To obtain register offsets, a set of macros exists, that have C<OFFS> in
-their names:
-
-B<REG_OFFS_INT(reg_no)> ...
-
-B<ROFFS_INT(n)> ...
-
-B<INT_CONST[n]>
-
-Gets replaced by the C<INTVAL> constant specified in the I<n>th argument.
-
-B<NUM_CONST[n]>
-
-Gets replaced by the C<FLOATVAL> constant specified in the I<n>th argument.
-
-B<MAP[n]>
-
-The I<n>th integer or floating processor register, mapped in this section.
-
-Note: The register with the physical number zero can not be mapped.
-
-=begin unimp
-
-B<STRING_CONST_strstart[n]>
-
-Gets replaced by C<strstart> of the C<STRING> constant specified in the I<n>th
-argument.
-
-B<STRING_CONST_buflen[n]>
-
-Gets replaced by C<buflen> of the C<STRING> constant specified in the I<n>th
-argument.
-
-B<STRING_CONST_flags[n]>
-
-Gets replaced by C<flags> of the C<STRING> constant specified in the I<n>th
-argument.
-
-B<STRING_CONST_strlen[n]>
-
-Gets replaced by C<strlen> of the C<STRING> constant specified in the I<n>th
-argument.
-
-B<STRING_CONST_encoding[n]>
-
-Gets replaced by C<encoding> of the C<STRING> constant specified in the I<n>th
-argument.
-
-B<STRING_CONST_type[n]>
-
-Gets replaced by C<type> of the C<STRING> constant specified in the I<n>th
-argument.
-
-B<STRING_CONST_language[n]>
-
-Gets replaced by C<language> of the C<STRING> constant specified in the I<n>th
-argument.
-
-=end unimp
-
-B<NATIVECODE>
-
-Gets replaced by the current native program counter.
-
-B<*CUR_OPCODE[n]>
-
-Gets replaced by the address of the current opcode in the Parrot bytecode.
-
-B<ISRn> B<FSRn>
-
-The I<n>th integer or floating point scratch register.
-
-
-=item B<TEMPLATE> I<template-name> { \n I<body> \n }
-
-Defines a template for similar functions, e.g. all the binary ops taking three
-variable parameters.
-
-=item I<template-name> I<perl-subst> ...
-
-Take a template and do all substitutions to generate the implementation for
-this jit function.
-
-Example:
-
- TEMPLATE Parrot_set_x_ic {
- if (MAP[1]) {
- jit_emit_mov_ri<_N>(NATIVECODE, MAP[1], <typ>_CONST[2]);
- }
- else {
- jit_emit_mov_mi<_N>(NATIVECODE, &INT_REG[1], <typ>_CONST[2]);
- }
- }
-
- Parrot_set_i_ic {
- Parrot_set_x_ic s/<_N>/_i/ s/<typ>/*INT/
- }
-
- Parrot_set_n_ic {
- Parrot_set_x_ic s/<_N>/_ni/ s/<typ>/&INT/ s/INT_R/NUM_R/
- }
-
-The jit function B<Parrot_set_i_ic> is based on the template
-B<Parrot_set_x_ic>, the I<s/x/y/> are substitutions on the template body, to
-generate the actual function body. These substitutions are done before the
-other substitutions.
-
-s. F<jit/i386/core.jit> for more.
-
-=back
-
-=head2 Naming convention for jit_emit functions
-
-To make it easier to share F<core.jit> files between machines of similar
-architecture, the jit_emit functions B<should> follow this syntax:
-
-jit_emit_I<<op>>_I<<args>>_I<<type>>
-
-=over 4
-
-=item I<<op>>
-
-This is the operation like B<mov>, B<add> or B<bxor>. In normal cases this is
-the PASM name of the op.
-
-=item I<<args>>
-
-B<args> specify the arguments of the function in the PASM sequence B<dest>,
-B<source> ... The B<args> consist of one letter per argument:
-
-=over 4
-
-=item B<r>
-
-A mapped processor register.
-
-=item B<m>
-
-A memory operand, the address of the parrot register.
-
-=item B<i>
-
-An immediate operand, i.e. an integer constant.
-
-=back
-
-=item I<<type>>
-
-Specifies if this operation works on integer or floating point arguments. If
-all arguments are of the same type, only one type specifier is needed.
-
-=over 4
-
-=item B<i>
-
-An integer argument
-
-=item B<n>
-
-A float argument.
-
-=back
-
-Examples:
-
-=over 4
-
-=item B<jit_emit_sub_rm_i>
-
-Subtract integer at memory from integer processor register.
-
-=item B<jit_emit_mov_ri_ni>
-
-Move integer constant (immediate) to floating point register.
-
-=back
-
-=back
-
-=head1 ALPHA Notes
-
-The access to Parrot registers is done relative to C<$6>, all other memory
-access is done relative to C<$27>, to access float constants relative to C<$7>
-so you must preside the instruction with I<ldah $7,0($27)>.
-
-=head1 i386 Notes
-
-Only 32 bit INTVALs are supported. Long double FLOATVALs are ok.
-
-There are four mapped integer registers B<%edi>, B<%esi>, B<%ecx>, and B<%edx>.
-The first 2 of these are callee saved, they preserve their value around extern
-function calls.
-
-Four floating point operations the registers B<ST1> ... B<ST4> are mapped and
-considered as preserved over function calls.
-
-The register C<%ebx> holds the register frame pointer.
-
-=head1 EXAMPLE
-
-Let's see how this works:
-
-B<Parrot Assembly:>
-
- set I0,8
- set I2,I0
- print I2
- end
-
-B<Parrot Bytecode:> (only the bytecode segment is shown)
-
- +--------------------------------------+
- | 73 | 0 | 8 | 72 | 2 | 0 | 21 | 2 | 0 |
- +-|------------|------------|--------|-+
- | | | |
- | | | +----------- end (no arguments)
- | | +-------------------- print_i (1 argument)
- | +--------------------------------- set_i_i (2 arguments)
- +---------------------------------------------- set_i_ic (2 arguments)
-
-Please note that the opcode numbers used might have already changed. Also
-generated assembly code might be different.
-
-B<Intel x86 assembly version of the Parrot ops:>
-
-B<Parrot_jit_begin>
-
- 0x817ddd0 <jit_func>: push %ebp
- 0x817ddd1 <jit_func+1>: mov %esp,%ebp
- 0x817ddd3 <jit_func+3>: push %ebx
- 0x817ddd4 <jit_func+4>: push %esi
- 0x817ddd5 <jit_func+5>: push %edi
-
- normal function header till here, now push interpreter
-
- 0x817ddd6 <jit_func+6>: push $0x8164420
-
- get jit function table to %ebp and
- jump to first instruction
-
- 0x817dddb <jit_func+11>: mov 0xc(%ebp),%eax
- 0x817ddde <jit_func+14>: mov $0x81773f0,%ebp
- 0x817dde3 <jit_func+19>: sub $0x81774a8,%eax
- 0x817dde9 <jit_func+25>: jmp *%ds:0x0(%ebp,%eax,1)
-
-B<set_i_ic>
-
- 0x817ddee <jit_func+30>: mov $0x8,%edi
-
-B<set_i_i>
-
- 0x817ddf3 <jit_func+35>: mov %edi,%ebx
-
-B<Parrot_jit_save_registers>
-
- 0x817ddf5 <jit_func+37>: mov %edi,0x8164420
- 0x817ddfb <jit_func+43>: mov %ebx,0x8164428
-
-B<Parrot_jit_normal_op>
-
- 0x817de01 <jit_func+49>: push $0x81774c0
- 0x817de06 <jit_func+54>: call 0x804be00 <Parrot_print_i>
- 0x817de0b <jit_func+59>: add $0x4,%esp
-
-B<Parrot_jit_end>
-
- 0x817de0e <jit_func+62>: add $0x4,%esp
- 0x817de14 <jit_func+68>: pop %edi
- 0x817de16 <jit_func+70>: pop %ebx
- 0x817de18 <jit_func+72>: pop %esi
- 0x817de1a <jit_func+74>: pop %ebp
- 0x817de1c <jit_func+76>: ret
-
-Please note the reverse argument direction. PASM and JIT notations use
-I<dest,src,src>, while F<gdb> and the internal macros in F<jit_emit.h> have
-I<src,dest>.
-
-=head1 Debugging
-
-Above listing was generated by F<gdb>, the GNU debugger, with a little help
-from Parrot_jit_debug, which generates a symbol file in I<stabs> format, s.
-B<info stabs> for more (or less :-()
-
-The following script calls F<ddd> (the graphic debugger fronted) and attaches
-the symbol file, after it got built in F<parrot_build_asm>.
-
- # dddp
- # run ddd parrot with given file
- # gdb confirmations should be off
- parrot -o $1.pbc -d1 $1.pasm
- echo "b runops_jit
- r -D4 -R jit $1.pbc
- n
- add-symbol-file $1.o 0
- s
- " > .ddd
-
- ddd --command .ddd parrot &
-
-Run this with e.g. I<dddp t/op/jit_2>, then turn on the register status,
-I<step> or I<nexti> through the source, or set break points as with any other
-language.
-
-You can examine parrot registers via the debugger or even set them and you can
-always step into external opcode and look at I<*interpreter>.
-
-The tests F<t/op/jit*.t> have some test cases for testing register allocation.
-These tests are written for a mapping of 4 processor registers. If your
-processor architecture has more mapped registers, reduce them to 4 and run
-these tests.
-
-=head2 Example for a debug session
-
- $ cat j.pasm
- set I0, 10
- set N1, 1.1
- set S2, "abc"
- print "\n"
- end
- $ dddp j
-
-(ddd shows above source code and assembly (startup code snipped):
-
- 0x815de46 <jit_func+30>: mov $0xa,%ebx
- 0x815de4b <jit_func+35>: fldl 0x81584c0
- 0x815de51 <jit_func+41>: fstp %st(2)
- 0x815de53 <jit_func+43>: mov %ebx,0x8158098
- 0x815de59 <jit_func+49>: fld %st(1)
- 0x815de5b <jit_func+51>: fstpl 0x8158120
- 0x815de61 <jit_func+57>: push $0x815cd90
- 0x815de66 <jit_func+62>: call 0x804db90 <Parrot_set_s_sc>
- 0x815de6b <jit_func+67>: add $0x4,%esp
- 0x815de6e <jit_func+70>: push $0x815cd9c
- 0x815de73 <jit_func+75>: call 0x804bcd0 <Parrot_print_sc>
- 0x815de78 <jit_func+80>: add $0x4,%esp
- 0x815de7b <jit_func+83>: add $0x4,%esp
- 0x815de81 <jit_func+89>: pop %edi
- 0x815de83 <jit_func+91>: pop %ebx
- 0x815de85 <jit_func+93>: pop %esi
- 0x815de87 <jit_func+95>: pop %ebp
- 0x815de89 <jit_func+97>: ret
- (gdb) n
- (gdb) n
- (gdb) n
- (gdb) p I0
- $1 = 10
- (gdb) p N1
- $2 = 1.1000000000000001
- (gdb) p *S2
- $3 = {bufstart = 0x815ad30, buflen = 15, flags = 336128, bufused =
- 3, strstart = 0x815ad30 "abc"}
- (gdb) p &I0
- $4 = (INTVAL *) 0x8158098
-
-XXX (p)rinting register contents like shown above is currently not supported.
-
-=head1 SEE ALSO
-
-F<docs/dev/jit_i386.pod>, F<jit/skeleton/jit_emit.h>
Deleted: branches/kill_jit/docs/native_exec.pod
==============================================================================
--- branches/kill_jit/docs/native_exec.pod Sat Sep 19 01:15:51 2009 (r41348)
+++ /dev/null 00:00:00 1970 (deleted)
@@ -1,77 +0,0 @@
-# Copyright (C) 2001-2004, Parrot Foundation.
-# $Id$
-
-=head1 NAME
-
-docs/native_exec.pod - Parrot Native Object Execution Subsystem
-
-=head1 Overview
-
-On supported platforms, Parrot can use the JIT subsystem to assemble a native
-executable binary from a Parrot program. This method wraps the VM runtime
-engine and a precompiled Parrot program into a single binary.
-
-=head1 Generating a native executable
-
-Generating a native executable is done in three steps: building a packfile,
-assembling a native object, and then linking the native executable.
-
-The packfile is generated in the standard way from .pir or .pasm source by IMCC.
-For a program in myprog.pasm:
-
- ./parrot -o myprog.pbc myprog.pasm
-
-This generates the myprog.pbc packfile. The native object is generated
-similarly:
-
- ./parrot -o myprog.o myprog.pbc
-
-This creates a native object called myprog.o. Assembly of the executable is
-done by the "exec" target in the root Makefile like so:
-
- make EXEC=myprog exec
-
-This generates the "myprog" executable, which runs equivalently to
-
- ./parrot -R jit myprog.pbc
-
-minus the time required to JIT-compile the bytecode.
-
-The "hello" target of the root Makefile demonstrates this method
-for a "Hello world" program.
-
-=head1 Details
-
-=head2 Platform support
-
-The exec subsystem is enabled if support is determined automatically by
-config/auto/jit.pl, or if the option --execcapable is explicitly specified to
-Configure.pl. The platform must support the JIT core, and some additional
-scaffold in the exec* sources must be provided. Implementation of such is
-beyond the scope of this document.
-
-=head2 Native object generation
-
-Native objects are generated by the "exec" run core. This core uses the JIT
-subsystem to compile a packfile to native instructions, then serializes it to
-the platform's native object format. This object is then loaded at runtime and
-executed using the normal JIT core.
-
-Unlike the standard cores (switch, computed goto, etc.) which are activated by
-command-line switch, the exec core is invoked by IMCC when the output file
-specified by the -o option has a .o extension. When creating a native object
-this way, IMCC requires that the input be a packfile. This process therefore
-must be performed in two steps, building the packfile and assembling the native
-object, as demonstrated above.
-
-=head2 Executable generation
-
-A native executable is generated by linking a native object against the parrot
-library and the loader in exec_start.c. The "exec" target in the root Makefile
-does this with the compile flags used to build parrot itself. Alternatively it
-may be done by hand, e.g.
-
- gcc -o myprog myprog.o src/exec_start.o blib/lib/libparrot.a
-
-Additional libraries may need to be included as appropriate for the platform.
-
Modified: branches/kill_jit/docs/parrot.pod
==============================================================================
--- branches/kill_jit/docs/parrot.pod Sat Sep 19 00:59:42 2009 (r41348)
+++ branches/kill_jit/docs/parrot.pod Sat Sep 19 01:15:51 2009 (r41349)
@@ -81,10 +81,6 @@
Describes the embedding subsystem in excruciating detail.
-=item F<jit.pod>
-
-A brief description of Parrot's Just-In-Time compiler.
-
=item F<memory_internals.pod>
An introduction to the Parrot GC subsystem
Modified: branches/kill_jit/docs/porting_intro.pod
==============================================================================
--- branches/kill_jit/docs/porting_intro.pod Sat Sep 19 00:59:42 2009 (r41348)
+++ branches/kill_jit/docs/porting_intro.pod Sat Sep 19 01:15:51 2009 (r41349)
@@ -46,71 +46,6 @@
=back
-=head1 JIT
-
-=head2 What it is
-
-Parrot contains a just-in-time compilation subsystem that compiles Parrot
-bytecode into native processor instructions just prior to execution,
-eliminating much of the overhead of bytecode interpretation.
-
-=head2 How to help
-
-Each unique processor target requires its own JIT engine. So far, engines have
-been implemented for DEC Alpha, ARM, Intel i386, SGI MIPS, PPC, and Sun4. If
-you know that your architecture is substantially similar to one of these,
-adding support may be possible with relatively little effort. Implementing a
-novel JIT core from scratch is a substantial undertaking.
-
-Also note that some changes may be required based on OS as well. (e.g.:
-OS X/i386 vs. Linux/i386; OS X/i386 doesn't currently work.)
-
-=head2 References
-
-=over 4
-
-=item * F<docs/jit.pod>
-
-=item * F<src/jit/$arch/*>
-
-=item * I<make testj>
-
-=item * F<t/op/jit.t>
-
-=back
-
-=head1 Native Exec
-
-=head2 What it is
-
-Parrot's "native exec" feature allows the integration of the parrot runtime and
-a Parrot program into a single precompiled binary, reducing program start-up
-cost and negating the need to package Parrot distinctly from an application.
-It's perl2exe/PerlApp/PAR for the Parrot generation.
-
-=head2 How to help
-
-The exec feature makes use of the JIT subsystem, and requires supporting code
-with knowledge of the operating system's native object format. This feature is
-only supported on JITable architectures (for now, just x86) running Linux,
-*BSD, or Darwin. An interested Parrot hacker with an eligible platform can
-contribute by submitting patches which emit exec objects in the OS's native
-object format (e.g., ELF, a.out, XCOFF).
-
-=head2 References
-
-=over 4
-
-=item * F<docs/native_exec.pod>
-
-=item * F<src/exec*.c>
-
-=item * F<include/parrot/exec*.h>
-
-=item * F<config/auto/jit.pl>
-
-=back
-
=head1 Threads
=head2 What it is
Modified: branches/kill_jit/docs/running.pod
==============================================================================
--- branches/kill_jit/docs/running.pod Sat Sep 19 00:59:42 2009 (r41348)
+++ branches/kill_jit/docs/running.pod Sat Sep 19 01:15:51 2009 (r41349)
@@ -137,7 +137,6 @@
slow, bounds bounds checking core (default)
cgoto computed goto core
cgp computed goto-predereferenced core
- exec exec core (uses JIT at compile time to generate native code)
fast fast core (no bounds checking, profiling, or tracing)
gcdebug performs a full GC run before every op dispatch (good for
debugging GC problems)
@@ -217,17 +216,6 @@
=head1 Generated files
-If JIT debugging is enabled (e.g. via C<--parrot-debug 04>), the
-following additional output files are generated:
-
- F<file.stabs.s> stabsfile for the program
- F<file.o> object file with debug information
- F<EVAL_n> source of C<compile> op number I<n>
- F<EVAL_n.stabs.s> stabsfile for this block
- F<EVAL_n.o> object file with debug information
-
-See F<docs/jit.pod> for further information.
-
=head1 About runcores
The runcore (or runloop) tells Parrot how to find the C code that implements
@@ -282,11 +270,6 @@
addresses. See "Predereferencing" in F<docs/glossary.pod> for a
fuller explanation.
-Finally, the JIT runcore uses the "slow" core, but also creates and
-jumps to JIT-compiled native code for supported opcodes. "cgp-jit"
-and "switched-jit" are variations that use the CGP or switched core
-but run JIT code when possible.
-
=head1 Operation table
Command Line Action Output
Modified: branches/kill_jit/docs/tests.pod
==============================================================================
--- branches/kill_jit/docs/tests.pod Sat Sep 19 00:59:42 2009 (r41348)
+++ branches/kill_jit/docs/tests.pod Sat Sep 19 01:15:51 2009 (r41349)
@@ -18,9 +18,6 @@
updated your code recently and tests began failing, go for a C<make
realclean> and recompile parrot before complaining.
-If your architecture supports JIT, you can test parrot JIT engine using C<make
-testj>. It works just like C<make test>, but uses the JIT engine when possible.
-
C<make languages-test> runs the test suite for most language implementations
in the languages directory.
More information about the parrot-commits
mailing list