Библиотеки-модули-программы...

Вид для печати

Показывать 40 сообщений этой темы на одной странице

13.10.2006, 00:12
captain cobalt

Цитата:

Сообщение от captain cobalt

1. Импорт по номеру (ординалу) функции.
2. Использование dynamic binding вместо dynamic linking.

Ещё уточнения:

Смещения (в таблице адресов) вкомпилируются в бинарник и вообще недоступны загрузчику.

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

Цитата:

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

Это поддерживаю на 100%
______________________

А вот ещё одна идея. :)

Заархивировать программы в непрерывный RAR архив.
Непрерывная архивация сожмёт одинаковый код в разных программах.
И степень сжатия приличная.
Осталось только на основе ZX-UnRAR сделать запускалку, которая будет распаковывать нужную программу в память и передавать ей управление. :)
13.10.2006, 00:19
captain cobalt

Цитата:

Сообщение от yoko_ono

Каждый 'exe' - после загрузки в память представляет из себя некоторое кол-во секций, с кодами, с данными и т.д. Если в секции есть абсолютные адреса со ссылками на к.-л. секцию - то в самом файле ставится относительное смещение от начала этой секции, а в таблице релокации для данной секции - смещение до адреса, который надо подкорректировать и номер секции, в которую он должен указывать. Плюс вариации с 16-32 битными смещениями. Вот и всё.

Как называется корректировка секций по таблицам релокаций? :)
13.10.2006, 00:46
Vitamin

Цитата:

Сообщение от yoko_ono

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

Ну да. Сам такое делал. У меня только гибкость немного больше- есть возможность ссылаться на функции в других модулях и делать загрузку неполного адреса (старшего либо младшего байта)

Цитата:

Сообщение от captain cobalt

Заархивировать программы в непрерывный RAR архив.
Непрерывная архивация сожмёт одинаковый код в разных программах.

Про это я говорил уже, можно даже не сжимать, а просто в один файл сложить все либы дабы не шариться по диску при сборке.

Цитата:

Сообщение от captain cobalt

Это поддерживаю на 100%

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

Итак, задача- рассмотреть варианты строения релоцируемых моделей на разных платформах и синтезировать некий гибрид, как можно более подходящий для использования на спеке.
13.10.2006, 11:08
elf/2

Цитата:

Сообщение от yoko_ono

И такой ужас ДЛЯ КАЖДОЙ функции?..

конечно нет:
1. открываем библиотеку
2. получаем указатель на fn1
3. получаем указатель на fn2
...

n. пользуем функции
n+1. закрываем библиотеку

Цитата:

Сообщение от yoko_ono

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

дело не в "убогости" архитектуры, а в том что подобный метод доступа к библиотекам используется очень редко. обычно библиотека линкуется динамически и система занимается "получением указателей". с точки зрения программиста в этом случае ничего открывать не надо, адреса тоже ресолвить не надо. он просто зовет нужную функу и все. вот это действительно оптимально :)
13.10.2006, 11:22
elf/2

вообще еще раз мое imho. динамическая компоновка (т.е. dll/so/exec.library) на текущем этапе на спекке на нужна, потому что:
1. оси нет, значить компоновщик придется добавлять СТАТИЧЕСКИ в каждую программу
2. даже если мы используем только одну функу из библиотеки в памяти будет висеть вся либа
!!! а памяти у нас не густо :(
3. поскольку библиотеки фактически ищутся по имени файла, загрузка всего приложения будет идти очень долго (придется каждый раз мотаться в каталог и обратно). если каталог кешировать для ускорения, то опять упираемся в память...
4. как правильно подметил psndcj реально нужны 2-3 библиотеки, стоит ли из-за этого огород городить?
5. у нас нет многозадачности, соответсвенно использования одной библиотеки несколькими приложениями не будет, следовательно экономии памяти от использования одного кода несколько раз тоже не будет

оригинальное предложение Витамина т.е. сборка из объектников (на мой взгляд опять же) имеет больше перспектив
13.10.2006, 11:54
ng_dead

Цитата:

Сообщение от elf/2

мое imho

+1
13.10.2006, 18:07
acidrain

Цитата:

Сообщение от Vitamin

Если имена либ неизвестны на этапе компиляции, то открываем необходимое число библиотек, достаем из них указатели на функции и вызываем по этим указателям нужное число раз. Если имена известны, то этими всеми операциями (открытие-получение адреса-закрытие) обычно заведует ОС

Что значит имена не известны? А как кодер их должен юзать, если он не знает их имена? По функциям запрос делать, что ли?

Цитата:

По сути, я предлагаю именно такую систему, но с некоторыми принципиальными отличиями:
-приложение ничего само не подключает, все делает загрузчик
-расположение библиотек не фиксированно, а выбирается сообразно обстоятельствам (в простейшем случае, одна за одной в памяти)

Ну, я тебе вчера о том же намылил - загрузчик открывает и закрывает либлы.

Цитата:

Для загрузки библиотеки по требованию необходим некий менеджер этих библиотек, а также менеджер памяти для распределения ресурса. Поскольку у нас нет ОС, то ясно, что эти менеджеры программа вынуждена таскать с собой. Все библиотеки подключаются один раз и ни разу не отключаются (в таком случае менеджер получается "одноразовый") Если это не так, то получаем плагинную систему (то, о чем я и говорил).

Не путайся и не путай народ - цитата: то получаем плагинную систему
опять ты пишешь менеджеры с собой (один менеджер загрузчик для всех! типа boot). Никаких плагинов (можно, но не к теме) - тут именно набор стандартных ф-ций, которые юзают любые проги (одназадачная оська;) с выходом в ось 8) а не в васик/тырдос.

