- Aug 26, 2014
-
-
Erwan Jahier authored
-
- Aug 14, 2014
-
-
Erwan Jahier authored
nb : the -exec mode was working because I did not use the generated soc, which was completely wrong. Note that to do that, I have modified the CURRENT variant of Lic.val_exp, to attach it the clock the current holds on. Indeed, the clock is mandatory to generated correct code... In an ideal world, this clock information may have explicitely been set by the user ("current(clk_of_X,X)" instead of "current(X)"), but for historical reason, it is not the case. Hence, this information is added as soon as it is available, namely, during clock checking.
-
- Feb 13, 2013
-
-
Erwan Jahier authored
BTW, put everything that concerns node environement into the new IdSolver module (from the Lic module).
-
- Jan 31, 2013
-
-
Erwan Jahier authored
nb : do not work for lv4/ec mode
-
- Dec 13, 2012
-
-
Erwan Jahier authored
nb: les tests ne passent toujours bien sur. * Partie lus -> AST predef.ml -> srcPredef.ml syntaxTreeCore.ml -> astCore.ml syntaxTree.ml -> astV6.ml syntaxTreeDump.mli-> astV6Dump.mli * Partie Ast -> Ast solveIdent.mli -> astRecognizePredef.mli syntaxTab.mli -> astTab.mli symbolTab.mli -> astTabSymbol.mli * Partie AST -> lic (static evaluation) eff.ml -> lic.ml getEff.mli -> ast2lic.mli lazyCompiler.mli -> licTab.mli builtIn.ml -> licMetaOp.ml predefEval*.ml -> licEval*.ml name.mli -> licName.mli * Partie Lic -> Lic uniqueOutput.mli -> l2lCheckOutputs.mli structArrayExpand.mli -> l2lExpandArrays.mli nodesExpand.mli -> l2lExpandNodes.mli doNoPoly.ml -> l2lRmPoly.ml doAliasTypes.ml -> l2lAliasType.ml doSplit.ml -> l2lSplit.ml
-
- May 26, 2009
-
-
Erwan Jahier authored
maintaining (ugly and error-prone) hash tables. That change revealed an untriggered bug in EvalClock.check_args: it was wrong to add in subst the substitutions made of the parameters and the arguments (it is enough to unify the clocks of the pars and of the args). For instance, consider the node (in should_work/clock/clock.lus) node clock5(x : bool; y: bool when x; z: bool when y) and the call z2 = clock5(a, b when a, c when e); I was adding y/b in the subst, which was wrong. Other minor changes: - move const_to_val_eff from Eff to UnifyClock. - GetEff.translate_val_exp now returns a substitution, in order to be able to unify clock vars and propagate the resulting substitution.
-
- 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...
-