[CVS ci] class autoload
Leopold Toetsch
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
Sam Ruby
> 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
Leopold Toetsch
>
> 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