On Wed, Feb 26, 2003 at 02:21:32AM +0100, Angel Faus wrote:
[snip lots of good stuff]
All this is obviously machine dependent: the code generated should only run in the machine it was compiled for. So we should always keep the original imc code in case we copy the pbc file to another machine.
Er, but doesn't that mean that imc code has now usurped the role of parrot byte code?
No. It's like another runtime option. Run "imcc -Oj the.pasm" and you get what you want, a differently optimized piece of JIT code, that might run faster then "imcc -j the.pasm".
And saying "imcc -Oj -o the.pbc the.pasm" should spit out the fastest bytecode possible, for your very machine.
I'm not sure what is a good answer here. But I thought that the intent of
parrot's bytecode was to be the same bytecode that runs everywhere.
Yep
... Which is slightly incompatible with compiling perl code to something that runs as fast as possible on the machine that you're both compiling and running on. (These two being the same machine most of the time).
At PBC level, imcc already has "-Op" which does parrot register renumbering (modulo NCI and such, where fixed registers are needed, and this is -- hmmm suboptimal then :) and imcc can write out CFG information in some machine independent form, i.e. at basic block level. But no processor specific load/store instructions and such.
This can help JIT optimizer to do the job faster, though it isn't that easy, because there are non JITed code sequences intersparsed.
I think some difficulties arise, when looking at, what imcc now is: It's the assemble.pl generating PBC files. But it's also parrot, it can run PBC files - and it's both - it can run PASM (or IMC) files - immediately. And the latter one can be always as fast as the $arch allows. Generating PBC doesn't have to use the same compile options - as you wouldn't use, when running "gcc -b machine".
Maybe we starting to get to the point of having imcc deliver parrot bytecode
if you want to be portable, and something approaching native machine code
if you want speed.
IMHO yes, the normal options produce a plain PBC file, more or less optimized at PASM level, the -Oj option is definitely a machine optimization option, which can run or will create a PBC that runs only on a machine with equally or less mapped registers and the same external (non JITted instructions) i.e. on the same $arch.
But the normal case is, that I compile the source for my machine and run it here - with all possible optimizations.
I never did do any cross compilation here. Shipping the source is enough. Plain PBC is still like an unoptimized executable running everywhere - not a machine specific cross compile EXE.
... Or maybe if you want the latter we save "fat" bytecode files, that contain IMC code, bytecode and JIT-food for one or more processors.
There is really no need for a fat PBC. Though - as already stated - I could imagine some cross compile capabilities for -Oj PBCs.
And is this all premature optimisation, give that we haven't got objects, exceptions, IO or a Z-code interpreter yet?
It is a different approach to JIT register allocation. The current optimizer allocates registers per JITed section, with no chance (IMHO) to reuse registers after a branch, because the optimizer lacks all the information to know, that this branch target will only be reached from here, and that the registers are the same, so finally knows, the savin/loading processor registers to memory could be avoided.
OTOH imcc has almost all this info already at hand (coming out of CFG/life information needed for allocating parrot regs from $temps). So the chance for generating faster code is there, IMHO.
Premature optimization - partly of course yes/no:
My copy here runs now all parrot tests except op/interp_2 (obvious, this compares traced instructions, where the -Oj inserted some register load/saves) and the pmc/nci tests, where just the fixed parameter/return result register are mess up - the "imcc calling conventions" thread has a proposal for this.
And yes: We don't have exceptions and threads yet. The other items, don't matter (IMHO).
But we will come to a point, where for certain languages, we will optimize P-registers, or mix them with I-regs, reusing same processor regs. :-)
Nicholas Clark
leo
