То, что в x86 несколько разных опкодов соответствуют одной и той же инструкции, — отдельный печальный баг; к этому можно по-разному относиться (и/или по-разному эксплоитить), но я помню, как удивил меня автор досовского ассемблера A86 в каком-то бородатом году, когда прямым текстом заявлял, что «this [ambiguity] creates a code-generation "footprint" that occupies no space in your program file, but will enable me to tell, and to demonstrate in a court of law (выделение моё), if a non-trivial object file has been produced by A86. The specification for this "footprint" is sufficiently obscure and complicated that it would be impossible to duplicate by accident. I claim exclusive rights to the particular "footprint" I have chosen, and prohibit anyone from duplicating it. Any assembler that duplicates the "footprint" is mine (ditto)». По-моему, это какое-то редкостное мудачество.

Почему? Это как-то ухудшает качество ассемблируемой программы?

Да нет, конечно: можно же быть автором хорошего ассемблера и при этом мудаком. 🤷‍♀

Как-нибудь обоснуете, почему защита интеллектуальной собственности вас так сильно задевает за живое?

Кстати, в таких случаях лучше пинать одного админа или нескольких?

Нескольких, конечно. В полтретьего ночи меня в чате не бывает

Это ещё что! Недавние (или уже давние? 😱) исследования показали, что можно идентифицировать программиста по выхлопу оптимизирующего компилятора.

А насчёт footprint, помню, ещё в книжке "Идентификация конструкций языков высокого уровня" (или как бишь её) покойного Криса Касперски Борландовские компиляторы с завидным постоянством генерировали add eax -x вместо sub eax x.

С помощью машинного обучения ?))

Ага. А что?

Как знал))

Вы так говорите, как будто это что-то особенное. 😄

Там дополнительная инструкция инверсии x, или зачем-то есть вариант опкода add со встроенным изменением знака?

Ни то, ни другое. Речь про константы, и компилятор положительные сам менял на отрицательные и делал сложение.

Помнится, вычитание отрицательных вместо сложения тоже делал. Может, это была какая-то внутренняя шутка в Borland? А может и специальный footprint.

Не думаю, что между add и sub существует какая-либо значимая разница в скорости, поэтому ставлю на footprint

Я вот думаю, а собирал кто список всех оптимизаций +/-

все что я видел какое то очень не полное

Хотя конечно наверное это не имеет смысла, проше брать списки гланга или гцц

https://grosskurth.ca/bib/1997/cardelli.pdf
"Program Fragments, Linking, and Modularization" Luca Cardelli.

Статья поднимает вопрос корректности раздельной компиляции и линковки, и потому — я считаю — обязательна к прочтению для всех авторов языков программирования! 😃

Уже во введении на простейшем примере создания воображаемой программы, состоящей всего из двух модулей, разрабатываемых независимо, автор иллюстрирует, наверное, все проблемы, при этом возникающие. Между делом Карделли упоминает публичные репозитории артефактов (типа Maven Central или Nuget. Напомню, что статья опубликована в 1996 году!). Многие из обозначенных проблем линковки раздельно скомпилированных модулей до сих пор не решены ни в мейнстримных, ни в исследовательских языках.

В качестве основного результата Карделли предлагает, вероятно, первую формальную модель раздельной компиляции и последующей линковки, позволяющую строго рассмотреть вопрос о корректности этих процессов. Корректность в этом смысле приведённой простейшей системы модулей для просто типизированного лямбда-исчисления (в качестве модельного языка) формально доказывается. Автор, конечно же, указывает на необходимость расширения модели как в сторону более развитых языков (параметрический полиморфизм, ООП), так и в сторону более сложных систем модулей (параметризованные модули, "функторы" в духе Standard ML, первоклассные модули). Существуют ли такие работы, непосредственно продолжающие это исследование, мне не известно.

Однако, в качестве related work и дальнейшего чтения могу указать на работы по формализации (и доказательству корректности) раздельной компиляции для языка C в рамках проекта CompCert.

#separatecompilation #linking #modules #stlc