Комментарии 19
Когда читаешь такую статью, думаешь что там такого. Но если кто попробует написать что-то на голом железе на си, вот даже под x86, то осознает насколько глубока кроличья нора. И насколько это реально сложно.
На голом железе в реализации с использованием ассемблера хорошо проработана
тематика создания Форт (Forth) систем и примеров этого подхода много и в проектах
на Github, но т.к. это мало представлено в каких то опубликованных статьях/книгах, то и
можно констатировать что этого в целом нет.
P.S. Один из проектов представленный в книге по программироанию на х86-64 ассемблере
Проект Forthress
С ассемблером как раз не очень сложно, а вы на си попробуйте.
За счет чего на C что-то может быть сложнее, чем на ассемблере? Ну, кроме экономии единиц байтов/тактов, само собой.
Главная проблема — это обеспечение совместимости. Можете посмотреть в моих последних статьях, например в этой. На асме всё просто, а вот си, нужно писать правильный линкер-файл, реализовывать стандартные библиотеки и прочее-прочее, но в результате получаем привычный инструментарий.
Правильный линкер-файл нужен в любом случае - ассемблер тоже не делает готового к исполнению кода.
И "на си" автоматически не подразумевает использования стандартных библиотек. Даже если их нет, писать на C всяко удобнее, чем на ассемблере.
Всё так, я об этом и говорил. Просто адаптировать си под голое железо чуть сложнее, но тоже реально. Мы говорим об одном и том же.
Я не понимаю, где там "сложнее". :) Любой вменяемый линкер изготовит корректный исполняемый бинарник из объектных файлов, не содержащих внешних ссылок. Разница лишь в том, что из ассемблерных файлов это получается автоматически, а для сишных придется явно указать линкеру точку входа, чтоб не тащил из библиотек CRT. То есть, вся "сложность" - в указании ключа в командной строке линкера. Считать это усложнением задачи несерьезно. :)
Ну начнём с того, что на си нужно будет использовать два языка. Плюс надо знать особенности компиляции и трансляции языка. Понимать формат elf и т.п. Значительно большее количество знаний. На ассемблере пишем на одном языке и потом линкуем линкером.
Но я полагаю, что у вас не было опыта такого, типа разработки загрузчика какого-нибудь для x86 платформы, поэтому вам кажется это простым.
Как человек реализовавший два проекта на ассемблере и си, скажу что си сложнее. Потому что надо в случае си знать и ассемблер, и особенности компилятора и прочее-прочее.
надо знать особенности компиляции и трансляции языка
Это справедливо и для ассемблера, если он не совсем примитивный. Если просто писать текст на ассемблере по справочнику, не проверяя, во что это транслируется, нетрудно и нарваться.
Понимать формат elf
Это не обязательно. Как уже правильно заметили, вполне достаточно иметь средства преобразования из ELF в голый бинарник.
Значительно большее количество знаний
Если это не любительское поделие на один вечер, то большее количество знаний с лихвой компенсируется увеличением скорости/надежности разработки.
полагаю, что у вас не было опыта такого
Именно загрузчика - нет, а "голый код" для загрузки по абсолютному адресу, без привязки к внешним API - был. Чем это принципиально отличается?
C Си/C++ тоже нет особых проблем, если посмотреть навскидку сколько и каких Форт систем реализовано: kForth, pForth, gForth, Ficl, BigForth… (далеко не весь перечисленный список)
сложнее в них при реализации добится существенного ускорения Форт кода при использовании Си языка как основы (в gForth есть некоторая технология, но у меня, к примеру, в разных его реализациях для ускорения собирается полностью в 32/64 вариант gForth 7.3 версии, а версии 7.9 в репах не наблюдается ещё и со сборкой её под 32-бита есть заморочки)
P.S. В том же gForth можно по слову SEE <имя слова> посмотреть ассемблерный код.
Это применимо и для gForth запускаемого под Андроид.
Форт не интересен от слова совсем. И разговор тут идёт об особенностях библиотечных реализаций.
В целом это так, т.к. нет аппаратных Форт процессоров, где программирование на нём заменило бы ассемблер (сейчас только аппаратно Форт (MISC )процессоры реализуют в FPGA за редкими исключениями и используют поверх существующего железа МК/Процессоров)
P.S. Труды ИСП РАН, том 33, вып. 5, 2021 г. // Trudy ISP RAN/Proc. ISP RAS, vol. 33, issue 5, 2021
Разработка компилятора для стековой процессорной архитектуры TF16 на основе LLVM
В первой версии компилятора архитектура TF16 рассматривалась как классическая регистровая архитектура, и сгенерированный код не использовал стековые возможности.
Эта версия была относительно проста в разработке и служила точкой сравнения для второй версии компилятора.
Во второй версии компилятора был разработан и реализован платформонезависимый алгоритм планирования команд c учётом особенностей стековых архитектур.
При сравнении двух версий версия компилятора с поддержкой стековых возможностей генерирует код, который в среднем на 35.7% быстрее по времени выполнения и на 50.8% меньше по размеру, чем код, генерируемый версией компилятора без поддержки стековых возможностей. Разработанный алгоритм позволяет реализовать в компиляторе LLVM поддержку других стековых процессорных архитектур.
Я вам о тёплом, вы мне о мягком. Рад за форт (нет). Я говорю о си и gcc.
В прошлом веке я принимал участие в разработке аналога NC1016, который в России называется ТF16. На данный момент это полная ерунда. Элементарный минимальный RISC-V будет на порядок эффективнее. Я читал приведенную статью. Опять же полная ерунда. Как можно писать статью не приведя ни одного примера. Какой обьем кода получился при компиляции хотя бы Коремарка на TF16? Почему бы не написать и сравнить с ARM или RISC-V? А вот нет. Если компилировать так, то получается Х, а если этак, то уже Х/2. И вот гадай чему у них равен этот Х :)
А, где есть спецификация NC1016 и ПО под него, если сохранилось.
Тоже ПО для 4-ёх битного Форт контроллера Marc4 от Atmel было представлено только для DOS.
P.S. В переведённой книге стековые компьютеры. Новая волна от 1989г. его ещё нет. (или это NC4016, но он точно не похож на TF16, но возможно послужил отправным дизайном)
Форт процессоры J1 и DCPU c Github тоже можно тогда приравнять к NC4016.
На данный момент это полная ерунда. Элементарный минимальный RISC-V будет на порядок эффективнее
А, насколько интересно/полезно использовать 0-адресную систему команд процессора для создания надёжного и предсказуемого ПО?
RTX-2010, вероятно, в проектах NASA и ESA себя окупил в полной мере.
По материалу видно что автор больше в линуксы ходил а не в BareMetal и многие вещи ему в диковинку. Что на atmega что на stm32 и более мощных arm - elf преобразуется в бинарник, в общем то стандартными средcтвами, а весь ввод-вывод надо писать самому "на регистрах", но обычно все регистры задокумнтированы, их не надо выискивать хитрыми путями, ну и вообще это уже кто то да сделал.
Ну и главное JTAG, отладка на реальном железе без всяких эмуляторов. первый одноплатник выбирал чтобы там JTAG был обязательно.. как же я ошибался :)
настолько роботизированный перевод, что оригинал легче читается.
Пишем и отлаживаем код для ARM64 на голом железе