forum.alglib.net

1. Have you modified ALGLIB in order to make it compile with Code Composer Studio? If yes, what modifications you've done?
2. I don't think that it is possible to resolve your problem remotely, without debugging actual code. Can you help me to reproduce your compilation environment and settings? I've heard that Code Composer Studio can be downloaded for free, is it right?

Hi Sergey,

I didn't modified the codes. During compiling, I just add the "--exceptions" for the linker command. Yes, we can download the Code Composer Studio freely, but I'm not sure the differences using the simulator and the actual hardware (mine is OMAP-L137, C6747).

I'm going to test the ALGLIB with DSP/BIOS, the operating system of the board. It is still failed to compile, maybe because of mixing DSP/BIOS with C++ (your codes ?)

Hi Sergey,

When I test your test_c.cpp inside the Code Composer Studio, the codes (including the ALGLIB codes) compiled fine, since all of the codes are C++.

In code composer studio, in my project, I'm using DSP/BIOS, which use C. I cannot compile my codes when including your header files (eg. ap.h) even using the extern "C" command.

The Texas Instuments Compiler is C/C++ compiler. I've found this page (http://www.parashift.com/c++-faq-lite/m ... d-cpp.html) for mix the C and C++ codes. Do you think the modification of header files is necessary in order to use your codes in C++ codes ?

I'm quite new in C and C++, sorry if this is too basic questions.

ALGLIB for C++ is a C++ package. It is composed from two parts:
* computational core, which can be used from both C and C++ (and compatible with both of them)
* interface, which is C++ only
The mix of these two is a C++ package, so if you want to "use them from C++", you should just use them :)

The problem is how to use them from pure C... I think that it is impossible without significant rewrite (=reimplementation) of package interface. But you can try to use C core without C++ interface. ALGLIB for Python is a wrapper around C core (which is distributed without C++ interface). I recommend you to download Python version of ALGLIB, extract C core from it (easy to do) and to compile it with T.I.C. You can understand how to work with C core by looking at internals of alglib.c (Python-C interface) or by looking at code of corresponding wrapper functions from C++ interface.

Hi Sergey,

Thanks for all your support and answers. I've tried to use the Python-C codes. I've include the alglib.c, basestat.c and evd.c since I only want to use the covm and smatrixevd command. I received error in alglib.c: this declaration has no storage class or type specifier at every function header with DLLEXPORT (eg. DLLEXPORT int x_malloc(void **p, ae_int64_t size), line 29 in alglib.c).

Do you have any idea about any modification so that I can use in the Code COmposer Studio ?
Thanks Sergey.

Just remove DLLEXPORT, if you don't want to make DLL from this code. And I think that you will need more units, because evd.c/h uses 12 other units. You can see full list in the beginning of evd.h

Hello Sergey,

I can now compile the codes. I want to use malloc through ae_matrix data type. I don't understand what is ae_state for. I've declared ae_state by using

ae_state mystate;

and initialize using

ae_state_init(&mystate);

However, when I use this state to initialize my ae_matrix

ae_matrix_init(&cubetemp, row*col, band, DT_REAL, &mystate, ae_true);

I've got error. Then I tried to debug. In void* ae_malloc(), the aligned_malloc was successfull (not NULL), but since mystate above is not NULL, this has cause the error (line 175 of aenv.c).

Maybe I've initialize mystate in the wrong way. When debugging, I've tried to set mystate as NULL, and the ae_matrix_init was successfull.

Lines 174-175 of aenv.c are



if your aligned_malloc was successful, then it is not NULL, and you have no chance to jump to 175. No matter what value is stored in state pointer. Either a) you made mistake when describing your situation, b) something is wrong with your compiler, or c) you have memory corruption problem which influences control flow of your program.

About ae_state structure. It is used by computational core for several purposes:
1. to store environment-specific information (endianness, IEEE special quantities, etc.)
2. for error handling (either C++ exception handling or setjmp/longjmp-based exception handling, depending on preprocessor definitions during compilation).
3. for automatic memory management - to release memory allocated for local variables during exception handling process. When ALGLIB exception is generated (either C++ exception or C longjmp-based one), all local arrays which were registered as automatic are freed. List of automatically managed arrays is stored in the state structure. This list has multilayered structure - automatic variables are organized into frames, one frame per one nested function call. When you exit function, only top frame is cleared. When exception is thrown, all frames are cleared.

This structure must be manually deallocated when it is no longer needed. You can register you variable as automatic (as you did by specifying ae_true in the ae_matrix_init() call), but it means that your matrix will be destroyed after deallocation of the ae_state structure.

P.S. It may sound overcomplicated, but it allows ALGLIB to use same code both for C++ and C versions without any significant changes.

Hi Sergey,

It turns out that the NULL is not defined properly. It has been defined in std.h (from TI), but something goes wrong that makes it undefined in my program. After redefine the NULL operator in my program, I can use the covm and smatrixevd from your library. The results from the TI DSP are similar with the Visual C++.

Congratulation to you because your library can be used in an embedded platform now. Thanks for your support. And thanks for developing such library, the process to use it in Code Composer Studio is straight forward, just like in Visual C++, except for the issues that has been addressed in this thread.

Well done and many-many thanks.
Rizuan

Glad to hear that it works! Good luck with ALGLIB on this DSP :)

BTW, this NULL issue is very strange - such basic functionality should be supported by all modern compilers...