Board.KolibriOS.org

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

Основной недостаток - повторная компиляция. Но для ядра, написанного целиком на fasm'е, это не слишком существенно. Остальное решается хорошим структурированием исходников, основанным прежде всего на парадигме секций. Хотя не уверен, что в Колибри код также распределяется по секциям, как и данные, но это можно исправить.

Edited. А можно и оставить как есть, чтобы не плодить уж слишком громоздкие макросы для всего, что может исполняться.

Edited. Я надеюсь, что все мы здесь под "статическими адресами" применительно к Колибри понимаем часто и просто жестко закодированные в исходниках адреса (явные или смещения к примеру относительно базы ядра).

Сам на FASM не писал, могу ошибаться.

Мне кажется, что подход FASM-а похож на подход Turbo Pascal до версии 4.0. В нём ещё не было модулей (unit), а были только включаемые файлы. Зато из-за скорости компиляции временем компиляции можно было пренебречь. Объектников тоже не было, всё собиралось сразу в файл .com, ещё даже не .exe. Директивой $L можно было подключать чужие объектные файлы, а функции и процедуры описывать с модификатором external в самом Паскале.

В fasm'е ситуация еще хуже. Директивы типа includelib нет, т.е. подключить объектник с помощью стандартных средств невозможно. Нужно либо писать макросы для подключения объектника/экспорта/импорта (не самая простая задача), либо делать все на уровне исходников. В Колибри код объединяется с помощью включаемых файлов, а данные с помощью специальных макросов, позволяющих группировать их в бинарнике по назначению (типа инициализированные данные отдельно, неинициализированные отдельно). У меня наравне с данными группируется и код. Это позволяет код из отдельно взятого исходника записывать в разные участки бинарника (типа инициализационный код реального режима отдельно, инициализационный код защищенного режима отдельно, "основной" код отдельно).

FireWall wrote: Кто нибуть экспериментировал по включению кода на C (грубо говоря) в код ядра KolibriOS?

Я чуток пробовал. Сейчас деталей не помню, но, думаю, ничего сложного. Завернуть код (и данные, ибо их никто не отделяет) ядра в отдельную секцию, написать правильно скрипт линковки и линковать с сишным кодом.

Только надо сначала узнать, куда и как колибревый код в памяти маппится и страницами покрывается.

Я отказался от этой идеи (пока) так как:
(1) Это всё-таки сложно сделать "в лоб": ядро загружается загрузочным сектором единым монолитным куском, который (а) стартует в реальном режиме процессора, устанавливая видео режим VESA, затем переходит в (б) защищённый режим процессора, включает страничное отображение и отображает себя в верхнюю память и переходит (в) в свой образ в верхней памяти : последняя и большая часть грубо говоря исполняется совсем по другим адресам, нежели начальная часть.
(2) Любой код можно так скажем - на лету включить в ядро посредством загрузки драйвера, а его уже написать на C проще (если не ошибаюсь - MS COFF примерно соответствующий pe-i386 gcc mingw, - формате объектников по умолчанию). Если очень надо, то символ можно добавить в таблицу экспортируемых ядром символов драйверам.

Поправлено название формата pe-i386.

Да, нехаляльно писать вирусы на ЯВУ для ос почти полностью написанной на асме. Ебаныйстыд получится.

Phantom-84 wrote:В fasm'е ситуация еще хуже. Директивы типа includelib нет, т.е. подключить объектник с помощью стандартных средств невозможно. Нужно либо писать макросы для подключения объектника/экспорта/импорта (не самая простая задача), либо делать все на уровне исходников. В Колибри код объединяется с помощью включаемых файлов, а данные с помощью специальных макросов, позволяющих группировать их в бинарнике по назначению (типа инициализированные данные отдельно, неинициализированные отдельно).

fasm отлично умеет компилировать в объектные файлы. А GNU LD умеет делать из них бинарники. И понимает скрипты линковки, в которых можно указывать любые адреса линковки и менять их по ходу процесса. А по секциям код и данные можно раскидать как директивами в исходниках, так и в скрипте линковки можно это проделать, хоть задавая для отдельных (групп) файлов выделенные секции в нужном порядке с нужными базовыми адресами.

Вместо этого изобретать какие-то велосипеды с квадратными колёсами в виде макросов… Прям комсомольцы: создадим себе проблем и будем героически их преодолевать.

wolf.ram wrote:fasm отлично умеет компилировать в объектные файлы. А GNU LD умеет делать из них бинарники. И понимает скрипты линковки, в которых можно указывать любые адреса линковки и менять их по ходу процесса. А по секциям код и данные можно раскидать как директивами в исходниках, так и в скрипте линковки можно это проделать, хоть задавая для отдельных (групп) файлов выделенные секции в нужном порядке с нужными базовыми адресами.

Ничего нового не услышал.

Вместо этого изобретать какие-то велосипеды с квадратными колёсами в виде макросов… Прям комсомольцы: создадим себе проблем и будем героически их преодолевать.

1. Сборка из исходников - это стиль fasm'а. 2. Кто мешал писать Menuet/Kolibri на асме/си, компилировать в объектники, а потом собирать при помощи ld (и компоновочного скрипта) и др. утилит в составе трехэтажного сборочного скрипта? 3. У fasm'а есть недостатки, но достоинств больше. Я выбрал сборку из исходников, потому что для проекта на ассемблере это не столь критично (чтобы выполнить полную сборку, не нужны чаепития или прогулки по улице), а кроме того позволяет формировать бинарник ядра нужного формата без использования каких-либо доп. утилит (да и сам сборочный скрипт не сильно-то нужен). К примеру у меня бинарник ядра защищен контрольной суммой и fasm сам в состоянии произвести такой бинарник непосредственно на этапе компиляции. Не хочешь париться, исходники Линукса и чашка чая тебе в руки.

art_zh wrote:

maximYCH wrote:Кстати, какой смысл в memmap.inc, если существует const.inc, в котором возможно без описаний, но зато более актуальная карта памяти?
.

const.inc определяет только часть статических адресов ядра. И кроме них - множество других констант, не имеющих никакого отношения к адресной карте.
mmemmap.inc - это робкая попытка документирования адресного пространства. Не очень удачная, и не всегда когеррентная реальным адресам.

Sorry.
А сейчас статическое адресное пространство ядра задокументированно? (и насколько это допустимо к использованию вне ядра и получится ли?)

Kopa
mmemmap.inc уже сильно устарел и его можно лишь использовать для быстрого получения как устроена структура той или иной области, а адреса уже совсем другие, да и структура иногда уже отличается. Serge вносил много изменений и, я думаю, может лучше ответить на попутные вопросы.

Kopa
Данных по абсолютным адресам практически не осталось. Со временем всё должно перейти в data32.inc. Это даёт очень хорошую экономию к памяти ядра.

При резервировании области данных при сборке ядра (~ больше 46500 байт перед data32.inc)
собранное ядро не проходит полную загрузку.

P.S. Хотел поэкспериментировать с существующими вариантами Форт в ядре системы
но существующие сейчас решения от 70Кб и выше, а в сжатии при добавлении Форт в ядро пока не вижу смысла на данном этапе.