Компьютерный флуд

IvanOFF · 11-02-10 15:43:08

Главной и пожалуй единственной серьезной проблемой в портировании Windows 8 на ARM я вижу проблему с запуском на ARM приложений написанных под архитектуру x86. Остро стоит и проблема с драйверами, но мне кажется именно проблема переносимости приложений является главным препятствием в выпуске Windows 8 на ARM.

Единственной серьезной проблемой могут стать драйвера. Проблем с приложениями не будет, т.к. они не работают с железом напрямую (кроме некоторых, ставящих свои драйвера или использующих недокументированные функции) а через Win32Api который в свою очередь общается с ядром через HAL, для поддержки ARM достаточно написать новое ядро и HAL.

IvanOFF · 11-02-10 22:18:19

Вы серьезно такую херню спороли?

Я серьезен как никогда. Если вы считаете по другому готов выслушать вашу аргументированную позицию.

IvanOFF · 11-02-10 23:19:35

А будет ли она там вообще работать?..

Будет.

WinXP была портирована на Itanium.

Не WinXP а WinXP 64-bit edition, которая по сути Server 2003

В принципе анологичный эффект можно наблюдать при попытке запуска 64-битного приложения на 32-битной ОС.

Вы здесь путаете разрядность ОС с аппаратной архитектурой. 64-битная система в принципе не способна исполнять 32-битный код кроме как в режиме эмуляции, от архитектуры это никоим образом не зависит. Родным для 64 битных версий Windows является win64api, win32api обрабатывается эмулятором win32api. 64-битные приложения будут без проблем работать в среде Windows как на x86-64 так и на IA64 без эмуляции.

IvanOFF · 11-02-10 23:42:57

Вот и все. Если бинарник скомплирован под х86, то он и прибит туда гвоздями навечно.

Каким образом он компилируется под конкретную архитектуру? Бинарник что, к регистрам процессора напрямую обращаться начинает, минуя winapi?

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

А чем по вашему является WOW64? Не нравится слово эмуляция, назовите подсистемой, смысл от этого не меняется. Пример тому 64-битная версия Linux, в которую никоим образом не установишь пакет для 32 битной версии, с чего бы так?

IA-64?! Товарищ, вообще-то IA64=Itanium=EPIC=проблемы с ассортиментом приложений.

Да, я про Итаниум. Проблемы с ассортиментом приложений там в другом, при стоимости систем на Итаниуме гонять на них x86 код, не использующий все возможности архитектуры, мягко говоря глупо, да и разрабатывался он не для массового рынка. А нативных приложений под Итаниум действительно мало, причина та же - крайне малый обьем рынка.

IvanOFF · 12-02-10 00:03:12

Еще добавлю.

Итаниум изначально разрабатывался для высокопроизводительных систем без оглядки на совместимость с архитектурой x86 и предусматривает изначально другие принципы работы ПО. Реализовать весь потенциал Итаниума может только ПО написанное специально под эту платформу. Но несмотря на это x86 приложения на Итаниуме работают, только гонять их там никто не будет, слишком дорогое удовольствие выходит.

ARM в противоположность Итаниуму очень простой RISC процессор, никаких принципиально иных принципов работы ПО не предусматривает. Кто мешает выполнить трансляцию CISC команд архитектуры x86 в RISC команды ARM на уровне ядра ОС? Тем более все современные x86 процессоры являются гибридными, формально CISC они используют вычислительные ядра RISC архитектуры, преобразуя команды внутренним транслятором.

На сегодняшний день сдерживающий фактор один - низкая производительность ARM процессоров, поэтому выгоднее написать несовместимый код именно под эту платформу, пожертвовав совместимостью в пользу производительности.

IvanOFF · 12-02-10 00:06:21

Опа! А вы не знали что машкоды для каждой архитектуры проца разные?

Каким образом это относится к приложению? Ему до фонаря какой там код.

Он не менует WinAPI. API - это набор сервисов для функционирования программы. Например системные вызовы и тд. Но код бинарника исполняется на процессоре (так сказать ему выдается процессорное время).

Бинарник не может напрямую обратится к процессору без посредников в виде winapi и HAL, а вот в их задачу входит уже обращение к аппаратным ресурсам.

IvanOFF · 12-02-10 11:46:26

Давайте не трогать Итаниум, это вообще другая область, со своими законами и правилами. К рынку ПК она относится примерно также как космическая отрасль к сельскому хозяйству. Коротко поясню. Архитектура IA-64 предусматривает принципиально иной тип вычислений нежели x86, в основном связано с многопоточностью и многопроцессорностью, нативные приложения под IA-64 не используют winapi, там своя система вызовов. Однако версии Windows для Интаниум поддерживают winapi, но не наоборот. Да и какой смысл настольной ОС поддерживать вызовы IA-64? Там софт явно не для прикладных задач и стоит весьма немалые суммы.

