Thanks for the clarification. But it would still be the case, would it not,
with an embedded version of the whole SAOL runtime, that you could create a
reasonably efficient SAOL orchestra for any particular DSP block, and get
samples into and out of it through the regular input/output facilities
(realtime audio streams)?
If that were the case, then sfront still could be used as a library of DSP
code, but only on condition that it be possible to create multiple instances
of the runtime, all running at the same time. I imagine such uses were not
envisioned, but would they be possible or practical?
-----Original Message-----
From: John Lazzaro [mailto:lazzaro@CS.Berkeley.EDU]
Sent: Saturday, December 11, 1999 3:43 PM
To: eds@media.mit.edu; gogins@nyc.pipeline.com;
music-dsp@shoko.calarts.edu; saol-dev@media.mit.edu
Subject: Re: Common standard for DSP acceleration
> John will comment, I'm sure, but there's also
> run-time efficiency reasons. If you only ever
> call a particular core opcode with static parameters,
> you can generate a special instance of the opcode
> with the parameters "rolled into" the opcode code.
Yes, with each release, sfront's opcode implementations
(core and to a degree user-defined) become more like
"module generators" and less like straight code. Constancy
is one of several properties the generators use -- rate,
implied integer or float, use of optional parameters,
all come into play. An extreme feature, currently in the
development version and due out in a week or two, traces
all table arguments back to their source, through multiple
levels of opcode calls if needed -- this will also be used
to rate-optimize tablemap indexing.
Apart from these issues, though, there are a few other
reasons why sfront isn't the right vehicle for a DLL for
opcodes:
-- The data structures the opcodes manupulate look a lot
more like Fortran than C++, on purpose -- sfront depends
on having a good optimizing C compiler detect things like
arrays being indexed by a constant, and a lot of the data
strcuture choices in sfront are geared to exposing static
optimization opportunities.
-- In an interpeted system, you'll really want to use the
techniques Giorgio and collaborators have developed for
blocking -- these techniques will probably make it into
sfront eventually in some form, but sfront currently is
looking in different directions for speedups -- directions
that leverage compilation.
Basically, if you're looking to embed sfront-related
technology into a system, I'd recommend embedding sfront
itself, if it fits the product (a C compiler is available,
the latency of C compilation is OK, the GPL is compatible
with your licensing, ect). If it doesn't fit, I'd recommend
either leverging an existing commercial or free interpeter,
or rolling your own ...
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:50 EDT