Nicholas Clark wrote:
On Thu, Jan 23, 2003 at 02:48:38PM -0800, Brent Dax wrote:I agree with the "roughly" bit, but I'd suggest ensuring that you putstruct Chunk { opcode_t type; opcode_t version; opcode_t size; void data[]; };
in enough bits to get data[] 64 bit aligned.
If there's a directory of some sort, it should record the type ID and
the offset to the beginning of the chunk.
Putting this together, and inserting an "Id" field above, would give alignment on a 64 bit boundary for data in PBC - assuming the strings, data, ... are also N*64 bit wide.
It might be useful for making "portable" fat bytecode.
As I stated, I changed all sizes/offsets to be opcode_t. Of course this breaks reading 32 bit PBC on machines with 64 bit opcode_t - but this was already broken before, e.g.:
header->magic = PackFile_fetch_op(self, cursor++);
If we want this portable, it probably should kook like
header->magic = PackFile_fetch_op(self, &cursor);
where the _fetch_xx has to advance the cursor by the PBC defined wordsize.
A _fetch_cstring and a _fetch_n_opcodes would also be handy. And for the latter, if the packfile is mmap()ed, it shouldn't fetch anything, but just set up the code pointer, advance the cursor, and remember, that the code_segment->code field should better not be freed at destroy time.
I'm thinking that register usage information from imcc could be of use to the JIT, as that would save it having to work out things again. So that probably needs a segment.
Yep. imcc does the whole CFG and life analysis, which JIT is doing again. At least basic blocks and register usage could be passed. Though register life range in JIT is different and depends on $arch. Calling (JIT) external functions ends a registers life, so it must be saved before calling and restored after.
Also some way of storing a cryptographic signature in the file, so that you could compile a parrot that automatically refuses to load code that isn't signed by you.
The palladium parrot :)
Juergen Boemmels wrote:
It might be even possible to dump the jitted code.
When you then are able to to get the same memory layout for a newly created interpreter, it might even run ;-)
So the JITted code contains lots of hard references to address in running interpreter? It's not just dependent on that particular binary's layout?
JIT/i386 does call parrot functions directly e.g. pmc_new_noinit or string_make, so these would need relocation - or probably slightly slower but simpler to handle a jump table. We (all? JIT $arch) have at least one register pointing to parrot data. Including a jump table there for used parrot functions would do it.
I guess in future once the normal JIT works, and we've got the pigs flying nicely then it would be possible to write a Not Just In Time compiler that saves out assembly code and relocation instructions. Bah. That's "parrot -o foo.o foo.pmc" isn't it?
*g*
Nicholas Clark
leo
