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)