Skip to content
Snippets Groups Projects
  1. Jul 03, 2008
  2. Jul 01, 2008
  3. Jun 26, 2008
  4. Jun 18, 2008
  5. Jun 13, 2008
  6. Jun 12, 2008
  7. Jun 09, 2008
    • Erwan Jahier's avatar
      Fix a bug in Lazycompiler: I was reordering variable declarations · 4fb31de3
      Erwan Jahier authored
      ordering in order to handle  clocks properly, but I forget to reorder
      them back for the interface variables!
      4fb31de3
    • Erwan Jahier's avatar
      Use type_eff_ext everywhere I was using type_eff (and rename · 00c67618
      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).
      00c67618
  8. Jun 06, 2008
  9. Jun 05, 2008
  10. Jun 03, 2008
    • Erwan Jahier's avatar
      Wrap the parser output with a new function, · e64e1031
      Erwan Jahier authored
      SolveIdent.recognize_predef_op  that  replaces  node call  by  Predef
      constructor  when   necessary,  via  a  complete   traversal  of  the
      SyntaxTree (instead  of doing it  in the parser). The  rationales for
      this change are that:
      
      - it is quite tedious to do it in parser as multiple locations are involved
      - I did missed some locations
      - It makes the parser more focused on parsing issues
      - that traversal  is a first step  do deal with  idref solving (hence
       the name of the new module that contains that function
      
      Note that lsrc/test/should_work/fab_test/lecteur.lus was using
      "plus" as a variable ident, which raised an error, which
      e64e1031
  11. May 30, 2008
  12. May 29, 2008
  13. May 27, 2008
  14. May 26, 2008
    • Erwan Jahier's avatar
      Add error messages when one tries to alaias a polymporphic or a · de984fca
      Erwan Jahier authored
      overloaded operator.
      
      Moreover, do not try to check that int or real constant are ok. It is
      the role of the host language.
      de984fca
    • Erwan Jahier's avatar
      I have complety rewritten the way predef operator typing is · b09c78c5
      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
      b09c78c5
  15. May 21, 2008
    • Erwan Jahier's avatar
      Add support to be able to use iterators in node aliases. · 65b93560
      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.
      6.13.0
      65b93560
  16. May 20, 2008
  17. May 16, 2008
  18. May 15, 2008
    • Erwan Jahier's avatar
      Fix a bug where, when defining a package exporting an abstract type · 16344043
      Erwan Jahier authored
      t, and a node returning such a t, the compiler was actually returning
      the type definition of t (instead of the abstract type).
      
      In  order  to fix  that,  it  was necessary  to  add  in argument  of
      Lazycompiler.solve_x_idref  a  flag  (named provide_flag)  indicating
      whether the  item being  compiled appears in  the provide, or  in the
      body part of the package.
      
      This fix  triggered another bug that  we also fix: indeed,  it is not
      correct to return  a compile error when the  provided parameters of a
      node is not equal to  its implementation. Indeed, such parameters can
      be abstract type that are defined in that package.
      
      The test "should_work/packEnvTest/packages.lus" is now ok.
      6.9.1
      16344043
  19. May 07, 2008
    • Erwan Jahier's avatar
      In symbolTab.ml, change · 956514c2
      Erwan Jahier authored
      	type 'a hereflagged =
      	  Here of 'a
      	| NotHere of Ident.long
      into
      	type 'a elt =
      	  Local of 'a
      	| Imported of Ident.long * static_arg list
      
      i.e., i am basically doing two things:
       - fix poor naming
       - adding static arg to nodes
      
      indeed, when compiling an equation that involves nodes defined
      in another package, I need to check that the static args and the
      static params match. Therefore I need to have the static params !
      Therefore I add them (I will use them in the next commit).
      
      Moreover, in SyntaxTreeCore.node_info, the static_params list was
      an option type, which is a bit weird (empty lists are enough to
      represent node with no static params).
      6.9.0
      956514c2
  20. May 02, 2008
  21. Apr 02, 2008
    • Erwan Jahier's avatar
      Add a --compile-all-items option, and use it in the non-regression · b6db7c6b
      Erwan Jahier authored
      tests.
      
      Also, Add the possibility to have several lustre files in the
      command-line arguments.
      
      remove the power operator.
      
      Define a lustre.lus that contains a packaged version of Lustre
      predefined operators. It will be in the standard lustre library,
      and should be accessible directly (path).
      6.8.0
      b6db7c6b
    • Erwan Jahier's avatar
      Add stuff to output the lic file. · 2b30a91d
      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.
      6.7.0
      2b30a91d
  22. Mar 28, 2008
  23. Mar 20, 2008
    • Erwan Jahier's avatar
      Add two new modules, Predef and PredefSemantics, that deals with predefined · 4c0a0b1f
      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
      4c0a0b1f
  24. Mar 17, 2008
    • Erwan Jahier's avatar
      Merge EvalType, EvalNode and EvalEq into a single module GetEff. · 64fca779
      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 !!!
      64fca779
  25. Mar 14, 2008
  26. Mar 11, 2008
    • Erwan Jahier's avatar
      Remove in node_info_eff the distinction between user nodes, and · f9408138
      Erwan Jahier authored
      predefined nodes. The idea is that the Predef module will contain
      all the necessary information to build a node_info_eff for each
      of the predefined operator.
      
      It migth makes thing more difficult to deal with overling, but we'll
      see later how to fix that. Anyway, not all the predefinef operator
      are overloaded, so...
      f9408138
    • Erwan Jahier's avatar
      Simplify the node_eff representation as well as change the names · 57431a16
      Erwan Jahier authored
      used in order to make it homogoneous with what is done in SyntaxTreeCore.ml
      
      This commit is related to the previous one actually.
      
      Also remove all this story of node_half_eff that is not
      used (yet), and that may not be useful (we'll see later).
      
      Also continue to fix the representation of SyntaxTrreCore.node_info :
       -> remove the node alias
       -> put the corresponding infomation in node_body field
       -> rename node_body field into node_def
       -> associate to node_def (instead of a body option) a new union
      type made of Abstract, Extern, Alias of ..., Body of ...
      
      This allows us to
       - remove an "assert false" to deal with node with body and alias
      (this new presentation makes it impossible)
       - Deal with Abstract node properly
      57431a16
    • Erwan Jahier's avatar
      Simplify significantly the node representation. The rational for this · 7f628ceb
      Erwan Jahier authored
      change is
      	- make the parser simpler
      	- make the compilation simpler
      	- make everything simpler actually...
      	- accepts more correct programs.
      	- etc.
      
      Indeed, before, we had specific syntax nodes for
      	- extern nodes
      	- aliased nodes
      	- abstract nodes
      	- normal nodes
      which leads to duplicate code everywhere. Now, we have a more generic
      representation.
      
      The nice thing is that the parser is much simpler, and a lot of
      duplicated code is avoided (for example, extern and abstract nodes do
      now share the same code).
      
      The bad thing is that we have more "assert false" lying everywere due
      to this «too rich» representation, in order to deal with cases
      that can never happen. For exemple, we have to do something with
      nodes that have  both an alias and a body. This cannot happen of
      course, so we issue an "assert false", which is a little bit painful,
      as it have been rejected by the parser anyway.
      
      Moreover, for some reason, external node params could not be clocked,
      and cannot have static params. Maybe it is not possible to compile
      such nodes (I don't know yet), but we should not raise a syntax error IMHO.
      
      Somehow, what was done was very similar to ask the parser to perform type
      checking.
      6.3.0
      7f628ceb
  27. Mar 06, 2008
Loading