Цитата:

Сообщение от yoko_ono

Cовершенно примитивное. Каждый 'exe' - после загрузки в память представляет из себя некоторое кол-во секций, с кодами, с данными и т.д. Если в секции есть абсолютные адреса со ссылками на к.-л. секцию - то в самом файле ставится относительное смещение от начала этой секции, а в таблице релокации для данной секции - смещение до адреса, который надо подкорректировать и номер секции, в которую он должен указывать. Плюс вариации с 16-32 битными смещениями. Вот и всё.

Все верно! Я поражен Вами, жаль женат и две дочки, а тоб ;)))
но Витамин спрашивал о libman либах а не об амиге!
2Витамин:Предполагаю, что все в либмане с релокацией просто, как то изучал исходники на Срр (они там в архивах, есть даже .ехе для авто реклокации или что то типа того - не помню 4 года прошло)
И еще, все вопросы по либману - к автору: Shaos, пиши на мыло, в его форум, аську - не спрашивай меня об этом, ок?
И не выдумывай, повторюсь, велосипед - либман - готовый, проработанный формат и легко автором портируется на спек - пользуйся тем, что уже готово! А так, если жаждишь славы - то дерзай.
Могу выслать мою первую либлу (если найду - на листочках хранил), которую я писал для спека и системы, как я описал выше. Тама мышко-драйвер типа :)
13.10.2006, 18:11
acidrain

Цитата:

Сообщение от captain cobalt

Даже на Мотороле, где косвеный вызов по таблице адресов делается одной командой, необходим регистр (весьма ценный ресурс)

Можешь регистром пользоваться, как заблагорасудится! =) Никто не запрещает его юзать - он не постоянно нужен, только при обращении к либле. Остальное время можешь про него забыть и юзать постоянно, до следующегно вызова. Система такова, что берешь хендл либлы в регистр, а по возвращению - он опять твой. Как и любой другой регистр, необходимый для передачи данных в либлу.
Надеюсь понятно изъяснил. Такчто не ресурсоемкий метод!
13.10.2006, 18:25
acidrain

Цитата:

Сообщение от elf/2

конечно нет:
1. открываем библиотеку
2. получаем указатель на fn1
3. получаем указатель на fn2
...

n. пользуем функции
n+1. закрываем библиотеку

А, простите меня, грешного, на амиге - не надо получать указатели на ф-ции! вот в чем финт.

Цитата:

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

Ну лично для меня (!) такой распространенный метод как динамически линкуемая либла - лезть зубочисткой через зад! Зачем оське знать, где какая ф-ция (тем более у стороннего производителя либл)? Ей надо другими вещами заниматься, например реалтаймом ;)
13.10.2006, 18:30
acidrain

Цитата:

Сообщение от elf/2

4. как правильно подметил psndcj реально нужны 2-3 библиотеки, стоит ли из-за этого огород городить?

Стоит - это начало из начал ... для оси :)
13.10.2006, 19:16
elf/2

Цитата:

Сообщение от acidrain

А, простите меня, грешного, на амиге - не надо получать указатели на ф-ции! вот в чем финт.

зато прямой вызов по известному адресу быстрее :)

Цитата:

Сообщение от acidrain

Ну лично для меня (!) такой распространенный метод как динамически линкуемая либла - лезть зубочисткой через зад! Зачем оське знать, где какая ф-ция (тем более у стороннего производителя либл)? Ей надо другими вещами заниматься, например реалтаймом

ось должна облегчать жизнь пользователя в первую очередь и программиста во вторую. что винда/линукс и делают. в результате уменьшается размер кода и число ошибок (нельзя забыть проинициализировать либу, ошибки линковки обрабатываются системой, нет никакой разницы для программиста между статической/динамической линковкой)
а механизм там простой до безобразия: у либы есть список экспортируемых функций а у проги - список jump'ов на импортируемые. при загрузке винда список jmp'ов корректирует
13.10.2006, 19:19
icebear

Цитата:

Сообщение от acidrain

Что значит имена не известны? А как кодер их должен юзать, если он не знает их имена? По функциям запрос делать, что ли?

Почитай про COM, там по дефолту вообще только три функции декларированы. Вот где башка кипеть начнёт.
13.10.2006, 19:32
elf/2

Цитата:

Сообщение от acidrain

Что значит имена не известны? А как кодер их должен юзать, если он не знает их имена? По функциям запрос делать, что ли?

очень просто. есть API - некий набор функций. некие библиотеки этот API поддерживают

при загрузке приложения ищем файлы по маске (например 'plugins/*.dll'). каждый файл по очереди грузим через LoadLibrary, и получаем из каждой библиотеки нужные функции.
если файло загрузилось и нужные функции нашлись то спокойно используем (кстати в ruby для этого (ну почти для этого :) даже спецтермин придумали - duck typing)
13.10.2006, 19:50
Vitamin

Цитата:

Сообщение от acidrain

Не путайся и не путай народ - цитата: то получаем плагинную систему
опять ты пишешь менеджеры с собой (один менеджер загрузчик для всех! типа boot). Никаких плагинов (можно, но не к теме) - тут именно набор стандартных ф-ций, которые юзают любые проги (одназадачная оська с выходом в ось 8) а не в васик/тырдос.

