Могу ли я написать (x86) язык ассемблера, который будет построен как с GCC, так и с MSVC?

Question

У меня есть проект, который полностью написан на C. Эти же C-файлы могут быть скомпилированы с использованием GCC для Linux или MSVC для Windows. По соображениям производительности мне нужно перезаписать часть кода как язык ассемблера x86.

Можно ли написать этот язык ассемблера в качестве исходного файла, который будет построен как с инструментами GCC, так и с MSVC? В качестве альтернативы, если я пишу исходный файл сборки для одной инструментальной цепочки, есть ли инструмент для его преобразования для работы с другим?

Или я застрял либо с сохранением двух копий исходного кода сборки, либо с помощью стороннего ассемблера, такого как NASM?

Answer 1

Я вижу две проблемы:

• MASM и газа имеют различный синтаксис. газ может быть сконфигурирован для использования синтаксиса Intel с директивой .syntax intel,noprefix, но даже тогда остаются небольшие различия (например, разные директивы). Возможный подход состоит в том, чтобы предварительно обработать ваш источник сборки препроцессором C, используя макросы для всех директив, которые отличаются друг от друга. Это также имеет преимущество в предоставлении единого синтаксиса комментариев.

  Однако использование портативного стороннего ассемблера, такого как nasm, скорее всего, будет сопряжено с трудностями.

• Linux и Windows имеют разные соглашения о вызовах. Возможным решением для x86-32 является придерживаться хорошо поддерживаемого соглашения о вызове, например, stdcall. Вы можете указать gcc, какое соглашение о вызове использовать при вызове функции, используя function attributes. Например, это объявить бы foo использовать stdcall соглашение о вызовах:

  extern int foo(int x, int y) __attribute__((stdcall)); 
  

  Вы можете сделать то же самое в MSVC с __declspec, решение этой проблемы.

  На x86-64 похожее решение, вероятно, возможно, но я не совсем уверен, какие атрибуты вы должны установить.

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