Re: Designing a language for dataflow/parallelism

nmm1@cus.cam.ac.uk (Nick Maclaren)
16 Jun 2005 00:07:53 -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)
Re: Designing a language for dataflow/parallelism gneuner2@comcast.net (George Neuner) (2005-06-21)
Designing a language for dataflow/parallelism peteg42@gmail.com (Peter Gammie) (2005-06-26)
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 16 Jun 2005 00:07:53 -0400
Organization: University of Cambridge, England
References: 05-06-081
Keywords: parallel

<tony@tonyRobinson.com> wrote:
>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:


Most of the work is older than the Web, so you will need to chase up
stuff on paper. I have not heard of any work that uses reference
counting for such a purpose, and think that you may well have an idea
worth pursuing. Of course, you may then find out why there is no such
work :-)


I have been thinking along related lines, but taking a hard line on
the program being allowed to introduce undeclared aliasing. For
example, at a procedure call, one rule could be that subojects of the
same object could not be passed twice (or passed and visible globally)
unless either they were disjoint or both were read-only.


By restricting the subsectioning operations, this becomes feasible, at
least for structures and arrays. It gets really rather hairy for
list-based structures, though.




Regards,
Nick Maclaren.


Post a followup to this message

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