Насколько непереносим ассемблер, / действительно /? - PullRequest
6 голосов
/ 18 сентября 2009

Я понимаю, что написание чего-либо в сборке или добавление сборки в любую программу вредит ее переносимости. Но как плохо? Я имею в виду, что в настоящее время все ПК имеют x86 или x64, верно? Итак, если я встраиваю сборку в программу на C, почему она все равно не скомпилируется, куда бы она ни шла?

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

Компьютерная игра "Roller Coaster Tycoon" была написана почти полностью на ассемблере, если я правильно помню. Итак ... Как это может быть непередаваемо?

Ответы [ 4 ]

16 голосов
/ 18 сентября 2009

Помимо самого процессора, всегда есть и другие соображения: каковы соглашения о вызовах на вашей целевой платформе? Как struct значения передаются другим (скажем, API) функциям? Какие регистры могут быть засорены вызываемым абонентом? Что гарантированно будет сохранено для звонящего? Как сделать системный вызов? Какая схема памяти подготовлена ​​для вас ОС при запуске процесса?

11 голосов
/ 18 сентября 2009

Портирование сборки, также существует проблема ABI, которая варьируется от ОС к ОС. Портирование программы на C из Unix в Windows (или даже из Linux в OpenBSD) может быть простой перекомпиляцией, но для программы сборки вы можете обнаружить, что некоторые регистры, сохраняющие вызов, становятся сохраняемыми, или что параметры с плавающей запятой прошло по-другому.

И это не только теоретическое, а именно. зарегистрируйте r2 версий PowerPC для Linux и Mac OS X. На практике проблема может быть не такой уж серьезной, например, AMD опубликовала «рекомендуемый» ABI одновременно с 64-битным набором инструкций.

9 голосов
/ 18 сентября 2009

Если вы думаете «PC == Windows», то добавление ассемблера в программу на C не сильно повредит. Если вы вступите в мир Unix, у вас будет много разных процессоров: PPC в PS3 или XBox, старые Mac и множество мощных серверов. Для многих маленьких устройств у вас будет ARM. Встраиваемые устройства (на которые сегодня приходится подавляющее большинство установленных процессоров) обычно используют свои собственные процессоры со специальным набором инструкций.

Таким образом, хотя многие ПК сегодня могут выполнять код Intel, на него приходится лишь небольшая доля всех процессоров.

Тем не менее, код x86 тоже не всегда одинаков. Существует две основные причины для ассемблерного кода: вам нужно получить доступ к специальным функциям (таким как регистры прерываний) или вы хотите оптимизировать код. В первом случае код довольно переносим. В последнем случае каждый процессор немного отличается. Некоторые из них имеют SSE . Но вскоре SSE был заменен SSE2, который был заменен SSE3 и SSE4. У AMD есть свой бренд. Скоро будет AVX. На уровне кода операции у каждого из них есть немного различное время на разных версиях процессоров.

Что еще хуже, некоторые коды операций имеют ошибки, которые исправлены в определенных степенях процессора. Кроме того, в некоторых версиях процессоров некоторые коды операций выполняются намного быстрее, чем в других.

Затем вам нужно будет связать этот код сборки с частью C. Обычно это означает, что вам либо нужно решить ABI проблемы.

Итак, вы можете видеть, что это может стать сколь угодно сложным.

3 голосов
/ 18 сентября 2009

сборка - это написание инструкции непосредственно для конкретного процессора, что означает, что да, если x86 живет вечно, ваш код каким-то образом переносим.

Но даже сейчас процессор руки возвращается (то есть, нетбуки следующего поколения), и я уверен, что процессор не изменится в следующем году.

Я бы сказал, что язык ассемблера не является переносимым.

...