Взялся я писать статью... SDCC как всегда:)

[SfS]

Итак, взялся я писать статью, забыв про новый год. И меня понесло. 12 страниц про динамическое связывание и подгружаемые модули на SDCC (SDCC-NOINIT). С примерами.

С одной стороны мне горетно, что в новогодние издания она не войдет. С другой - радостно, что всё ж написал.

Так что выкладываю её на обзор. Опечаток там наверное много и других оговорок. Но что получилось, то получилось. Вдруг кому интересно.

Специально извиняюсь перед WBR, что на новый год не получилось сделать то, что нужно - к лету ещё что-нибудь напишу для зарулем. Если доживу

----------------------------------------------------------------------------------------------------
Итак статья https://github.com/salextpuru/sdcc-n.../sdcc-art2.pdf
----------------------------------------------------------------------------------------------------

Примеры там же:
https://github.com/salextpuru/sdcc-n...r/apps/test-so
https://github.com/salextpuru/sdcc-n...bsrc/libtestso
https://github.com/salextpuru/sdcc-n...r/libsrc/libso

Другая дока по SDCC-NOINIT:
https://github.com/salextpuru/sdcc-n...ree/master/doc
https://github.com/salextpuru/sdcc-noinit

[Advertiser]

[JV-Soft]

SfS, теперь ядро надо и графический интерфейс

[SfS]

SfS, теперь ядро надо и графический интерфейс

Пока бы менеджер памяти осилить. Там проблема - как данные между страничками передавать при вызове...

- - - Добавлено - - -

Да и в одного както грустно творить чтото большое.

[Shiny]

[Oleg N. Cher]

SfS, красава! Направление взял чёткое, без базара.
Придерусь к частности. ИМХО зря использовал HL вот здесь:


Лучше взять BC или DE. Чтобы иметь возможность использовать в функциях модель вызова __z88dk_fastcall с передачей аргумента в паре HL.

[Barmaley_m]

Отличный проект и красивая реализация! Спасибо! Очень пригодится как компонент будущей ОСи.

Отдельно порадовала чистота русского языка в статье и отсутствие заимствованных без необходимости слов, что в последнее время было распространенным и раздражающим явлением в русской компьютерной прессе.

Также присоединяюсь к мнению Oleg N. Cher:

Придерусь к частности. ИМХО зря использовал HL вот здесь:
...
Лучше взять BC или DE.

А по-моему лучше вообще не использовать никаких регистров. Кроме программистов на Си встречаются ещё программисты на ассемблере, которые передают параметры в регистрах. Например, "резидентная интерфейсная часть" (в английском используется термин "Import Library") может состоять из команд JP 0, JP 3, JP 6 и т.д., которые изменяются в ходе настройки основной программы на фактический адрес загрузки модулей.

Также стоит иметь в виду, что динамическая библиотека может не только экспортировать, но и импортировать функции из других динамических библиотек. Например, загрузчик исполняемых модулей будет обращаться к драйверу файловой системы.

- - - Добавлено - - -

Там проблема - как данные между страничками передавать при вызове...

Я тоже думал над этой проблемой. Пришел к следующим идеям:

1) Исполняемые файлы и динамические библиотеки состоят из сегментов. Paged Code/data - код или данные, которые можно размещать в страницах (C000-FFFF); Nonpaged Code/data - то, что необходимо размещать вне страниц, в резидентной памяти. Сегменты реализованы в современных исполняемых форматах (Windows EXE, ELF). Упомянутый подход реализован для драйверов Винды, где часть кода или данных загрузчик размещает в "дорогой" резидентной памяти (Nonpaged Pool), а остальные - в той памяти, которая может свопиться.

2) Системный менеджер памяти принимает параметр - какая требуется память: резидентная (которой мало), страничная в текущей странице (которой тоже мало, но предпочтительно использовать её) или же страничная в любой странице (которой много, но доступ неудобный).

3) Программист должен стремиться свести к минимуму перемещения данных между страницами и использование Nonpaged Memory. Вызовы функций можно разделить на "близкие" (когда вызываемый код находится в резидентной памяти или той же странице); и "далёкие" - посредством системной функции, переключающей страницу перед вызовом и после возврата.

4) Для крайних случаев сделать системные функции вроде "Far memory Read" и "Far memory Write", которые перемещают данные из "чужой" или "в чужую" страницы.

5) Резидентный код может вызывать системные фукнции переключения страниц и иметь непосредственный доступ к памяти из любых страниц.

Да и в одного както грустно творить чтото большое.

Ну дык, аналогично. Давай скооперируемся. Я уже выкладывал прототип диспетчера многозадачности. С тех пор пришло много идей его улучшения, грустно только было за это браться ввиду отсутствия единомышленников! Также я недавно выложил свой оконный интерфейс, драйверы клавиатур, диска. Этот код старый, но тоже может быть тщательно переработан и выведен на современные стандарты качества. За последнюю неделю занимался функциями быстрого вывода текста. Выложить только не успел еще.

[SfS]

А по-моему лучше вообще не использовать никаких регистров. Кроме программистов на Си встречаются ещё программисты на ассемблере, которые передают параметры в регистрах. Например, "резидентная интерфейсная часть" (в английском используется термин "Import Library") может состоять из команд JP 0, JP 3, JP 6 и т.д., которые изменяются в ходе настройки основной программы на фактический адрес загрузки модулей.

Отвечу сразу обоим.