Ща поясню. Плагинная система- сиречь ОС и приложения (только в другом масштабе). Одна большая хост-программа с навороченным менеджером и простенькие плагины. А если у нас нет хост-программы/ОСи, то лепить навороченный менеджер (заметь, в КАЖДУЮ программу) нет абсолютно никакого смысла.

Цитата:

Сообщение от acidrain

И не выдумывай, повторюсь, велосипед - либман - готовый, проработанный формат и легко автором портируется на спек - пользуйся тем, что уже готово! А так, если жаждишь славы - то дерзай.

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

2Shaos: можно получить документацию по формату библиотек, возможностям и т.п. Потому как функциональности может быть недостаточно и придется "изобретать велосипед"...
13.10.2006, 19:58
acidrain

Цитата:

Сообщение от Vitamin

(заметь, в КАЖДУЮ программу)

Нет же, не в каждую!!!
13.10.2006, 20:46
yoko_ono

Цитата:

Сообщение от Vitamin

Смотрим внимательнее на тот исходник. Вызов функции (многократный) там занимает одну строчку. Все остальное- подготовка библиотеки и ее освобождение. Это однократно выполняемая последовательность.

Для КАЖДОЙ функции!

Цитата:

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

Ну вот, вы сами и написали, что в любом случае дело сводится к выковыриванию абсолютных адресов КАЖДОЙ функции, либо руками, либо стартап-кодом!
13.10.2006, 20:51
yoko_ono

Цитата:

Сообщение от elf/2

конечно нет:
1. открываем библиотеку
2. получаем указатель на fn1
3. получаем указатель на fn2
...

n. пользуем функции
n+1. закрываем библиотеку

Получаем указатель для КАЖДОЙ используемой функции, как же 'конечно нет'?

Цитата:

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

Оптимально ли? С каждым ехешником путешествуют лишние ссылки релокации, а если какой-нибудь, даже мелкой, либы нету - то ехешник осью в принципе не загрузится. Хотя программист мог бы решить по ходу дела, что если либы нету, то и каких-то функций нет.
13.10.2006, 21:02
yoko_ono

Цитата:

Сообщение от elf/2

2. даже если мы используем только одну функу из библиотеки в памяти будет висеть вся либа

Именно! В то время как компиляция либ из исходника позволяет компилировать только РЕАЛЬНО требуемые функции, а ведь именно от сборки либ из исходников Vitamin и хочет уйти!

Цитата:

оригинальное предложение Витамина т.е. сборка из объектников (на мой взгляд опять же) имеет больше перспектив

Ну на мой скромный взгляд, оригинальности тут на грош - идея 'цельнотянутая' с пц-винды-линуха.

Прежде всего его идея подразумевает релоцируемость. Коя реалтизуется на этапе компиляции в любом ассемблере или генераторе кода и поддерживается осью на пц/амиге/и т.д. На Спектруме же - ни того, ни другого. Существующие ассемблеры все как один не поддерживают релоцируемость (хитрости с макросами не в счёт). Да и вообще, парадигма программирования на Спектруме чужда релоцируемости - если, конечно же, не писать все программы в 'академическом' стиле программирования Z80.

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

Юзер-прога грузит либу в статически определённое место в памяти. Та сама себя релоцирует каким-либо методом (пусть автор либы поупражняется, раз уж ему нечего делать, кроме как либы писать). И например в начале указанного user-программой места строит таблицу вызовов своих функций, состоящей из JP func1:JP func2:JP func3 и т.д. После чего user-программа, зная начало этой таблицы (раз уж она его и указала), делает туда CALL'ы. Можно отделить собственно тело библиотеки от таблицы вызовов. Можно тело библиотеки класть в страницу, перед вызовом включая её (нету оси - нету менеджера страниц, доступного библиотеке).
14.10.2006, 05:40
Shaos

Цитата:

Сообщение от Vitamin

2Shaos: можно получить документацию по формату библиотек, возможностям и т.п. Потому как функциональности может быть недостаточно и придется "изобретать велосипед"...

Дык вот же всё: http://www.nedopc.org/nedopc/shaos/libman_r.shtml

Поясню в двух словах - либы релоцируемы с шагом 256 байт (таблица релокации занимает 1/8 размера кода) во время загрузки. Либы при открывании накидываются друг за другом в страницу 16К пока не займут её полностью, потом ново-открываемые либы накидываются в другую страницу 16К и т.д. Страницы подключаются в нужные окна в момент вызова функций из соответствующей либы. Возможность задавать окно где либа будет вызываться нужна не только ради удобства программиста, но и например ради вызывания либы из другой либы (для этого они должны сидеть в разных окнах).
14.10.2006, 13:11
Vitamin

Цитата:

Сообщение от yoko_ono

Получаем указатель для КАЖДОЙ используемой функции, как же 'конечно нет'?

Ржунимагу. А на амиге по индексу функции случайно не указатель на нее ищется (косвенный) для последующего перехода? Потому как, если нет указателя на функцию или ее адреса (разные вещи), то функцию вызвать невозможно!

Цитата:

Сообщение от yoko_ono

Именно! В то время как компиляция либ из исходника позволяет компилировать только РЕАЛЬНО требуемые функции, а ведь именно от сборки либ из исходников Vitamin и хочет уйти!

