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

[captain cobalt]

RAM.ChangeLog - смена страницы памяти на заданную логическую

Не очень удачное название функции.

Список модулей хороший.

Теперь, нажал я резет. Надоел мне вьюер, я захотел текст понабирать - и всё то же самое - загрузился только МОЙ индивидуальный код и все остальные модули подхватились сами.

Ну вот опять.

Не надо нажимать RESET.

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

Загрузить текстовый редактор. Он будет использовать модули уже находящиеся в памяти.

Есть что-нибудь против такого подхода?

2) возможность расширения - отсутствует, это готовый код - только при перекомпиляции; возможность подмены библиотек - 100% за счёт модульной организации;

Возможность расширения - за счёт добавления модулей.

[Advertiser]

[GriV]

Ну вот опять.

Не надо нажимать RESET.

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

Загрузить текстовый редактор. Он будет использовать модули уже находящиеся в памяти.

Есть что-нибудь против такого подхода?

Уже использованный один раз модули надо будет подгружать ещё раз или держать отдельную партию где то в памяти. Фишка в том, что уже "вставленные" в программу модули не получится отделить от программы - это такое свойство модульной структуры.
Всё-таки я тебе рекомендую посмотреть и разобраться досконально со структурой модулей. С моей точки зрения такой подход совместим только с отдельно фунциклирующей ОСью, а никак не самостоятельные приложения.
Впрочем здесь нет ограничений на решения, ежели boot.b будет настолько "умным" то возможен и такой вариант - он грузит контейнер модуля в вырхнюю память, а в нижнюю копирует его присоединяет к программе и поехали...

Возможность расширения - за счёт добавления модулей.

Ты здесь чего-то недопонимаешь, опять же наверное из-за модулей. Ты можешь расширять программу только когда ты её пишешь - модули же уже написанные и откомпилированные программы (пусть и в особом контейнере). Чтобы чего-нибудь там расширить придётся грузить ассемблер (или ЯВУ если угодно) править программу и включать в неё указание на эти модули. Технология динамической подгрузки здесь не канает, потому что уже запущенное приложение не должно нуждаться ни в одной библиотеке и работать самостоятельно.
Если же утверждается обратное, то ещё раз - это уже будет не бут-линковщик и целая ОСь.

[GriV]

2Vitamin> какие уже (в настоящее время) есть вещи так или иначе связанные с модульной организацией (полный список, включая документацию). Что нужно чтобы сие стало "скорее живым, нежели мёртвым"?

[yoko_ono]

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

После чего, например, запустить qc, скопировав им полностью какую-нибудь дискету на другую. Или создать рам-диск в памяти. Или запустить аласм, который всосёт в себя пару десятков исходников, разместив их в страницах, да и сам откушает страниц вдоволь.

Загрузить текстовый редактор. Он будет использовать модули уже находящиеся в памяти.

Если от них останутся следы. Иначе, он снова полезет на диск, и будет ёрзать башкой, как раненный (из скромности умолчу, куда именно).

Кстати, заодно придумайте поиск модулей по страницам и проверку их целостности, и сообщите затраты машинного времени на это.

[captain cobalt]

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

Выше 'подход библиотек Амиги' был проклассифицирован 'в терминах винды'.

Никто из амижников не оспорил.

Вы вон давеча ажно драйвер памяти аласма записали в ООП или куда там. Признайтесь, вы даже его в глаза не видели?!

Конечно же видели.

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

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

Больше регистров - это хорошо.
Для однопоточного программирования это очень хорошо.

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

Кроме того, извольте продемонстрировать тормоза вызовов библиотек амиги, не будьте голословным!
Например так:

Все тормоза перечислены.

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

На всякий случай повторю, что предлагаю заменить тормоза загрузки на тормоза компоновки. Модуль загружается один раз, и много раз компонуется.

Поверьте, никакой миграции не будет.
Вот вы лично готовы использовать вашу эту динамическую компоновку, и в каком именно программном продукте для Спектрума?

Никаких новых программных продуктов сразу не будет.
Для начала предлагается адаптировать существующий софт, как то ALASM, BGE, PT. Классические игры Exolon, Earth Shaker, добавить по вкусу.

Раз вы так в этом уверены, то вы ни разу не проводили дизассемблирование чужих программ.

