static code generation and open Accs

[Stephen Blackheath [to Accelerate]]

Manuel & Trevor & all,

I mentioned to you at AusHac2010 that I've got some Haskell code in our 
video game that needs speeding up, and accelerate is looking like an 
attractive option to avoid having to write some C.

Since our platforms are mobile ones (and therefore no compiler at 
runtime), I'm considering writing a static C back end for accelerate, so 
I took a look at what would be needed.

The generated code would need to be a C function that takes arguments, 
and so the accelerate AST would have to represent a lamba expression. 
Assuming I'm reading the code right, it looks like I can do this easily 
by adding the arguments to the environment, then binding an Avar to the 
argument names at the Haskell level.  Primitive values can be passed in 
as scalars.

However, the accelerate language code could not have the current type of 
Acc a ~ OpenAcc () a, because that doesn't allow the environment type 
required by Avar.  The obvious way to fix this is to change every 
function in the accelerate language to have type OpenAcc aenv a instead 
of Acc a.  But - I can't imagine you would want to do this.

I tried to think of some type trickery to somehow 'bubble' the types of 
the argument Avar values through the environment type up to the top 
level after the fact.  This would be the ideal solution, but at the 
moment I can't see any way of doing it.  What we'd like to do is take 
some expression, for example, containing an Avar value of type Acc 
(Array DIM1 Int) somewhere in the AST, and translate it internally to an 
expression of type OpenAcc (Array DIM1 Int, ()) a.

If that doesn't work, then a solution that would work after a fashion is 
to have a whole new public module, perhaps Data.Array.Accelerate.Open, 
which duplicates the whole accelerate language, but uses OpenAcc aenv 
types.  There are several reasons why this is not nice, though.

So, my questions are:

1. Do I understand the code wrong, that is, is there some easier way of 
achieving static compilation that I can't see?

2. If I have got it right, do you know of any way to achieve the type 
trickery so we could introduce Avar values without having to expose the 
OpenAcc types at the accelerate language level?

3. If you don't, then do you think the type trickery approach is valid? 
  If so, I'd be happy to spend some more time on it and try to figure 
out a way to achieve it.

4. Failing the above, is there any other way we can do it?  (Perhaps 
static compilation is not something you want to do.)

Thanks!


Steve