Re: Using imcc as JIT optimizer
[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
Re: Using imcc as JIT optimizer
Although it might be nice if IMC were binary at this stage (for some feel-good-reason?). You mean, that a HL like perl6 should produce a binary equivalent to ther current .imc file? Yep - this was discussed already, albeit there was no discussion, how this should look like. And the lexer in imcc is pretty fast. ... The current bytecode from parrot already has potential for slowing things down, and that's what worries me here. I don't see that. My post was more a wish-list of what I was hoping parrot would be like in terms of imc/pbc/jit/whatever. Since I don't completely understand how parrot works, my comment above was actually more of a guess. But I'll try to explain what I meant, in the off-chance it was right. My understanding is that PBC has a limit of 16 (32?) integer registers. When a code block needs more than 16 registers, they are overflowed into a PMC. With a processor with 16 registers, I guess this would work. Although the JIT would have to overflow more than what was originally planned in the PBC. (Or does it just switch back and forth between the VM and the JIT, I don't know.) But with a processor with 16 registers (do such things exist?). Parrot would be overflowing registers that it could have been using in the JIT. My guess is that this would slow things down. Anyway, before I strut my ignorance of VMs and JITs and processors anymore, I think I will end this message. :) Thanks, Phil
Re: Using imcc as JIT optimizer
On Tuesday 25 February 2003 08:51, Leopold Toetsch wrote: Angel Faus wrote: Saturday 22 February 2003 16:28, Leopold Toetsch wrote: With your approach there are three levels of parrot registers: - The first N registers, which in JIT will be mapped to physical registers. - The others 32 - N parrot registers, which will be in memory. - The spilled registers, which are also on memory, but will have to be copied to a parrot register (which may be a memory location or a physical registers) before being used. Spilling is really rare, you have to work hard, to get a test case :-) But when it comes to spilling, we should do some register renumbering (which is the case for processor registers too). The current allocation is per basic block. When we start spilling, new temp registers are created, so that the register life range is limited to the usage of the new temp register and the spill code. This is rather expensive, as for one spilled register, the whole life analysis has to be redone. Not knowing much about virtual machine design... Here's a question -- Why do we have a set number of registers? Particularily since JITed code ends up setting the register constraints again, I'm not sure why parrot should set up register limit constraints first. Couldn't each code block say I need 12 registers for this block and then the JIT system would go on to do it's appropriate spilling magic with the system registers... I suspect the answer has something to do with optimized C and not making things hairy, but I had to ask anyway. :) ... Phil
multi-programming-language questions
List, I've been lurking here for about two months, after having read the summaries for several months previous. I'm interested in parrot because 1. I want it very badly for php / python / perl combinationability(?) 2. Just reading about the project is a fascinating learning experience. I've looked over the parrot docs on parrotcode.org, and have a few questions / concerns. Most of my problems lie within the fact that I'm so interested in seeing php / python / perl coexisting peacefully. 1. Function case -- some languages like php don't use case for function or method names. Thus $a-toString(); is the same as $a-tostring(); However, a language like java does care. How will php be able to call the correct java method? I suspect one solution for php would be to have a way to do a case insensitive method lookup. 2. Strings -- everyone deals with strings differently. There was some allusion to this issue in the docs on parrotcode.org, although the question wasn't quite answered. I also might not have quite understood the vtables chapter... So if I create a perlscalar string, and send it to a python function, what happens? Does the string act like a perlscalar or a pythonString? Or if I cared one way or an other, could I force it to switch to being a pythonString or stop it from switching? I suspect a language like PHP wouldn't have too much trouble with dealing with foreign strings, as it uses functions, and if all strings were a subclass of some parrotString class, PHP could handle them. But when a php string was sent to python or perl, that string would have no methods at all (except for maybe the parrotString methods?) The more fundamental question is -- is it possible to (if requested) magically transform one object to another type -- but only while it's in a different languages context? I suppose multi-threading would make the issue even more confusing... 4. Global Scopes -- each language has its own idea of what is part of the core function/pre-defined values set. If I start a python script, and call a php script, will php have python's global core (__import__,apply, compile,complex,xrange, etc...) or will the php script have the usual myriad of php functions available (all 5000 of them)? I guess when I'm in a php or python context, I'd want things to feel like a php or python context... Maybe each language gets its own namespace? php::main, python::main... Anyway, all these questions are comeing from someone who doesn't do a whole lot with perl. Yet, I'm _very_ excited about parrot, as I see a lot of duplicated effort between the various dynamic languages. And because of that duplicated effort, some things just never get duplicated. There are _many_ times when I'm using PHP, that I wish I could _really_ use CPAN. And other times when I'm using python that I wish I could jump back into PHP for a second. Or I want to use a function that I know is only implemented the way I like it in the other language... And there are even sometimes that I wish I could move over to perl for a minute and do something else. Beyond code reuse, and language switchability, I also like the idea of a single powerful platform. (That, hopefully, is superior to the individual ones. I have gripes about the PHP platform and the python platform, that I wishfully hope to see resolved by parrot.) So, anyway, sorry for liking PHP, and sorry for asking lots of (maybe ignorant) questions about how it will all work. BTW -- is anyone working on php-parrot right now? I saw a mention of it a few weeks ago, but no links.. Thanks! Phil
