(Ah, stupid Emacs...) ...but a Pike interpreter compiled with machine code support can _not_ handle the platform independent bytecode.
On Sat, May 17, 2003 at 01:35:04PM +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
(Ah, stupid Emacs...) ...but a Pike interpreter compiled with machine code support can _not_ handle the platform independent bytecode.
Why? As I understand, JIT (or whatever) is only a kind of extension to byte-code, not a replacement, so still full set of original byte-code should be supported. OTOH, JIT pass must be done over generated byte-code, not instead (at least this is how Java JIT works).
But anyway, even if it is platform dependent, it still would be useful (I don't care about interplatform compatibility and portability because I can enforce some platform requirements).
Regards, /Al
Then you understood wrong. The machine code generator _replaces_ the byte code interpreter. The way it happens is that instead of a separate pass, the code generator is added to the pipeline. So when the frontend outputs a bytecode, instead of storing it to memory it is immediately converted to machinecode. So the internal storage format becomes machine code instructions, not bytecodes.
It is not a JIT at all, it's an ahead-of-time compiler. Machine code is always generated, regardless of whether the code is actually run or not.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-05-17 15:59: Subject: Re: byte-code
On Sat, May 17, 2003 at 01:35:04PM +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
(Ah, stupid Emacs...) ...but a Pike interpreter compiled with machine code support can _not_ handle the platform independent bytecode.
Why? As I understand, JIT (or whatever) is only a kind of extension to byte-code, not a replacement, so still full set of original byte-code should be supported. OTOH, JIT pass must be done over generated byte-code, not instead (at least this is how Java JIT works).
But anyway, even if it is platform dependent, it still would be useful (I don't care about interplatform compatibility and portability because I can enforce some platform requirements).
Regards, /Al
/ Brevbäraren
On Sat, May 17, 2003 at 04:05:05PM +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Then you understood wrong. The machine code generator _replaces_ the byte code interpreter.
But not completely - only some (very few for now) parts. So basically it should mean that pure byte-code should be interpreted correctly even when machine-dependent Pike was built. Or I am wrong again?
Regards, /Al
Take a look at interpret_functions.h. This contains the implementation of all Pike opcodes. When you are compiling a Pike --without-machinecode, the OPCODE* macros will transform this into a giant switch statement that executes the different bytecodes. When compiling --with-machinecode, it instead becomes one function per opcode, so that the machinecode generator can insert call instructions to them. Also, the actual implementation of the opcodes change a bit, the DO_JUMP_TO etc macros expand to radically different things depending on whether you are using machinecode or not. So for all practical purposes the interpretter _is_ completely replaced in the current Pike implementation.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-05-17 16:34: Subject: Re: byte-code
On Sat, May 17, 2003 at 04:05:05PM +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Then you understood wrong. The machine code generator _replaces_ the byte code interpreter.
But not completely - only some (very few for now) parts. So basically it should mean that pure byte-code should be interpreted correctly even when machine-dependent Pike was built. Or I am wrong again?
Regards, /Al
/ Brevbäraren
pike-devel@lists.lysator.liu.se