Мадам! А вы про оптимизацию слышали? Когда из объектого кода (библиотек то есть) удаляются неиспользуемые функции? Конечно, данная операция применима только при сборке готовой программы, а не runtime-сборке, но тем не менее :lol
Да, кстати, как на этапе компиляции определить нужность-ненужность функций с учетом "парадигмы программирования на спектруме" и без "извратов с макросами"? Я, если честно, даже с извратами не смогу однозначно это определить.

Цитата:

Сообщение от yoko_ono

Ну на мой скромный взгляд, оригинальности тут на грош - идея 'цельнотянутая' с пц-винды-линуха.

А глаза разуть и посмотреть, что идея динамической линковки одинакова и на амиге и на линухе и на винде (что неоднократно показывалось в этой ветке)? Разница только в технических тонкостях организации вызова.
ЗЫ. Если б идея была "цельнотянута" с амиги, тут бы наверное кипятком пИсали....

Цитата:

Сообщение от yoko_ono

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

И почему же не в счет? И что мешает написать новый компилятор?

Цитата:

Сообщение от yoko_ono

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

user-программа свободно может быть и нерелоцируемой, ей это не нужно. Читаем внимательнее.

Shaos: выравнивание это хорошо. Но не всегда. Я у себя это опционально делаю. Еще вопросы
-из либы экспортируются только функции или могут экспортироваться данные?
-возможно ли при компиляции либы задать ссылки на внешние, неизвестные на этапе компиляции точки?
-если да, то как это описывается форматом
-каким образом компилируется релоцируемая либа? (особый компилятор, еще какие "извраты" :)))
14.10.2006, 15:06
acidrain

Цитата:

Сообщение от Vitamin

Потому как, если нет указателя на функцию или ее адреса (разные вещи), то функцию вызвать невозможно!

Нет, ты упорно не хочешь слышать, что тебе говорят! Нету никаких указателей на функции! Есть только хендл либлы и все! Ведь прежде чем вызвать ф-цию ты ведь должен знать, что она делает? Значит ты знаешь, в какой либле ее искать? То тогда ЗАЧЕМ тебе адрес или указатель на ф-цию?
14.10.2006, 15:11
acidrain

Цитата:

Сообщение от Vitamin

И что мешает написать новый компилятор?

Исторически слложившиеся пристрастия и нежелание все конвертировать из своего любимого асма в твой новый. Это еще один тормозящий фактор быстрого развития твоей идеи.
14.10.2006, 15:41
Shaos

Цитата:

Сообщение от Vitamin

Shaos: выравнивание это хорошо. Но не всегда. Я у себя это опционально делаю. Еще вопросы
-из либы экспортируются только функции или могут экспортироваться данные?
-возможно ли при компиляции либы задать ссылки на внешние, неизвестные на этапе компиляции точки?
-если да, то как это описывается форматом
-каким образом компилируется релоцируемая либа? (особый компилятор, еще какие "извраты" :)))

Только функции - доступ к данным через функции. Каждый экземпляр библиотеки будет иметь свои данные и свой код. Никаких внешних точек. Релоцируемая либа компилируется так - компилим с адреса #0000, потом компилим с адреса #0100 и побайтно сравниваем что получилось - если соответствующие байты в двух результатах компиляции отличаются, то пишем в соответствующий бит 1, иначе 0. Подобный фокус с релокацией прокатывает только если адреса указываются прымым текстом и не вычисляются хитрыми формулами. И соответсвенно не может быть никакой самомодификации кода либы с исправлениями адресов переходов.
14.10.2006, 18:27
elf/2

Цитата:

Сообщение от yoko_ono

Оптимально ли? С каждым ехешником путешествуют лишние ссылки релокации, а если какой-нибудь, даже мелкой, либы нету - то ехешник осью в принципе не загрузится. Хотя программист мог бы решить по ходу дела, что если либы нету, то и каких-то функций нет.

по крайней мере более гибкий :) если либа обязательная, то пусть система сама все делает, если не обязательная - то пользуемся загрузкой через LoadLibrary

а если очень надо то можно почти что ваш подход использовать: библиотека экспортирует всего одну функцию, дальше зовем ее передавая индекс нужной "невидимой" функции

Цитата:

Сообщение от yoko_ono

Получаем указатель для КАЖДОЙ используемой функции, как же 'конечно нет'?

видимо я не совсем понял Ваш исходный комментарий, мне показалось что Вы интересовались необходимостью всей конструкции (load, получить адрес, высвать, close). действительно необходимо получить адрес каждой используемой функции. или воспользоваться выше описанным подходом (используется например в Mirande)

Цитата:

Сообщение от yoko_ono

Ну на мой скромный взгляд, оригинальности тут на грош

имел в виду: оригинальный = предложенный в первом посте темы

Цитата:

Сообщение от acidrain

Нет, ты упорно не хочешь слышать, что тебе говорят! Нету никаких указателей на функции! Есть только хендл либлы и все! Ведь прежде чем вызвать ф-цию ты ведь должен знать, что она делает? Значит ты знаешь, в какой либле ее искать? То тогда ЗАЧЕМ тебе адрес или указатель на ф-цию?

ну что вы опять? вы оба правы:
1. не зная адреса - нельзя вызвать функцию напрямую
2. на амми ее напрямую никто и не зовет
14.10.2006, 18:58
captain cobalt

Цитата:

Сообщение от Vitamin

Про это я говорил уже, можно даже не сжимать, а просто в один файл сложить все либы дабы не шариться по диску при сборке.

Взять статически скомпонованные программы.
В каждой программе может быть свой экземпляр библиотеки.

