[snip] > > 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.
Seems to me it would be good if - mycode.pl -- my original code would be compiled into - mycode.pbc/imc -- platform neutral parrot bytecode with (as I sort of suggested a day ago) no limitations on what registers there are, no spilling code, as that comes next... In someways, this is what IMC code is right now. Although it might be nice if IMC were binary at this stage (for some feel-good-reason?). The current bytecode from parrot already has potential for slowing things down, and that's what worries me here. which when run on any system would generate - mycode.jit -- a platform specific thing with native compiled code And as a worst case, if a system didn't have a jit module would just run the mycode.pbc, albeit not very speedily. This gives the developer several choices: 1. He can hand out his original source (which would require the target to be able to compile, jit) 2. He can hand out a platform neutral pbc/imc of compiled code that can be compiled to full speed (which would require the target to be able to either jit or just run it.) 3. He can hand out a platform specific .jit (which would require the target to be able to run it.) I suspect most end users would be able to use #1 or #2. However for use on embedded systems where size is an issue, having #3 an option would be useful, as I suspect it would shrink the footprint of parrot somewhat. Just the thoughts of a future parrot user :) Hope they benefit someone. Cheers, Phil