Проводили.

И даже можно провести параллель.

Разбирая одну программу, в принципе, всё что нужно, можно держать в человеческой памяти. Но если параллельно разбирать десять программ, придётся записывать на бумажку.

Точно так же и с библиотеками.
Одну библиотеку ещё можно использовать без документации. Десяток библиотек - никто не будет.

Есть два основных выхода:
1. ...
2. ...

Готовы ли Вы лично взяться за написание подобного ассемблера для Спектрума?

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

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

Скажите, а что вы будете использовать, если вы захотите написать 50fps вьювер, игрушку с выводом спрайтов через стек и кучей 256b-aligned таблиц, мультиколорную или чанковую дему, наконец?

В некоторой степени это возможно.
Это всё примеры на динамическую кодогенерацию.

Можно дать модулю побольше памяти - и пусть он в неё разворачивает процедуры и вызывает их.

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

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

Всё правильно.
Речь только про то, чтобы предусмотреть для них синтаксис для объявления в сигнатуре.

После чего, например, запустить qc, скопировав им полностью какую-нибудь дискету на другую. Или создать рам-диск в памяти. Или запустить аласм, который всосёт в себя пару десятков исходников, разместив их в страницах, да и сам откушает страниц вдоволь.

Ну и в чём проблема.
Ненужные библиотеки можно выкинуть из памяти.
Если совсем припёрло, можно и динамический компоновщик выкинуть.
Получится точно такой же qc\alasm, но перезагружаться опять через RESET.

Если от них останутся следы. Иначе, он снова полезет на диск, и будет ёрзать башкой, как раненный (из скромности умолчу, куда именно).

Кстати, заодно придумайте поиск модулей по страницам и проверку их целостности, и сообщите затраты машинного времени на это.

Не предусмотрено такого механизма.

Есть модули - программа работает. Убиты модули - программа не работает; RESET; загрузка модулей с диска.

Кстати, уважаемый captain cobalt, раз уж вы замечены в бытности 'одептом ООП', зачитайте вот это:

Хорошо.
Я не против.

А как насчёт ООП на спеке?

[acidrain]

Все тормоза перечислены.

Не видел, уточните! Напрасно голосновно заявляете - вам девушка привела кучу примеров, так что дерзайте - сравнивайте с амигой ваш писизм дальше. Только не забудьте на арм процессор (лучше тогда на ппц) сделать спек, чтоб шот как то работал с вашим писизмом и оопами и прочими попами

[captain cobalt]

Фишка в том, что уже "вставленные" в программу модули не получится отделить от программы - это такое свойство модульной структуры.

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

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

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

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

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

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

[captain cobalt]

Что есть токенизация?

Перевод из plain text в "формат ассемблера".

Ни один из широко используемых спековых ассемблеров не использует plain text для исходников.

Дополнительный проход некой утилитой? А ее нету.

Такая утилита есть.
Для каждого ассемблера своя.

Смотри на вещи шире. Предполагаемый подход твоей хотелки не отрицает.

Вижу, что не отрицает.

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

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

Рассмотрим на примере Linux.
У него есть загружаемые модули ядра.
Загрузим такой модуль. Смонтируем.
Всё. Теперь любая программа может пользовать функциональность модуля через стандартный файловый ввод-вывод, хотя о самом модуле "ни сном ни духом".

Теперь обобщим на произвольный программный интерфейс (не только файловый).
Понятно?

[Vitamin]

Перевод из plain text в "формат ассемблера".
Ни один из широко используемых спековых ассемблеров не использует plain text для исходников.

Зато как минимум один ассемблер использует существующие наработки. Лучше синица в руке, чем утка под кроватью %)

Такая утилита есть.
Для каждого ассемблера своя.

Уж тогда возложить на эту утилиту генерацию таблиц для создания релоцируемого кода. Иначе никак.

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

Рассмотрим на примере Linux.
У него есть загружаемые модули ядра.
Загрузим такой модуль. Смонтируем.
Всё. Теперь любая программа может пользовать функциональность модуля через стандартный файловый ввод-вывод, хотя о самом модуле "ни сном ни духом".
Теперь обобщим на произвольный программный интерфейс (не только файловый).
Понятно?

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

[captain cobalt]

"Монтирование" с точки зрения ядра Linux это что?