Сжать эти программы.
Непрерывное сжатие сожмёт дубликаты библиотек внутри программ. :)

Цитата:

Сообщение от ng_dead

+1

-1

Цитата:

Сообщение от elf/2

оси нет, значить компоновщик придется добавлять СТАТИЧЕСКИ в каждую программу

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

ООП позволяет разбивать систему на подсистемы по абстракциям, а не по функциональности.

Цитата:

Сообщение от acidrain

Можешь регистром пользоваться, как заблагорасудится! =) Никто не запрещает его юзать - он не постоянно нужен, только при обращении к либле. Остальное время можешь про него забыть и юзать постоянно, до следующегно вызова. Система такова, что берешь хендл либлы в регистр, а по возвращению - он опять твой. Как и любой другой регистр, необходимый для передачи данных в либлу.
Надеюсь понятно изъяснил. Такчто не ресурсоемкий метод!

Загрузить хэндл в регистр - машинная команда и расход ресурсов. :)

Цитата:

Сообщение от Shaos

таблица релокации занимает 1/8 размера кода

Много.

Цитата:

Сообщение от libman_r.shtml

Вызов функций библиотеки производится с помощью подпрограммы L_CALL.
Эта подпрограмма самостоятельно подключает необходимый код в нужное
окно (программист должен корректно указать его при загрузке
библиотеки, чтобы не закрыть открываемой страницей кода
менеджера, данных, стека), передает управление на код
соответствующей функции библиотеки, а затем возвращает обратно ту
страницу, которая была там до вызова функции библиотеки.
Перед вызовом в HL устанавливается идентификатор библиотеки, а в
регистре B - функция библиотеки, которую нужно вызвать. Регистр C
- зарезервирован на будущее:

ld hl,(handle)
ld b,function
call l_call
jp c,error

Об ошибке свидетельствует взведеный флаг переноса. Данные можно
передавать и получать в регистрах A,DE,IX,IY, а также через
второй набор регистров.

Другими словами, четыре регистра недоступны для передачи аргументов.
Каждый вызов - потенциальная махинация со страницами.

Довольно прямолинейная реализация подхода Амиги.
А практичность результата? ;)
14.10.2006, 21:22
elf/2

Цитата:

Сообщение от captain cobalt

Цитата:

Сообщение от elf/2

оси нет, значить компоновщик придется добавлять СТАТИЧЕСКИ в каждую программу

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

ООП позволяет разбивать систему на подсистемы по абстракциям, а не по функциональности.

не понял что ты имел в виду :(
1. причем здесь ООП?
2. какой еще вариант кроме добавления компоновщика в каждую программу возможен если у нас нет ОСи?
14.10.2006, 21:31
elf/2

Цитата:

Сообщение от yoko_ono

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

Юзер-прога грузит либу в статически определённое место в памяти. Та сама себя релоцирует каким-либо методом (пусть автор либы поупражняется, раз уж ему нечего делать, кроме как либы писать). И например в начале указанного user-программой места строит таблицу вызовов своих функций, состоящей из JP func1:JP func2:JP func3 и т.д. После чего user-программа, зная начало этой таблицы (раз уж она его и указала), делает туда CALL'ы. Можно отделить собственно тело библиотеки от таблицы вызовов.

кстати примерно так сделано на винде когда либа подгружается системой :)

только в качестве списка jmp'ов используется таблица импорта программы и ее заполняет система на основании списка экспортируемых функций либы
14.10.2006, 22:05
Shaos

Цитата:

Сообщение от captain cobalt

Много.

Плюс RLE сжатие файла либы, которое съест все нули, если в коде небыло переходов. На самом деле 1/8 от объема кода это вовсе немного, если учесть что в замен мы получаем настоящую перемещаемость с шагом 256 байт.

Цитата:

Сообщение от captain cobalt

Другими словами, четыре регистра недоступны для передачи аргументов.
Каждый вызов - потенциальная махинация со страницами.
Довольно прямолинейная реализация подхода Амиги.
А практичность результата? ;)

Ну да - переключить страницу памяти это копейки времени. И всё работает. И пока никто не предложил что-то лучше ;)

P.S. Кроме того этот формат либ поддержан в компиляторе языка Форт и в компиляторе языка Си (оба на Спринтере)
14.10.2006, 23:18
captain cobalt

Цитата:

Сообщение от elf/2

не понял что ты имел в виду :(

Плохо.
Надо разбираться в ООП. Рекомендую книгу.

Цитата:

Сообщение от elf/2

1. причем здесь ООП?

Попробуем разобраться.
Есть "процедурное программирование" и есть ООП.
В чём отличие?
Процедурное программирование - это явное использование функциональности процедур. Например, для вывода спрайта используется процедура вычисления адреса в видеопамяти. При этом точно известно, что от неё ожидать, у программиста имеется реализация этой процедуры.

ООП расширяет эту модель, допуская неявное использование функциональности. Это называется "полиморфизм". Вызывая процедуру, программист уже не опирается на конкретную её реализацию. Реализация может быть неединственна, и, более того, один и тот же вызов в разные моменты времени может фактически обращаться к разным реализациям.

Рассмотрим на примере виндовых DLL.

Если используется конкретная библиотека, то самый разумный способ - это прописать её в импорте, и она будет неявно загружена при загрузке программы.

Теперь посмотрим на FAR с плагинами. FAR, очевидно, явно загружает их с помощью LoadLibrary. При этом разработчики FAR не знают, что реализовано в плагине. Они лишь надеются что это нечто полезное. :) Это неявное использование функциональности.