Не может резидентная часть "состоять из команд JP 0, JP 3, JP 6 и т.д., которые изменяются в ходе настройки основной программы" и вот почему. Я там кратко упомянул (потом дополню), что задача резидентной части не просто переход, но и обращение к менеджеру памяти для впечатывания нужной странички, той, в которой лежит данная библиотека. Поэтому, там придётся много чего использовать. И fastcall не выйдет. Опять же ограничение - стек должен быть в НЕПЕРЕКЛЮЧАЕМОЙ странице на момент обращения к библиотеке.

Там ещё не дописана часть про "мягкое связывание". Если кто внимательно читал, то заметит, что "мягкое связывание" не включает в себя пока что механизма автоматического переключения страниц. Поэтому я его хочу усложнить немного, но обеспечить так же возможность прозрачного вызова функций.

Тут выбор простой - или "все предельно быстро" или "всё стандартно и по возможности быстро".

Если заставлять программиста самого щелкать страничками все время, то смысл механизма подгружаемых модулей теряется как таковой.

- - - Добавлено - - -

Кроме программистов на Си встречаются ещё программисты на ассемблере, которые передают параметры в регистрах

Да пусть сколько угодно передают. Кто ж им мешает. Например, в альтернативном наборе, если хотят. Я могу пообещать его не использовать в менеджере памяти и своих процедурах поддержки подгружаемых модулей.

Если немного философии-болтологии, то так. Как бы нам ни хотелось - любой ЯВУ это прежде всего стандарт. А стандарт - это рамки и ограничения. Зато и возможности быстро соединять разные модули воедино. Собственно, отсутствие стандартов на порты, системные вызовы и прочее и убило в своё время спектрум. Точнее убило возможности логичного расширения его аппаратной и программной архитектуры.

Поэтому для "программистов на ассемблере" - остаётся ассемблер. Пусть хоть jump через stack себе там засовывают по ret на call. Но если они хотят, чтобы их модуль использовали другие, то им не сложно будет сделать интерфейсную часть, совместимую со стандартом - например забрать параметры со стека или отдать их в нужном регистре.

- - - Добавлено - - -

Ну дык, аналогично. Давай скооперируемся. Я уже выкладывал прототип диспетчера многозадачности. С тех пор пришло много идей его улучшения, грустно только было за это браться ввиду отсутствия единомышленников!

Я не против кооперации. Но есть проблема - мой абсолютно непредсказуемый и невменяемый график. Я вот несколько месяцев вообще ни за что не брался. Загруз был полный. Появилось время - за недельку по вечерам накидал описалово и доработал модульность. Кстати, описалово я больше для себя делаю. Пока код пишешь вроде все логично. А как возмешься его объяснять - другим и себе - сразу начинают косяки всплывать, которые не заметил.

Я к тому, что мне сложно обещать что-то сделать в срок. Сегодня время есть - завтра трах-бах и я полетел на другой конец нашей необъятной Родины по наитию начальства. Или привалило работы, что до 22.00 сидишь и в 23.00 домой приходишь.

- - - Добавлено - - -
Для Shiny

О каком "тулчейне венды" речь? Если о SDCC-NOINIT - то https://www.cygwin.com/ должен пойти.

[Shiny]

Для Shiny

О каком "тулчейне венды" речь? Если о SDCC-NOINIT - то https://www.cygwin.com/ должен пойти.

кхм. а можно привести пример компиляции сырка для чайников и сковородок?

[Barmaley_m]

Не может резидентная часть "состоять из команд JP 0, JP 3, JP 6 и т.д., которые изменяются в ходе настройки основной программы" и вот почему. Я там кратко упомянул (потом дополню), что задача резидентной части не просто переход, но и обращение к менеджеру памяти для впечатывания нужной странички, той, в которой лежит данная библиотека. Поэтому, там придётся много чего использовать. И fastcall не выйдет.

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

Я могу пообещать его не использовать в менеджере памяти и своих процедурах поддержки подгружаемых модулей.

Я думаю, достаточно гарантировать неиспользование каких-то регистров только при вызове функций из динамической библиотеки. Во всех остальных случаях твоей системы модулей это не критично.

С остальным сказанным согласен.

Я не против кооперации. Но есть проблема - мой абсолютно непредсказуемый и невменяемый график.

Ну и славно. А с графиком у меня не лучше. Так что просто посмотрим по обстоятельствам, как сложится.

- - - Добавлено - - -

В общем как сделать прозрачный и удобный вызов функций при мягком связывании, если есть много страничек памяти - голову ломаю...

У тебя же есть точка входа _hl_jumper. Вот и возвращать её адрес и требуемое значение hl из твоего аналога функции GetProcAddress.

Ну или добавить к резидентной части каждого модуля функцию "CallProcModule", которая будет принимать один параметр и прыгать на _hl_jumper. Значение же этого параметра будет возвращать GetProcAddress.

[SfS]

У тебя же есть точка входа _hl_jumper. Вот и возвращать её адрес и требуемое значение hl из твоего аналога функции GetProcAddress.

Ну или добавить к резидентной части каждого модуля функцию "CallProcModule", которая будет принимать один параметр и прыгать на _hl_jumper. Значение же этого параметра будет возвращать GetProcAddress.

Она есть только если есть есть резидентная часть. Если я просто загрузил модуль и нашёл в нем функцию по имени, то ни точки _hl_jumper нет.
Наверное придётся в библиотеку libso какойто универсальный кусочек пихать для вызова функций. Я подумаю, в общем.