[PD] PureData to C/C++ language
Mathieu Bouchard
matju at artengine.ca
Tue Sep 28 19:35:26 CEST 2010
On Mon, 27 Sep 2010, Ludwig Maes wrote:
> I think that if we could write a Pd => GIMPLE converter (hence a Pd
> frontend) for gcc, that gcc could do quite a lot of optimization for us.
What's the advantage over simply producing a large lump of C code ?
Because, learning GIMPLE takes time, whereas learning C... everyone
willing to take on that task already knows all of C.
> I could be wrong but I have the impression that every message between Pd
> objects is sent as an abstracted structure and not optimized for
> architecture to the extent compilers do (could be wrong, but would be
> positively amazed if I am).
Pd is often hard to categorise, but I'd call its message-system an « AST
intepreter », even though the «T» is supposed to stand for Tree, and it's
not a Tree in the context of Pd. An AST interpreter is faster than one
which constantly reparses, but is usually at least a bit slower than
bytecode, which is much slower than a conversion to C compiled with -O0.
> This ability would further not only the goals of optimization freaks but
> also those of dataflow programming in general (stepping into C or other
> is like admitting -whether correct or not- dataflow is insufficient, at
> least in practice as long as we cant compile...) Also people would be
> able to write general software in dataflow languages. Whether it be
> drivers, pd-developer code, ...
Dataflow programming as a whole is not a programming paradigm, it's a
collection of them. The Pd/Max paradigm could be called « imperative
dataflow » (in the case of the message-system). Before I came, the
totality of programming languages called dataflow had very little to do
with Pd/MAX, while Pd/MAX weren't called dataflow ; and those that were
called dataflow didn't always have so much to do with each other. There
are still lots of researchers who use the phrase « dataflow programming »
in a specific manner that excludes Pd/MAX. Anyway, what I want to say is
that there is not much that you can do that can apply to the whole of what
is called dataflow.
> We could bootstrap Pd for example, so that users who at first use Pd
> for audio, then start to code in GEM later could also start to adapt
> their interface or fix inner workings of Pd
I don't understand what you mean.
_______________________________________________________________________
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
More information about the Pd-list
mailing list