Спасибо, попробую. Почему нет? Мои руководители высказывали заинтересованность. Понятно - чем больше возможных осей, тем лучше. Впрочем, как обычно бывает в таких вариантах они ждут решения снизу. Впрочем, возможно к них своя правда.
На сайте эта почта указана для разработчиков приложений. Точно имеет смысл спрашивать там именно про портирование? И, если конечно это не секрет - вы сами имеете отношение к Авроре?
Про Apple - это да. Самые разные Hackintosh'и тому нагляднейший пример. Впрочем, пока не видно чтоб код для Apple Silicon работал на чем-то отличном от Apple Silicon. Возможно это потому, что за пределами Apple очень мало ноутбуков и ПК с Aarch64, а может быть и другие причины.
Что до "никто не мешает" - ну наверное. Только вот я говорить от имени организации, а тем более заключать договора, не уполномочен. Да и процедура эта, судя по всему, не формализована. А значит и идти на нее не всякий руководитель захочет. Судя по всему придется ждать пока появится заказчик, выставляющий Аврору как обязательное требование, и готовый за реализацию этого требования платить. Самой Авроре не очень надо расширять парк изделий.
Запустить ваниль, а не ядро от silicon vendor, вы такое по-чесноку часто встречали в проде на ARM платформах ?
Вы, конечно, не поверите, но... Последние лет 15 (чёрт, даже больше - как же я уже стар) это моя основная рабочая обязанность. Так что не только встречал, но и способствую. Другое дело, что за пределами моего мирка (а это две-три организации, на которые я время от времени работаю и одна на которую работаю постоянно) это действительно встречается сильно реже, чем хотелось бы.
На коленке можно все , но это если только ради веры что ваниль лучше LTS, что неправда.
LTS - по сути та же ваниль. Не всегда, правда, накаченая до последних safety and security патчей. Хорошо если у вендора есть хотя бы SLTS-версия. Все становится сильно проще. Но такие вендоры, как правило, в штате имеют свои подразделения, который потихоньку доводят поддержку чипа до вменяемого состояния и в ванили. Правда процесс этот очень медленный. Но даже при этом очень бы хотелось, чтоб все вендоры действовали именно так.
По факту... Ну да - тот же Samsung. Телефоны, во всяком случае популярные модели, всегда могут быть рутованы. В подавляющем большинстве случаев это проблемы с ядром. И чаще всего в вендорских драйверах (ибо остальное так или иначе закрывается в тех самых SLTS версиях). По сути для Samsung это в некотором смысле даже хорошо. Потому могут себе позволить.
Так что что правда, а что нет - решает заказчик. Описанный вами сценарий, да - один из самых массовых. Покупной процессорный модуль с несущей платой. Пара-тройка плат расширеня с датчиками и исполнителями под нужды проекта. Тюнинг загрузчика под возможности восстановления, пропись в DTS обвязки. В крайнем случае свой драйвер, под что-то на микроконтроллере или FPGA. Но пока еще есть те, кто ставит в изделие не модуль, а процессор. Обвязывает его памятью, питанием, накопителями, внешней периферией. И в этом случае объем работ по адаптации вендорского кода и ванили становится соизмерим. Так зачем браться за вендорщину?
Какие арм устройства выпускаете?
Носимые, возимые, стационарные... Европейские, Американские, Китайские. Разные. Для датацентров с пиковой производительностью, блокчейном и нейронными сетями ничего не делаем. А вы с какой целью интересуетесь?
Впрочем, я все это готов вынести за скобки. Оно к делу отношения не имеет. А реально имеет единственный вопрос. Тот самый, который я уже задал. Допустим, я, как часть организации, был бы готов попробовать запустить на разрабатываемом нами железе помимо прочего еще и Аврору. Мне куда?Только вот почти уверен - ответ если и будет, то не очень цензурный.
iOS и MacOS изначально предназначены для работы на cтрого определенном железе и портированию не подлежат (кроме как по желанию Apple). Это предельно четко прописано. Это предельно четко прописано и это понятная позиция авторов. В Авроре так же? Т.е. это во всех смыслах очередной Русский IPhone?
Ваше описание портирования - это не описание портирования. Вернее как... Оно про него, но... Не про него. Ядро Linux на чип от Silicon Vendor надо завести. Желательно не пятилетней давности, как дает производитель, а ваниль. Если у вендора есть хоть что-то - уже хорошо. Но прежде чем заводить его, надо обеспечить его загрузку. Смотрите эту довольно старую презенташку. Она, тем не менее, вполне по делу. То же по драйверам. Если посмотреть на их код, который под NDA как правило, то обычно становится очень и очень грустно. Это, конечно, если код тот в принципе есть. Но даже если так, то пускать его напрямую в production - очень сомнительное и смелое решение. Оно возможно - я не спорю. Больше того, оно регулярно случается. Но обычно именно оно источник трудноразрешимых, а то и вообще фатальных проблем. Впрочем, это уже к железу. А мы здесь все же ось обсуждаем.
Допустим, я, как часть организации, был бы готов попробовать запустить на разрабатываемом нами железе помимо прочего еще и Аврору. Мне куда? К тем ребятам (производителю) со спецификацией и вагоном денег или есть другие пути?
Для Linux есть понятные шаги как его портировать на новый ARM. Для AOSP есть. Для (кто там был у Mozilla) тоже были. В принципе даже для Windows известно что делать. Во всяком случае эту информацию когда-то можно было найти. Если не простому смертному, то организации.
А тут что? Ограниченный круг допущенных? NDA? Ещё что-то?
А давайте так - у Андроид есть AOSP и внятные требования для аппаратуры. Что она должна поддерживать и обеспечивать для работы системы. Есть такое для Авроры? Вообще интересно было бы почитать про то как портировать Аврору на новую платформу (и в целом могут ли этим заниматься разработчики платформы или ждать милости от разработчиков Авроры)? Собственно говоря, отчасти от этого зависит распространенность (а значит и популярность) платформы.
Другое дело, что с подходом - мы самые безопасные, потому что о нас никто не знает... Вспоминается старый анекдот про Неуловимого Джо. Ровно с той же концовкой.
Может быть. А может наоборот - производителям не интересно иметь унифицированную тару. Когда различие только в наполнении и цене. Ни один гигант, даже такой как CocaCola никогда не сможет провернуть такое без четкой унификации тары.
Рыбки - это уже про другое. Из сцены интересны только те, которые максимум в 1К размером, а лучше 256 байт. Вот тут чудеса упрощения алгоритмов и оптимизации. Даже 4К уже не настолько вылизаны.
Помимо тетриса и змейки есть еще реверси, ветка (или как там она в оригинале), арканоид, сокобан. Это из того, что на слуху. Список наверняка не полный. Они все предельно просты и категорически нетребовательны к ресурсам. Самое интересное, что находятся и относительно современные варианты. В частности flappy birds (или я чего-то не знаю)?
А еще часто используются старые находки демосцены. Огонь, бублик, полет над планетой и через космос. Но они, как правило, не интерактивны и используются именно как демо.
если верить мануалу к монитору, то можно было 1024х768 черезстрочно. В Windows 3.11 это работало. Здесь так и не завел. Помимо прочего создатели монитора (как много бы я дал тогда за эту информацию...) посадили один из выводов будущего DDC канала на землю. Когда-то именно это было признаком подключенного монохромного монитора. И очень многие это трактовали именно как монохром - как у Hercules'ов. В частности Norton Utilites ни в какую не хотели быть цветными (по факту оттенками серого), а были именно монохромом. И то ли Linux, то ли XFree86 туда же. Помню что даже пересобирал что-то, дабы наглухо отключить эту особенность и заставить считать это дело цветным безоговорочно. Это было сильно важнее, чем черестрок завести.
Да, первый Linux, который был поставлен и получен доступ к консоли. Повозиться с конфигом иксов для цироза в PS/2 машинке с монохромным VGA пришлось повозиться. Но 800x600 тогда получилось.
У меня первый монитор был монохромным (те самые оттенки серого). В принципе, даже в lines играть можно было. Но исключать тот факт, что именно по этой причине меня куда больше влекло программирование, нежели гейминг исключать нельзя.
Сегодня включать детям такое... Я бы не стал. Хотя... Возможно, что-то в этом есть....
Ну, сказав "А", неплохо бы сказать и "Бе". Приведите реализацию поставленной задачи на Pascal. Так, чтоб все компиляторы ее съедали. Попкорн я уже заготовил.
Реализуйте эту же задачу на вашем любимом языке. Желательно чтоб у того не было единственного, богами созданного, компилятора и был принятый стандарт языка.
А за одно объясните нам практическую ценность. А то правда не очень понятно зачем это надо и как это использовать.
Ну да. С ростом кодовой базы, начинаем топтать те же грабли, что и C. Особенно опускаясь к тому же уровню исполнения. И с теми же проблемами. Этот арканоид никогда не будет работать, на чем-то отличном от PC c VGA. Но "зоопарк архитектур" уже начинает влиять.
Вообще мы с вами на разных языках разговариваем. Начиная с того, что память, разделяемая на память-память с произвольным доступом и порты ввода-вывода с доступом только с использованием пары специальных ассемблерных инструкций - это чуть ли не уникальный костыль PC. Понятно откуда взявшийся, но от этого не менее уникальный. От костыля этого, по сути, уже отказались и держат исключительно для совместимости с legacy решениями. Сравнивать его даже с регистрами периферийных блоков STM32 или AVR не самая корректная идея. Это физически очень разные сущности. Не говоря уже про программные каналы где бы то не было.
Да и ассемблер, в общем случае, оперирует очень небольшим количеством базовых типов (из которых тот же Rust плодит производные). И очень небольшим количеством операндов. Ваше строгое "нельзя" точно не соответствует истине. В конце-концов и при трансляции все сводится к ассемблерным инструкциям. Другое дело, что целесообразность этих операций вызывает серьезные вопросы. А вот вопрос как относиться к человеку, который пишет asm! - как к вредителю, не желающему пользоваться средствами языка, или как к профи, обходящему бутылочное горлышко... Впрочем, ваш ответ понятен. Имеете право.
Трансляцию можно посмотреть с помощью какого-нибудь cargo-asm, но, если честно, не совсем уверен, что вы хотите там увидеть - при сборке с оптимизацией вызова Arkanoid::new() там просто нет.
Ну давайте так - этот проект одна из множества попыток поиграть на embedded поле. Без runtime, без аллокатора, и даже без ОС. И в отличии от обычных Skeleton-ов тут есть какой-то ощутимый результат. Тем и интересен. Потому и пошел смотреть, а не пролистал как обычно.
Да, есть "золотой фонд" - змейка, тетрис, арканоид. Ну еще с пламя, бублик и ряд других находок с демосцены. Достаточно простые в реализации, не требовательные к ресурсам. Все они в некотором смысле "Hello, World!". Тем и интересны.
Только вот по embedded правилам игра идет несколько по шуллерски (или по читерски если хотите). В этом нет ничего плохого, но просто надо понимать - тогда это не Embedded, а скорее Demo. Что в обзем случае тоже совсем не плохо. Да, здесь нет ОС. Но кто-то должен проинициализировать память, накопители, прочитать BOOT сектор, передать управление. Т.е. подготовить поляну для работы кода. В реальной жизни embedded проекта этого всего, как правило, нет и этим озадачен сам проект. Тут этим всем занимается BIOS. Ну да бог с ней - это не страшно, а скорее полезно. Хотя, чего тут - тот же код, но подменяющий не BOOT сектор, а образ. BIOS (раз уж он такой независимый) - это было бы сильно интереснее и показательнее и куда как ближе к тому самому embedded (хотя, безусловно, на порядок сложнее).
В частности здесь я без ассемблера не очень понимаю как и кем готовится поляна, и в первую очередь в части памяти. Поэтому предполагаю что живет она частично на предварительно подготовленном стеке, а частично делается той самой new() (допускаю, что плюсы меня сильно отравили, но все же). При этом я не вижу привычных операций по подготовке стека, очистки и инициализации сегментов данных и прочего. Того круче - я вообще не вижу обозначенных границ доступной памяти во всем проекте.
Т.е. какой-то очень специфический embedded/demo получается. И становится интересно - это недоработки проекта, полагания на то, что BOOT сектор на любой машине окажется по фиксированным адресам с фиксированнымы настройками сегментов памяти или это я слепой и не вижу где и как это все делается. В таких случаях мой арбитр всегда один - итоговый код. Ему работать - а значит в нем все будет.
А вообще интересно. Есть ли у Rust опция, которая позволяет оставлять промежуточные файлы (как у gcc)? Тот вполне в состоянии предоставить тот самый подстрочник. В реальном embedded весьма востребованный инструмент. Не ежедневного использования, но все же.
P.S.
О недоверии ассемблерным вставкам говорю не я. Я этому скорее удивляюсь. И пытаюсь понять почему так.
#[unsafe(no_mangle)]
pub extern "C" fn _start() -> ! {
let mut game = Arkanoid::new();
Ага. Осмотрелся повнимательнее. Я правильно понимаю, что это заклинание как раз сделало то, что категорически не приветствуется. Объявило unsafe контекст на весь код. И дальше не столь важно будет или не будет вложенный блок (функция) помечена как unsafe - это уже ничего не изменит. А данный пример, делает по сути не больше и не безопаснее, чем аналогичный С код? Так получается?
Тем более интересно посмотреть подстрочную трансляцию. И в первую очередь третьей строчки в этом частичном листинге.
И еще - а что реально такая большая разница между asm! в Rust и asm{} в С? Я полагал что это куда как более близкие родственники, чем #define.
Потом - не всякий ассемблер небезопасен. В частности примеры автора - надо сильно много думать, чтоб придумать их небезопасное поведение. nop как инструкция абсолютно безопасна - она просто не делает ничего (кроме инкремента PC). Чтение порта... Ну, черт знает. Была бы запись - да, возможно. Чтение... На вскидку даже не предположу что и как оно может поломать. Правда и на 100% уверенно сказать что не может не возьмусь. Но на 99,9 точно уверен - не может. Если к кого есть пример как оно может поломать - пишите. Будет интересно заняться цифровой археологией. Раз уж все равно клавиатуру из 0x60-ого порта считываем (это даже не юность - это мое детство).
Собственно потому и удивляет безусловное недоверие ассемблерным вставкам. Фобией попахивает. Или параноей. Кому что ближе.
Если так, то просто отлично. Попробую связаться. Чем не шутит черт?
Спасибо, попробую. Почему нет? Мои руководители высказывали заинтересованность. Понятно - чем больше возможных осей, тем лучше. Впрочем, как обычно бывает в таких вариантах они ждут решения снизу. Впрочем, возможно к них своя правда.
На сайте эта почта указана для разработчиков приложений. Точно имеет смысл спрашивать там именно про портирование? И, если конечно это не секрет - вы сами имеете отношение к Авроре?
Про Apple - это да. Самые разные Hackintosh'и тому нагляднейший пример. Впрочем, пока не видно чтоб код для Apple Silicon работал на чем-то отличном от Apple Silicon. Возможно это потому, что за пределами Apple очень мало ноутбуков и ПК с Aarch64, а может быть и другие причины.
Что до "никто не мешает" - ну наверное. Только вот я говорить от имени организации, а тем более заключать договора, не уполномочен. Да и процедура эта, судя по всему, не формализована. А значит и идти на нее не всякий руководитель захочет. Судя по всему придется ждать пока появится заказчик, выставляющий Аврору как обязательное требование, и готовый за реализацию этого требования платить. Самой Авроре не очень надо расширять парк изделий.
Может. В бесконечной вселенной возможно все. (с)
Черт, в других переводах оно звучит как "В бесконечной Вселенной все может случиться". Впрочем, сути это совершенно не меняет.
Вы, конечно, не поверите, но... Последние лет 15 (чёрт, даже больше - как же я уже стар) это моя основная рабочая обязанность. Так что не только встречал, но и способствую. Другое дело, что за пределами моего мирка (а это две-три организации, на которые я время от времени работаю и одна на которую работаю постоянно) это действительно встречается сильно реже, чем хотелось бы.
LTS - по сути та же ваниль. Не всегда, правда, накаченая до последних safety and security патчей. Хорошо если у вендора есть хотя бы SLTS-версия. Все становится сильно проще. Но такие вендоры, как правило, в штате имеют свои подразделения, который потихоньку доводят поддержку чипа до вменяемого состояния и в ванили. Правда процесс этот очень медленный. Но даже при этом очень бы хотелось, чтоб все вендоры действовали именно так.
По факту... Ну да - тот же Samsung. Телефоны, во всяком случае популярные модели, всегда могут быть рутованы. В подавляющем большинстве случаев это проблемы с ядром. И чаще всего в вендорских драйверах (ибо остальное так или иначе закрывается в тех самых SLTS версиях). По сути для Samsung это в некотором смысле даже хорошо. Потому могут себе позволить.
Так что что правда, а что нет - решает заказчик. Описанный вами сценарий, да - один из самых массовых. Покупной процессорный модуль с несущей платой. Пара-тройка плат расширеня с датчиками и исполнителями под нужды проекта. Тюнинг загрузчика под возможности восстановления, пропись в DTS обвязки. В крайнем случае свой драйвер, под что-то на микроконтроллере или FPGA. Но пока еще есть те, кто ставит в изделие не модуль, а процессор. Обвязывает его памятью, питанием, накопителями, внешней периферией. И в этом случае объем работ по адаптации вендорского кода и ванили становится соизмерим. Так зачем браться за вендорщину?
Носимые, возимые, стационарные... Европейские, Американские, Китайские. Разные. Для датацентров с пиковой производительностью, блокчейном и нейронными сетями ничего не делаем. А вы с какой целью интересуетесь?
Впрочем, я все это готов вынести за скобки. Оно к делу отношения не имеет. А реально имеет единственный вопрос. Тот самый, который я уже задал. Допустим, я, как часть организации, был бы готов попробовать запустить на разрабатываемом нами железе помимо прочего еще и Аврору. Мне куда?
Только вот почти уверен - ответ если и будет, то не очень цензурный.iOS и MacOS изначально предназначены для работы на cтрого определенном железе и портированию не подлежат (кроме как по желанию Apple). Это предельно четко прописано. Это предельно четко прописано и это понятная позиция авторов. В Авроре так же? Т.е. это во всех смыслах очередной Русский IPhone?
Ваше описание портирования - это не описание портирования. Вернее как... Оно про него, но... Не про него. Ядро Linux на чип от Silicon Vendor надо завести. Желательно не пятилетней давности, как дает производитель, а ваниль. Если у вендора есть хоть что-то - уже хорошо. Но прежде чем заводить его, надо обеспечить его загрузку. Смотрите эту довольно старую презенташку. Она, тем не менее, вполне по делу. То же по драйверам. Если посмотреть на их код, который под NDA как правило, то обычно становится очень и очень грустно. Это, конечно, если код тот в принципе есть. Но даже если так, то пускать его напрямую в production - очень сомнительное и смелое решение. Оно возможно - я не спорю. Больше того, оно регулярно случается. Но обычно именно оно источник трудноразрешимых, а то и вообще фатальных проблем. Впрочем, это уже к железу. А мы здесь все же ось обсуждаем.
Допустим, я, как часть организации, был бы готов попробовать запустить на разрабатываемом нами железе помимо прочего еще и Аврору. Мне куда? К тем ребятам (производителю) со спецификацией и вагоном денег или есть другие пути?
Очень рад за этих ребят. Но...
Для Linux есть понятные шаги как его портировать на новый ARM. Для AOSP есть. Для (кто там был у Mozilla) тоже были. В принципе даже для Windows известно что делать. Во всяком случае эту информацию когда-то можно было найти. Если не простому смертному, то организации.
А тут что? Ограниченный круг допущенных? NDA? Ещё что-то?
А давайте так - у Андроид есть AOSP и внятные требования для аппаратуры. Что она должна поддерживать и обеспечивать для работы системы. Есть такое для Авроры? Вообще интересно было бы почитать про то как портировать Аврору на новую платформу (и в целом могут ли этим заниматься разработчики платформы или ждать милости от разработчиков Авроры)? Собственно говоря, отчасти от этого зависит распространенность (а значит и популярность) платформы.
Другое дело, что с подходом - мы самые безопасные, потому что о нас никто не знает... Вспоминается старый анекдот про Неуловимого Джо. Ровно с той же концовкой.
Может быть. А может наоборот - производителям не интересно иметь унифицированную тару. Когда различие только в наполнении и цене. Ни один гигант, даже такой как CocaCola никогда не сможет провернуть такое без четкой унификации тары.
Рыбки - это уже про другое. Из сцены интересны только те, которые максимум в 1К размером, а лучше 256 байт. Вот тут чудеса упрощения алгоритмов и оптимизации. Даже 4К уже не настолько вылизаны.
Помимо тетриса и змейки есть еще реверси, ветка (или как там она в оригинале), арканоид, сокобан. Это из того, что на слуху. Список наверняка не полный. Они все предельно просты и категорически нетребовательны к ресурсам. Самое интересное, что находятся и относительно современные варианты. В частности flappy birds (или я чего-то не знаю)?
А еще часто используются старые находки демосцены. Огонь, бублик, полет над планетой и через космос. Но они, как правило, не интерактивны и используются именно как демо.
если верить мануалу к монитору, то можно было 1024х768 черезстрочно. В Windows 3.11 это работало. Здесь так и не завел. Помимо прочего создатели монитора (как много бы я дал тогда за эту информацию...) посадили один из выводов будущего DDC канала на землю. Когда-то именно это было признаком подключенного монохромного монитора. И очень многие это трактовали именно как монохром - как у Hercules'ов. В частности Norton Utilites ни в какую не хотели быть цветными (по факту оттенками серого), а были именно монохромом. И то ли Linux, то ли XFree86 туда же. Помню что даже пересобирал что-то, дабы наглухо отключить эту особенность и заставить считать это дело цветным безоговорочно. Это было сильно важнее, чем черестрок завести.
Да, первый Linux, который был поставлен и получен доступ к консоли. Повозиться с конфигом иксов для цироза в PS/2 машинке с монохромным VGA пришлось повозиться. Но 800x600 тогда получилось.
У меня первый монитор был монохромным (те самые оттенки серого). В принципе, даже в lines играть можно было. Но исключать тот факт, что именно по этой причине меня куда больше влекло программирование, нежели гейминг исключать нельзя.
Сегодня включать детям такое... Я бы не стал. Хотя... Возможно, что-то в этом есть....
Поздно заметил тег "перевод". Каюсь. Думал статья "живого" автора. А так да, абсолютно согласен.
Ну, сказав "А", неплохо бы сказать и "Бе". Приведите реализацию поставленной задачи на Pascal. Так, чтоб все компиляторы ее съедали. Попкорн я уже заготовил.
Реализуйте эту же задачу на вашем любимом языке. Желательно чтоб у того не было единственного, богами созданного, компилятора и был принятый стандарт языка.
А за одно объясните нам практическую ценность. А то правда не очень понятно зачем это надо и как это использовать.
Ну да. С ростом кодовой базы, начинаем топтать те же грабли, что и C. Особенно опускаясь к тому же уровню исполнения. И с теми же проблемами. Этот арканоид никогда не будет работать, на чем-то отличном от PC c VGA. Но "зоопарк архитектур" уже начинает влиять.
Вообще мы с вами на разных языках разговариваем. Начиная с того, что память, разделяемая на память-память с произвольным доступом и порты ввода-вывода с доступом только с использованием пары специальных ассемблерных инструкций - это чуть ли не уникальный костыль PC. Понятно откуда взявшийся, но от этого не менее уникальный. От костыля этого, по сути, уже отказались и держат исключительно для совместимости с legacy решениями. Сравнивать его даже с регистрами периферийных блоков STM32 или AVR не самая корректная идея. Это физически очень разные сущности. Не говоря уже про программные каналы где бы то не было.
Да и ассемблер, в общем случае, оперирует очень небольшим количеством базовых типов (из которых тот же Rust плодит производные). И очень небольшим количеством операндов. Ваше строгое "нельзя" точно не соответствует истине. В конце-концов и при трансляции все сводится к ассемблерным инструкциям. Другое дело, что целесообразность этих операций вызывает серьезные вопросы. А вот вопрос как относиться к человеку, который пишет asm! - как к вредителю, не желающему пользоваться средствами языка, или как к профи, обходящему бутылочное горлышко... Впрочем, ваш ответ понятен. Имеете право.
Ну давайте так - этот проект одна из множества попыток поиграть на embedded поле. Без runtime, без аллокатора, и даже без ОС. И в отличии от обычных Skeleton-ов тут есть какой-то ощутимый результат. Тем и интересен. Потому и пошел смотреть, а не пролистал как обычно.
Да, есть "золотой фонд" - змейка, тетрис, арканоид. Ну еще с пламя, бублик и ряд других находок с демосцены. Достаточно простые в реализации, не требовательные к ресурсам. Все они в некотором смысле "Hello, World!". Тем и интересны.
Только вот по embedded правилам игра идет несколько по шуллерски (или по читерски если хотите). В этом нет ничего плохого, но просто надо понимать - тогда это не Embedded, а скорее Demo. Что в обзем случае тоже совсем не плохо. Да, здесь нет ОС. Но кто-то должен проинициализировать память, накопители, прочитать BOOT сектор, передать управление. Т.е. подготовить поляну для работы кода. В реальной жизни embedded проекта этого всего, как правило, нет и этим озадачен сам проект. Тут этим всем занимается BIOS. Ну да бог с ней - это не страшно, а скорее полезно. Хотя, чего тут - тот же код, но подменяющий не BOOT сектор, а образ. BIOS (раз уж он такой независимый) - это было бы сильно интереснее и показательнее и куда как ближе к тому самому embedded (хотя, безусловно, на порядок сложнее).
В частности здесь я без ассемблера не очень понимаю как и кем готовится поляна, и в первую очередь в части памяти. Поэтому предполагаю что живет она частично на предварительно подготовленном стеке, а частично делается той самой new() (допускаю, что плюсы меня сильно отравили, но все же). При этом я не вижу привычных операций по подготовке стека, очистки и инициализации сегментов данных и прочего. Того круче - я вообще не вижу обозначенных границ доступной памяти во всем проекте.
Т.е. какой-то очень специфический embedded/demo получается. И становится интересно - это недоработки проекта, полагания на то, что BOOT сектор на любой машине окажется по фиксированным адресам с фиксированнымы настройками сегментов памяти или это я слепой и не вижу где и как это все делается. В таких случаях мой арбитр всегда один - итоговый код. Ему работать - а значит в нем все будет.
А вообще интересно. Есть ли у Rust опция, которая позволяет оставлять промежуточные файлы (как у gcc)? Тот вполне в состоянии предоставить тот самый подстрочник. В реальном embedded весьма востребованный инструмент. Не ежедневного использования, но все же.
P.S.
О недоверии ассемблерным вставкам говорю не я. Я этому скорее удивляюсь. И пытаюсь понять почему так.
Ага. Осмотрелся повнимательнее. Я правильно понимаю, что это заклинание как раз сделало то, что категорически не приветствуется. Объявило unsafe контекст на весь код. И дальше не столь важно будет или не будет вложенный блок (функция) помечена как unsafe - это уже ничего не изменит. А данный пример, делает по сути не больше и не безопаснее, чем аналогичный С код? Так получается?
Тем более интересно посмотреть подстрочную трансляцию. И в первую очередь третьей строчки в этом частичном листинге.
И еще - а что реально такая большая разница между asm! в Rust и asm{} в С? Я полагал что это куда как более близкие родственники, чем #define.
Потом - не всякий ассемблер небезопасен. В частности примеры автора - надо сильно много думать, чтоб придумать их небезопасное поведение. nop как инструкция абсолютно безопасна - она просто не делает ничего (кроме инкремента PC). Чтение порта... Ну, черт знает. Была бы запись - да, возможно. Чтение... На вскидку даже не предположу что и как оно может поломать. Правда и на 100% уверенно сказать что не может не возьмусь. Но на 99,9 точно уверен - не может. Если к кого есть пример как оно может поломать - пишите. Будет интересно заняться цифровой археологией. Раз уж все равно клавиатуру из 0x60-ого порта считываем (это даже не юность - это мое детство).
Собственно потому и удивляет безусловное недоверие ассемблерным вставкам. Фобией попахивает. Или параноей. Кому что ближе.