Re: Dope-Vectors for low energy compliers

nmm1@cus.cam.ac.uk (Nick Maclaren)
19 Mar 2002 12:00:37 -0500

          From comp.compilers

Related articles
Dope-Vectors for low energy compliers verma@ls12sr.cs.uni-dortmund.de (Manish Verma) (2002-03-11)
Re: Dope-Vectors for low energy compliers sumesh_uk@hotmail.com (sumesh) (2002-03-17)
Re: Dope-Vectors for low energy compliers nmm1@cus.cam.ac.uk (2002-03-19)
| List of all articles for this month |

From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Newsgroups: comp.compilers
Date: 19 Mar 2002 12:00:37 -0500
Organization: University of Cambridge, England
References: 02-03-055
Keywords: design, storage
Posted-Date: 19 Mar 2002 12:00:37 EST

Manish Verma <verma@ls12sr.cs.uni-dortmund.de> wrote:
> I am Phd student working on Low Energy Compilers and I have the
>following ques tion. Why do we need to store the Array(Data) in
>consecutive memory areas. We co uld use something like Dope-Vectors
>(the way HPF/Fortran uses) and then divide the array on different
>memories( Scratch-pad or main memory). I need help as I am confused
>as how to do this allocation and when is it worthwhile to do divide
>the data or rather is it worthwhile to divide the data. And try to
>optimise energy.


No, HPF and Fortran do not make it easy to use dope vectors. Dope
vectors were very popular in the 1960s, when memory access was cheaper
than multiplication, but have been known to be a very bad way of
handling rectangular arrays since the 1970s. See a very recent thread
on comp.arch (look for postings by Terje Mathisen and me) which give
the reasons.


However, that doesn't mean that your question is irrelevant. The
problem of splitting data into high- and low-access requirements IS
very relevant to all shared memory models and low-power systems. But,
in the case of most languages, it should be done at the object level,
and not the sub-object level.


It is yet ANOTHER variation on the great unsolved compiler problem:
that of how to analyse arbitrary code automatically. This is
theoretically impossible, occasionally easy in practice, but usually
foul. It depends far more on the cleanness of the language used
and the programming paradigm than the target architecture.


So my guess is that your problem is directly mappable to the standard
problem of optimisation, but with a variation on the requirements
for code generation.




Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679


Post a followup to this message

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