c # — перенос существующей кодовой базы на другой чипсет
Я слышал, что Microsoft портировала Windows на чипсеты ARM.
Мне просто интересно, что это значит для порт программа на другой чипсет. Будучи программистом на Java, я не очень разбираюсь в деталях низкого уровня.
Наивно полагаю, что Windows написана на смеси C, C ++ и C #. Я почти уверен, что в ARM уже есть свои компиляторы C и C ++, поэтому эти коды нужно было перекомпилировать только с использованием этих компиляторов. C # нужен интерпретатор .NET, который также может быть написан на языках более низкого уровня и теоретически может быть перекомпилирован с помощью специфичного для ARM компилятора C или C ++.
Конечно, я знаю, что процедура не так проста, поэтому я хотел бы узнать о теоретических ограничениях, возможных проблемах и т. Д., Которые могут затруднить такую процедуру.
Примечание: вопрос не относится к примеру, который я упомянул
Решение
Компьютерные программы имеют тенденцию быть совершенно разными по своей природе. Вы можете иметь тривиальное «привет мир!» например, тогда у вас также может быть полноценная ОС.
Операционная система с классическими определениями (от Tanenbaum) «Операционная система как расширенная машина» и «Операционная система как менеджер ресурсов» должна обеспечивать множество вещей.
Когда ОС должна выступать в качестве диспетчера ресурсов, она просто работает на базовом компьютере, контролируя ее функции, такие как загрузка, прерывания, ввод-вывод, режимы безопасности и т. Д. Хотя мы не можем заглянуть в исходный код Windows, чтобы увидеть Каковы различия в этих аспектах, мы можем взглянуть на его конкурента с открытым исходным кодом, который уже работает на архитектурах x86 и ARM — Linux!
В Linux поддержка разных архитектур лежит в арка каталог. Например, у нас есть x86 а также РУКА каталоги среди многих других есть. Я считаю, что даже проверка имен каталогов дает подсказку о необходимых усилиях (загрузка, питание, управление памятью и т. Д.)
Между мирами 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-код считал само собой разумеющимся, могут откусить их назад …
Другие решения
Проблемы различаются, но обычно они попадают в следующие области:
-
Где используются нестандартные функции. Например, объявление переменных после исполняемого кода в блоке недопустимо в ANSI C, но в C99 и C ++. Но компиляторы Microsoft не поддерживают C99. С этим связано все, что не охвачено стандартом, например, создание процесса CreateProcess v. Fork / exec, обработка сигналов и т. Д.
-
Программист делает неверные предположения. Например, предполагая, что
long32 бита. Это могут быть настоящие свиньи, чтобы найти и исправить. -
Компилятор не соответствует стандарту. Менее распространенный в наши дни. Более распространенным является отсутствие библиотечных реализаций на некоторых платформах. Конечно, стандарты не идеальны, иногда могут быть разные интерпретации одного и того же стандарта.
-
Подлинные архитектурные различия: например, проблемы с прямым или прямым порядком байтов, форматы файлов и т. Д.
Хотя подавляющее большинство кода в операционной системе написано на C, все еще есть значительная часть, написанная на ассемблере. Это нужно будет перенести на новую платформу. Некоторая часть только что сделанного — это сборка, потому что она более эффективна (такие как memcpy), но некоторая сборка написана, потому что нет эквивалентной инструкции C (например, выполнение системного вызова или для правильной обработки спин-блокировок). Все это нужно портировать.
Операционная система также напрямую обращается к оборудованию, и будет небольшое подмножество оборудования, такого как таймеры и т. Д., Которые необходимы для работы операционной системы. Все это нужно будет портировать.
В операционных системах защищенного режима, в которых требуется модуль управления памятью (MMU), потребуется перенести код, который обрабатывает MMU.
Большая часть этого будет в некоторой степени абстрагирована от остальной части операционной системы, но некоторые из этих абстракций могут основываться на определенных предположениях. В этом случае нужно будет исправить эти инструкции, чтобы все это заработало.
Затем идет загрузка драйверов, которые необходимо будет перенести на новое оборудование.
detector