[EMAIL PROTECTED] wrote:
Leo --
- a opcode is obsoleted => you can't delete it anyway, so keep it, update docs.
Aside: Begs the question: Should op metadata include an 'obsolete' tag? It would allow you to report on obsolete op use.
Would't harm, yep.
- a opcode gets more or less or changed params => you are as out of luck
with the old PBC as my approach is: invalidate PBC file.
Nope. The op 'name' includes the number and types of the args, foo_i_ic. A "change" involves a new op and marking the old one obsolete. As far as existing bytecode is concerned an op signature change is equivalent to an op deletion and an op addition, and therefore should not be treated as a separate case.
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.
Removing an op instead of marking it obsolete will cause the oplookup to fail, and the interpreter would report and error, just as with finger- printing. However, you would actually have more information to report, such as which op is missing from which oplib, which can be helpful in tracking down the problem. So, IMO, the finer granularity is useful both for evolution and for failure diagnosis.
So, how would the PBC with extended ops look like: still mmap()able? Or name/signature of extension ops? Your proposal looks like moving the assembler to runtime.
Regards, -- Gregor
leo
