> Meaning that "opcodes that would be executed slower than the guard
expression"
> doesn't only mean "no kopcode or iopcode" but also talks about the
> rate of any statements in the UDO.
Yess! Very precisely stated, John. I think that's a plausible reading of
6.8.6.6.4. However, I also think that 6.8.6.6.4 is ambiguous with respect to
satements within guarded UDOs, and therefore requires a ruling by Eric as to
the precise intent.
(1) 6.8.6.6.4 *does* restrict the rate of statements within UDOs.
or
(2) 6.8.6.6.4 does *not* restrictions on statements within UDOs.
That's why I'm not taking a really hard line on this one. (yet. <g>). If (1)
is true the whole issue is moot. If (2) is true, then we need to deal with
the issues we've been discussing. However, if we (or I, whichever) advocate
for (2), then the question of what additional requirements are neccessary to
ensure unambiguous semantics is an important one.
From an aesthetic point of view, I am opposed to interpretation (1). As you
point out, it would mean that library code would have to have the nasssty
table of conditional rate restrictinos like the Sun docs do (except much
worse, really). The aesthetic objection is only valid however, if 6.8.6.6.4
really is ambiguous, and it's not just wishful thinking on my part (I don't
think it is).
(2) *seems* to be workable in my mind, although it *may* require an
additional requirement that sub-guard-rate code be executed uncoditionally.
Umm. Just occurred to me. I wonder whether copy-out of parameters at
sub-guard-rate would expose the problem as well.... <think>
Yes. It would. Consider:
aopcode foo(kisg kGuard, ksig kResult) {
if (kGate) {
kResult = 1;
}
}
instr Instr() {
asig aTest;
ksig kResult;
if (aTest) { // always false.
foo(1, kResult); // kResult <- 1 (sfx, but not saint).
}
}
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:56 EST