[PD] PureData to C/C++ language

[Mathieu Bouchard]

On Tue, 28 Sep 2010, Ludwig Maes wrote:

> 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.

It's easier to compile C++ to C, but typically, compiler writers would 
consider it "cleaner" to have a direct compilation to asm. But then, I 
recall that on MSDOS, the norm was instead to compile straight to machine 
code. Much of the reason was to skip encoding/decoding steps. You may 
trust the gcc developers but we're not the gcc developers, and they're not 
the ones likely to write you a pd frontend.

> Since all the supplied front ends emit gimple I think there are good 
> reasons for this.

That's because the other compilers that emit C or close derivatives of C 
are produced by other people than the GCC team, and they are compilers 
that don't benefit from nearly as much visibility as the GCC team.

> 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.

Excuse me, I don't understand this sentence. (I think it's missing some 
words near the beginning.)

BTW, Pd isn't any more threadable than C. Pd isn't part of the same family 
of dataflow languages as most other dataflow languages (one family of 
which is designed to be threadable). I don't know where you want to go 
with that topic though.

> 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?

Use of registers has been done automatically by GCC since the last 15 
years or more. Because of this, I don't even hear about registers 
anymore... almost. Use of L1, L2 and L3 caches is also completely 
automated by default for all apps, but that's a motherboard thing.

However, much of Pd is interpreted, and that usually involves processing a 
much larger amount of conditionals, switches and function pointers than 
what usually happens in compiled code. But are you sure you are talking 
about the message system only, and not about dsp ? do you use specific 
collections of externals such as gem,pdp,gridflow,vasp,iemmatrix,pmpd, 
that may operate on large collections of data while using very little of 
the interpreter...? it may make the interpreter irrelevant.

> 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...).

do you mean this ? -> http://en.wikipedia.org/wiki/Connection_Machine

but that was in the eighties.

> I know dataflow means a lot of different things. This is not mathematics.

Mathmatics is more standardised than computer science, but mathematicians 
of the world are still divided in two, according to whether natural 
numbers include zero or not, and whether zero is called a 'positive' 
number or not.

> 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.

Show me people who want to collaborate on a thing like this that would 
include Pd... because I don't believe you can get such a team together. 
The dataflow families don't have so much in common.

> 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...)

You don't need to bootstrap Pd to recompile any part of a graph. 
Specifically, you need a graph compiler than can work on any part of a 
graph. Bootstrapping is a cool concept, but its advantages are harder to 
find.

> 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 also doesn't need any bootstrapping. I came quite close to providing 
this possibility, but didn't finish it. With a bit more work, you'd have 
been able to load and save object attributes and connection attributes in 
.pd files, and from that point, you'd be able to implement the feature in 
Tcl language, which is not as hard as 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!).

The problem with this, is that there's a very large intersection between 
people who write externals and people who write abstractions, so, there 
isn't a big incentive to provide tools that are only needed by those 
abstraction-writers who can't write externals. It also explains why some 
features become available to abstractions in 2009 or 2010, that were 
available to externals in the nineties.

> 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

Dataflow languages aren't really easier, and generally speaking, you can't 
get the general users to program. There's (at least) fifty years of 
history of programming languages being introduced "so that non-programmers 
can program too" but it's always a lie or a delusion. Much of the skills 
and qualities required to program aren't dependent on the programming 
language.

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

It's a manner of speech. I say it's AST-like because it uses data 
structures with pointers, but it's still a graph, not a tree. I say it's 
an AST because it's not bytecode, not machine code, and it's also not the 
kind of interpreter that reparses everything all of the time (Tcl7 was 
reparsing everything; Tcl8 uses bytecode).

  _______________________________________________________________________
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC