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

[captain cobalt]

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

В примере - одна программа.
Ведь могут одни библиотеки использовать другие?

Не видел, уточните!

1. Надо загрузить в регистр хэндл библиотеки.
2. Косвенный переход медленнее.
3. Регистр недоступен для передачи аргумента.

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

У меня другое мнение.

Вон какие RAM-диски себе отгрохали. И всё ради комфорта работы.
По сравнению с этим одна страница - ерунда.

[elf/2]

В примере - одна программа. Ведь могут одни библиотеки использовать другие?

извиняюсь, невнимательно прочитал

однако, иметь несколько версий одной библиотеки на диске - это суровая необходимость. иначе получим неработающие программы (тот самый dll hell)

[Vitamin]

да не, ты меня не обижал =) читай пост №217 еше раз, ок? =)

Ну как это не обижал? Постоянно требовал аргументации %)

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

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

[captain cobalt]

однако, иметь несколько версий одной библиотеки на диске - это суровая необходимость. иначе получим неработающие программы (тот самый dll hell)

Моя позиция:
1. Каждая библиотека должна быть одна. На диске и в памяти.
2. Нужен контроль целостности.
3. Если совместимость достаточна - должно компоноваться.
4. Всё остальное - проблемы программистов.

[elf/2]

Я понимаю, что вам трудно все воспринять, но почитайте это (смотрю модеры тщательно удаляют все нужное?)
http://www.totalamiga.org/pdf/totalamiga_19.pdf
страницы 24-26. срочно! =)

пока злобные модеры не потерли, бросился читать... если в двух словах, то очень похоже на COM , только менее гибкое поскольку в runtime нельзя узнать список интерфейсов поддерживаемых библиотекой и похоже список функций для конкретного интерфейса жестко прошит в header'ах. хотя на основании только этой статьи утверждать не буду.

расстраивает, то что даже для использования базовой функциональности (Intuition - это GUI? я не ошибся?) приходится делать кучу телодвижений:
1. открыть либу
2. получить интерфейс

попользоваться...

3. отдать интерфейс
4. закрыть либу

структура самой программы напоминает то что рекомендовала MS во времена Windows 3.11, тот же цикл ожидания сообщений, тот же разлапистый switch-case внутри

зы: только без обид пожалуйста, сами ссылку предложили

[elf/2]

1. Каждая библиотека должна быть одна. На диске и в памяти.
2. Нужен контроль целостности.
3. Если совместимость достаточна - должно компоноваться.
4. Всё остальное - проблемы программистов.

есть старая, но очень нужная программа требующая main.lib.1.0
поставили новую программу, которой нужна main.lib.10.4

как программист может эту проблему решить?

[Advertiser]

[acidrain]

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

Задавай, и задавай девушке Лене (хорошо прошаренной не только в амиге, но и пц и zx) - думаю она компетентно ответит...

[Vitamin]

Задавай, и задавай девушке Лене (хорошо прошаренной не только в амиге, но и пц и zx) - думаю она компетентно ответит...

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

Лене:
-я все еще жду ответа на тему автоматического исключения неиспользуемых функций при компиляции с помощью аласма
-если есть возможность, можно ответить на вопросы к acidrain

[acidrain]

структура самой программы напоминает то что рекомендовала MS во времена Windows 3.11, тот же цикл ожидания сообщений, тот же разлапистый switch-case внутри

Не знаю, как там с виндовз - я в виндовз (из вредности и пристрастия к амиге и спеку) никогда не кодил (не считая пару сишных прог для моего покетпц).
То, что в этой статье написано - справедливо для ОС4, а мы обсуждаем ОС3.9. тут несколько иначе (кстати в статье об этом сказанно). Как там хеадерами и прописанными ифейсами - хз, не кодил. Но т.к. уже модуль какой то настряпан автором треда - то думаю обсуждение не уместно.
Давайте немного отдалимся от ооп и современных методах прогинга и пойдем старым, дедовским способом?
Сначала я воспринял предложение Витамина так, что будет некий типа бут, который займется загрузкой либл и прог и их распределением в памяти (то, что я делал на спеке, до окончания универа - после я забросил сие велеколепное дело). Посему посчитал абсурдным линковку и тем более запрос ифейсов и прочее. Разве не разумнее иметь либлы на диске и всего 2-3 открытых для прог в один момент времени. Т.к. о многозадачности не шло речи, то распределение памяти, упраление открытием-закрытием либл вполне мог на себя загрузчик. Одна либла - графический интерфейс (ГУИ), графическая либла (? не вижу необходимости для спека). Возможно математическая либла. Что еще может понадобиться? Управление клавой? Мышью? Все это в ехес (керналь-загрузчик). Итого, мы имеем реально 1 либлу для прог.
Выход из проги ессно в бут (или что там будет). Ествественно все это обрастет со временем. больше никаких изысков.
Для программера будет еще проще - список входов в инклудах(.h, .i) и autodoc's. Единственное что - релокация, но с этим справится загрузчик и прога пост-компилятора для создания таблицы релокации.
Пока все, пора бежать

[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 представлена в виде отдельных файлов то ничто не помешает ими пользоваться одновременно - потому что в итоге это будет машкод после сборки.

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

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