On Sat, Jan 12, 2002 at 10:26:37AM -0500, Dan Sugalski wrote: [on prederef going SEGV with the bsr opcode]
> I'm not going to worry too much about it for the moment, as I'm not sure > what the ultimate fate of the prederef stuff will be. If the JIT works out > well on most of our platforms, we may end up removing it. I agree that at this time it's pragmatic idea not to worry about the prederef. So maybe I should postpone the rest of this reply until much later. I can see that JIT is going to be far more useful on the <20% of platforms that >80% of parrot users will be using (it's more like 2% and 98%, isn't it? So effort is probably better spent on improving the JIT, or improving general optimisation. Also, it's not clear on typical code (MOPS isn't typical, as isn't Dhrystone) how much advantage prederef gives. [Define "typical". Yes, right :-) However, even knowing that it's impossible to define what is typical, I feel confident in saying that we don't have any typical code yet, because it's too early] Maybe I'm closing off too many roads, but my intuition says that while we can make the C compiler offer many permutations of INTVAL, NUMVAL and opcode size on a single CPU architecture, and compile to executables on architectures no-one here has access to (if we get our portability correct), the JIT is going to need different glue code for every CPU, and probably even on a single CPU different guts code for every INTVAL, NUMVAL, opcode size permutation. So assuming for "typical" (or is that "mythical") code prederef gets us some win over standard, it might well still be worth supporting (ie making work again) for the >80% of non-core platforms/configurations we are unable to write a JIT for. (eg anyone going to write a JIT for MIPS so that parrot runs fast on the Indy which earns its keep raising my monitor slightly?) Nicholas Clark -- ENOJOB http://www.ccl4.org/~nick/CV.html
