[EMAIL PROTECTED] wrote:
I see. So you would need to keep the implementation of 'foo_i_ic' for old PBCs and you would have 'foo_x_y_z', your new variant of this opcode. Seems not the best idea too me, in terms of maintanability and code size.
Yep. But I don't see how this is different from what you proposed for
new and obsolete ops.
This was a compromise between my original proposal (invalidate PBC) and yours. And really - I think we should go that way for the *normal* case, which is not meaning, that I don't like dynamic approaches. But the normal case is/should be fast loading and execution of PBC.
And as already stated, when things settle, we won't have much PBC changes.
So, how would the PBC with extended ops look like?
You can take a static or dynamic approach. The static approach has you tacking the optable onto the PBC as a segment (yes, its bigger than a fingerprint). Small code segments will have small op gamuts (gama? :), larger code segments will likely have larger op gamuts (and thus larger op tables), but it would not be linear.
So, this seems to be a translation table between PBC ops numbers and something I don't understand yet.
The extreme dynamic approach involves a new oplib (boot.ops) with a
new op called useop_ic_sc_sc. This op is prewired (not necessarily
*hard* wired) to optable slot zero at startup. C<usop> fills in optable
slots:
useop 1, "foo", "bar_i_ic"
So, instead of a formal optable segment in the packfile, you modify
your optable any time you please.
Brr, that's so much overkill beyond my thoughts, that I not even can imagine the implications on PBC loading til runtime :)
... The
idea would be to make the core set just large enough that real-world
programs wouldn't need very many dynamic ops
So your proposal is really overkill ;-)
One objection to this approach could be PBC bloat, but I'd challenge that
one on these grounds: We use 32-bit bytecode slots to hold 5-bit register
numbers and < 10 bit opcode numbers, "wasting" many of the bits (they
were traded for simplicity and speed).
Yep. I did think about this too. Many ops could code their opcodes + 1 or 2 operand in this bits. But, as you said: simplicity and speed. And when I compare PBC to i386/JIT code size or source/compiled C code size, PBC is a really compact format - nethertheless.
Your proposal looks like moving the assembler to runtime.
Not really. This is a separate but equally interesting issue.
Having IMCC available (loadable, anyway) is a good idea.
This is not a "good idea", ehem no - yes - it is a good idea - but *reality*, please consult languages/imcc/t/syn/eval.t.
Again:
imcc = parrot + (assemble.pl - macro_preprocessor) + IMCC_parser
<blue-sky>
I like languages with good introspection capabilities. The ability to
do things like define new classes at run time is a bonus, too.
s/a bonus/necessary/
... I'm
interested in seeing similar capabilities in the underlying virtual
machine (I guess I want to turn it into a malleable machine).
Yep, here these capabilities exist.
... Not only would I like to see dynamic optables, but I'd like a program to be able to find out about its op table, too.
Before dreaming of totally synthetic optables for a simulate 6502 processor, plz lets stay feet on the ground and really have a look at my proposal. Yours would just be an expansion to - I think we both agree here - a necessary or at least good change for now.
Oh, and I'd like to have indirect addressing modes where the register numbers come from other registers.
This one came into my mind too - and I was wondering why parrot doesn't have an indirect register syntax.
set N1, N[I2] # only set operations should do it
</blue-sky> Regards, -- Gregor
leo
