Рефакторинг разобранного кода

Question

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

Вы хотели бы сохранить функцию, которую вы написали, для удобства чтения, но вы хотели бы заменить свою собственную сборку на сборку компилятора.Есть ли какой-нибудь способ установить связь между вашей высокодоходной языковой функцией и новой сборкой?

Answer 1

Если вы смотрите на сборку, то справедливо предположить, что у вас есть хорошее представление о том, как компилируется код.Если у вас есть эти знания, то иногда возможно "реверсировать" изменения обратно на язык оригинала, но часто лучше не беспокоиться.

Произведенная вами оптимизация, скорее всего, будет очень незначительной по сравнению со временем и усилиями, необходимыми для первоначального внесения этих изменений.Я бы посоветовал вам оставить такого рода работу компилятору и пойти выпить чашечку чая.Если изменения значительны, а производительность критична (как, скажем, во встроенном мире), то вы можете каким-то образом смешать обычный код с ассемблером, однако на большинстве компьютеров и чипов производительности обычно достаточно, чтобы избежать этой головной боли.

Если вы в самом деле нужна большая производительность, тогда оптимизируйте код, а не сборку.

Answer 2

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

Я бы настоятельно не советовал заниматься такого рода оптимизацией, потому что, если вы не уверены с помощью профилирования и анализа, что вы действительно что-то меняете.

Answer 3

Это зависит от языка, на котором вы написали свою функцию.Некоторые языки, такие как C, являются очень низкоуровневыми, переводя каждый вызов функции или оператор в конкретные инструкции assembly.Если вы действительно использовали C, вы можете заменить свою функцию встроенной сборкой для повышения производительности.

Другие языки высокого уровня могут преобразовывать каждый оператор в макропрограммы или другие более сложные вызовы на стороне сборки.Определенные оптимизации (такие как хвостовая рекурсия, развертывание цикла и т.д.) Могут быть легко реализованы на стороне исходного кода, но другие (например, более эффективное использование файла register) могут быть невозможны (опять же, в зависимости от языка и используемого вами компилятора).

Answer 4

Трудно сказать, существует ли какая-либо связь между измененной сборкой и исходным кодом, который сгенерировал неизмененную версию.Это, безусловно, приведет к путанице в инструментах отладки:содержимое регистра больше не будет соответствовать исходным переменным, которым они должны были соответствовать.

В коде обработки пакетов есть несколько мест, где я изучил сгенерированную сборку и вернулся к изменению исходного кода, чтобы улучшить результат.Перестановка исходного кода может уменьшить количество ветвей, __атрибут___ и аргументы компилятора могут выровнять точки ветвления и функции, чтобы уменьшить количество пропусков.В крайних случаях можно использовать небольшую встроенную сборку, чтобы двоичный файл все еще можно было скомпилировать из исходного кода.

Answer 5

Что вы могли бы попробовать, так это отделить вашу исходную функцию от ее собственного файла и предоставить правило make для сборки ассемблера оттуда.Затем обновите файл assembler своей улучшенной версией и предоставьте правило make для создания объектного файла из файла assembler.Затем измените свои правила ссылок, чтобы включить этот объектный файл.

Если вы только когда-либо измените файл ассемблера, он будет продолжать использоваться.Если вы когда-либо измените исходный языковой файл более высокого уровня, файл ассемблера будет перестроен, а объектный файл собран из новой (неулучшенной) версии.

Это дает вам связь между этими двумя;вероятно, вы захотите добавить предупреждающий комментарий в верхней части языкового файла более высокого уровня, чтобы предупредить об этом поведении.Использование той или иной формы VCS даст вам возможность восстановить улучшенный файл ассемблера, если вы допустите здесь ошибку.

Answer 6

Если вы пишете собственное скомпилированное приложение на Visual C ++, существует два метода:

1. Используйте __asm { } заблокируйте и запишите туда свой ассемблер.
2. Запишите свои функции в МАСМ ассемблер, соберите в файл .obj и свяжите его как статическую библиотеку.В вашем коде на C / C ++ объявите функцию с помощью extern "C" декларация.

Другие компиляторы C / C ++ имеют аналогичные подходы.

Answer 7

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