Портирование существующей кодовой базы на другой чипсет

Question

Я слышал, что Microsoft портировала Windows на чипсеты ARM.

Мне просто интересно, что означает перенос программы на другой чипсет. Будучи программистом на Java, я не очень разбираюсь в деталях низкого уровня.

Наивно полагаю, что Windows написана на смеси C, C++ и C#. Я почти уверен, что в ARM уже есть свои компиляторы C и C++, поэтому эти коды нужно было перекомпилировать только с использованием этих компиляторов. C# нужен интерпретатор.NET, который также может быть написан на языках более низкого уровня и теоретически может быть перекомпилирован с помощью специфичного для ARM компилятора C или C++.

Конечно, я знаю, что процедура не так проста, поэтому я хотел бы узнать о теоретических ограничениях, возможных проблемах и т. Д., Которые могут затруднить такую ​​процедуру.

Примечание: вопрос не относится к примеру, который я упомянул

Answer 1

Компьютерные программы имеют тенденцию быть совершенно разными по своей природе. Вы можете иметь тривиальное "привет мир!" например, тогда у вас также может быть полноценная ОС.

Операционная система с классическими определениями (от Tanenbaum) "Операционная система как расширенная машина" и "Операционная система как менеджер ресурсов" должна обеспечивать множество вещей.

Когда ОС должна выступать в качестве диспетчера ресурсов, она просто работает на голой машине, управляющей ее функциями, такими как загрузка, прерывания, ввод-вывод, режимы безопасности и т. Д. Хотя мы не можем заглянуть в исходный код Windows, чтобы увидеть Каковы различия в этих аспектах, мы можем взглянуть на его конкурента с открытым исходным кодом, который уже работает на архитектурах x86 и ARM - Linux!

В Linux поддержка разных архитектур лежит в каталоге arch. Например, у нас есть каталоги x86 и ARM среди многих других. Я считаю, что даже проверка имен каталогов дает подсказку о необходимых усилиях (загрузка, питание, управление памятью и т. Д.)

Между мирами ARM и x86 довольно много различий. В x86 практически все стандартизировано (когда-либо слышали о совместимости с IBM PC?), И многие производители создают клоны архитектуры. В экосистеме ARM, напротив, сама компания ARM, являющаяся только поставщиком IP, у каждого поставщика есть различия между небольшими или большими (просто проверьте имена подкаталогов в папке arch, начиная с mach - это для машины, или plat - для платформы), С ARM у вас не было ничего похожего на BIOS как раз перед недавними разработками с UEFI, которые до сих пор не реализованы (я не говорю, что BIOS - это хорошо или плохо, просто пример).

Для роли "расширенного компьютера" ОС, которая делает Windows такой, какой она есть, перенос должен быть относительно простым. В основном это касается таких функций, как вызов раздела жесткого диска "c:" - наличие прав доступа к файлам, таких как "только чтение" или "скрытый", и сохранение основных API, таких как Win32 API, в основном функциональными. Но опять же, это не так просто.

Я ожидаю, что MS строго определит, на какой машине ARM может работать Windows с какими периферийными устройствами по сравнению с очень открытым миром Linux, чтобы обеспечить качество и скорость выхода на рынок.

Это две большие проблемы, которые я могу себе представить, однако с каждым поворотом могут возникать такие маленькие проблемы, как; ARM - это 32-битная RISC-архитектура, символ не подписан, даже в последних высокопроизводительных ядрах ARM нет поддержки целочисленного деления (производительность?), Все эти мелочи, которые Windows-код считал само собой разумеющимся, могут откусить их назад...

Answer 2

Хотя подавляющее большинство кода в операционной системе написано на C, все еще есть значительная часть, написанная на ассемблере. Это нужно будет перенести на новую платформу. Некоторая часть только что сделанного - это сборка, потому что она более эффективна (такие как memcpy), но некоторая сборка написана, потому что нет эквивалентной инструкции C (например, выполнение системного вызова или для правильной обработки спин-блокировок). Все это нужно портировать.

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

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

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

Затем идет загрузка драйверов, которые необходимо будет перенести на новое оборудование.

Answer 3

Проблемы различаются, но обычно они попадают в следующие области:

1. Где используются нестандартные функции. Например, объявление переменных после исполняемого кода в блоке недопустимо в ANSI C, но в C99 и C++. Но компиляторы Microsoft не поддерживают C99. С этим связано все, что не охвачено стандартом, например, создание процесса CreateProcess v. Fork/exec, обработка сигналов и т. Д.

2. Программист делает неверные предположения. Например, предполагая, что long 32 бита. Это могут быть настоящие свиньи, чтобы найти и исправить.

3. Компилятор не соответствует стандарту. Менее распространенный в наши дни. Более распространенным является отсутствие библиотечных реализаций на некоторых платформах. Конечно, стандарты не совершенны, иногда могут быть разные интерпретации одного и того же стандарта.

4. Подлинные архитектурные различия: например, проблемы с прямым или прямым порядком байтов, форматы файлов и т. Д.