(забавное сочетание: явное использование функциональности - неявная загрузка DLL; неявное использование - явная загрузка)

При чём здесь всё это?

ИМХО о пяти пунктах насквозь пропитано духом процедурного программирования. "Чтобы был динамический компоновщик, нужно чтобы сначала была ось". Это не так. ООП даёт механизм преодоления. FAR запросто может использовать плагины, которых не существовало во время его написания.

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

Цитата:

Сообщение от elf/2

2. какой еще вариант кроме добавления компоновщика в каждую программу возможен если у нас нет ОСи?

Пусть у нас нет ни оси, ни программ, ни библиотек, есть только динамический компоновщик. Теперь, подсовывая этому компоновщику модули, можно построить хоть ось, хоть программу. Всё что угодно. :)
15.10.2006, 01:02
yoko_ono

Цитата:

Сообщение от Vitamin

Ржунимагу. А на амиге по индексу функции случайно не указатель на нее ищется (косвенный) для последующего перехода? Потому как, если нет указателя на функцию или ее адреса (разные вещи), то функцию вызвать невозможно!

Господин Vitamin, по-моему, вы скатились в абсурд. Что-то мешает вам адекватно воспринимать написанное?

Цитата:

Мадам!

Ну уж простите, это просто грубо! Я вам никакая не 'мадам'! Обращайтесь так к французским потаскушкам!!!

Цитата:

А вы про оптимизацию слышали? Когда из объектого кода (библиотек то есть) удаляются неиспользуемые функции? Конечно, данная операция применима только при сборке готовой программы, а не runtime-сборке, но тем не менее :lol

А вы слышали про это на СПЕКТРУМЕ?

Цитата:

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

Вы не знакомы со всеми возможностями alasm? Сочувствую...

Цитата:

И почему же не в счет? И что мешает написать новый компилятор?

Ничто не мешает, но почему-то не пишут. Задумайтесь, почему.

Цитата:

user-программа свободно может быть и нерелоцируемой, ей это не нужно. Читаем внимательнее.

Как это нерелоцируемой, если адреса вызовов ваших этих линкуемых библиотек всё равно меняются и информацию о них всё равно нужно хранить?
15.10.2006, 01:08
yoko_ono

Цитата:

Сообщение от captain cobalt

ООП позволяет разбивать систему на подсистемы по абстракциям, а не по функциональности.
Загрузить хэндл в регистр - машинная команда и расход ресурсов. :)
Много.

А что, ваше хвалёное ООП разве не подразумевает использование указалетелей на объекты в регистрах и передачу этих указателей функциям? Труднее придумать что-либо более разбазаривающее ресурсы, чем ООП в реализации 'с-крест-крест'.

Цитата:

Другими словами, четыре регистра недоступны для передачи аргументов.
Каждый вызов - потенциальная махинация со страницами.

А сколько же регистров у ВАС в вашем ООП будет использовано? Не соизволите ли привести примеры?

Цитата:

Довольно прямолинейная реализация подхода Амиги.
А практичность результата? ;)

Скажите, вы в детстве не зачитывались ли 'зх-ревю' и 'спектрофонами' на ночь? По-видимому, зачитывались...
15.10.2006, 01:12
yoko_ono

Цитата:

Сообщение от captain cobalt

Плохо.
Надо разбираться в ООП. Рекомендую книгу.

Признайтесь, вы - засланец секты ООП? Сколько вам заплатили за рекламу этой книги?

Цитата:

Попробуем разобраться.
Есть "процедурное программирование" и есть ООП.
В чём отличие?
Процедурное программирование - это явное использование функциональности процедур. Например, для вывода спрайта используется процедура вычисления адреса в видеопамяти. При этом точно известно, что от неё ожидать, у программиста имеется реализация этой процедуры.

ООП расширяет эту модель, допуская неявное использование функциональности. Это называется "полиморфизм". Вызывая процедуру, программист уже не опирается на конкретную её реализацию. Реализация может быть неединственна, и, более того, один и тот же вызов в разные моменты времени может фактически обращаться к разным реализациям.

Какое это имеет отношение к СПЕКТРУМУ? Способны ли вы 1 - привести пример реализации вашего 'ООП' на СПЕКТРУМЕ и 2 - продемонстрировать полученный при применении этого 'ООП' выигрыш в скорости работы или размере программы?
15.10.2006, 01:17
yoko_ono

Цитата:

Сообщение от elf/2

только в качестве списка jmp'ов используется таблица импорта программы и ее заполняет система на основании списка экспортируемых функций либы

Вот именно - в отдельной части EXE хранится список ячеек, в которые надо подставить абсолютные адреса этих функций в момент приведения EXE в работоспособный вид (при загрузке), и создание таких списков - штатная функция генераторов кода на пц. На спектруме же такая операция - нештатная, и до сих пор осуществляется макросами, привнося множество ограничений и существенно усложняя и замедляя процесс компилирования программы, следовательно, необходимо уходить от такого механизма.
Варианты Shaos'а и мой свободны от любой модификации абсолютных адресов вызовов библиотечных функций в user-программе.
15.10.2006, 03:22
Vitamin

Цитата:

Сообщение от acidrain

