2

Is it possible to "link" the STL to an assembly program, e.g. similar to linking the glibc to use functions like strlen, etc.? Specifically, I want to write an assembly function which takes as an argument a std::vector and will be part of a lib. If this is possible, is there any documentation on this?

jena
  • 8,096
  • 1
  • 24
  • 23
  • Do you need to populate the vector in the function? if its just to pass data to it you can write your function to accept normal arrays and pass `&vec.front()` as a parameter. – Node Jun 20 '11 at 14:30
  • Doing something with C linkage would be my plan A. – Node Jun 20 '11 at 15:03

2 Answers2

1

Any use of C++ templates will require the compiler to generate instantiations of those templates. So you don't really "link" something like the STL into a program; the compiler generates object code based upon your use of templates in the library.

However, if you can write some C++ code that forces the templates to be instantiated for whatever types and other arguments you need to use, then write some C-linkage functions to wrap the uses of those template instantiations, then you should be able to call those from your assembly code.

sehe
  • 374,641
  • 47
  • 450
  • 633
Kristopher Johnson
  • 81,409
  • 55
  • 245
  • 302
  • 1
    That code would be, simply e.g.: `template std::vector;` in one UT (cpp). Then use objdump -t or nm or similar to get the mangled names. Food for masochists :) – sehe Jun 20 '11 at 14:45
  • Sounds good, thanks for the explanation and the reference to objdump. :) – jena Jun 20 '11 at 14:53
  • If it was me, I wouldn't use the mangled names. I'd write some little C wrapper functions around each of the operations I need to use. – Kristopher Johnson Jun 20 '11 at 17:42
  • Kristopher: I wonder if that is worth the trouble, since the functions are probably compiler (and possibly -version) dependent anyway. Such precautions only apply to functions that have a standarized non-mangled signature. – Marco van de Voort Jul 08 '11 at 13:26
  • I think `extern "C" addObjectToList(void *list, void *object);` will be easier to maintain in the long run than using mangled names. – Kristopher Johnson Jul 22 '11 at 17:49
1

I strongly believe you're doing it wrong. Using assembler is not going to speed up your handling of the data. If you must use existing assembly code, simply pass raw buffers

std::vector is by definition (in the standard) compatible with raw buffers (arrays); the standard mandates contiguous allocation. Only reallocation can invalidate the memory region that contains the element data. In short, if the C++ code can know the (max) capacity required and reserve()/resize() appropriately, you can pass &vector[0] as the buffer address and be perfectly happy.

If the assembly code needs to decide how (much) to reallocate, let it use malloc. Once done, you should be able to use that array as STL container:

std::accumulate(buf, buf+n, 0, &dosomething);

Alternatively, you can use the fact that std::tr1::array<T, n> or boost::array<T, n> are POD, and use placement new right on the buffer allocated in the library (see here: placement new + array +alignment or How to make tr1::array allocate aligned memory?)

Side note

I have the suspicion that you are using assembly for the wrong reasons. Optimizing compilers will leverage the full potential of modern processors (including SIMD such as SSE1-4);

E.g. for gcc have a look at

  • __attibute__ (e.g. for pointer restrictions such as alignment and aliasing guarantees: this will enable the more powerful vectorization options for the compiler);
  • -ftree_vectorize and -ftree_vectorizer_verbose=2, -march=native

Note also that since the compiler can't be sure what registers an external (or even inline) assembly procedure clobbers, it must assume all registers are clobbered leading to potential performance degradation. See http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html for ways to use inline assembly with proper hints to gcc.

probably completely off-topic: -fopenmp and gnu::parallel

Bonus: the following references on (premature) optimization in assembly and c++ might come in handy:

And some other relevant resources

Community
  • 1
  • 1
sehe
  • 374,641
  • 47
  • 450
  • 633
  • Thanks a lot for the hints and the references! This is definitely interesting and helping. I should mention, however, that the aim is not to speed up the runtime performance of a program but rather its compilation time. – jena Jun 20 '11 at 15:23
  • Then by all means `s/assembly/ANSI C/g` and have a much easier time (read the rest unaltered) – sehe Jun 20 '11 at 15:24