Jump to content

Philipp A Hartmann

Members
  • Content Count

    485
  • Joined

  • Last visited

  • Days Won

    117

Everything posted by Philipp A Hartmann

  1. Philipp A Hartmann

    Memory leak with concatenation operator

    Ok, after having a closer look at your code, I know remember that a similar issue has popped up very shortly before the release of SystemC 2.3.0. On Microsoft VC++ something strange has been going on in the sc_concatref conersion to sc_big(u)int, which especially affects the comparison operator in certain corner cases. Your workaround is known to avoid this problem. Since a "hotfix" made it into the 2.3.0 release (see src/sysc/datatymes/misc/sc_concatref.h:247, and we have not observed this (or a similar) problem on other platforms, we need more information from your side: SystemC version (Accellera's 2.3.0, right?) platform, compiler, compiler flags compile/runtime warnings and errors a self-contained code sample, preferable less than 100 lines, demonstrating the problem Any valgrind and purify reported memory leaks are probably false positives here. Reported accesses to uninitialized memory may be a better indication for the bug's origin. Can you paste the (first) related error in this case? You can also download the SystemC regression test suite from the accellera.org website and check the systemc/datatypes/misc/concat/test07 test case, which has originally triggered the related issue on MSVC. Greetings from Oldenburg, Philipp
  2. Philipp A Hartmann

    Memory leak with concatenation operator

    A memory leak would not cause "random results". It would just consume more memory. Can you post some information about these "random results"? Secondly. whether or not a memory leak exists requires more details as well. The reports from Valgrind and Purify could be false positives as well, especially since there are memory pools used behind the scenes. Why do you suspect a memory leak here? Greetings from Oldenburg, Philipp
  3. Philipp A Hartmann

    SystemC 2.3.0 with main()

    If you look at the error message more closely, the problem is not caused by the existence of your "main" function, but by the missing sc_main function. The main reason for this is the preferred use of the dynamic library since SystemC 2.3.0. The dynamic libraries needs the sc_main symbol to be present, as you cannot decide during the (dynamic) linking step, if this function is actually called or not. Two solutions are possible link against the static library libsystemc.a (e.g. by moving libsystemc.so out of the way) add an (empty) sc_main Greetings from Oldenburg, Philipp
  4. Philipp A Hartmann

    sc_signal<vector<T> >

    The "NewVector" class proposed by AR/Ravi in the linked post is a class template already. Therefore, you should be able to define the missing functions (==,<<,sc_trace) for all datatypes T based on T's operations elementwise. sc_vector<T> is meant for vectors of SystemC object (moduls, signals, ports). The element type of a signal is not covered here. I'm not aware of any proposal to add a "signal-aware" element vector class to SystemC.
  5. Philipp A Hartmann

    Sensitivity inside the constructor

    The method process will be run once in the initialization phase of the simulation. [see 1666-2011, Section 4.2]. NB: Please try to post working code and wrap it in a [code] [/code] block to enable C++ highlighting.
  6. Just read the linked article, I posted in my earlier reply. You just can't use placement new with 'this' inside the constructor, period. You have not shown any reason, why you need to use delegating constructors. You can either use default parameters, or duplicate the constructor body, or use an intermediate base class, which always receives "all" constructor parameters No, you did not succeed. Your code still has "undefined behaviour", which just seems to work correctly. Yes, there is quite some magic in sc_module, like handling the SystemC object hierarchy, etc. That's what I said: you mess up the lifetimes of the internal (sub-)objects. It's just undefinied behaviour in C++ and you can't use this approach.
  7. It just means, what you already quoted: You can use your Loader_Scheduler, you just can't create new signals (or other primitive channels) dynamically during simulation.
  8. The feature you're looking for is called "delegating constructors" in C++11. It is not possible in C++03. Your solution is just plain wrong. You'd run the sub_module contructor twice, but the destructor would be run only once. See this article for a more detailed explanation of what happens. One option could be to use default parameters instead: sub_module( sc_core::sc_module_name n , int a = t1, int b = t2, int c = t3 ) : sc_core::sc_module(n) { // ... }
  9. Philipp A Hartmann

    Installation problems on Ubuntu 12.04

    It's a local problem, not related to SystemC itself. Make sure, that you have 'executable' permissions on this file (chmod a+x ...src/sysc/qt/config) the partition, you're building on, is not mounted with the "noexec" flag Greetings from Oldenburg, Philipp
×