Hi Eric and everybody,
At 08:54 AM 3/5/99 -0500, Eric Scheirer wrote:
>I have some comments...
>
>>Given that, unlike Csound, there are (so far as I can see)
>>no opcodes specifically for displaying data, graphic code will have to
>>be linked to saolc at a fairly deep level.
>
>There's always a question whether 'saolc' is the proper implementation
>of SAOL for real-time experiments in the long run, or whether we
>would be better served to steal the parser and other front-end
>parts and start again. I think the latter is the approach of
>EPFL -- can someone from there comment on how much of 'saolc'
>you're using in your work? Are you trying to "improve" saolc
>or only use the best bits to build a better SAOL implementation?
>
We started using the same lexer/parser of saolc (the reference software),
converting its structure to an OO structure, and then we built a new execution
unit from scratch trying to understand in which ways it was possible
to speed up execution.
In the meantime I wrote a completely new compiling unit also from scratch,
even without lex and yacc, so that everything is completely "readable"
in pure C and C++. At the moment we are integrating the two parts, so that
we are still using of saolc only the aif libraries (and just for input, the
output is already flat PCM).
The engine is more or less working but we have a *very* low number of
generators and opcodes implemented, because we are not sure yet at
100% about the best speedup approach. We started from rigorous complexity
analyses (already presented months ago at MPEG) and we are moving
towards implementations for high complexity and quality bitstreams.
Anyway I will be happy to make our work of public domain asap, let's say a few
weeks: not because we need to hide it, but because we want to propose
a stable skeleton for the complete decoder (only the MPEG compliant
part of it, we don't think to extensions at this time) and keep control
on it. We still have 2-3 basic problems to solve.
It is sure anyway that to speed-up saolc it is necessary to improve
the execution unit; a different parser and data structure can only save
some 400-500 kbytes of memory allocation for complex examples.
Best regards to all,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Center - DE/c3i - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:22 EDT