Designing a language for dataflow/parallelism

tony@tonyRobinson.com
13 Jun 2005 17:57:19 -0400

          From comp.compilers

Related articles
Designing a language for dataflow/parallelism tony@tonyRobinson.com (2005-06-13)
Re: Designing a language for dataflow/parallelism torbenm@diku.dk (2005-06-16)
Re: Designing a language for dataflow/parallelism nmm1@cus.cam.ac.uk (2005-06-16)
Re: Designing a language for dataflow/parallelism mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2005-06-16)
Re: Designing a language for dataflow/parallelism rand@rice.edu (Randy) (2005-06-18)
Re: Designing a language for dataflow/parallelism gneuner2@comcast.net (George Neuner) (2005-06-18)
Re: Designing a language for dataflow/parallelism peteg42@gmail.com (Peter Gammie) (2005-06-19)
[2 later articles]
| List of all articles for this month |

From: tony@tonyRobinson.com
Newsgroups: comp.compilers
Date: 13 Jun 2005 17:57:19 -0400
Organization: ntl Cablemodem News Service
Keywords: parallel, question

Out of idle curiosity (and for my own education) I'm kicking about the
idea of designing and implementing a very simple programming language.


One of the objectives is a "safe" language with good optimisation and
for that I've decided that there will be no explicit pointers (e.g. as
Java).


In C terminology, I'm looking at the problem of detecting at compile
time whether the writable areas of two structs (and whatever they
reference) are disjoint in memory. If so then I can maximise code
reordering, for example the execution of function calls in parallel:


func0(foo);
func1(bar);


I'm thinking of ideas such as implementing reference counting to
eliminate conflicts on memory that isn't referenced from anywhere else.
Even perhaps a memory type that only allows one reference and
automatically takes the prior reference out of scope, as in:


char *a = malloc(1);
char *b, *c;
b = a;
c = a; // causes compile time error as a is now invalid


There's clearly a tradeoff between expressiveness of the language and
ability to optimise. Googling on "alias analysis" and "automatic
scoping" gets me somewhere, for example the "why C can't be as fast as
Fortran" debate, which is educational. However I'm really interested in
the idea of a new language (or portable assembler, c-- style), so I'm
looking for references, papers, projects on this sort of problem, more
comparative analysis of different languages, or even just the right
keywords to hit google with...




Tony Robinson


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.