Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Apr 25, 2019 9:09 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 58 posts ]  Go to page Previous 1 2 3 4
Author Message
PostPosted: Mon Sep 05, 2011 2:23 am 
Offline

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


Top
   
PostPosted: Mon Sep 05, 2011 2:30 am 
Offline

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

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

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


Top
   
PostPosted: Mon Sep 05, 2011 7:46 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 346
Сам на FASM не писал, могу ошибаться.

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

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


Top
   
PostPosted: Mon Sep 05, 2011 9:40 pm 
Offline

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


Top
   
PostPosted: Fri Nov 18, 2011 4:26 pm 
Offline

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

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

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


Top
   
PostPosted: Sat Nov 19, 2011 7:11 pm 
Offline

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

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


Last edited by FireWall on Mon Nov 21, 2011 6:05 pm, edited 1 time in total.

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


Top
   
PostPosted: Wed Nov 23, 2011 5:50 pm 
Offline

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

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


Top
   
PostPosted: Thu Nov 24, 2011 6:10 pm 
Offline

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

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


Top
   
PostPosted: Sat Oct 05, 2013 7:42 am 
Offline

Joined: Mon Mar 27, 2006 6:33 am
Posts: 650
art_zh wrote:
maximYCH wrote:
Кстати, какой смысл в memmap.inc, если существует const.inc, в котором возможно без описаний, но зато более актуальная карта памяти?
.

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

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


Top
   
PostPosted: Sat Oct 05, 2013 10:38 am 
Offline
Kernel Developer

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

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


Top
   
PostPosted: Sat Oct 05, 2013 2:49 pm 
Offline
Kernel Developer

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


Top
   
PostPosted: Fri Apr 15, 2016 4:25 pm 
Offline

Joined: Mon Mar 27, 2006 6:33 am
Posts: 650
При резервировании области данных при сборке ядра (~ больше 46500 байт перед data32.inc)
собранное ядро не проходит полную загрузку.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 58 posts ]  Go to page Previous 1 2 3 4

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited