[linux-audio-dev] XAP spec - early scribbles

[Simon Jenkins]

torbenh at gmx.de wrote:

>>>is it in C ?
>>>
>>>      
>>>
>>Yes, but you'll have to excuse the "accent".
>>    
>>
>
>:-) where did you get that accent from ?
>the only functional langage i know is python and
>i use it imperative most of the time...
>  
>
Stuff like the brackets in...
#define WHATEVER (6)
is habit due to having a very defensive coding standard at work.

The functional stuff is where the code gets heavily recursive: First a
recursive descent parser to parse the structure of the .amble files, then
a recursive "expansion" which turns a graph containing subgraphs
containing sub-subgraphs (etc) into one giant, flat graph which only
contains the real components.

The weird stuff is experimentation.

>>The graph ordering part of it is messily entwined with the rest of it
>>though, and its poorly structured: I didn't know the correct way to
>>structure it until after I'd finished. (That being part of the point
>>of doing it).
>>    
>>
>
>had a 10 minute glance on the code but did not understand yet...
>
>Is the ordering done only in CalculateRenderOrder ?
>
>what does the Graph expansion do ?
>
What happens is this:
1) ambLoadModule parses the .amble file.

2) Graph expansion recursively blows up the graph-to-render into a
big flat graph containing nothing but the "real" (ie code) components.
As it does so, it generates the mangled names that will be used
during code generation to make every instance of a code component
unique.

3) CalculateRenderOrder sorts the graph (ie the big, flat, expanded
graph). There's nothing special about the sorting to deal with the
nesting, its all expanded out before CalculateRenderOrder sees it.

4) ambGenerateCode generates the code from the render order,
substituting the mangled names for the placeholders that were
in the original CFRAG {{ }} sections of the .amble file.

The placeholders in the CFRAG {{ }} sections are...
In:xxxx input
Out:xxxx output
Mv:xxxx member variable
Sv:xxxx shared variable
Def:xxxx definition

>>I'm seriously thinking about neatly encapsulating the graph
>>ordering algorithm, extending it to address concerns which
>>other apps might have but which amble doesn't, making sure
>>it actually is correct, and releasing it as an LGPL library.
>>    
>>
>
>i'd be your first client...
>if it also did the tmp var allocation :)
>
erm... amble cheats and leaves var allocation to the C compiler. It
just generates a local var for every output and lets the compiler
optimise most of them away. The only special handling is when
an output is the beginning of a feedback path, in which case amble
generates a static local var so the previous value persists between
calls to the process function.

>let me think about an API which would fit my needs...
>to be continued...
>
I'd definitely like to see people's thoughts on an API. I liked the
style of encapsulation used in ssm but a C++ interface, especially
with STL on top, might prevent a lot of people from considering it.
Better a C library and a C++ wrapper for it. (Or a C++ library with
a C callable interface? It would be nice to use STL on the inside, its
just exposing it on the outside that I'm worried about).

Simon Jenkins
(Bristol, UK)