[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