Contract resolution still need to be done as well as dealing with the machine code level and so on.

- Adapted the parsing of specification with a cocospec compatible one
- The data structure of contracts is now almost cocospec compatible
- Lustrec-test has been updated to use the newest syntax

Adapted the parser/types/constructors for cocospec syntax

- Renamed type declarations as lustre_types and machine_code_types

[general] large modification: added machine types, a second typing phase dealing with machine types (eg uint8)
          typing was transformed as a functor and parametrized by basic types (int/real/bool)
          it can also be applied multiple times on the same program

- EMF backend now impose the optimization level to be set to 0 in order to avoid equation elimination that would render traceability difficult
- Options.ml has been split into Options.ml / Options_management.ml. Options.ml only contains references and no functions

 - destination dir should now work properly
 - lusic files now have a version number, to avoid nasty segfaults
   when loading lusic files created by an older compiler version
 - inlining should now work with generic nodes and generic array library
 - tests_ok_dev.list has been added that focuses on advanced (but unused !)
   features of lustrec, avoiding the large 'kind' test files 

 - destination dir should now work properly
 - lusic files now have a version number, to avoid nasty segfaults
   when loading lusic files created by an older compiler version
 - inlining should now work with generic nodes and generic array library
 - tests_ok_dev.list has been added that focuses on advanced (but unused !)
   features of lustrec, avoiding the large 'kind' test files 


git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@443 041b043f-8d7c-46b2-b46e-ef0dd855326e

 - global constants were not accounted for
 - no good avoidance of name capture when inlining
 - static parameters (array sizes and clocks) not handled
 - ill-typed generated expressions, when inlining array expressions

 - global constants were not accounted for
 - no good avoidance of name capture when inlining
 - static parameters (array sizes and clocks) not handled
 - ill-typed generated expressions, when inlining array expressions



git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@434 041b043f-8d7c-46b2-b46e-ef0dd855326e

git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@426 041b043f-8d7c-46b2-b46e-ef0dd855326e

git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@333 041b043f-8d7c-46b2-b46e-ef0dd855326e

 - removed a potential source of bug in scheduler

 - removed a potential source of bug in scheduler


git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@330 041b043f-8d7c-46b2-b46e-ef0dd855326e

git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@329 041b043f-8d7c-46b2-b46e-ef0dd855326e

 - corrected several bugs in inlining
 - STILL, BUGS REMAINING in inlined code !!??!!

 - corrected several bugs in inlining
 - STILL, BUGS REMAINING in inlined code !!??!!


git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@328 041b043f-8d7c-46b2-b46e-ef0dd855326e

  - added interface files (.lusi) in the language, that can be compiled on their own, giving an object file (.lusic) and a header file (.h)
  - modular code generation, from Lustre to C level included.
  - nice amount of code refactoring

  - added interface files (.lusi) in the language, that can be compiled on their own, giving an object file (.lusic) and a header file (.h)
  - modular code generation, from Lustre to C level included.
  - nice amount of code refactoring



git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@326 041b043f-8d7c-46b2-b46e-ef0dd855326e

Moved backends in separate folders

Moved backends in separate folders



git-svn-id: https://cavale.enseeiht.fr/svn/lustrec/lustre_compiler/trunk@313 041b043f-8d7c-46b2-b46e-ef0dd855326e