Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Чт апр 27, 2017 3:44 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 58 сообщений ]  На страницу Пред. 1 2 3 4
Автор Сообщение
СообщениеДобавлено: Пн сен 05, 2011 2:23 am 
Не в сети

Зарегистрирован: Ср дек 26, 2007 5:09 am
Сообщения: 214
Прямая трансляция хороша для примитивных программ вроде загрузочных секторов, но в сложных проектах от неё больше проблем, чем пользы.


Вернуться к началу
СообщениеДобавлено: Пн сен 05, 2011 2:30 am 
Не в сети

Зарегистрирован: Вс фев 18, 2007 8:34 pm
Сообщения: 158
Основной недостаток - повторная компиляция. Но для ядра, написанного целиком на fasm'е, это не слишком существенно. Остальное решается хорошим структурированием исходников, основанным прежде всего на парадигме секций. Хотя не уверен, что в Колибри код также распределяется по секциям, как и данные, но это можно исправить.

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

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


Вернуться к началу
СообщениеДобавлено: Пн сен 05, 2011 7:46 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт май 08, 2007 12:44 am
Сообщения: 340
Сам на FASM не писал, могу ошибаться.

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

_________________
Разработчик языка программирования Кантор


Вернуться к началу
СообщениеДобавлено: Пн сен 05, 2011 9:40 pm 
Не в сети

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


Вернуться к началу
СообщениеДобавлено: Пт ноя 18, 2011 4:26 pm 
Не в сети

Зарегистрирован: Ср июл 02, 2008 8:02 pm
Сообщения: 21
FireWall писал(а):
Кто нибуть экспериментировал по включению кода на C (грубо говоря) в код ядра KolibriOS?

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

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


Вернуться к началу
СообщениеДобавлено: Сб ноя 19, 2011 7:11 pm 
Не в сети

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

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


Последний раз редактировалось FireWall Пн ноя 21, 2011 6:05 pm, всего редактировалось 1 раз.

Вернуться к началу
СообщениеДобавлено: Сб ноя 19, 2011 8:10 pm 
Да, нехаляльно писать вирусы на ЯВУ для ос почти полностью написанной на асме. Ебаныйстыд получится.


Вернуться к началу
   
СообщениеДобавлено: Ср ноя 23, 2011 5:50 pm 
Не в сети

Зарегистрирован: Ср июл 02, 2008 8:02 pm
Сообщения: 21
Phantom-84 писал(а):
В fasm'е ситуация еще хуже. Директивы типа includelib нет, т.е. подключить объектник с помощью стандартных средств невозможно. Нужно либо писать макросы для подключения объектника/экспорта/импорта (не самая простая задача), либо делать все на уровне исходников. В Колибри код объединяется с помощью включаемых файлов, а данные с помощью специальных макросов, позволяющих группировать их в бинарнике по назначению (типа инициализированные данные отдельно, неинициализированные отдельно).
fasm отлично умеет компилировать в объектные файлы. А GNU LD умеет делать из них бинарники. И понимает скрипты линковки, в которых можно указывать любые адреса линковки и менять их по ходу процесса. А по секциям код и данные можно раскидать как директивами в исходниках, так и в скрипте линковки можно это проделать, хоть задавая для отдельных (групп) файлов выделенные секции в нужном порядке с нужными базовыми адресами.

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


Вернуться к началу
СообщениеДобавлено: Чт ноя 24, 2011 6:10 pm 
Не в сети

Зарегистрирован: Вс фев 18, 2007 8:34 pm
Сообщения: 158
wolf.ram писал(а):
fasm отлично умеет компилировать в объектные файлы. А GNU LD умеет делать из них бинарники. И понимает скрипты линковки, в которых можно указывать любые адреса линковки и менять их по ходу процесса. А по секциям код и данные можно раскидать как директивами в исходниках, так и в скрипте линковки можно это проделать, хоть задавая для отдельных (групп) файлов выделенные секции в нужном порядке с нужными базовыми адресами.
Ничего нового не услышал.

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


Вернуться к началу
СообщениеДобавлено: Сб окт 05, 2013 7:42 am 
Не в сети

Зарегистрирован: Пн мар 27, 2006 6:33 am
Сообщения: 522
art_zh писал(а):
maximYCH писал(а):
Кстати, какой смысл в memmap.inc, если существует const.inc, в котором возможно без описаний, но зато более актуальная карта памяти?
.

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

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


Вернуться к началу
СообщениеДобавлено: Сб окт 05, 2013 10:38 am 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Kopa
mmemmap.inc уже сильно устарел и его можно лишь использовать для быстрого получения как устроена структура той или иной области, а адреса уже совсем другие, да и структура иногда уже отличается. Serge вносил много изменений и, я думаю, может лучше ответить на попутные вопросы.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Вернуться к началу
СообщениеДобавлено: Сб окт 05, 2013 2:49 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Kopa
Данных по абсолютным адресам практически не осталось. Со временем всё должно перейти в data32.inc. Это даёт очень хорошую экономию к памяти ядра.


Вернуться к началу
СообщениеДобавлено: Пт апр 15, 2016 4:25 pm 
Не в сети

Зарегистрирован: Пн мар 27, 2006 6:33 am
Сообщения: 522
При резервировании области данных при сборке ядра (~ больше 46500 байт перед data32.inc)
собранное ядро не проходит полную загрузку.

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 58 сообщений ]  На страницу Пред. 1 2 3 4

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB