Использование контейнеров STL в GNU Assembler

Question

Можно ли "связать" STL с программой сборки, например, похоже на связывание glibc для использования таких функций, как strlen и т. д.? В частности, я хочу написать ассемблерную функцию, которая принимает в качестве аргумента std :: vector и будет частью библиотеки lib. Если это возможно, есть ли какая-либо документация по этому поводу?

Answer 1

Я твердо верю, что вы делаете это неправильно. Использование ассемблера не ускорит обработку данных. Если вы должны использовать существующий ассемблерный код, просто передайте необработанные буферы

std::vector по определению (в стандарте) совместимо с необработанными буферами (массивами); Стандартные мандаты непрерывного распределения. Только перераспределение может сделать недействительной область памяти, которая содержит данные элемента. Короче говоря, если код C ++ может знать требуемую (макс.) Емкость и reserve() / resize() соответственно, вы можете передать &vector[0] в качестве адреса буфера и быть совершенно счастливым.

Если ассемблерный код должен решить, как (сколько) перераспределить, позвольте ему использовать malloc. После этого вы сможете использовать этот массив в качестве контейнера STL:

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

В качестве альтернативы, вы можете использовать тот факт, что std::tr1::array<T, n> или boost::array<T, n> являются POD, и использовать размещение нового права на буфер, выделенный в библиотеке (см. Здесь: размещение нового + массив + выравнивание или Как заставить tr1 :: array выделять выровненную память? )

---

примечание

У меня есть подозрение, что вы используете сборку по неправильным причинам. Оптимизирующие компиляторы будут использовать весь потенциал современных процессоров (включая SIMD, такие как SSE1-4);

например. для gcc посмотрите на

• __attibute__ (например, для ограничений указателя такие как гарантии выравнивания и псевдонимов: это позволит использовать более мощные опции векторизации для компилятора);
• -ftree_vectorize и -ftree_vectorizer_verbose=2, -march=native

Обратите также внимание, что, поскольку компилятор не может быть уверен, что регистрирует внешние (или даже встроенные) блокирующие процедуры сборки, он должен предполагать, что все регистры засорены, что приводит к потенциальному снижению производительности . См. http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html о способах использования встроенной сборки с соответствующими подсказками для gcc.

вероятно, совершенно не по теме: -fopenmp и gnu::parallel

Бонус: могут пригодиться следующие ссылки на (преждевременную) оптимизацию в ассемблере и c ++:

• Оптимизация программного обеспечения на C ++: руководство по оптимизации для платформ Windows, Linux и Mac
• Оптимизация подпрограмм на языке ассемблера: руководство по оптимизации для платформ x86
• Микроархитектура процессоров Intel, AMD и VIA: руководство по оптимизации для программистов на сборках и производителей компиляторов

и некоторые другие соответствующие ресурсы

Answer 2

Любое использование шаблонов C ++ потребует от компилятора создания экземпляров этих шаблонов.Таким образом, вы не «связываете» что-то вроде STL в программу;компилятор генерирует объектный код на основе вашего использования шаблонов в библиотеке.

Однако, если вы можете написать некоторый код C ++, который заставляет шаблоны создавать экземпляры для любых типов и других аргументов, которые вам нужно использовать, тогда напишитенекоторые функции C-linkage, чтобы обернуть использование этих экземпляров шаблона, затем вы сможете вызывать их из вашего кода сборки.