OSDev

Ну так и не вижу проблемы. Добавляем возможность кросс-компиляции, этим же фасмом компилим сам себя под новую архитектуру (думаю, с не очень значительными правками), и, как говорится, вуаля

_________________
We are back with a hard even better than before [D-Block & S-Te-Fan – Evolutionz {Ran-D remix}]

Ну почему же сразу невозможно. При желании можно. Просто в данном случае асм ИА-32 будет выступать как своего рода извращенский язык высокого уровня (как СИ по отношению к NASM'у), и можно скомпилить ФАСМ под арм. Может даже можно организовать это на макросах (каждую команду IA-32 сделать макросом, вместо которого будет подставляться аналогичный код на ARM). Да, будет дико медленно и фигово, но будет.
Другой вопрос, надо ли оно: часто под не-х86 архитектуры проще компилить на обычном ПК.

А Вы не подумали о том, что для компиляции ФАСМа под новую архитектуру его надо переписать абсолютно полностью? Т.е. фактически написать совершенно новую программу (пускай и повторяющую логику другой программы, а именно исходного ФАСМа)?

Если извращаться с макросами, то, может, что-то и получится. Только тогда каждая команда ИА-32 будет преобразована в кучу команд АРМа, поскольку трансляция "в лоб" невозможна из-за архитектурных различий. Фактически придётся даже не транслировать команды, а делать на макросах целый эмулятор ИА-32. Например, установка флагов у ИА-32 и у АРМа различается, а значит, придётся эмулировать регистр флагов ИА-32, чтобы всякие там условные переходы работали правильно. В общем, полный изврат, и не только эффективнее, но и проще переписать всё с нуля.

Зачем fasmу быть табуреткой, это просто хороший транслятор 32\64 с открытыми исходниками. Для каждой архитектуры должен быть свой хороший транслятор.

Абсолютно согласен насчёт второго. А насчёт того, хорош ли он... Ну, мне лично не нравится, посему и не использовал; но, поскольку на практике не использовал, то и ругать не стану.

Я ж пошутил про макросы и прочее.

ИМХО, FASM похож на NASM. Только макросы прокачаны очень сильно, что в некоторых случаях выручает. NASM использовал всего пару раз, так что может каких возможностей не знаю, но FASM мне понравился чуть больше.

Насчёт ассемблеров и разработки операционок... Вопрос популярный. На тему "Ассемблер и ядро Операционной Системы" http://dev64.wordpress.com/2011/12/25/os_kernel_and_assembler/ у меня появилась такая мысль:

Есть ещё один аргумент против ассемблера... Как известно, загрузкой операционной системы после включения компьютера занимается BIOS. BIOS - Basic Input Output System. А в целом, API для работы с аппаратурой, представляет из себя набор прерываний, с передачей данные через регистры, а также набор портов ввода-вывода и memory mapped областей памяти. Появилась такая система в момент разработки первых компьютеров IBM/PC еще в 80-е годы прошлого века. Архитектура IBM PC Compatible систем медленно эволюционировала. Появлялись новые системные шины и стандарты: ISA, EISA, PCI, и т.д. При этом BIOS оставался частной собственностью нескольких компаний. BIOS предоставляет интерфейсы программам только в реальном режиме, интерфейсы BIOS устарели, несли бремя совместимости и ограничены в возможностях. Такая ситуация стала тормозить развитие фантазии разработчиков аппаратных средств. При разработке платформы Itanium, Intel выступил с инициативой EFI (Extendible Firmware Interface). Идея EFI заключалась в замене BIOS новой разработкой. EFI, в отличии от BIOS больше не базируется на прерываниях. EFI больше не написан на ассемблере, и предоставляет для использования таблицы функций разного назначения написанных на Cи. Естественно процесс продвижения новой технологии долгий. Прошло несколько лет и после версии EFI 1.10 Intel передал права на дальнейшее развитие нового стандарта ново созданной инициативной группе UEFI, включающей в себя представителей Intel, IBM, Apple, Microsoft и других. Теперь эта технология получила приставку Unified, означающую, что единые переносимые firmware получат как компьютеры на базе Intel PC, так и планшетники на базе ARM. UEFI, по сравнению с BIOS несомненно прогрессивен. Он предоставляет графические драйвера, сетевые драйвера и т.д. Компьютер без операционной системы будет способен осуществлять в том числе сетевые подключения... Однако есть у этого всего и минусы. Одной из технологий, поддерживаемой UEFI является Safe boot. Запрет загрузки не подписанного софта. Это означает, что возможно создание железа, на котором будет загружаться лишь одна разрешенная (подписанная) операционная система.

Самым недавним ударом по BIOS стало требование Microsoft во всех системах, сертифицированных для работы с Windows 8 наличие UEFI safe boot.

Что из вышесказанного следует? Из вышесказанного следует, что платформе Intel PC в том её виде, в котором она существует сегодня, жить осталось недолго. Выход Windows 8 не за горами. Второй вывод - ассемблер перестает быть инструментом, даже при написании операционных систем. С появлением новых интерфейсов, необходимость в ассемблере, судя по всему уменьшится. Третий вывод - загрузка операционной системы, да и архитектура драйверов в ближайшее время может пережить весьма революционные изменения. Поэтому все текущие эксперименты с MBR и Boot Sector-ами переходят в разряд экспериментов с Legacy кодом.

P.S. Для меня критерий выбора компилятора - поддержка нужных форматов объектных файлов.

Что касается вопроса написания всей ОС на ассемблере, то я тоже придерживаюсь мнения, что это способ, мягко говоря неэффективный: не перенести на другую платформу; трудность отладки, точнее, даже не отладки, а, как бы тут выразиться, больше риск допустить ошибку в коде, а потом ее часами искать; кроме того, современные компиляторы зачастую генерируют код эффективнее, чем если писалось бы с нуля на ассемблере.

Писать на ассемблере только для того, чтобы экстремально минимизировать размер ОС? Типа, "Эта ОС умещается на дискете!", "На чем, на чем?" - спросит современный школьник .
Кому это сейчас надо?

Все что я писал выше относится к ПК, но я думаю, во встраиваемых системах тоже самое - не очень разбираюсь в них. В конце-концов в роутерах, например, тот же Linux, а он не на ассемблере написан.

Другой вопрос, что при написании ОС без знания ассемблера никуда - это факт, тут и низкоуровневые модули, и та же отладка.
Автор топика как раз хочет именно изучить ассемблер, а не писать на нем ОС, насколько я понял.

Не знаю, с чего такое мнение. По моему личному опыту переписывание фрагментов кода с нуля на ассемблере даёт выигрыш как в размере, так и в быстродействии в несколько раз, вплоть до десятка. Сравнивал с GCC и с MS VS.


Экстремальная минимизация размера - своего рода спорт. Надо сказать, иногда это занятие вполне осмысленно. Например, может оказаться необходимо вместить разбор файловой системы в один-два сектора начального загрузчика и здесь на счету каждый байт.
Но на самом деле большинство упускает из виду то обстоятельство (на этом форуме уже обсуждали этот вопрос), что, как правило (за исключением специальных случаев, типа разворачивания циклов), оптимизируется одновременно и размер, и быстродействие. Так, две цепочки одинаковой функциональности, не содержащие циклов, но имеющие разную длину, в среднем (грубо) будут выполняться за время, пропорциональное их длине.
Есть ещё один момент, напрямую ставящий в зависимость быстродействие от размера. Представь себе, что CPU имеет кэш, например, 1Мб. И есть две ОС одинаковой функциональности. Одна целиком вместе с данными занимает 1Мб, другая 10Мб. Вопрос: какая из них с большей вероятностью будет работать быстрей?
А если у нас 1Гб ОЗУ в системе и две ОС, - одна расходует 512Мб, а другая 2Гб?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>