[EMAIL PROTECTED] wrote:
Leo --
You need to account for the possibility that the number of ops in an oplib
could change over its versions,
This does invalidate the PBC, as it's currently done via fingerprinting.
I think this needs to be done at the op level, not at the oplib level (as I've
detailed before). I believe op{info,func} lookup by name is fast enough
that this can be done as a preamble without too much trouble.
Not really necessary and too expensive IMHO. The language/ops will stabilize. Having major changes in opsfiles will invalidate PBCs, as e.g. a change from gcc 2.x to 3.x invalidates C++ object files.
Generally, I'm in favor of a greater number of smaller oplibs, with the option
for static or dynamic linking.
Yep
The main objection I know of is the implications for the fast runops cores.
They tend to dislike dynamic optables.
With my proposed scheme, I can't see any implications except on compiled C (but this still needs a lot of work anyway)
... Although I haven't had the time
to do the JIT tinkering to prove it, I think the JIT machinery might be
sufficient to build the equivalent of a computed goto core for a dynamic
optable on the fly.
When JIT is there, it will run the code, it's substantially faster - for a non trivial number of JITed opcodes.
... I don't know what the long-term policy on non-JIT architectures is (going to have them? does the cgoto core have to work on them?).
Nor do I. But non-JIT architectures have to run what's available. Even CGoto might not be available.
Regards, -- Gregor
leo
