Also, use rdbg instead of lurettetop to run the test.

Reference Manual enhancements.

so that w7/lesar can help otawa/ilp to prune path in the binary.

nb : not working on the convertible example:
 - sometimes the module name still appear in the ident (enums)
 - clocks are not well supported by Lesar actually. More thinking is necessary.

generates unvalid C code.

The bug was appearing a node was called on a non base clock that was
existing in the called nodes (name clash). Typically, it occurs on
recursive node called on some non-trivial clocks.

Also, use maps instead of list to hold the substitution between
params and args.

and replace enumerated clock in the var_info even if it does not
appear in a val_exp.

nb : luciole-rif is now  in the rdbg repo.

var_info appears in
- node decl
- left var
- static args

not yet working. I commit as Ive fix a missing dep on WenOnId in the _oasis.

More precisely, transforms equations of the form

   y = x when Toto(c);

into

   x when Toto_c ;
   Toto_c=Toto(c);

Rationale: the << normal mode >> (i.e., not translating enums) was
not even accessible!

The bug was (in soc2c.ml::137) that, for array of instances of size
n, it was generating n+1 initialisations, causing a seg fault.

Factorize duplicated code in gen_loop_file and gen_loop_file4ogensim
along the way.

Ditto for Misc and Compile

Indeed, otherwise, in some cases, rdbg or lurette migth not realise
that lus2lic exited in error.

More precisely, issuing an "exit 2" is not enough for the
should_work proc in test/site.exp to state that the test fails.

That fix revealed a certain number of bad programs.
Some were not really wrong ; there were just not respecting the
naming convention used to automated the test (i.e., main node name =
file name).

It also releaved a real bug due to the fact that type
instanciatiation is not propagated during model instanciatiation,
where creates a loop between (Lic2soc.process_node and
Lic2soc.soc_of_node). Indeed it searches in the soc the table for an
abstract profile.

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

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

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.

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 ?

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

However the code generated by 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 ?

Indeed, in order to copy an array, I used to generate something like

   memcpy(out, in, sizeof(in));

but if 'out' and 'in' are arrays, and if 'in' is an argument of a function,
sizeof() considers it as a pointer, not an array !!!!

note that if 'in' is a local var, sizeof(in) works fine.

To fix it, I use the type of the dest (instead of the id) as argument of sizeof.

nb : The pb never occured before, as in the heap mode only the ctx is
passed a args of step functions.

There were problems with:
- a clash in the node_loop.c file with the local 's' counter (oups).
- code generated for boolred
- code generated for arrow on arrays