[PD] PureData to C/C++ language

[Ludwig Maes]

As I said, I am no expert at all in this, but I can explain what
motivated me to make these specific remarks, and express my beliefs or
doubts:

On 28 September 2010 19:35, Mathieu Bouchard <matju at artengine.ca> wrote:
> 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 would think that having an extra intermedia language would hide
information from the middle end, I trust that the gcc developers know
what they do, otherwise by the same argument it would be much easier
for the other GCC front ends to compile to C and hand that over to the
C compiler and thus indirectly to the middle end. Since all the
supplied front ends emit gimple I think there are good reasons for
this.
One example of why I think taking the detour (in code transformations,
but possibly shortcut in ease of programming) along C would be
organizing  code into threads, since C/C++ were originally not
develloped for multithreading but assumed a rather pure Von Neumann
architecture.

>
>> 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.
As I said I dont really know the message system, I just notice my
system monitors network histogram (on ubuntu) soar as I use Pd.
Surely passing information through registers when possible would be
faster, or are processor caches even aware of Pd messaging system?

>
>> 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.
Here I must say that I hesitated a lot and didnt know how to phrase
it. I know that since at least the sixties there was 'dataflow' (I got
interested in dataflow because I stumbled on old MIT papers about
them, back when they tried to make 'dataflow' hardware before it
appeared to be inefficient for multiple reasons...). I know dataflow
means a lot of different things. This is not mathematics. I realise
that even if people were willing to create such a system, that there
would be multiple possible graphlike languages, each with their pros
and cons. What is more important to me is that one would be made, so
that people who stand for different forms of dataflow programming
would adapt it to their needs or respond to a higher bar by making
their dataflow language compilable through existing compiler middle
ends.
These wouldnt directly apply to the whole of dataflow, but at least it
could create courage to the whole to apply compilability to their
specific view of 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.
Suppose Pd (or other dataflow language) were rewritten in the dataflow
language, so that Pd almost becomes a sub operating system, to run a
mixture of uncompiled and compiled code (for example in theory if the
sources of running code (including Pd) were provided in the dataflow
format, then during normal usage, a user could freeze the program,
change and recompile part of the graph and continue the program...)
Another example: a user want bezier curves to connect the boxes, or
color code hot inlets, or ..., then he could adapt Pd gui to do so
without having to know C (like a lot of the now supposedly 'only
artistic' user base, which in my view are programmers, but just
program Pd instead of C). This could equalize the user base to the
developer base, so that users could represent themselves instead of
whining agains the developers when something breaks or isnt
satisfactory (like me for example!).
A long term dream would be to rewrite Linux in a dataflow language, so
that general users could represent themselves more easily.
This is as much about democracy as about technology (not saying
developers are evil henchmen, to the contrary they provide us with
lots of choices and options, to which the user can delegate, but
democracy works best if we constantly minimize delegation).

I didnt know the interpreter was kind of AST based... nice to know!

Greetings!