Ports array (size)

[lfranz]

Hello fellows,

I'm working on a big design and i am facing a "segmentation fault" problem. I debug it a lot but i am in doubt in how much big can be a port vector. For exemplo, an sc_in<double> input[1024] is too big to systemc handle it?

Someone knows if the systemc has a limitation on the size of ports array?

any information can be helpfull.

[apfitch]

I don't think there's a limitation. However you might be running into some stack limit in your compiler. Try creating a dynamically allocated array, e.g.

sc_in<double> * input;

then allocate the memory using new in the constructor.

regards

Alan

P.S. Or perhaps sc_vector would help in SystemC 2.3.0?

[dakupoto]

Hello,

Segmentation faults are caused mostly when one attempts

to dereference a NULL pointer. So, if ports array that you

use is to be created dynamically, you have to ensure that

it is actually created, before trying to add any element to it,

especially when as you mention, it is a complicated/large

design. Hope that helps.

[lfranz]

Thank you for the reply!!

I will try to make it dynamically. If i have success i will comment.

Regards.

[lfranz]

Hello,

I was investigating the problem and it seems that the stack of my linux is limited to 10240 (ulimit -s). I don't ahve to much experience with the memory allocation but my question is: it is a better approach to modify the stack or to make dynamic allocation on my systemc program? the problem is tht if i have to modify the systemc the hand work will be very big.

Thank you for the help!!!

[apfitch]

I guess you've answered your own question :-) , as it sounds like you feel the work to modify your code is too much.

However if you can afford the time, then using dynamically allocated memory is better. Suppose you want to run the code on another operating system in the future? Or give the code to someone else to run? Then using dynamic memory allocation makes it more likely your code will work on other OS, or for someone else.

Often in electronics (and life!) there is the "80/20" rule where most of the problem lies in the 20% area - perhaps you can reduce the problem by attacking just the "20%" and leaving other code untouched?

Good luck!

Alan

[dakupoto]

Respected Sir,

In my humble opinion, how is dynamic memory allocation

related to (a) operating system or ( different user using

a piece of code

Using static allocation forces the programmer to analyze

the problem to be solved, in a disciplined manner, removing

the irritating issue of tracking down segmentation faults/

memory leaks -- when a 'new' is not followed by a matching

'delete' -- especially in a large complicated design with lots

of interacting modules.

Also, if someone provides a large piece of code, and I do

try to understand the guts of it, then I am headed for

trouble.

[maehne]

I agree with Alain,

You should opt for dynamic allocation of your memory -- in this case for your array of ports. By using a container such as

sc_vector

from SystemC 2.3 or

boost::ptr_vector

from Boost, the deallocation of the dynamic memory will be automatically handled upon the destruction of the surrounding module or, in general, when the current context is exited. The dynamic allocation of the ports has the additional advantage that you can explicitly call each individual constructor with the necessary arguments to achieve the correct naming of the ports in your design hierarchy.

If these containers do not fit your needs using the smart pointers (e.g.,

shared_ptr<T>

,

weak_ptr<T>

,

unique_ptr<T>

) provided by C++ 11, C++ TR1 or Boost may be an alternative. They make handling of dynamic memory much safer, as they also handle the automatic deletion upon context exit or when no one is anymore referencing memory.

Best regards,

Torsten Maehne

[lfranz]

Thank for the reply!!!

I will extend the limit of my stack memory for now as a fast solution. In the future release of the code i will use some dynamic allocation. Once again thank you for the tips!!

[apfitch]

Hi Dakupoto,

in my experience, gcc on Linux generally has much more stack "out of the box" than Visual C++ - I think Visual C++ defaults to about 1MByte of stack.

Regarding different users - see the comment above about ulimit... environment changes for each user can affect the amount of stack as well.

If you use dynamic memory, it shouldn't matter how much stack the compiler allocates by default, or how much the user environment/sysadmin gives each user/process,

regards

Alan

[david.wcc]

Hi :

I would like to provide my experience of programming on both Qt and Visual C++ platforms. Yes, there is a limitation for the compiler specially when you program with a thread(process). It will shunt down if you generate a large file up to around 500M byte with a thread under Qt platform . Although I modified codes by using the dynamic allocation, it still shunt down. Finally, i just re-wrote it under console mode(DOS mode). Recently, i try the new version of visual C++, it can generate a file up to 7G bytes with a thread.

By the way, Bjarne Stroustrup(creator of C++) has an idea for a simple GC as bellow :

// ConsoleApplication1.cpp : Defines the entry point for the console application.

//

#include "stdafx.h"

#include <iostream>

#include <map>

#include <vector>

using namespace std;

class Register {

map<void*,void (*)(void*)> m;

public :

void insert(void* po, void (*pf)(void*)) { m[po]=pf;}

void remove(void* po){m.erase(po);}

void showInf(){cout<<"There are "<<m.size()<<" shape elements "<<endl;}

};

Register cleanup_register;

class shape {

protected :

int x,y;

static void cleanup(void* pv)

{

shape* px = (shape*)pv;

cleanup_register.remove(px);

// delete px;

}

public:

shape(int vx, int vy)

{ x=vx; y=vy; cout<<" shape constructor "<<endl;

cleanup_register.insert(this,&cleanup);

}

~shape(){ cleanup(this); }

virtual void draw()=0;

};

class circle : public shape{

int z;

public:

circle(int vx, int vy, int vz):shape(vx,vy){ z =vz ; cout<<" circle constructor "<<endl;}

void draw(){ cout <<" is a circle at "<<x<<" : "<<y<<" : "<<z<<endl;}

};

class line : protected shape{

int z;

public:

line(int vx, int vy):shape(vx,vy){ cout<<" circle constructor "<<endl;}

void draw(){ cout <<" is a circle at "<<x<<" : "<<y<<endl;}

};

int _tmain(int argc, _TCHAR* argv[])

{

vector<shape*> shapeVector0;

vector<shape*> shapeVector1;

vector<shape*> shapeVector2;

shapeVector0.push_back(new circle(4,7,5));

shapeVector0.push_back(new circle(4,7,5));

shapeVector0.push_back(new circle(2,5,7));

shapeVector1.push_back(new circle(6,8,3));

shapeVector1.push_back(new circle(4,7,5));

shapeVector1.push_back(new circle(1,4,6));

shapeVector2.push_back(new circle(2,4,7));

shapeVector2.push_back(new circle(5,7,6));

shapeVector2.push_back(new circle(1,5,7));

cleanup_register.showInf();

system("Pause");

return 0;

}

The result will be .............

shape constructor

circle constructor

shape constructor

circle constructor

shape constructor

circle constructor

shape constructor

circle constructor

shape constructor

circle constructor

shape constructor

circle constructor

shape constructor

circle constructor

shape constructor

circle constructor

shape constructor

circle constructor

There are 9 shape elements