Comments 70
Прочесть такой текст сможет не только лишь каждый... А так спасибо, было интересно
Дочитал до "IMB" вместо "Intel", дальше промотал до итогов (поскольку уровень текста в нулевом приближении уже наметился), отметил "россии" и вот что хочу автору сказать.
Не умеешь летать -- не выпендривайся.
У меня на куда более редкой архитектуре e2k, где до сих пор нет портов тех же chromium или golang с оптимизацией -- что на домашнем 16С, что на рабочем бинарный транслятор не используется за ненадобностью.
Как и на линуксе когда-то тоже в студенческие годы был dosemu для HMM2, затем отсох опять же за ненадобностью.
Бери задачи по силам и чуточку выше, набирайся опыта, получай пользу от делаемого -- и потихоньку всё, что нужно, срастётся, а что не нужно -- отвалится естественным путём.
Ну и вишенка на эээ... тортик для массовки кукаретиков, топящих за RISC-V: он хотя бы попытался, а вот вы -- кроме одного до сих пор откликнувшегося исключения -- только и способны за клоунами да подлецами повторять чужую ложь. Попробуйте-ка сами.
Ваш код скомпилированный под x64 является ассемблерным.
Он не является ассемблерным. Это просто голые инструкции для процессоров x86_64 вне зависимости от того получен этот бинарь из asm, c или cpp исходников. А ассемблер - это представление этих инструкций в виде, более понятном для человека (не любого, только для некоторых).
Спасибо за комент.
Я же говорил, что стараюсь упрощать всю внутреннюю кухню, чтобы не раздувать статью теорией. Да, это важные понятия, но для простого обывателя отличие бинаря от ассемблера не сильно и велико.
Да и мне кажется, что все хоть раз, но открывали (будь то случайно или специально) бинарник в текстовом виде и видели там 16-ти ричный код. Логично что это не ассемблер.
Все верно, это машинный код, а ассемблерный код - это низкоуровневый язык программирования, чей синтаксис зависит от конкретного железа.
Насколько знаю, была разработана Valve
Это не так, но журналисты как обычно наврали.
Щас бы apple слили исходники своего эмулятора, было бы круто. Там x86 как будто бы свой родной :)
А толку? Он только на apple silicon будет работать (и возможно на XElite). Ключевое - это аппаратная поддержка x86 TSO.
На Винде точно так же. Запускаешь любую программу и пофиг, для какой она написана архитектуры.
На Винде точно так же. Запускаешь любую программу и пофиг, для какой она написана архитектуры
Не скажи. Иначе они бы не делали призм для запуска x64 на arm. Да и проблем на старте с их сурфейсом не было бы, а там прог было... лучше сказать что не было. Я помню как на старте его, отчасти, из-за этого и закидали помоями
Иначе они бы не делали призм для запуска x64 на arm.
Ась? Благодаря эмулятору и можно не париться по поводу архитектур. Впрочем, у меня почти все приложения в нативе работают.
Из другого коммента:
А когда до нас в СНГ arm-ноуты дойдут.
До вас это куда? В России они свободно продавались сразу после релиза и на авито и у ретейлеров. С русской раскладкой.
А толку? У них хоть формально и ARM, но микроархитектура своя, да и какие то специальные аппаратные оптимизации используются .
Они свою резетту делали под свою ось, там очень вряд ли получится запустить что-то, кроме их софта на их же оси.
Тут больше майковский призм был бы интересен.
Такой эмулятор, очевидно, состоит из отдельного транслятора бинарного кода и модуля который разрешает все эти библиотечные зависимости, с которыми вы провели столько незабываемых часов. Транслятор кода и общую архитектуру можно переиспользовать в линуксах, а вот разрешателя зависимостей придётся переделать.
Мало эмулятора (тем паче какие-то есть). У них он интегрирован в систему, так что все описанные в статье танцы с бубном просто не нужны.
Ближайший аналог – если бы в Linux запуск кода для другой архитектуры поддерживался на уровне ядра. Велели системе загрузить "неправильный" ELF – она его скормила транслятору, но загрузила.
А вот трансляторы могли бы быть разные...
Статью читать было интересно, особенно для человека с линуксом не знакомым, но весь этот геморрой оставляет горькое чувство, что с винды я не слезу
что с винды я не слезу
Это только кажется геморроем со стороны. На обычном пк (x64) там проблем будет мало. А когда до нас в СНГ arm-ноуты дойдут... не скоро. Можно спойокно на это забить.
Я сам не 24/7 в лине. Он у меня на ноуте стоит как основная система, а на основном пк винда. Так как мне нужен софт для работы с графикой (тот же T-Flex Cad 17, который я пробовал запустить в статье про wine), которые там не запускаются, чтобы ты не делал.
Но. Я на ноуте сделал себе образ винды для QEMU, ставил туда нужные проги (T-Flex, Affinity Photo/Designer) и он работал очень даже шустро (конфу ноута можете в статье найти). Только весил под 32 гига, вот это боль. А так, проблем не много.
Разве нельзя положить нужную версию библиотеки в одну директорию с исполняемым файлом и дать команду линкеру искать библиотеку именно в этой директории?
Можно. Но это знать надо, а судя по статье, автору до этого далеко
А ты собери весь этот заопарк библиотек из инета.
Это не винда, где dll можно найти в любой дыре, плюс сама программа тащит в себе 98% всего нужного.
Вот представь себе, что программа использует где-то 15-20 библиотек. Где ты их искать будешь в инете? Да и даже так это очень геморно в плане времязатрат/пользы.
графическое приложение тянет за собой преизрядно зависимостей. Которые тянут за собой ещё столько же. Именно поэтому каждый дистрибутив поставляется с пакетным менеджером, который всё это разруливает.
Хм... Я не уверен, что правильно понял поставленную задачу... Но в целом, qemu-user + binfmt_misc кажется лучшим решением. Возможно не самым быстрым, но точно куда как более простым. Во всяком случае в обратную сторону (запуск Arm/Aarch64 приложений на x86/amd64) оно работает сильно проще. Были причины, по которым такой вариант не рассматривался? Ибо так или иначе, а бинарная трансляция все равно будет. В таком варианте варианте вполне возможна даже динамическая линковка исполняемого файла amd64 с нативными библиотеками Aarch64. А смысл пассажа про недостаток ресурсов, обозначенный в статье, остался несколько непонятым.
qemu-user + binfmt_misc кажется лучшим решением
Да. Оно будет лучшим, когда железка может делать чуть больше, чем ничего. На данном аппарате запускать qemu - это застрелится просто. Он и так работает, скажем так, неторопливо.
Возможно не самым быстрым, но точно куда как более простым
У меня была цель проверить именно байтовые трансляторы (ну, изначально). То что с виртуализацией можно проще - ктож спорит. И винду на виртуалку накатить можно, зачем wine? Только скорость в таком случае будет очень дурной.
Были причины, по которым такой вариант не рассматривался?
Скорость и маломощность аппарата. Если это чудо не способно переварить веб-версию телеги, о какой производительности вообще может идти речь? А теперь сюда пихните виртуалку, и получите полу-недо рабочее чудо, которое виснет в 2 раза чаще.
Был бы какой-нибудь X Elite - было бы проще. Тут можно разгуляться.
Для слабых одноплатников qemu-user может быть медленным, FEX и Box64 обещают быть быстрее за счет более агрессивной JIT-компиляции, но плата за это - сложность настройки и баги. Тут классический трейд-офф: скорость против стабильности
Когда вы компилируете .NET приложение на C#, вы получаете на выходе IL-код, который потом интерпретируется виртуальной машиной
У вас "компилируете" и "интерпретируется" в одном предложении.
Как и тот же JIT в разы медленнее, чем условный C++ скомпилированный в ассемблер
JIT не может быть медленнее, он компилятор. И нет, не в разы медленнее. Он компилирует не только под конкретную архитектуру, но и под особенности конкретного процессора, что иногда приводит к тому, что C# оказывается быстрее C++.
Ну и надо упомянуть такой режим дотнета, как Native AOT. Это когда JIT компилирует в исполняемый бинарь ДО публикации, а не перед запуском на целевой машине. Я именно так и собираю OrmFactory. К теме статьи - да, там есть сборка под linux arm64. Так что никаких трансляторов не нужно.
Историческая справка про IBM архитектуру
Как то смешали в одну кучу архитектуру интеловских процессоров и IBMовских компьютеров.
с IBM, которая в конце 70-х начинала распространять свою архитектуру 8088, на которую в последствии был выпущен процессор intel 8086 в 78 году.
Сначала вышел интеловский 8086, и только потом тоже интеловский 8088 с 8битной внешней шиной (и он использовался в первых IBM PC).
В чём сложность - ARM-устройства это как смартфоны. Для того, чтобы туда поставить хоть что-то, его нужно предварительно собрать под конкретный аппарат.
На серверах на ARM (типа такого) вполне себе ставится обычная Ubuntu из образа для ARM64, устройства при загрузке определяются через ACPI как на x86 машинках.
На linux я нашёл 2 адекватных варианта запуска прог x64 на ARM. Это пакеты Box64/86 и FEX.
В принципе есть ещё qemu. Не знаю, как с производительностью в игрушках и прочих клиентских приложениях, но оно точно живое - один коллега случайно по ошибке поднимал виртуалку из образа с чужой архитектурой и оно вполне работало (только по тормозам заметил, что что то не то).
На серверах на ARM (типа такого) вполне себе ставится обычная Ubuntu из образа для ARM64, устройства при загрузке определяются через ACPI как на x86 машинках
Я про это вкурсе. На сервачных решениях это унифицировано, а вот на user-end устройствах - нет.
qemu
Это не транслятор (о которых речь и шла), а виртуалка. Многие уже отписались по этому поводу. Честно, я думаю, что у меня оно будет лагать и будет шляпа. А так способ рабочий, да. Но на уровне "поставь винду на виртуалку и не мучь wine". Вопрос в скорости и производительности.
Автору респект, не каждый бы пробивался через все эти костыли и тормоза!
Ну и вообще, задача трансляции под другую архитектуру возникает только в мире закрытых программ (в основном игры и старый неподдерживаемый софт под Windows). В мире опен-сорса правильнее будет скомпилировать нужный вам софт под целевую платформу. Операционные системы, десктопные окружения, QT GTK, браузеры (electron) и множество популярных программ и пакетов имеют версии под ARM64.
Кстати, а что насчёт запуска программ с Macos в Linux? Эти программы уже ведь скомпилированы под ARM?
а что насчёт запуска программ с Macos в Linux? Эти программы уже ведь скомпилированы под ARM?
Они вполне могут использовать нестандартные расширения процессоров Apple (например AMX) - если и не напрямую, то через системные библиотеки.
если бы это было так просто то наверное и не было бы нужды очень особых сборок мультиплатформенного софта именно под macos, а там че то так кучеряво еще все
В мире опен-сорса правильнее будет скомпилировать нужный вам софт под целевую платформу
Согласен. Саммый яркий пример для чего нужна эмуляци - стим. Его на ARM (пока) нет. Поставить, кроме как через трансляцию, нельзя.
Операционные системы, десктопные окружения, QT GTK, браузеры (electron) и множество популярных программ и пакетов имеют версии под ARM64.
Я их брал только как пример для демонстрации работоспособности. Это было проще всего. Это можно применить и к более нетривиальным решениям, просто действуя по аналогии.
Кстати, а что насчёт запуска программ с Macos в Linux? Эти программы уже ведь скомпилированы под ARM?
Это вы как себе представляете? Программы под mac собраны под mac и не могут быть запущены где-то кроме mac.
Попробуйте прокинуть бинарь из Linux в FreeBSD. Спойлер - BSD вас пошлёт.
Разные ОС = разные решения по сборке, расположению и/или версиям библиотек, разные компиляторы. То что это всё *nix погоды не делает.
Программы под mac собраны под mac и не могут быть запущены где-то кроме mac.
Аналог wine теоретически возможен.
Попробуйте прокинуть бинарь из Linux в FreeBSD. Спойлер - BSD вас пошлёт.
А если так?
Это эмулятор, а не базовая система. Вы с таким же успехом можете qemu запустить.
Смотрим описание
Linuxulator (Linux Emulation)
Linux binary compatibility, commonly referred to as Linuxulator, is a mechanism to run unmodified Linux binaries under FreeBSD. It does not involve virtual machines or emulation
Некие аналогии можно провести с подсистемами в Windows NT и потомках.
Я, конечно, не знаток фряхи (как раз её трогаю потихоньку), но точно знаю, что linuxulator тянет с собой окружения дебиана (на момент теста, там был 9). Так что это с натяжкой эмулятором (как box64), а скорее эмулятором как FEX.
Жалко что на фряхе нет distrobox, было бы удобно иметь контейнеры линя на ней. Причём, на фряхи есть и докер, и подман. Но работать они не хотят, видимо из-за ядра
Это вы как себе представляете? Программы под mac собраны под mac и не могут быть запущены где-то кроме mac.
ну технически это возможно, мак и линух и бсд хотя бы отдалённо схожи. винда же отличается от них куда сильнее, тем не менее виндовый софт на них работает (wine) и линуксовый софт на винде тоже (wsl/wsl2).
другой вопрос что не очень понятно зачем..
понятно про wine - есть ряд виндовозного софта который хочется пользовать без страдания от винды (да хотя бы в игры поиграть)
понятно про wsl - если корпоративное правило что все должны страдать на винде нельзя обойти но работать надо то приходится прибегать к wsl
а вот с макосью не понятно, с ходу не могу припомнить такого кол-ва маковского софта чтобы создавать вино на "маковых цветах" имело смысл.
Статья местами малограмотная и многословная, но автору большой плюс за труд.
Один вопрос возник, почему надо качать пакет во внешней системе для установки в rootfs. Нельзя-ли запустить "FEX ./rootfs/usr/bin/apt ..." ?
Можно. И оно его запустит. Но только если уже есть RootFS. Fex не умеет работать без него совсем.
И тут есть ньюанс. Даже так, этот apt не будет ставить внутрь RootFS, а будет тянуть пакеты в основную систему. Все пути тоже от основной системы.
Я перед написанием статьи пробовал делать всё на этой железке. Проимелся с дня 2-3 и понял, что это слишком тухлая идея. Проще сделать там где всё работает и перенести туда, где не работает.
Можно использовать qemu-user и через эмуляцию системы x64 всё настроить, но ждать придётся дольше. Тормоза и ещё раз тормоза.
Я больше про то, как вы в конце пакеты ручками качали. Сам-то первый rootfs понятно проще готовый сделать на нормальной тачке.
Возвращаясь к вопросу инсталляции дополнительных пакетов, во-первых, в интернете пишут, что есть опция Dir. Во-вторых, можно внутрь rootfs пробросить FEX, bash и пару библиотек с хоста и работать через chroot.
Блин, это надо было показать отдельно в статье. Это так не работает, как вы думаете. Я пробовал запускать apt внутри rootfs через фех. Но вот беда, он туда ничего упорно не ставит.
Я его тестировал ещё до написания и, в этот раз, не делал того, что делал тогда специально. Так как я тогда встрял.
Насколько я знаю, единственный способ что-либо менять в rootfs, это поднимать qemu-user и заходить в rootfs. Иначе никак.
Во-вторых, можно внутрь rootfs пробросить FEX, bash и пару библиотек с хоста и работать через chroot.
Хорошо бы, если бы это было в документации FEX, так как я устал выискать по разным ресурсам как сделать то или иное. Информации не слишком много
начало статьи - супер
конец статьи - супер
в середине - а не хотите ли немножко бреда от человека не умеющего читать
автор заявляет:
А дальше начинает происходить хаос.
и говорит про лакончиный fhs который избавляет от хаоса описанного выше чем заявление про хаос
Вы не можете держать 2 версии одной и той же программы, ибо если одна старая, то она хочет старые зависимости, а ВСЯ система живёт по новой. Фиг вам, а не старая версия.
вот это вот с чего бы вдруг? fhs не запрещает тебе хранить несколько версий любой либы и не только либы, просто в большинстве случаев это ненужная глупость. у тебя прямо сейчас на твоём рабочем пк с 99% шансом найдётся несколько одинаковых либ разных версий.
Обновить одно приложение у вас НЕ выйдет, так как если ему нужно, условно, libc_10.1, а во всей системе используется libc_10.0, то у вас упадёт вся система и пакетник вас пошлёт очень далеко за такие деструктивные действия.
ну если ты не наркоман то ты собираешь своё приложение в пакет с теми либами которые есть в репозитории, но даже если тебе хочется сотворить хаоса ничто не мешает тебе покласть либу отличающейся версии рядом с родной системе или вообще в папочку с бинарём, это будет кривота но это будет работать
Одни библиотеки НЕ уживаются с другими. Конфликт зависимостей (у меня такое было, поставил из AUR программу, которая притянула ноду, а мне нужна была новая версия ноды. И вот тут начинается дилемма, нужна ли вам программа с одной версией ноды, или вам нужна новая нода, но тогда приложение скажет “досвидос”.
а может просто не стоит использовать AUR который просто помойка больной фантазии юзверей? есть куча более адекватных решений
Представьте себе, что вы ставите программу, которая хочет QT. А теперь вопрос, как вам прокинуть ВЕСЬ QT к этой программе (тот который нужен разумеется, а не совсем всё)? А вот ответ. Никак.
а этот "никак" он с вами в одной комнате? потому что я на вскидку могу назвать целых три способа
Проблема ещё и в том, что скачать версию под AMD64 из интернета (не QT, а программы) вы врядли сможете вообще.
Система настолько заточена под пакетник, что бинарей собранных в инете просто не найти обычно (кроме deb-пакетов или .tar.zst). А уж библиотек - тем более.
смогу и сделаю если захочу, но я не захочу потому что софт, либы и прочее имеющее отношение должно поставляться из репозиториев а не иначе, и да если система x86_64 а хочется aarch64 (или наоборот) это тоже возможно хотя и мягко скажем нестандартно.
Поэтому, то, что работало спокойно в windows (библиотеки прям в папке с прогой) и в macOS (тоже самое), в linux работать НЕ БУДЕТ.
у всех будет а у вас не будет.. это как так? я вам может быть секрет открою, но такие базовые вещи работают во всех системах одинаково за исключением тех случаев когда это поведение кто-то целенаправленно сломал.
Проблема ещё и в том, что скачать версию под AMD64 из интернета (не QT, а программы) вы врядли сможете вообще.
Ну это погорячился, любой репозиторий Debian/Ubuntu это и есть тот самый "интернет", откуда можно скачать любой deb-пакет любой архитектуры. Просто нужно знать команду apt download или уметь пользоваться packages.debian.org
Да, можно. Но когда у приложения 20+ зависимостей, это делать малость утомительно.
Я думаю, что для подобного решения нужно что-то типо winetricks - само скачает, распихает, только галочки поставь.
И да, надо пояснить. Про то, что нельзя скачать из интернета. Я имел ввиду сайты по типу такого, который всплывает по одному запросу в гугле. Тут действительно нужно знать, что с пакетника можно выкачать именно нужные пакеты, именно той архитектуры, что их можно распаковать и запустить. Согласитесь, это в разы труднее для условного Пети, который на винде всё за 2 клика сделает. Нашёл, скачал, скопировал - работает. Профит.
Начну свой рассказ с IBM, которая в конце 70-х начинала распространять свою архитектуру 8088, на которую в последствии был выпущен процессор intel 8086 в 78 году.
Шта? Во первых, 8086 появился первым, а уже потом был выпушен 8088 с восьмибитной внешней шиной данных чтобы иметь возможность использовать периферийные м/с с 8-битной шиной данных и с целью чуть упростить процесс обвязки CPU. Во вторых, х86 не был каким то прорывным, и изначально запускался как временно костыльное решение чтобы дать возможность Intel доделать свой iapx432 micromainframe. В третьих, IBM изначально хотели видеть в качестве центрального процессора мотороловский 68000, и только неготовность 68008 (68000 с восьмибитной внешней шиной данных) и мнение Билла Гейтса склонило чашу весов в сторону intel 8088
Ещё чуть позже IMB хотели сделать (и сделали) 64-битную архитектуру, но вот тут проблема.
IBM не хотела делать 64 битную архитектуру на IBM PC, поскольку на тот момент не являлась существенным игроком на рынке ПК. И процессорное отделение IBM прекратило выпуск х86 процессоров на 486, причем ЕМНИП дизайнером этих процессоров являлась Cyrix, а IBM выступала только как производитель.
Информация полезная, но статью оооооочень сложно читать.
Если выкинуть вступление и оставить правильный путь без лирики, тогда можно будет осилить
(список сделан ChatGPT).
Ндааа, суда по количеству "фантазий" в тексте, ChatGPT составляет не только списки :(
Начну свой рассказ с IBM, которая в конце 70-х начинала распространять свою архитектуру 8088, на которую в последствии был выпущен процессор intel 8086 в 78 году.
IBM начала распространять свою архитектуру IBM PC на процессоре i8088 не в конце 1970-х, а с 1981 года, когда был выпущен IBM PC Model 5051. Процессор i8086 (1978) был выпущен раньше i8088 (1979). i8088 является адаптацией i8086 к 8-разрядной шине данных с целью удешевления архитектуры, т.к. 16-битные решения стоят в 2 раза дороже, что в то время было неприемлемо дорого.
Собственно, дальше этот бред можно и не читать.
И кстати, автору надо было попытать насчет бинарной трансляции эльбрусовцев, вдруг оничто-то дельное подскажут?
https://github.com/DnCraptor/pico2-cross386
взято из телеграмм канала мурмулятора
Новости с полей трансляции x86 в ARM Cortex M33. Вот такой примерчик:
org 0x100
mov ah, 0 ; Функция INT 16h — ожидание нажатия клавиши
int 0x16 ; Возвращает ASCII в AL, scan-код в AH
mov ah, 0x0E ; BIOS: вывод символа в TTY-режиме
int 0x10 ; Печатает символ из AL
mov ax, 0x4C00 ; Выход из программы
int 0x21
собранный nasm'ом как .com-файл, после трансляции стал вот такими кодом для м33:
start_it:
AND R4, R4, #0xFFFF00FF ; x86 00000000: B4h 00h = MOV AH, 0 - Обнуляем старший байт
CPSID i ; Запрет прерываний перед INT
adr r11, %m00000004 ; x86 00000002: CCh = int 16
mrs r12, apsr ; Сохраняем флаги
push {r11, r12} ; Эмулируем PUSH IP, PUSH FLAGS
ldr r11, =0x11000058 ; Адрес обработчика INT 16h
ldr r11, [r11] ; Адрес обработчика (IDT)
mov pc, r11 ; Переход к обработчику
m00000004:
LDR R0, =0x0E ; x86 00000004: B4h 0Eh = MOV AH, 0x0E
LSL R0, R0, #8 ; imm8 → в позицию AH
AND R4, R4, #0xFFFF00FF ; Обнуляем старший байт
ORR R4, R4, R0 ; объединить AL и новый AH
CPSID i ; Запрет прерываний перед INT
adr r11, %m00000008 ; x86 00000006: CCh = int 10
mrs r12, apsr ; Сохраняем флаги
push {r11, r12} ; Эмулируем PUSH IP, PUSH FLAGS
ldr r11, =0x11000040 ; Адрес обработчика INT 10h
ldr r11, [r11] ; Адрес обработчика (IDT)
mov pc, r11 ; Переход к обработчику
m00000008:
MOV R4, #0x4C00 ; x86 00000008: B8h 00h 4Ch = MOV AX, 0x4C00
CPSID i ; Запрет прерываний перед INT
adr r11, %m0000000D ; x86 0000000B: CCh = int 21
mrs r12, apsr ; Сохраняем флаги
push {r11, r12} ; Эмулируем PUSH IP, PUSH FLAGS
ldr r11, =0x11000084 ; Адрес обработчика INT 21h
ldr r11, [r11] ; Адрес обработчика (IDT)
mov pc, r11 ; Переход к обработчику
m0000000E:
NOP
Запуск x64 программ на ARM или почему вы не захотите этим заниматься