On Sat, 2001-11-03 at 21:40, Gregor N. Purdy wrote:
> James --
>
> > We're going to have to think about assigning static opcode numbers,
> > instead of the current order-defined. For one thing, we're looking at
> > perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
> > need to:
> > 1) Define an ordering on things like open(i, s|sc, i|ic, i|ic).
> > 2) Define the notation for setting the opcode number in the .ops file.
> > 3) Define what the correct behavor is for when you have holes in the opcode
> > numbering.
>
> None of these are issues with the approach I've been working on /
> advocating. I'm hoping we can avoid these altogether.
>
I think this is a cool concept, but it seems like a lot of overhead with
the string lookups.
How about instead of the string lookups the ops remained a constant per
version.
Once the core is set up, it shouldn't change any, though we'll be adding
new ops later (and possibly be removing some). Given that, and since
the ops are created in a predictable fashion, why not create a version
number for "new" ops in the module. For example, if after the core is
stable we want to add a new debugging op called "dwim". We could add it
to the file (in any location) as:
AUTO_OP dwim() 1.1 {
}
Where 1.1 is the version number. All unversioned core ops (at last
count 292) would be generated first in the order they are defined. Then
all versioned ops in increasing version order in the order they are
defined. This way, version 1 core ops would be in the table from 1-292
and 1.1 ops might be in 293-333. We could specify ".use core 1" to
disallow dwim and friends....or to make backwards compatible code. By
default the whole table would be available.
It would provide some sanity checking without the overhead of doing a
bunch of string lookups on every load. Of course, its not perfect...
Thoughts? Or am I too tired to be sending email? :)
Brian
