Есть вообще чудо техники: FireSim — ему даётся маленький инстанс на Amazon, ключ API и исходник на Chisel, а он сам развернёт сборочные инстансы, FPGA-инстансы, прогонит тесты. Правда смущает вот что:
после прочтения этой статьи я как-то начал опасаться сочетания постоплатной системы и API-ключей. Впрочем, с тех пор, возможно, всё десять раз поменялось
не знаю, нет ли риска "спалить" FPGA-ускоритель аппаратно (а стоит он, наверное, весьма немало)
А вообще было бы забавно (даже без FireSim и API-ключей): "На AWS нет нужной архитектуры процессора — сейчас исправим!" — ПЛИСины там стоят огромные и стоимость аренды гуманная (подсказка: спотовые инстансы существенно дешевле, если подходят в плане доступности под задачу — не "всегда on-line", а "когда-нибудь посчитать подешевле").
Кстати, как говорится, на правах рекламы: если вдруг будет интересно из серии "написать с нуля", тут я экспериментировал с генерацией композитного сигнала как раз на "Марсоходе", но предупреждаю, там редкостный гов^Wнеидиоматичный код с точки зрения HDL, зато с нуля. :)
Спасибо! :) На всякий случай уточню: моего кода здесь и 0.1% не наберётся — я его только портирую на нестандартную плату
Если надумаете покупать плату, рекомендую попробовать для начала синтезировать целевой дизайн: я вот сначала думал вообще на втором "Марсоходе" попробовать RocketChip, а оказалось, он даже минимальный приблизительно 16K ячеек (против 10 у платы). А когда я переключился с Tiny ядра на Small, использование подскочило до ~30K (и 60K у Big)! А я ещё думал, не купить ли что поизвестнее да попроще!..
Кстати, сейчас на чём только аппаратуру не пишут: Haskell, Scala, даже Python. Но на Scala добрые люди целый процессор написали!
«Говорю же, чисто поржать» А если серьёзно — то изначально это было "на слабо" — написать JIT, который будет переделывать машинный код в JS (а QEMU в силу наличия режима не-аппаратной виртуализации для этого чудесно подходил). Ну а потом уже какие-то use case-ы начали вырисовываться.
Это виртуальная машина, работающая в браузере. Потенциально, более быстрая, чем аналоги, и уж вряд ли кто с нуля напишет для такого количества гостевых архитектур. В ней можно, например, демонстрировать однодискетные ОС прямо на сайте. Или прошивки для встраиваемых устройств.
Возможно. К счастью, TCG более-менее общий и там, и там. Правда, 64-битные гостевые системы у меня пока не поддерживаются.
С другой стороны, если от приложения есть исходники, то возможно, его проще будет пересобрать Emscripten-ом нативно. Да и как его в браузер запихивать, со всеми-то зависимостями… В общем, тут с ходу не скажешь. С ОС такого не получится. Хотя, если в дополнение к слою syscalls дописать в Emscripten слой hypercalls и тривиальное паравиртуализованное оборудование… :)
Если интересно, вот здесь есть обсуждение реализации Binaryen TCG Backend. Здесь — прототип, но в Хроме от него быстро падает вкладка (не готовы они к тому, что будет больше ~1000 WASM-модулей), ну и с лицензией у него есть некие шероховатости — QEMU как целое распространяется под GPLv2, а Binaryen — под Apache 2.0. Они говорят, что есть надежда это как-то "починить".
Теоретически, она должна была закончиться второй статьёй и финальной (точнее, стабильной и замороженной) версией, но она ещё не готова — вечно находится что-нибудь более интересное и перспективное. На данный момент многие мелкие доделки запуллреквесчены в Emscripten и есть прототип с трансляцией уже в WASM (и честным TCG-бекендом) — он, вроде, существенно отзывчивее и весит поменьше, но есть один маленький нюанс: отсутствует поддержка блочных устройств. Дело в том, что они в QEMU традиционно делаются через корутины, а корутины поддержать в JS или WASM проблематично (нет низкоуровневых манипуляций стеком и с потоками некоторые проблемы), поэтому они делаются через предоставленный Emscripten-ом интерпретатор (Emterpreter). Заставить компилятор разделить код на интерпретируемую и "нативно" запускаемую часть в этот раз, увы, не получилось. Нужно ещё попробовать.
Честно говоря, не берусь сказать, но, может, эта страница чем-то подскажет. Сам я, технически тоже использовал два clock domain (один "умный" и один "высокочастотный"), но связывал их снаружи на диаграмме.
Согласен, с примерами — беда. Это, скорее, точки входа и то, что я знаю «вотпрямщас». По тому же rr я уже давно хотел написать tutorial, но даже непонятно, как подступиться (думаю, там не на одну статью хватит).
Тот же strace — такое умеет, что просто жуть!
У ltrace, помнится, вообще man было страшно читать — столько опций.
Кому нужен много контроля и низкий уровень — пишут на С.
Кому нужен максимальный контроль — на asm.
<сарказм>… а кому нужно ещё больше контроля, пишут на Scala.</сарказм> Я, конечно, понимаю, что это просто DSL, но забавно всё-таки, что функциональный язык оказался в чём-то ближе к железу, чем asm (да, я знаю, что можно "писать процессоры" хоть на Python).
Ссылки на сайты опенсорсных и бесплатных продуктов, если на сайте нет платных продуктов-сателлитов. Наличие платной техподдержки и форм донейта на сайтах допускается.
То есть теперь нельзя дать для удобства ссылку на скачивание Visual Studio Code / Idea Community Edition / ещё чего-то, в чём создан приложенный проект? Не то, чтобы замена ссылки простым упоминанием была большой проблемой, просто в порядке занудства.
Правда, боюсь, проблематично "успешно пройти" проверку фаззингом — её, скорее, можно "не завалить" за определённое время под определённым типом тестовых данных. Это же не формальное доказательство.
Есть вообще чудо техники: FireSim — ему даётся маленький инстанс на Amazon, ключ API и исходник на Chisel, а он сам развернёт сборочные инстансы, FPGA-инстансы, прогонит тесты. Правда смущает вот что:
А вообще было бы забавно (даже без FireSim и API-ключей): "На AWS нет нужной архитектуры процессора — сейчас исправим!" — ПЛИСины там стоят огромные и стоимость аренды гуманная (подсказка: спотовые инстансы существенно дешевле, если подходят в плане доступности под задачу — не "всегда on-line", а "когда-нибудь посчитать подешевле").
Кстати, как говорится, на правах рекламы: если вдруг будет интересно из серии "написать с нуля", тут я экспериментировал с генерацией композитного сигнала как раз на "Марсоходе", но предупреждаю, там редкостный гов^Wнеидиоматичный код с точки зрения HDL, зато с нуля. :)
Спасибо! :) На всякий случай уточню: моего кода здесь и 0.1% не наберётся — я его только портирую на нестандартную плату
Если надумаете покупать плату, рекомендую попробовать для начала синтезировать целевой дизайн: я вот сначала думал вообще на втором "Марсоходе" попробовать RocketChip, а оказалось, он даже минимальный приблизительно 16K ячеек (против 10 у платы). А когда я переключился с Tiny ядра на Small, использование подскочило до ~30K (и 60K у Big)! А я ещё думал, не купить ли что поизвестнее да попроще!..
Кстати, сейчас на чём только аппаратуру не пишут: Haskell, Scala, даже Python. Но на Scala добрые люди целый процессор написали!
-
О, точно! Спасибо! Но умение выполнять пачку команд с терминала тоже пригодится :) Только там уже, наверное, лучше будет использовать
-x script-file«Говорю же, чисто поржать» А если серьёзно — то изначально это было "на слабо" — написать JIT, который будет переделывать машинный код в JS (а QEMU в силу наличия режима не-аппаратной виртуализации для этого чудесно подходил). Ну а потом уже какие-то use case-ы начали вырисовываться.
Это виртуальная машина, работающая в браузере. Потенциально, более быстрая, чем аналоги, и уж вряд ли кто с нуля напишет для такого количества гостевых архитектур. В ней можно, например, демонстрировать однодискетные ОС прямо на сайте. Или прошивки для встраиваемых устройств.
Ну, когда-то у меня вообще возникло ощущение, что "хренак-хренак и в продакшн" + автотесты => GitHub Flow.
Возможно. К счастью, TCG более-менее общий и там, и там. Правда, 64-битные гостевые системы у меня пока не поддерживаются.
С другой стороны, если от приложения есть исходники, то возможно, его проще будет пересобрать Emscripten-ом нативно. Да и как его в браузер запихивать, со всеми-то зависимостями… В общем, тут с ходу не скажешь. С ОС такого не получится. Хотя, если в дополнение к слою syscalls дописать в Emscripten слой hypercalls и тривиальное паравиртуализованное оборудование… :)
Статья
Если интересно, вот здесь есть обсуждение реализации Binaryen TCG Backend. Здесь — прототип, но в Хроме от него быстро падает вкладка (не готовы они к тому, что будет больше ~1000 WASM-модулей), ну и с лицензией у него есть некие шероховатости — QEMU как целое распространяется под GPLv2, а Binaryen — под Apache 2.0. Они говорят, что есть надежда это как-то "починить".
Теоретически, она должна была закончиться второй статьёй и финальной (точнее, стабильной и замороженной) версией, но она ещё не готова — вечно находится что-нибудь более интересное и перспективное. На данный момент многие мелкие доделки запуллреквесчены в Emscripten и есть прототип с трансляцией уже в WASM (и честным TCG-бекендом) — он, вроде, существенно отзывчивее и весит поменьше, но есть один маленький нюанс: отсутствует поддержка блочных устройств. Дело в том, что они в QEMU традиционно делаются через корутины, а корутины поддержать в JS или WASM проблематично (нет низкоуровневых манипуляций стеком и с потоками некоторые проблемы), поэтому они делаются через предоставленный Emscripten-ом интерпретатор (Emterpreter). Заставить компилятор разделить код на интерпретируемую и "нативно" запускаемую часть в этот раз, увы, не получилось. Нужно ещё попробовать.
Честно говоря, не берусь сказать, но, может, эта страница чем-то подскажет. Сам я, технически тоже использовал два clock domain (один "умный" и один "высокочастотный"), но связывал их снаружи на диаграмме.
Согласен, с примерами — беда. Это, скорее, точки входа и то, что я знаю «вотпрямщас». По тому же rr я уже давно хотел написать tutorial, но даже непонятно, как подступиться (думаю, там не на одну статью хватит).
У ltrace, помнится, вообще man было страшно читать — столько опций.
<сарказм>… а кому нужно ещё больше контроля, пишут на Scala.</сарказм> Я, конечно, понимаю, что это просто DSL, но забавно всё-таки, что функциональный язык оказался в чём-то ближе к железу, чем asm (да, я знаю, что можно "писать процессоры" хоть на Python).
WooHoo, наверное, хочет сказать, что сравнивать "площадь" (
38 попугаев24 икстерма) и диагональ (24 дюйма) — размерность не сходится.Да уж, даже говоря про программу размером в 10, байт лучше не употреблять термин самая маленькая. Ну, будем считать, что это была версия под C++ :)
Ну, тут хоть приблизительно описано, для чего использовать нельзя, хотя и не СПО, конечно, но её использование выглядит не так рискованно.
То есть теперь нельзя дать для удобства ссылку на скачивание Visual Studio Code / Idea Community Edition / ещё чего-то, в чём создан приложенный проект? Не то, чтобы замена ссылки простым упоминанием была большой проблемой, просто в порядке занудства.
Правда, боюсь, проблематично "успешно пройти" проверку фаззингом — её, скорее, можно "не завалить" за определённое время под определённым типом тестовых данных. Это же не формальное доказательство.
Был The Fuzzing Project с похожими целями, ему, вроде, даже грант от Linux Foundation выдали на это, но конкретно сейчас сайт, похоже, лежит...