Nicholas Clark <[EMAIL PROTECTED]> writes: > 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? > > 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. 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). > > 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. 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.
Aren't there safety implications with 'fat' code? One could envisage a malicious fat PBC where the IMC code and the bytecode did different things... -- Piers
