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

[yoko_ono]

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

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

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

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

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

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

[yoko_ono]

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

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

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

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

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

[yoko_ono]

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

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

[Vitamin]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

;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.

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

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

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

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

[captain cobalt]

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

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

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

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

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

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

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

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

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

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

Нисколько.

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

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

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

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

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

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

Скорость и размер при этом могут деградировать обратно пропорционально мастерству программиста. В особенности уровню владения ООП.

[captain cobalt]

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

;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 станет доступным для передачи аргументов в виртуальную функцию.

[acidrain]

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

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

[Vitamin]

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

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

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

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

[Vitamin]

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

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

3. GUI в BGE.

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

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

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

[Shaos]

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

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

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

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