To run it, just launch just:

  cd test/
  make test.kcg

(which breaks lurettetop)

nb : Mamadou's change broke some tests (18->53). Empty body is
generated for nodes that have one eq.  I'll fix that later.

(which breaks lurettetop)

nb : Mamadou's change broke some tests (18->53). Empty body is
generated for nodes that have one eq.  I'll fix that later.

-kcg: forces the -esa(expand_arrays) option so that arrays walk with diese.We will see later how to treat properly the arrays.

-kcg: evaluates types enum and struct correctly.
-kcg: evaluates const correctly.

lus2lic -h shows the basic options
lus2lic -more shows more experimental options
lus2lic -dev shows experimental/internal  options

+ the utils/lustrequiv script that tries to state that 2 nodes a equivalent or not
using lesar and lurette.

Indeed, I've missed that case and have no nonreg test for -2ch

that I should have catched then. Sigh.

only affect array concat

by grouping instances of the same type into arrays.

The rationale is to be able to generate for loops with iterators.

The previous code was working, but probably by chance.

Actually, that was the default behavior. Now the default behavior is
to generate loops for iterators.

nb : with -2ch, loops are still always inlined

Indeed, an iterator is a kind of node.

combined with -cc, actually computes the wcet.

nb : only works if wcet tools are installed (owcet.arm, arm-elf-gcc)

combined with -cc, actually computes the wcet.

nb : only works if wcet tools are installed (owcet.arm, arm-elf-gcc)

That generated dummy main calls one step function and exits.

Imposes -2c.

Indeed, in order to sort Soc.gao, I currently process in 3 stages ;
1. compute a total ordering of Actions.t according to the deps
2. transform Actions.t into Soc.gao (List.map)
3. factorize Soc.gao by looking at consecutive gao that have the same guard

With this change, between steps 1 and 2, I reorder the list of actions
so that group of independent actions are sorted according to their
clock. The idea is of course to provide to step 3 more opportunities
of factorization.

The result is not very convincing yet.

I've also tried to sort the actions wrt their clock before performing
the toposort. Seems not too bad.

I've kept the old behavior by default though.

Indeed, having two different mechanisms is bad.

In the end, I've kept mine (and not the one of Pascal), because the
it was depending on LicPrg.t, which was creating a circular dep
(which could of course be fixed, but I am lazy).

by removing a unit test that does not work on win32 (because of bad path convention).

e.g., for arrays.

No test actually catches this bug.

Now all the tests that were ok in the heap mode are also ok in the
stack mode !

However the code generated for programs that use fillred and co is weird.

For instance, in should_work.pipeline.lus, in
fillred_oneStep_pipe_10_step, accu_in is used both as an input and an
output, which seems wrong in the stack mode as no copy is performed.

Is it working by chance ?