Skip to content
Snippets Groups Projects
  1. Jan 14, 2016
  2. Sep 25, 2015
  3. Sep 23, 2015
  4. Sep 21, 2015
  5. Aug 20, 2015
  6. Aug 17, 2015
  7. Jul 10, 2015
  8. Jul 07, 2015
  9. Jul 06, 2015
    • Pascal Raymond's avatar
      Probleme des noeud parametrique definis dans un pack : · 03572aa0
      Pascal Raymond authored
      * la syntaxe est changee pour l'accepter
      * la stucture IdSolver (compil "lazy") contient maintenant
        "all_srcs" qui permet d'acceder si besoin a n'importe quelle info source,
        notamment les params statiques des noeuds identifies par "Pack::name"
      03572aa0
  10. Jul 03, 2015
  11. Jul 01, 2015
  12. Jun 25, 2015
  13. Jun 24, 2015
  14. Jun 23, 2015
  15. Jun 18, 2015
  16. May 22, 2015
    • Erwan Jahier's avatar
      Add a third level of options. · 71fc4b66
      Erwan Jahier authored
      lus2lic -h shows the basic options
      lus2lic -more shows more experimental options
      lus2lic -dev shows experimental/internal  options
      71fc4b66
  17. Apr 10, 2015
  18. Apr 08, 2015
  19. Mar 30, 2015
  20. Mar 24, 2015
  21. Mar 20, 2015
  22. Mar 18, 2015
    • Erwan Jahier's avatar
      lic2soc: try a few optimisation wrt Soc.gao scheduling and test opening. · 7d0da0b8
      Erwan Jahier authored
      Indeed, in order to sort Soc.gao, I currently process in 3 stages ;
      1. compute a total ordering of Actions.t according to the deps
      2. transform Actions.t into Soc.gao (List.map)
      3. factorize Soc.gao by looking at consecutive gao that have the same guard
      
      With this change, between steps 1 and 2, I reorder the list of actions
      so that group of independent actions are sorted according to their
      clock. The idea is of course to provide to step 3 more opportunities
      of factorization.
      
      The result is not very convincing yet.
      
      I've also tried to sort the actions wrt their clock before performing
      the toposort. Seems not too bad.
      
      I've kept the old behavior by default though.
      7d0da0b8
  23. Mar 03, 2015
  24. Feb 27, 2015
  25. Feb 24, 2015
  26. Feb 23, 2015
    • Erwan Jahier's avatar
      --2c--stack: fix a bug in code generated for array concat. · 5f3d50f1
      Erwan Jahier authored
      Now all the tests that were ok in the heap mode are also ok in the
      stack mode !
      
      However the code generated for programs that use fillred and co is weird.
      
      For instance, in should_work.pipeline.lus, in
      fillred_oneStep_pipe_10_step, accu_in is used both as an input and an
      output, which seems wrong in the stack mode as no copy is performed.
      
      Is it working by chance ?
      5f3d50f1
  27. Feb 13, 2015
    • Erwan Jahier's avatar
      --2c--stack: fix a bug in code generated for array concat. · f5802db0
      Erwan Jahier authored
      Now all the tests that were ok in the heap mode are also ok in the
      stack mode !
      
      However the code generated by fillred and co is weird.
      
      For instance, in should_work.pipeline.lus, in
      fillred_oneStep_pipe_10_step, accu_in is used both as an input and an
      output, which seems wrong in the stack mode as no copy is performed.
      
      Is it working by chance ?
      f5802db0
    • Erwan Jahier's avatar
      soc2c: fix a bug occuring when copying arrays with memcpy(). · fffd1850
      Erwan Jahier authored
      Indeed, in order to copy an array, I used to generate something like
      
         memcpy(out, in, sizeof(in));
      
      but if 'out' and 'in' are arrays, and if 'in' is an argument of a function,
      sizeof() considers it as a pointer, not an array !!!!
      
      note that if 'in' is a local var, sizeof(in) works fine.
      
      To fix it, I use the type of the dest (instead of the id) as argument of sizeof.
      
      nb : The pb never occured before, as in the heap mode only the ctx is
      passed a args of step functions.
      fffd1850
  28. Feb 12, 2015
Loading