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

[GriV]

Уважаемый captain cobalt, скажите, вы вживую видели 'подход библиотек Амиги'? Я что-то сомневаюсь... Вы вон давеча ажно драйвер памяти аласма записали в ООП или куда там. Признайтесь, вы даже его в глаза не видели?!

Давайте поосторожней, всё-таки у нас клуб друзей...

Был предложен вариант динамической линковки со статически распологаемой (по указанному программой адресу) таблицей входа (JP func1:JP func2:...). Данный вариант позволяет писать программы 'как обычно', с единственной проблемой - распределением памяти под разные библиотеки. Также есть вариант libman примерно с аналогичной функциональностью, за исключением принципа вызова. Но нет же, вам подавай писизм, с обязательным исправлением абсолютных адресов везде, где только можно! Ну ничего, время лечит...

Во-первых, то что вы предлагаете, это не есть что-то новое и для спектрума в частности - такая древня игра как "Strip Poker 2+" - я её ломал - использовала именно такой подход. А если посмотреть, например, http://zx.pk.ru/showthread.php?t=1811, то вы увидите, что это всё уже обсуждалось и флеймилось не раз.

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

Пока что я вижу идеалистов от амиги а не идеалы от писизма. В нашей среде (имею в виду спектрумистов) это очень тяжкое оскорбление, думаю вы извинитесь перед captain cobalt за незаслуженное обвинение.

Скажите, а что вы будете использовать, если вы захотите написать 50fps вьювер, игрушку с выводом спрайтов через стек и кучей 256b-aligned таблиц, мультиколорную или чанковую дему, наконец? Ваш подход - опять же отдаёт писизмом, он не позволяет на СИЛЬНО ОГРАНИЧЕННЫХ ресурсах Спектрума делать действительно быстрые и крутые вещи. Если только лишь тошнить стандартными процедурами уровня инфоркома (помните, были ещё книжки - 'как написать игру на ассемблере' или 'динамическая графика') с кучей заморочек насчёт линковки, ооп и проч. пурги - то и получатся тошные программы - медленные, неинтересные.

В том то и дело, что ежели сей код можно уложить в пределах одной страницы, то можно написать библиотеку - и это будет отлично работать, потому что переходы к этой библиотеке, выраженной в виде модуля и впоследствии собранной линковщиком, будут простым Call или Jp. Как раз это и позволяет реализовать на сильно ограниченных ресурсах хорошие программы - потому что библиотеки будут разрабатываться (в теории конечно, если всё хорошо пойдёт...) коллективом из нескольких (надеюсь десятков) человек. В итоге как вы не пляшите, для вывода мультиколоров вы будете пользоваться
pop hl
ld (XXXX),hl
или
ld hl,YY
push hl
И почему бы генератор сего кода не сделать универсальным? тогда останется лишь набрать строчку типа
call ScrMulti.Generate
да вызов
ld hl,<адрес картинки>
call ScrMulti.Show
и всё.
Да, есть такие случаи которые нельзя стандартными библиотеками охватить, но читайте внимательно - я уже про это писал - это около 1% всех случаев программо-производства.

За каждой из программ тянется шлейф похожих (на процедуры в других программах) процедур, и если это не те программы, от которых тошнит, а реально быстрые вещи, то каждая процедура вылизана десятки раз и адаптирована именно под конкретный случай применения. Зачем тут некие стандартные библиотеки (модули - называйте, как хотите) с 'swiss-knife type'-процедурами на все случаи жизни, с обработкой всех возможных ситуаций и тонной вариантов действий?

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

Это технология чтения аргументов, 'вшитых' в машинный код, т.е. неизменяемых. И опять же, чтения в регистры, а не использования. Для комфортного их использования (несколько раз и в нужные моменты) их придётся переложить в память, по IX/IY ли, в абсолютную ли (по адресу). Немаловажно и то, что такие аргументы (вшитые в код) затрудняют отладку программы (не ясно, сколько таких аргументов идёт после CALL и когда они кончаются и начинается дальше код, к тому же дизассемблер воспримет их как код, выдав бессмысленные команды).

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

Вы в жизни не видели процессоры архитектуры 68к, вам мало 15 32-битных регистров? Это вам не х86, где каждый регистр на вес золота.

Это какой то оффтоп, здесь речь идёт, напомню, про спектрум и про Z80.

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

+1

Модули не "вставляются" в программу.
Программа загружается поверх библиотечных модулей.
Когда программа завершается, модули остаются и не трогаются.
Теперь поверх них можно загрузить другую программу.

Всё-таки вы не прочитали по модули, потомы вы такое говорите.

Заменим слово "модули" на слово "ОС".
ОС "вставляется" в программу? Нет.
ОС можно отделить от программы? Можно.
Тогда зачем нужно "свойство модульной структуры"?

Какая то софистика...
Я совсем не про это вам говорил.
Прежде всего, если ктото хочет многократно пользоваться одним модулем, находящимся резидентно в памяти, то нужна система управления модулями - централизованная - которой будут подчиняться все приложения. Это попахивает целой операционной системой (как это кстати и стало в iSDOS).
Модуль это ГОТОВАЯ программа с точками экспорта, когда она внедрена компоновщиком, то она стала единым целым с программой-инициализатором и отодрать её от программы это сродни пытаться выдрать черенок плодонесущей яблони из дички после того как они 10 лет вживались - вы просто убьёте и то и другое без какого-либо результата. Это не плагинная система, это система пользования готовыми пользовательскими библиотеками.

Это опять "дух процедурного программирования".

Функциональностью не обязательно пользоваться явно.

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

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

тогда надо было начинать с рассказа о том что уже есть и как это работает. и обязательно объяснить чем это лучше/удобнее других методов.

Кажется я пытался это сделать, жаль что столь безуспешно...

Я тоже было подумал, что черная кошка пробежала дважды, но ты меня опередил %)

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

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

Вообразим себе программу, которая использует библиотеки A и B.
В свою очередь A использует C1.0, а B использует C2.0

В любом случае эта программа будет на совести программиста который её писал. Обычно комплект библиотек не являются внутри себя противоречивым, а значит и "кривые" модули будут связаны с криворукостью писавшего текст. Кроме того, если библиотека С версии 1.0 и 2.0 представлена в виде отдельных файлов то ничто не помешает ими пользоваться одновременно - потому что в итоге это будет машкод после сборки.

у нас уже есть многозадачность?

Хочу уверить что есть и очень хорошая - кооперативная с механизмом псевдовытеснения.