Нет, ты упорно не хочешь слышать, что тебе говорят! Нету никаких указателей на функции! Есть только хендл либлы и все! Ведь прежде чем вызвать ф-цию ты ведь должен знать, что она делает? Значит ты знаешь, в какой либле ее искать? То тогда ЗАЧЕМ тебе адрес или указатель на ф-цию?

Рассказываю. При классическом использовании либы происходит получение адреса функции (однократное) и ее вызов (многократный). На амиге же происходит вычисление адреса функции (многократное!) вместе с последующим многократным вызовом.

Цитата:

Сообщение от acidrain

Исторически слложившиеся пристрастия и нежелание все конвертировать из своего любимого асма в твой новый. Это еще один тормозящий фактор быстрого развития твоей идеи.

Согласен. Как ни прискорбно, но согласен. Но в таком случае все идеи по реализации релоцируемых бинарников разбиваются об этот fuck'тор.

Цитата:

Сообщение от Shaos

Только функции - доступ к данным через функции. Каждый экземпляр библиотеки будет иметь свои данные и свой код. Никаких внешних точек. Релоцируемая либа компилируется так - компилим с адреса #0000, потом компилим с адреса #0100 и побайтно сравниваем что получилось - если соответствующие байты в двух результатах компиляции отличаются, то пишем в соответствующий бит 1, иначе 0. Подобный фокус с релокацией прокатывает только если адреса указываются прымым текстом и не вычисляются хитрыми формулами. И соответсвенно не может быть никакой самомодификации кода либы с исправлениями адресов переходов.

Имхо маловато функционала. Весьма нехватает ссылок на внешние библиотеки для совместной работы.

Цитата:

Сообщение от captain cobalt

Сжать эти программы.
Непрерывное сжатие сожмёт дубликаты библиотек внутри программ.

Не, дубликатов библиотек внутри программ быть не должно! Максимум- дубликаты функций.

Цитата:

Сообщение от yoko_ono

Господин Vitamin, по-моему, вы скатились в абсурд. Что-то мешает вам адекватно воспринимать написанное?

Где я написал абсурд? Что для вызова функции надо иметь ее адрес или указатель на нее?

Цитата:

Сообщение от yoko_ono

Ну уж простите, это просто грубо! Я вам никакая не 'мадам'! Обращайтесь так к французским потаскушкам!!!

Оп-па (поручик, молчать!!!!)! Феминизм в действии! Товарищ Елена, прощу прощения за излишнее проявление уважения к слабому полу и впредь буду пытаться выдерживать положенные 3 см дистанции :lol:

Цитата:

Сообщение от yoko_ono

А вы слышали про это на СПЕКТРУМЕ?

Нуну. Каких-то пять лет назад на Спектруме не слышали ни о jpeg, ни о RAR, ни о еще многих вещах. Или то что я сказал совсем нереализуемо?

Цитата:

Сообщение от yoko_ono

Вы не знакомы со всеми возможностями alasm? Сочувствую...

Исходник в студию.

Цитата:

Сообщение от yoko_ono

Ничто не мешает, но почему-то не пишут. Задумайтесь, почему.

Пишут. SjASM название ничего не говорит? Если не ошибаюсь, у него с макросами все в порядке, как и у Alasm. А если идея широко пойдет в массы, можно раскочегарить автора на нативную поддержку генерации релоцируемого кода.

Цитата:

Сообщение от yoko_ono

Как это нерелоцируемой, если адреса вызовов ваших этих линкуемых библиотек всё равно меняются и информацию о них всё равно нужно хранить?

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

Цитата:

Сообщение от yoko_ono

Труднее придумать что-либо более разбазаривающее ресурсы, чем ООП в реализации 'с-крест-крест'.

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

Цитата:

Сообщение от yoko_ono

привести пример реализации вашего 'ООП' на СПЕКТРУМЕ

В одной из веток уже приводился. Первое что пришло в голову- вызов виртуальной функции:

;iy=this a=func index
add a,a
add a,(iy)
ld l,a
adc a,(iy+1)
sub l
ld h,a,a,(hl)
inc hl
ld h,(hl)
ld l,a
jp (hl)

Тяжеловато, не спорю. Использовал IY для хранения this чтоб можно было легко достучаться до членов класса. Для сравнения, вызов по индексу а-ля амига:
;a- func index hl-libr addr
add a,a
add a,a
add a,l
ld l,a
adc a,h
sub l
ld h,a
jp (hl)

исходил из предположения, что таблица переходов занимает 4 байта на точку. Если не 4, а 3 (обычный jp addr), то вызов будет еще больше.
Можно слегка оптимизировать, если располагать библиотеку с адреса кратного 256.

Сильно существенная разница получается?

Цитата:

Сообщение от yoko_ono

Варианты Shaos'а и мой свободны от любой модификации абсолютных адресов вызовов библиотечных функций в user-программе.

Вариант Shaos'a видел. Ваш где, товарищ? ;)
А от чего он еще свободен? От возможности позднего связывания модулей между собой?

ЗЫ. А вот мой вариант позволяет безо всяких проблем реализовать керналь точек входа, если так хочется. А может и без него работать. Чего нельзя сказать о предлагаемом. А вот в собранной программе этот керналь- лишняя трата времени и памяти.
15.10.2006, 08:36
captain cobalt

Цитата:

Сообщение от yoko_ono

А что, ваше хвалёное ООП разве не подразумевает использование указалетелей на объекты в регистрах и передачу этих указателей функциям?

