[CVS ci] class autoload
1) There is a new opcode new Px, Sc: new P0, PyInt 2) If the given class doesn't yet exist, Parrot_autoload_class is called which has hardcode mapping for Py = python_group, Tcl = tcl_group. A bit hackish but working ... 3) The pybuiltin.__load__() function is automatically called by the library _init loading hook now. There is one more test in t/dynclases/pybuiltins that has an example. leo
Re: [CVS ci] class autoload
Leopold Toetsch wrote: 1) There is a new opcode new Px, Sc: new P0, PyInt 2) If the given class doesn't yet exist, Parrot_autoload_class is called which has hardcode mapping for Py = python_group, Tcl = tcl_group. A bit hackish but working ... Perhaps longer term, a change to the pbc format may be in order... the idea would be for each binary to have a list of dependencies which need to be loaded previously. Developers could declare such a dependency with a IMCC macro, something like this: .lib python_group This would enable JITs to convert the above new opcode into the equivalent new Px, Ic variety in many cases. 3) The pybuiltin.__load__() function is automatically called by the library _init loading hook now. There is one more test in t/dynclases/pybuiltins that has an example. Cool, thanks! - Sam Ruby
Re: [CVS ci] class autoload
Sam Ruby wrote: Developers could declare such a dependency with a IMCC macro, something like this: .lib python_group That could be .class_mapping Py, python_group OTOH when the classes are built in dynclasses, we can as well hard-code the entries. We'll see. This would enable JITs to convert the above new opcode into the equivalent new Px, Ic variety in many cases. That code is already written ;) Well, the real JIT (Just in time) system in Parrot is predereferencing and used by the switch and CGP run cores. These cores are replacing (after an initial lookup) the opcode already. I'll check it in tomorrow. JIT will eventually call one of these cores and have the same benefit. Cool, thanks! Welcome. - Sam Ruby leo
