> loscil is actually a fairly good example to consider. Caveat: this isn't
> actual sfx code, but indicates how i would implement loscil based on my best
> recollection of the opcode.
Here's what sfront generates for loscil today:
Given this short instr:
instr trumpet (note)
{
imports table trump;
output(0.5*loscil(trump,cpsmidi(note)));
}
It generates (extensively edited):
float trumpet__sym_loscil2(struct ninstr_types * nstate)
{
float freq;
[... other temp variables ...]
freq = NV(trumpet__tvr0); // temp variable for cpsmidi call
// moved to i-rate, after safety
// checks were done statically.
if (acycleidx)
{
// code for all but first a-pass
}
else
{
// code for first a-pass in each block
// and very first a-pass ever, where
// k-rate and i-rate precomputation done
}
}
Gcc at least does a pretty credible job with conditions like
this -- profiling with gprof on my 450Mhz PIII shows 250ns per
call, which translates to a "guaranteed not to exceed" 90 voices
at 44100Hz. A simple division
of (1/450Mhz) by 250ns shows 112 clock ticks, but its unclear if
its directly comparable to your 80 clock ticks estimate. I did
cross-check the profiling numbers by actual run time numbers
from audio generation and they do roughly match ...
> Since the results of the two methods are computationally equivalent, it
> seems entirely justified to me to execute the k-rate code unconditionally
> when the opcode is guarded by an a-rate if guard. The conditions for this
> optimization to be computationally equivalent to the language of the spec:
> (1) The k-rate code must not have any side effects that that modify opcode
> state that persists from k-cycle to k-cycle. If condition (1) does hold,
> then the results of then we have a condition that must either generate an
> error or, produces undefined results per the current specification.
This reminds me of Solaris man pages for function calls, which include
a section like this:
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| MT-Level | Async-Signal-Safe |
|_____________________________|_____________________________|
Section for each function. SAOL opcode libraries will need this too
if this sort of semantics gets standardized, with "k-rate side
effects" and "i-rate side effects" as attributes ...
This way programmers will know what opcodes are safe to use in
conditionals and which ones aren't (although static analysis should
be able to locate persistance and give warning errors as well, an
echo of sfront's current UDO-rule warnings ...),
--jl
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:56 EST