Да.
Каждый раз, когда данные не влезают в регистры, используют передачу через память. В ООП данные храняться в объектах и передаются указатели на объекты. В чем проблема? Чем хуже передачи указателей в "обычном программировании"?

Цитата:

Сообщение от yoko_ono

А сколько же регистров у ВАС в вашем ООП будет использовано? Не соизволите ли привести примеры?

Это неправильный вопрос.
Libman (и библиотеки Амиги) не претендует на ООП. А уже регистры как щепки летят. Лучше бы поинтересоваться, что получится, если попробовать реализовать ООП поверх него.

Цитата:

Сообщение от yoko_ono

Скажите, вы в детстве не зачитывались ли 'зх-ревю' и 'спектрофонами' на ночь? По-видимому, зачитывались...

К ним имеются какие-то претензии?

Цитата:

Сообщение от yoko_ono

Признайтесь, вы - засланец секты ООП?

Да, а в чём проблема? :)

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

Цитата:

Сообщение от yoko_ono

Сколько вам заплатили за рекламу этой книги?

Нисколько.

Цитата:

Сообщение от yoko_ono

Способны ли вы 1 - привести пример реализации вашего 'ООП' на СПЕКТРУМЕ

1. Блочные драйверы iS-DOS (и других OS).
2. Драйверы расширенной памяти в ALASM (и многом другом).
3. GUI в BGE.

Все эти примеры справедливо считаются жемчужинами программирования на Speccy.

Цитата:

Сообщение от yoko_ono

продемонстрировать полученный при применении этого 'ООП' выигрыш в скорости работы или размере программы?

Основной выигрыш от ООП - гибкость.
Полезная функциональность часто является следствием гибкости. Полезная функциональность - это то что предстаёт перед конечным пользователем.

Именно отсюда следует брать область применимости ООП.

Скорость и размер при этом могут деградировать обратно пропорционально мастерству программиста. В особенности уровню владения ООП. :)
15.10.2006, 08:55
captain cobalt

Цитата:

Сообщение от Vitamin

Первое что пришло в голову- вызов виртуальной функции:

;iy=this a=func index
add a,a
add a,(iy)
ld l,a
adc a,(iy+1)
sub l
ld h,a,a,(hl)
inc hl
ld h,(hl)
ld l,a
jp (hl)

Обычно func index для каждой конкретной точки вызова это константа.
Можно выполнить constant propagation. Получим:

Код:

LD L,(IY+Д) LD H,(IY+Д+1) JP (HL)

Этот кусок кода можно инлайнить. Можно ещё перед этим добавить PUSH HL, а в начало каждой виртуальной функции POP HL. Соответственно HL станет доступным для передачи аргументов в виртуальную функцию. :)
15.10.2006, 10:57
acidrain

Цитата:

Сообщение от Vitamin

На амиге же происходит вычисление адреса функции (многократное!) вместе с последующим многократным вызовом.

Ты шутишь, да? Скажи, что шутишь? Нет, ну ты ведь ниче не понял? Какое вычесление (тем более многократное?) - мотивируй (видимо кодишь на амми каждый день?)
15.10.2006, 12:43
Vitamin

Цитата:

Сообщение от acidrain

Ты шутишь, да? Скажи, что шутишь? Нет, ну ты ведь ниче не понял? Какое вычесление (тем более многократное?) - мотивируй (видимо кодишь на амми каждый день?)

Выдвигая данное предположение я основывался на том факте, что libman портирован (более мягкий термин, нежели "содран", да? ;)) с амиги с теми же идеями. А именно, кернель с переходами на функции:
jp func1
jp func2
jp func3
...

А вызов осуществляется следующим образом:
ld hl,(handle)
ld b,function
call l_call
jp c,error

и скажи мне, что же происходит внутри функции l_call? Вероятнее всего, тот код, что я и написал, а именно вычисление адреса и переход на него....
15.10.2006, 12:49
Vitamin

Цитата:

Сообщение от captain cobalt

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

Угу. Пускай реализация ООП в С++ не фонтан (нехватает некоторых вещей и есть избыточность), но это стандарт де-факто. А в процедурном программировании для имитации полиморфизма используют массивы указателей на функции. Явно, а не силами компилятора.

Цитата:

Сообщение от captain cobalt

3. GUI в BGE.

Не знаю как другие примеры, но этот к примерам реализации полиморфизма можно отнести с такой же вероятностью, как и ВСЕ плагины для других программ, а также... скомпилированные музыкальные модули! %)

Цитата:

Сообщение от captain cobalt

Обычно func index для каждой конкретной точки вызова это константа.
Можно выполнить constant propagation.

Гм. Не подумал даже про это дело, ориентировался на ассемблер и охватывающую функциональность. В случае распространения констант, конечно все получается весьма и весьма изящно и красиво. Respect!
15.10.2006, 15:28
Shaos

Цитата:

Сообщение от Vitamin

Выдвигая данное предположение я основывался на том факте, что libman портирован (более мягкий термин, нежели "содран", да? ;)) с амиги с теми же идеями. А именно, кернель с переходами на функции:
jp func1
jp func2
jp func3
...

А вызов осуществляется следующим образом:
ld hl,(handle)
ld b,function
call l_call
jp c,error

и скажи мне, что же происходит внутри функции l_call? Вероятнее всего, тот код, что я и написал, а именно вычисление адреса и переход на него....

Когда я писал либмана, то Амигу в глаза не видел, так что "содрать" не мог :)

Показывать 40 сообщений этой темы на одной странице