Можно ли на RISC-V динамически имитировать х86?

Всё точно так же, как и на ARM/MIPS.

x86 даже на всяких AVR можно имитировать тащемта.

Правда, не очень понятно нафига вообще это делать, кроме как ради прикола.

Для совместимости с х86-софтом, вестимо

А пересобрать под нужную архитектуру уже не модно, что-ли?

Проприетарщину не пересоберёшь

Попробуй QEMU.

Эмулировать, ты это хотел сказать?

Эмулировать, да, можно. Потери только будут.

У apple для arm с rosetta как-то получилось, почему у кого-то еще с risc-v не получится?

apple для arm

Ценой очередного ожирения бинарников.

Потому, что эппл не эмулирует чужие инструкции в рантайме как это должен делать QEMU.

Нет, речь про rosetta2 - выполнение только x64 бинарников

непонятно какая религия запрещает делать это не в рантайме любому другому проекту

Что-то как-то не припомню никакой линуксовой проприетарщины (VariCAD какой-нибудь?) которую имело бы смысл запускать на неPC.

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

венду гонять, которой для не x86 нету

А как они винду на Snapdragon™-ах гоняют?

https://docs.microsoft.com/en-us/windows-hardware/design/minimum/supported/windows-11-supported-qualcomm-processors

Рассуждать о религиях которые запрещают что то делать в рантайме могут не только лишь все, и ты в их число походу не входишь. Розетта это по сути JIT со всеми его плюсами, минусами и ограничениями

А откуда ты их возьмёшь? Из Universal binary

Не только. Яблоось на армах умеет выполнять старые только интеловые бинарники (которые не universal binary). При этом срабатывает JIT-подобный механизм который транслирует интеловый код в армовый который уже нативно выполняется.

Что-то как-то не припомню никакой линуксовой проприетарщины

xnViewMP

Ну у мелкософта-то есть сырцы венды. Пересобрали для себя да и всё. ТС-то откуда возьмёт не x86 венду?

И зачем его гонять на RISC-V? Для решения какой задачи?

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

ТС-то откуда возьмёт не x86 венду?

Реактось будет пересобирать :)

венду гонять, которой для не x86 нету

Юзеры parallels на маках не в курсе почему-то.

Вопрос не в том, хорош он или плох, вопрос в том, зачем его на машине с RISC-V гонять.

Линукс на армах технически может запускать x64-код через розетту но… оно одноядерное поскольку считает, что процессор умеет в TSO. Ну и лицензия непонятна.

Наверное, ровно за тем же, зачем и на машине с x86. Что, RISC-V не позволяет создать десктоп?

ТС-то где её возьмёт? Так-то венда была и для DEC Alpha и для PPC ЕМНИП, вот только где её взять?

Нет, не эмулировать. Именно имитировать, на ходу собирая из мелких инструкций risc-v большие инструкции х86.

Наверное, ровно за тем же, зачем и на машине с x86. Что RISC-V не позволяет создать десктоп?

Позволяет. Но гонять на нём ненативный софт-то зачем? Тем более под линуксом. Если это для себя - то нет проблем найти альтернативу и допилить нужные фичи. Если это для заказчика - пусть он и предоставляет проприетарный софт который он хочет запускать собранный под RISC-V.

Зачем ты забиваешь тему нерелевантным флудом?

Для RISC — без понятия, для arm — буквально на сайте MS.

Затем, что без описания конкретной конечной цели описанного в ОП извращения, что-то разумное посоветовать нереально.

Ну да, о том и речь.

To access this page, you need to be a member of the Windows Insider program.

Ок, не советуй

Но гонять на нём ненативный софт-то зачем? Тем более под линуксом. Если это для себя - то нет проблем найти альтернативу и допилить нужные фичи.

Ну, гоняю же я под линуксом, пусть нативный, но закрытый xnViewMP! Наверное, потому, что аналогов не нашёл, а фичи допиливать не способен? А ещё, наверное, потому, что xnViewMP мне на ЛОРе посоветовали?

Наверное, потому, что аналогов не нашёл, а фичи допиливать не способен?

Ну так запустить его на RISC-V с приемлемой юзабельностью намного сложнее чем допилить фичи в опенсурсный аналог.

А я ещё ничего и не советовал вообще-то. Я пытаюсь выяснить цель данного экзерсиса. Потому что от цели будет прямо зависеть вариант возможного совета.

Нет, не эмулировать. Именно имитировать, на ходу собирая из мелких инструкций risc-v большие инструкции х86.

