- Jun 19, 2020
-
- Aug 29, 2019
-
-
erwan authored
Remove a lot of warnings (considered as errors by dune).
-
- Aug 18, 2017
-
-
erwan authored
And it is now done only by Lic2soc (L2lCheckLoops is not used anymore) Also, during this change, I was bitten again by the « "__" versus "::" in ident names » problem again. The core of this problem is due to the fact that I use LicDump both for (1) dealing with internal ident names (2) generating lustre files Because of (2), ident names may depend on the ec or the v4 option. hence, internal names were sometimes translated with "__" instead of "::". To (try to) fix that, I've added a boolean flag to all "to_string" functions that states whether the function is used for internal purposes, or for generating lustre files. It was quite a boring change, that triggered other problems, that I've fixed in this (too long) commit : - -esa should force -en, otherwise bad things happen (-esa is used for -ec anyway) - in -esa mode, #/nor inputs tuples of bool, not arrays - fix the list of predi op that returns a type different that its arg (SocPredef)
-
- Jul 18, 2017
-
-
erwan authored
It is useless (I hope) and it sometimes creates combinatory loops.
-
- Jul 04, 2017
-
-
erwan authored
To do that, I have created a new dedicated module L2lExpandEnum, that actually also deals with -eei (which was probably wrong, even if I have not counter-exemple). Use 1-hot encoding instead of log-encoding I've fixed a bug in L2lExpandArrays that occurs on equation such as some_bool = (some_array1 = some_array2); Also, I've rewritten Lv6Compile for more readability Remove duplicated code when using SocMap.find and co
-
- Jun 20, 2017
- Nov 30, 2016
-
-
Erwan Jahier authored
nb : i have changed the var name in the generated nodes, which was a bad idea (=painful to get it rigth again).
-
- Oct 25, 2016
-
-
Erwan Jahier authored
-
- Aug 26, 2016
-
-
Erwan Jahier authored
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.
-
- Feb 03, 2016
-
-
Erwan Jahier authored
by - remove duplication (add a profile_info function ine Lv6Verbose - be more efficient (computing Sys.time only when necessary - control the time-profiling printing via the -dbg flag "profile", and not the verbosity level
-
- Jan 14, 2016
-
-
Erwan Jahier authored
Ditto for Misc and Compile
-
- Mar 03, 2015
-
-
Erwan Jahier authored
-
Erwan Jahier authored
Indeed, having two different mechanisms is bad. In the end, I've kept mine (and not the one of Pascal), because the it was depending on LicPrg.t, which was creating a circular dep (which could of course be fixed, but I am lazy).
-
- Jan 22, 2015
-
-
Erwan Jahier authored
-
- Jan 21, 2015
-
-
Erwan Jahier authored
- predef Lustre op were declared as memoryful. - expr like "if true then ..." were badly translated - The clock and types of some expressions created by L2lOptimIte had a bad arity (in presence of tuples) - in order to perform the -oite optim, also check that each branch is safe.
-
- Jan 19, 2015
-
-
Erwan Jahier authored
Indeed it is possible when each branch of the ite updates no memory. This is done in the new L2lOptimIte module. For the time being, it does detect when the node has no memory. It only looks at the declaration: nodes have memory, and not functions. I should infer that information and raise warnings or errors if what I infer is not compatible with waht is declared (will come later). Also split ActionsDep into ActionsDep and Action. Also fix a bug in L2lsplit where deeply nested (>2) merge were not splitted.
-
- Sep 04, 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.
-
- Jan 22, 2014
-
-
Erwan Jahier authored
More specifically, replace @ by rev_append and flatten+map by fold_left. On a file that has 11000 equations (normal.ec), I win a factor 4: 60s -> 15s
-
- May 28, 2013
-
-
Erwan Jahier authored
The test now runs in 150s (versus 417s) [...] for some reasons, i cannot reproduce the 150s !!!
-
- Apr 26, 2013
-
-
Erwan Jahier authored
(to be kind with data plotters).
-
- Apr 12, 2013
-
-
Erwan Jahier authored
As far as ldbg is concerned, it only traces the toplevel node, at call event. Note that I needed to rename quite a lot of modules to avoid name clashes between lus2lic.a and ltop. I've also merged the Verbose module with the one of Lutin so that they can be shared (there were sharing 95% already).
-
- Apr 05, 2013
-
-
Erwan Jahier authored
In order to do that, I've generalised the type of merge : now the clock argument can be any expression. Some assert false still prevent its use, but it should be easy to get rid of them (I'll do that latter).
-
- Apr 03, 2013
-
-
Erwan Jahier authored
nb : programs do run, but I did not check that they run correctly... Also fix a regression introduced in the previous change where incorrect ec code was generated for diese.
-
- Mar 27, 2013
-
-
Erwan Jahier authored
1) At the Lic level, there's no reason to distinguish betwenn node calls, and predef node calls. Indeed it makes things simpler and more homogeneous afterwards. 2) int strings are only converted when necessary (constant evaluation). 3) const are handled directly under Lic.by_pos_op instead of being under PREDEF_CALL, which make things easier and more logical.
-
- Mar 25, 2013
-
-
Erwan Jahier authored
-
- Feb 20, 2013
-
-
Erwan Jahier authored
-
- Feb 06, 2013
-
-
Erwan Jahier authored
-
Erwan Jahier authored
Pascal prepared « the field » for that change.
-
- Feb 04, 2013
-
-
Erwan Jahier authored
The only culprit was the one in unifyClock.ml::249, but I've lazyfied most of the non-trivial verbose call. The 2 remaining unresolved testq that were timeout-ing now pass in a few ms... The whole non-reg test time has been divided by more than 2!
-
- Jan 31, 2013
-
-
Erwan Jahier authored
nb : do not work for lv4/ec mode
-
- Jan 16, 2013
-
-
Erwan Jahier authored
It was beacause the tables in LicVarName were cleaned and because the way this module work sucks...
-
Erwan Jahier authored
on programs containing equations such as : b3, b4, b5, b6 = (three_outputs(two_outputs(b1,b2),true), false); because TUPLES where not correctly inlined (i.e., "...= n((x,y),z)" instead of "...=n(x,y,z)"
-
- Jan 11, 2013
-
-
Erwan Jahier authored
nb : I've transformed all the regressions I've seen into todo entries in todo.org. nb 2 : I did not mv the newly broken tests into the broken dirs. I'll do that for those I do not want to fix in the short term.
-
- Dec 18, 2012
-
-
Erwan Jahier authored
-
- 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
-
- Aug 10, 2012
-
-
Pascal Raymond authored
- plus de macros prefefinies (e.g. FILL, BOOLRED etc...) (remplacé par la notion de BuiltIn) - split.ml adapté et remanié pour rentrer dans le moule source to source (voir DoSplit)
-
- Jul 13, 2012
-
-
Pascal Raymond authored
IDENT remplacé par VAR_REF/CONST_REF - plus de node_exp dans les CALL, juste une ref (node_key) - reste a faire pareil pour les NodeStaticArgEff
-
- Jul 12, 2012
-
-
Pascal Raymond authored
-