[<<][rtl][>>][..]
Sun May 12 10:29:44 EDT 2019

Grid

I started doing this in a separate module.

Two important insights:

- Grid needs to be separated from Seq.  Basically:
  - Seq  = Expr x Time (implicit)
  - Grid = Expr x Space (arrays)

- Grid will provide "intermediate storage holes" for Expr.

So the interface between Grid and Expr is at the level of ALLOCATION.

Practically, when a Grid compiler passes control to an Expr compiler,
it will need to provide the mechanism to create a variable in a
context.


Maybe I should stop here to not get too confused.

EDIT: Continued a bit, distinguiing a number of entities into separate
types.  It can now represent:

T c[100];
T d[100];
for(int i=0; i< 100); i++){
	c[i] = op(a[i], b[i])
	d[i] = op(c[i], c[i])
}

EDIT: This is still not correct, as arrays can span multiple loops.
So next is to encode nested loops.

EDIT: Will it be possible to mix different "types" of expressions
inside loops?  No.  This will have to be recovered in post-processing.

Let's try to express at least 2 levels.

In this light, there is a difference between

- the loop being expressed abstractly (iterate over i,j)
- actual concrete nesting order

The loop order will be important for implementations, as it will allow
for certain kinds of optimizations.

But. If everything is inside a single loop, then nothing is inside a
single loop.  The product _doesn't add any structure_.

So it appears that this entire exercise is about identifying reuse
patterns in nested loops.  And I am very naturally arriving at the
same approach as RAI, though with a separate optimization step.




[Reply][About]
[<<][rtl][>>][..]