- Feb 25, 2009
-
-
Erwan Jahier authored
extern constants.
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
as extern constants. Also fix a bug in the struct/array expanser: when expanding structured constants into val_exp, I need to add a entry into the type and clock val_exp tables.
-
- Feb 11, 2009
-
-
Erwan Jahier authored
- expr such as "current x,y" should be written "current (x,y)" - abstract struct or array types were handled as extern types, which prevent the struct and array expanser to work them out. In order to fix that, I have added an Abstract_type_eff variant to Eff.type_ which contains the concerte type.
-
- Feb 10, 2009
-
-
Erwan Jahier authored
2 source transformations), we add an entry in the EvalType and the EvalClock tables. Otherwise, when we use EvalType.lookup or EvalClock.lookup, an error migth be raised.
-
- Feb 09, 2009
-
-
Erwan Jahier authored
the moment, I just don't generate such operator anymore (i generate the polymorphic version Lustre::lt instead). I don't really know what is the better. fixing the v4 backend : print "+" instead of "Lustre::plus" (and ditto for the others).
-
- Feb 06, 2009
-
-
Erwan Jahier authored
i.e., transform x,y = (0,1) -> (a,b); into x = 0 -> a; y = 1 -> b;
-
Erwan Jahier authored
where generated in the --expand-nodes mode..
-
Erwan Jahier authored
-
Erwan Jahier authored
(i.e., tuple of size one).
-
Erwan Jahier authored
-
Erwan Jahier authored
with a non-empty body (instead of just the first node).
-
- Feb 05, 2009
-
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
some_clk" should be written "(x:some_type) when some_clk"
-
- Feb 04, 2009
-
-
Erwan Jahier authored
When a node P::n1 wants to access to a node P::n2, it is ok to search for it in the boby of P.
-
- Feb 03, 2009
-
-
Erwan Jahier authored
node, as UniqueOutput.check take as argument the source info with the original arity...
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
conjunction of some program transformation (-ei or -esa). In Lazycompiler.node_check_do, I've forgotten to put the node i/o in the local_env table in the case of node alias.
-
Erwan Jahier authored
nodes (e.g., map<<+,2>>). While fixing that, I put all the functions that deals with polymorphism into a new (Eponymous) dedicated module. The idea to be able to expand polymorphic node is basically the same, as the one for printing polymorphic nodes: we need to wait until the type is instanciated (in GetEff). That delay is implemented by using a stack of nodes.
-
- Jan 30, 2009
-
-
Erwan Jahier authored
an expanser to will expand only struct, and i whant to name it like that).
-
Erwan Jahier authored
For example, that kind of set of equations didn't trigger any error: x [1 .. 2][0][0].f1 = z ; x=y; nb : it was working if equations were ordered differently tough...
-
Erwan Jahier authored
-
- Jan 23, 2009
-
-
Erwan Jahier authored
-
- Dec 12, 2008
-
-
Erwan Jahier authored
In short, the rationale for this change, is that it is having a recursive node_exp is - useless, - too complicated, - wrong w.r.t. nesting iterator calls In long: - It is useless because, at the Eff level, a node cannot call itself via one of its static arg (which was where the recursivity came from). - and indeed, it is much simpler to consider that a static arg node can only be ident.long that identifies a node alias. This means of course, that nested iterators have been unnested before, inventing alias node names along the way... And polymorphism makes thing difficult once again. - But the *big* problem with a recursive node_exp is that it make things very complicated to (lic)dump nested iterator call because of polymorphism! Actually, it even makes thing complicated when the iterators were themselves not nested in the source code ! Some ugly things were done in LicDump to unnest those calls when printing node_exp. But this uglyness have a price: tricky code, and bugs! Indeed, nested iterators calls were wong for example when using the --inline-iterator mode (but i would not be surprised that is wrong in other cases...). Hence, LicDump is simpler, but of course LazyCompiler is more complicated. But this is reasonable: a pretty-printer is not supposed to be complicated.
-
- Dec 08, 2008
-
-
Erwan Jahier authored
-
- Dec 05, 2008
-
-
Erwan Jahier authored
+ more work on the release dir.
-
- Nov 28, 2008
-
-
Erwan Jahier authored
lustre-v6 release.
-
Erwan Jahier authored
-
Erwan Jahier authored
-
- Nov 26, 2008
-
-
Erwan Jahier authored
-
Erwan Jahier authored
-
- Nov 25, 2008
-
-
Erwan Jahier authored
To do that, we centralized the ident name creation into a new dedicated module Name. + fix should_work/NONREG/param_node.lus, we contained a combinational loop.
-
Erwan Jahier authored
The rationale for this change is that this is necessary for constants appearing static arg to be replaced. One problem is that they are handled in exactly the same way as top-level constants, which could be left un-expanded. I could make something in order to not expand those top-levelconstants, but is it worth the trouble ? To do that, I have changed sligthly the representation of Eff.ARRAY (the elements are now attached to the constructor itself, and the operands is empty) and the one of array constant (we attach to Array_const_eff a list instead of an array, for the sake of homogeneity) with what is done in Eff.val_eff.
-
- Nov 21, 2008
-
-
Erwan Jahier authored
-
- Nov 20, 2008
-
-
Erwan Jahier authored
-