Mon Jan 28 10:57:23 CET 2013

The `bus' form

Also, it's probably best to do explicit binding of collection ->
element to avoid trouble later, and maybe write a "hack" form on top
of that.

Wow this takes time to sink in.
That's not what I decided yesterday!

I *can't* do explicit binding because of the state threading stuff.
The simplest way to solve this is to do implicit lifting, and just
make sure there is a loop context created.  Then to *undo* the lifting
using the `constant' form.

This corresponds to the way it is actually used, so even if it feels a
little dirty, it's probably best that way.

There is a problem however: the output is no longer flat, so it's
probably best to first fix that.

So how does the C code generator work?  It needs to know it is in a
loop context, so it can index any variable that is typed as a

The question then seems to be, do we insert a nested loop, or goto and

I think I got it.  Definitely, all temporary nodes should be scalar
nodes in a loop context, while input/output/state nodes are indexed.
It's probably enough to keep the dictionary global, but to insert
"begin" and "end" loop hooks that delimit the loop context.

This even fits in the SSA line syntax:

(i) (p_loop_begin 0 n)

() (p_loop_end)

This then translates to

_ i; for(i = 0; i < n; i++) {



EDIT: It seems to work.  I'm separating code generation and context
(loop) dependent variable mapping.

It's quite an intensive transformation though.  But it doesn't look
more dirty.  That's good.

Something to note: the state is interleaved in the wrong way.  The C
app doesn't care about this since the total state size is the same,
but it might be good to add this as a parameter.

  - actual sizes
  - propagate size to C compile time
  - const doesn't work - indexed access stx gets generated too early
  - trouble with (values 123 (bus ...)) (values in (bus ...))
  - accumulator doesn't work properly

Next: accumulator.

[1] http://llvm.org/docs/tutorial/LangImpl5.html