- 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.
-
- 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...
-
- Jun 09, 2008
-
-
Erwan Jahier authored
type_eff_ext into type_eff btw). The rationale is to be able to type alias on polymorphic nodes (cf test/should_fail/semantics/bad_call03.lus, that now have a correct error msg). It also makes to code more compact (no more translation from one to the other), and more general (type_eff_ext being more general than type_eff). User polymorphic nodes should be easy now. move all the code in parsey.mly into parserUtil.ml (ease the debug).
-
- Jun 06, 2008
-
-
Erwan Jahier authored
equations is not done at all yet). Also, print the clock decorations (when clk) in the generated file.
-
- May 26, 2008
-
-
Erwan Jahier authored
performed. The resulting code is both more compact, and more general. It is more general, since that predef operators are now represented by node_exp_eff, exactly as user nodes. Hence, all the functions that were operating on user nodes via node_exp_eff (such as, node aliasing) works for free on predef op! In order to be able to perform that generalisation, it was necessary to extend sligthly the data structure used to represent the node profile in CompiledData.node_exp_eff with information indicating if a variable is polymorphic or overloaded. Not that, currently, polymorphic or overloaded variables can only be introduced by predef operators. But I think it would be easy to add those notions for normal user nodes after this change. New non-reg files boolred now compiles. Those involving - boolred - alias on predef.op
-
- May 21, 2008
-
-
Erwan Jahier authored
Also, node aliased to other nodes were handled poorly: I was replacing in the syntax tree the node by its alias. Now, I really define the alias node using the aliases one. For instance, node toto(x:t) returns (y:t); let ... tel node titi = toto; node tutu(...) returns(...); let ... z = titi(a); tel was compiled into node toto(x:t) returns (y:t); let ... tel node tutu(...) returns(...); let ... z = toto(a); tel Now, I generate node toto(x:t) returns (y:t); let ... tel node titi(i1:t) returns (o1:t); let o1 =toto(i1); tel node tutu(...) returns(...); let ... z = titi(a); tel which is equivalent, but closer to the original program.
-
- Apr 02, 2008
-
-
Erwan Jahier authored
For non-regression tests, do not use Lazycompiler.test function anymore and just use LazyCompiler.node_check instead. put in the new file compiledDataDump.ml all the stuff related to string convertions of CompiledData items.
-
- Mar 28, 2008
-
-
Erwan Jahier authored
and anonymous structures. I've even found some type errors in the non-reg files!
-
- Mar 20, 2008
-
-
Erwan Jahier authored
operators. Predef contains the abstract syntax of those operators (taken for SyntaxTreeCore.by_pos_op), and PredefSemantics contains: - const_eval: that says how to statically evaluate constants - type_eval: that provides the type profile of predef operators - clock_eval: that provides the clock profile of predef operators The code in EvalConst that dealt with predef const evaluation is now in Predef.const_eval
-
- Mar 17, 2008
-
-
Erwan Jahier authored
EvalNode.f -> GetEff.node, EvalType.f -> GetEff.typ, EvalEq.f -> GetEff.eq EvalConst.f (val_exp -> const_eff list) should have been put there too, but in fact EvalConst.f ougth to be splitted in two parts: - val_exp -> val_exp_eff (but this function already exist) - val_exp_eff -> const_eff list Therefore, the signature of EvalConst.f will be changed to: val_exp_eff -> const_eff list (and will use GetEff.val_exp) Ditto for eval_array_index. eval_array_index : CompiledData.id_solver -> SyntaxTreeCore.val_exp -> int -> int ougth to be splitted into two functions: - CompiledData.id_solver -> SyntaxTreeCore.val_exp_eff - SyntaxTreeCore.val_exp_eff -> int -> int Ditto for eval_array_size eval_array_size : CompiledData.id_solver -> SyntaxTreeCore.val_exp -> int ougth to be splitted into two functions: - CompiledData.id_solver -> SyntaxTreeCore.val_exp_eff - SyntaxTreeCore.val_exp_eff -> int arg... evalConst.f est utilis par GettEff.typ !!!
-