Это только гарантирование исполнения машинного кода. Суть в том что у всех ОС есть свой API. В API есть функции спецефичные какой-то ОС (системные вызовы, различные библиотеки и тд).

Winapi, в отличии от api Linux, обладает обратной совместимостью, что позволяет использовать программы написанные для старых версий ОС в новых.

Ну да. Напрямую в проц он сунутся не может. Но тем не менее продя все стадии его код в итоге загружается в процессор (процессорное время, планировшик ОС и тд, можешь посмотреть в вики).

Здесь вы не совсем правы, загружается не его код, а трансляция его кода в команды конкретного процессора. Простой пример. У нас стоит система на базе процессора с MMX, вызовы мультимедийного приложения транслируются в команды с использованием MMX инструкций, тут мы этот процессор вынимаем и вставляем без MMX, у нас бинарник перестанет работать? Нет, его вызовы будут транслироваться в систему команд этого процессора, вместо MMX инструкций будут использовать заменяющие их последовательности простых команд, доступных данной архитектуре.

Есть 3DNow! / MMX / SSE - хорошо, будем их использовать. Нет - ничего страшного, обойдемся простыми командами.

ARM, как я уже говорил, очень простая архитектура. Набор команд весьма невелик, сделать трансляцию CISC команд x86 в RISC команды ARM задача несложная. Единственное препятствие на сегодня - низкая производительность ARM процессоров, потому как каждая CISC команда будет разложена на несколько RISC команд возможно значительное снижение производительности. Именно по этому сегодня выгоднее писать ПО именно под ARM, без оглядки на совместимость.

IvanOFF · 12-02-10 23:17:17

Тем не менее чтобы запускать на ней программы нужно их перекомпилить под ARM.

Это еще не говорит ни о чем, о причинах именно такого положения вещей я уже писал выше.

И что их транслирует (ни слова про трансляцию в RISC это идет намного глубже в проц)?

HAL, с которым приложение общается посредством подсистемы win32api.

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

Простой эксперимент, сменим HAL с поддержкой ACPI на HAL без ACPI, система тут же забудет о том, что она умеет управлять питанием, убейтесь хоть головой об стену, но ни одно приложение не сможет использовать ACPI функции.

И еще тебе для размышлений, если в компиляторе не будет поддержки MMX, то фигас два твоя прога будет его использовать, уловил?

Естественно не будет, потому вызовы системные вызовы использующие такие функции использоваться не будут.

Уважаемый, вы кажется путаете машкод с байткодом.

Не путаю. Вы путаете. Бинарный код приложения и машинный код процессора вещи разные. Компилятор транслирует язык высокого уровня на язык близкий к машинному. Перевод инструкций машинно-ориентированного языка в набор команд для конкретного процессора осуществляется на уровне HAL.

IvanOFF · 13-02-10 00:03:48

Вызовы MMX входят в бинарный код приложения.

Если вы продолжаете настаивать, расскажите мне, опираясь на приведенную выше схему, каким образом приложение работает с MMX инструкциями процессора.

Найди в этих статьях слова "HAL транлсирует код" или что-то вроде. Долго будешь искать. Если не найдешь, то поищи достойный пруфлинк.

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

Если не найдешь, то поищи достойный пруфлинк.

М. Руссинович, Д. Соломон
Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP, Windows 2000. Мастер-класс

https://www.ozon.ru/context/detail/id/2427699/

IvanOFF · 13-02-10 00:27:09

У меня складывается мнение, что вы где-то нахватались верхушек. Почему моя отсылка к одной из лучших книг по архитектуре NT вам не подходит? Вас более утраивает абзац на MSDN?

Прямым. MMX - это блок процессора. Для таких вещей есть машинный код.

Смеяться при слове лопата? Если вы имеете такие глубокие познания, то разъясните мне, сирому и убогому, каким именно образом и посредством какого механизма приложение уровня Win32 Application обращается напрямую к ЦП. Схема приведена выше.

Форум StopLinux

Объявление

#1 11-02-10 15:43:08

Re: Компьютерный флуд

#2 11-02-10 22:18:19

Re: Компьютерный флуд

#3 11-02-10 23:19:35

Re: Компьютерный флуд

#4 11-02-10 23:42:57

Re: Компьютерный флуд

#5 12-02-10 00:03:12

Re: Компьютерный флуд

#6 12-02-10 00:06:21

Re: Компьютерный флуд

#7 12-02-10 11:46:26

Re: Компьютерный флуд

#8 12-02-10 23:17:17

Re: Компьютерный флуд

#9 13-02-10 00:03:48

Re: Компьютерный флуд

#10 13-02-10 00:27:09

Re: Компьютерный флуд

Подвал форума