> > [Robin writes]
> >
> > Sfx currently evaluates the sub-guard-rate expressions unconditionally.
>
> > [Giorgio writes]
> >
> > The k-rate expression, if it is broken into intermediate statements
> > like in saint, generates a k-block inside the a-rate-guarded block.
>
I may be mistaken here. Giorgio was referring to expressions rather than
statements, and particularly wrt/ expression that provide parameters to core
opcodes that take k-rate or i-rate arguments within a-rate guarded
expressions. The distinction between statements and expressions is an
important one.
Consider the core opcode
aopcode loscil(table tbl, asig cps, ivar basefreq, ivar loopstart, ivar
loopend);
and the instr code fragment.
if (kTest) {
aResult = loscil(
tbl[iSample],
cps,
iBaseFrequency[iSample], // [1]
iLoopStart[iSample],
iLoopEnd[iSample]);
}
The argument at [1] is an i-rate expression being evaluated within a k-rate
guard. I believe Giorgio was saying that Saint handles this particular case
by converting the i-rate expression to an assignment to a temporary (e.g. a
hidden assignment "statement" to a temporary). Note that the standard
actually currently forbids use of an i-rate opcode to supply an i-rate
actual argument to loscil so we needn't consider this problem.
Giorgio made the point that it's difficult to forbid the use of i-rate
expressions within k-rate guarded code blocks (well, actually he said k-rate
expressions in a-rate guarded code, but the first suitable example opcode I
found had i-rate arguments).
If the given example were "loscil(tbl[iSample], cps, 1,2,3)" the question to
ask would be this: what "rate" do the constant arguments get evaluated at
(yes yes, I know you and I perform constant folding to solve this case, but
that avoids the fundamental question). Consider how those arguments get
parsed.They are expression. Furthermore, they are I-rate expression. Sure,
they're degenerate expressions, but they still remain i-rate expression. I
don't have code that says "is the expression parse tree deeper than 1?" when
I parse that expression. Do you?
Saint and Sfx produce the same results in this case, primarily because this
particular expression has no side-effects. Sfx converts the expression to an
i-rate assignment that is executed before the guard; saint converts it to an
expression that is evaluted at k-rate inside the guarded code block. The the
results, however, are the same, since the expression doesn't have
side-effects other than to modify hidden temporary variables in both cases.
Giorgio has already stated that Saint won't handle k-rate statements in
a-rate-guarded UDOs (e.g. assignment statements).
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:55 EST