I have checked in a first attempt to make parrot generate an executable. It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on NetBSD
For PPC (Darwin) it generates code correctly just for programs that use *only* fully jitted opcodes. It should work with or without JIT_CGP. After building parrot you should "make exec_start.o" that is used to start running the compiled code. Then you can use it like this: # ./test_main -o t.pbc This will generate exec_output.o (I know that -o must require an argument I just don't know which is the correct way to actually make the argument "visible" from insede the core, should I just add a pointer in the interpreter and a subroutine to embed.c? or what?) # cc -o <whatever> exec_output.o exec_start.o blib/lib/libparrot.a -lm -lutil (or whatever your system require) It's not finished, vtable and nci stuff is missing. This are some of the things I did in order to make this work: * Added an interpreter structure as a global variable. * Make all the opcodes in core_ops.c global, not static, I add a rellocation every time a non-JITted opcode is called and need the linker to know about this functions. * Put the program bytecode (the pbc) as part of the obj, as pbc2c.pl does since I need the address of the bytecode in the JITted code and in x86 (at least in BSD) the bytecode is the same than in the pbc, I know this might not be 100% correct since if a pbc generated at a 64bit architecture or with a different endianess will be unpacked differently and this won't work, but I'll look at this later. * Added the opcode_map too, this is need to make the restart and the not jitted opcodes that change the program control flow work, the real adresses are fixed at runtime, I'll see if I can do something to make the linker take care of this, I'm sure this is possible yet. * The constant table is also added and every time the bytecode unpacker need to add a constant this memory is used instead of allocating new memory. Now, every time the jit emits an instruction that has the address of a Parrot regiter, the interpreter, the bytecode or a constant I must add a rellocation at the exact address of the 4 bytes that will be the adress, for this I assume that the last 4 bytes of the emited instruction holds this address adding the rellocation at native_ptr - 4, but this is not correct for macros that emits more than 1 instruction (like the floating point ones) hence I made a horrible hack at jit2h.pl which change the displacement from -4 to, say, -6. Another way I see to make this is adding a list of macros with their displacement? (if the macro is not in the table it's -4) or what? Enjoy. Daniel Grunblatt.
