- Mar 09, 2009
-
-
Erwan Jahier authored
constants that are not on the base clock, add the suitable "when" statement if it was not present in the source code (the lic (and the ec/lv4) backend does not perform such kind of clock inference for constants.
-
- 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.
-
- Jan 30, 2009
-
-
Erwan Jahier authored
-
- Sep 15, 2008
-
-
Erwan Jahier authored
change the parser and accept only clock expressions after a when. A clock is now made of 2 idents: one for the clock constructor, and one for the clock variable.
-
- Aug 29, 2008
-
-
Erwan Jahier authored
-
- Aug 28, 2008
-
-
Erwan Jahier authored
-
- Aug 19, 2008
-
-
Erwan Jahier authored
as many new local variables as necessary so that an expression is made at most of one operator. The rational for that is to obtain a lic code that is trivial to clock check (nested node calls, for example, make it less simple). The old behavior can still be obtained using --keep-nested-calls. During that change, I realised that I did not clock check asserts. Hence, I have also added this check.
-
- Jun 26, 2008
-
-
Erwan Jahier authored
clock_info, and therefore also remove clock_info. The rationale of this change is that it makes things slightly simpler, and more homogeneous with what is done in type checking.
-
Erwan Jahier authored
Not yet implemented (assert false): iterators, struct Add a UnifyClock module, and rename Unify into UnifyType. nb : a lot of test are now broken, because - the clock checking is now plugged ;-) - iterators, struct are not yet implemented
-
- Jun 12, 2008
-
-
Erwan Jahier authored
It does not work, I have changed my mind to use a more general clocking algorithm based on unification. I commit that current state just in case I change my mind again...
-