#macos #arm #apple-silicon #rosetta-2
#macos #arm #apple-silicon #розетта-2
Вопрос:
Это тема, в которой я не очень хорошо разбираюсь, и я надеялся лучше разобраться в этой теме.
Я просматривал статьи о переходе Apple на Apple Silicon и в какой-то момент прочитал: «Apple собирается выпустить Rosetta 2, уровень эмуляции, который позволяет запускать старые приложения на новых компьютерах Mac».
Насколько я знаю, приложение написано на языке высокого уровня (например, C / C , Java и т. Д.). Затем компилятор (предположим, что интерпретаторы на мгновение не существуют) считывает этот код и преобразует его в ассемблерный код. Затем ассемблер преобразует ассемблерный код в машинный код, который может быть прочитан процессором.
Мой вопрос в том, что, если предположить, что вышесказанное верно, зачем требуется Rosetta 2, поскольку предполагается, что процессор в любом случае переводит код высокого уровня в читаемый машинный код? Зачем разработчикам нужно «оптимизировать» (или заботиться о том, на каком процессоре выполняются их приложения) свои приложения, поскольку они написаны (в основном) на языке высокого уровня (который процессор может компилировать)? Я не понимаю, почему программистов должно волновать, должен ли процессор обрабатывать компиляцию и сборку.
Этот вопрос, вероятно, довольно тривиален, но я не смог найти то, что искал, просто прочитав о компиляторах или архитектуре процессора.
Комментарии:
1. Разные архитектуры процессоров несовместимы. Возможно, (язык высокого уровня) разработчикам все равно, но если не для эмуляции, программное обеспечение необходимо переписать, чтобы настроить таргетинг на новую ISA. Вот почему x86 все еще существует — существует и активно используется множество устаревшего программного обеспечения и инструментов (компиляторов), предназначенных для x86.
2. @ryanwebjackson Значит, инженеры, которые заботятся об этом, работают над такими инструментами, как компиляторы? Потому что они должны быть нацелены на определенную ISA?
3. @ryanwebjackson: Переписать — это преувеличение для большинства приложений, вы можете просто перекомпилировать . Но если у вас есть пользовательский код для x86, например, вручную векторизованные циклы SIMD с использованием SSE / AVX, вам придется перенести их в NEON / AArch64 SIMD.
4. @PeterCordes Справедливо, но должен существовать компилятор, предназначенный для этой ISA. Очевидно, что Apple собирается поддерживать свою собственную платформу (да, имеются в виду компиляторы), но в остальном поддержка еще предстоит выяснить. Большой нюанс заключается в том, что M1 основан на ARM, который уже имеет огромную поддержку на рынке. Это была бы совершенно другая история, если бы это была новая ISA.
5. @ryanwebjackson: Да, точно, сам процессор является полностью стандартным AArch64 (с удивительно широким суперскалярным выполнением вне очереди, anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 ). Здесь нет никаких проблем, основные компиляторы, такие как GCC и clang, уже хорошо оптимизированы для AArch64, а формат файла MachO64 должен быть задокументирован. Единственная проблема с переносом на нее полноценной ОС, такой как GNU / Linux, — это драйверы для проприетарного оборудования вне процессора, например, экрана. Но чтобы запустить программу под macOS, вы можете использовать те же интерфейсы ОС, что и всегда, Для доступа к экрану, файлам и т. Д.
Ответ №1:
предполагается, что процессор в любом случае преобразует код высокого уровня в читаемый машинный код?
Нет, процессор сам этого не делает, это происходит с помощью программного обеспечения, работающего на процессоре (JIT или компилятор с опережением времени).
Для компилятора с опережением времени (например, для обычных реализаций C ) программное обеспечение с закрытым исходным кодом предоставляет только машинный код x86, а не исходный код. Так что вы не можете просто перекомпилировать его самостоятельно. Программное обеспечение с открытым исходным кодом обычно легко переносимо путем перекомпиляции.
Переписать — это преувеличение для большинства приложений, большинство из них можно просто перекомпилировать.
Но если у вас есть пользовательский код для x86, например, вручную векторизованные циклы SIMD с использованием встроенных функций SSE / AVX или написанный вручную asm, вам придется перенести их на NEON / AArch64 SIMD.
Комментарии:
1. Спасибо за это. Я предполагаю, что технические блоги чрезмерно обобщили эту потенциальную проблему, заявив, что «разработчикам придется …», и тем самым они включили в список всех разработчиков, которые действительно ломают голову. Также не знал, что программное обеспечение с закрытым исходным кодом поставляет только машинный код, специфичный для процессора, но это имеет смысл. P.S. под «читаемым машинным кодом» я подразумевал читаемый для процессора, если это имеет какое-либо значение.
2. @alexandrosangeli: Терминология: «машиночитаемый код» может выражать то, что вы хотите сказать. Или «исполняемый машинный код» был бы другим способом сказать это, хотя это все равно излишне. «машинный код» подразумевает, что процессор может его выполнить, для людей, знакомых с этим термином. И, кстати, обратите внимание, что программное обеспечение с закрытым исходным кодом на некоторых других языках, таких как Java, по-прежнему обычно должно отправлять переносимый байт-код Java, который только JIT-компилируется в машинный код на лету с помощью JVM. Но все, что представляет собой просто двоичный исполняемый файл библиотеки, обычно является просто машинным кодом.