[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 w
Leo --
>>>- 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
[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 o
Leo --
> > > ... Having major changes in opsfiles will invalidate PBCs, as
> > > e.g. a change from gcc 2.x to 3.x invalidates C++ object files.
> >
> > I disagree that it is too expensive, but I expect it will require
> > hard data to settle the matter. Since this is my pet issue, I
> > expect y
[EMAIL PROTECTED] wrote:
Leo --
[[ Caveat Reador: Extremely dynamic stuff is a pet issue of mine. Keep
your favorite halide handy. ]]
The per-op approach makes fingerprinting obsolete, which is another
reason I'm for it.
Yes partly, see below.
... Having major changes in opsfiles will i
Leo --
[[ Caveat Reador: Extremely dynamic stuff is a pet issue of mine. Keep
your favorite halide handy. ]]
> > 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 fingerpri
[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'v
Leo --
You need to account for the possibility that the number of ops in an oplib
could change over its versions, and so depending on it being stable is
a losing proposition. That is exactly what is going on in the scheme
below,
where you append oplibs en their entirety to the code segment's opta
