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

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

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

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 сообщений этой темы на одной странице