Полностью транслировать произвольный софт из x86 в risc-v инструкции невозможно. Можно JIT (qemu так умеет через tcg), можно в какой-то степени сделать AOT части кода (вроде бы это делает rosetta2), можно кэшировать результаты JIT’а и получить примерно то же самое, что и в AOT. Но в любом случае нужен будет фоллбэк на интерпретацию же. Вся прочая разница в терминах — маркетинг.

Что-то как-то не припомню никакой линуксовой проприетарщины

Ansys, Siemens NX, и ещё ворох другого подобного софта.

Ну так запустить его на RISC-V с приемлемой юзабельностью намного сложнее чем допилить фичи в опенсурсный аналог.

Тут такая проблема: кто может допилить фичи - те считают, что «ненужно». А те, кому действительно нужно - не могут допилить. Это, как с far для линукс: 20 лет ждали. Хотя, казалось бы, что сложного: взять исходники mc, и перепилить в far?

Смысл такой софт запускать на RISC-V, да ешё и через эмуляцию другой архитектуры? Из не-x86 такое разве что на Power9 будет как-то юзабельно. А RISC-V аналогичной мощности никто вроде ещё не выпускает и на том, что можно сейчас купить это будет неюзабельно.

Я ж говорю - эмулировать x86 можно на чём угодно, хоть на AVR, хоть на Z80. Но чисто в академических целях.

Полностью транслировать произвольный софт из x86 в risc-v инструкции невозможно

Жаль. А почему?

Тут такая проблема: кто может допилить фичи - те считают, что «ненужно». А те, кому действительно нужно - не могут допилить.

Ну то же самое и с запуском на другой архитектуре. Те, кто может - не понимают смысла этой охоты. Те, кому нужно - не смогут запустить.

Это, как с far для линукс: 20 лет ждали. Хотя, казалось бы, что сложного: взять исходники mc, и перепилить в far?

mc и far весьма системоспецифичны. Особенно если учесть упоротость вендовой консоли. Это как софтину на GTK зачем-то переписывать на Qt, тем более если уже есть аналогичная софтина на Qt.

Да и far на самом деле не нужен для линукса. Он нужен прикипевшим к нему вендузятникам переползшим на линукс которым mc непривычен и они не умеют его готовить. Для тех, кто с самого начала пользовал mc far тупо неудобен и укушен.

Потому что помимо процессора есть ещё ОС и бмблиотеки и для разных архитектур формат структур которыми обменивается софт и система может быть разным - выравнивание всякое, наличие или отсутствие полей и т.п. Хорошо хоть BE/LE нынче уже история.

Жаль. А почему?

Потому, что произвольный софт нереально анализировать не запустив, как минимум автоматически. А если запускать — это уже динамическая трансляция (= эмуляция, с jit как правило).

Как, например, ты собираешься транслировать JIT-компилятор?

ЕМНИП, там ещё «проще» – с какого-то момента исходники far стали открыты. «Всего-то» переписать windows-специфичный код под linux. (ага)

В общем случае нельзя, поскольку трансляция в x86 байт-код спецификациями и конструктивно не предусмотрена. Но в частном случае, если имеются незадокументированные аппаратные возможности, то да, такой финт ушами проделать можно.
Оффтоп: знакомый разраб пишет софтину под заказ, а в ТЗ записано пожелание обеспечит невозможность копирования базы. В общем случае сделать без костыля нельзя, спецификация файла БД разрешает манипуляции в любом направлении. Но в дескрипторе файла имеется поле из 4 байтов, куда запихивается служебная информация. Возможно динамически освобождать эти четыре байта и записывать туда проверочный код и сравнивать его с кодом из фронтэнда. Будет работать, я проверял.

Транслировать на лету в байт-код x86 умеет Эльбрус.

ARM-процессоры кнопочных телефонов на лету умели транслировать java-байткод в нативные команды процессора. Поэтому на кнопочниках ява не тормозит, даже несмотря на «игрушечность» процессора

Ну мы же о RICS-V говорим, нет?

Кстати, надо глянуть спецификации RISC-V, а то я точно не знаю, откровенно говоря.

На полочке книжечка стоит по ядру на PowerPC-машинах, я когда-то скупал всё, что попадалось под руку. Вот надо глянуть, там есть описание спецификаций. Наверное не сильно устарело.

Это называется динамическая бинарная трансляция. Для app level это может быть условная qemu или любой другой аналог, оно не требует аппаратной поддержки. Еще есть system level DBT типа трансметы или денвера или эльбруса.

Отвечая на вопрос из треда: никаких одобренных спецификаций для ускорения бинарной трансляции на riscv нет. В будушем, может, появятся, но явно не для системной бинарки.

java-байткод куда проще, чем х86 isa. К тому же java vm стековая.

Подушню, но

Транслировать на лету в байт-код x86 умеет Эльбрус.

байткод тут совсем не уместный термин