Конструктор (ZX SDK)

[caro]

... таблицы патчей для CALL -- это никто не умеет

Хочу еще раз коснуться вопроса создания релоцируемых программ.

Как известно ассемблеры M80, RMAC (CP/M-80) и кросс ассемблер
MA80 в результате копиляции исходника создают файл с расшире-
нием REL - перемещаемый обьектный код, формат которого разра-
ботан фирмой Microsoft.
Для создания исполняемого обьектного кода производится сборка
(линковка) отдельных модулей программы с помощью линковщика
L80 (CP/M-80) или кросс-линковщика MLINK.
Эти линковщики расчитаны на создание исполняемых модулей для
запуска программ под управлением CP/M-80, тоесть по умолчанию
расчитанных на их загрузку и запуск с адреса 100h (начало TPA).
Начиная с 1979 года фирма Digital Reserch начала поставки
операционной системы MP/M - Multi-Programming Monitor Control
Program.
В этой системе, в отличии от CP/M-80, предполагалась возможность
запуска программ с произвольного адреса и поэтому наряду с
файлами COM, которые загружались и запускались с адреса 100h,
были добавлены файлы PRL - Page Relocatable Programs.
В структуре этих файлов присутствует заголовок длиной в два
логических сектора (256 байт), исполняемый код и третий блок,
который содержит битовую таблицу признаков смещения - таблица релокации.
Для создания файла с такой структурой, фирма Digital Research
разработала линковщик LINK80. Эта программа из REL-файлов
создает PRL-файл, который можно загрузить в произвольный
адрес памяти Z80 (с дискретом в 100h), настроить все адреса
в соответствии с таблицей смещений и запустить на исполнение.
В MP/M использовались такие PRL файлы нескольких модификаций:
1) PRL - Page Relocatable Program.
2) SPR - System PRL.
3) RSP - Resident System Process.
4) RSX - Resident System Extensions.
LINK80 также позволяет создавать OVL (оверлейные) файлы,
которые имеют PRL заголовок, но являются не перемещаемыми.

Этот линковщик очень часто присутствовал на системных дисках
CP/M-80, но поскольку синтаксис его командной строки сильно
отличался от L80, то он практически не использовался.

Кому интересно, описание этого линковщика есть на:
http://www.retroarchive.org/cpm/archive/unofficial/

[captain cobalt]

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

Рассмотрим "драйверы расширенной памяти" (сверх 128К)

Это пример отделения интерфейса (например, "установить страницу") от реализации (действительно устанавливающей страницу через порты конкретного клона).

Такие "драйверы" используются, например, в ассемблере alasm, который показывает довольно неплохую производительность. Поэтому утверждение о пц неверно. А эти "драйверы" радикально повышают гибкость alasm.

[Sinus]

как обычно следует выдирание куска текста из контекста, не взирая на отсутствие смысла.
если captain cobalt соблагоизволит прочитать страницы 1-8 из этой темы, то где- то там, в недрах символов и байтов кроется истина, что ДРАЙВЕРЫ НУЖНЫ но не всегда и не везде.
и перед принятием некого паттерна программирования надо немного пораскинуть мозгами, и подумать о областях его применения.
и что есть задачи где применение данного паттерна ведёт к уменьшению стоимости разработки (стоимость = потраченное время + сложность) а есть задачи, где применение тех же концепций наоборот, ведёт к дикому возрастанию стоимости.

[captain cobalt]

Коль скоро "драйверы нужны", то нужен и поддерживающий механизм.
Механизм отделения интерфейса от реализации.

[fk0]

Коль скоро "драйверы нужны", то нужен и поддерживающий механизм.
Механизм отделения интерфейса от реализации.

Наконец-то. Прогресс налицо.

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

интерфейс-1 интерфейс-2 интерфейс-3
| | |
| | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
преобразователь интерфейсов
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | |
интерфейс-1 интерфейс-2 интерфейс-3 интерфейс-4
| | | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
драйвер
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

То-есть что имеем. Имеем интерфйес A. Имеем драйвер
реализующий этот интерфейс. Но собственно интерфейс к
драйверу может быть реализован различными способами.
Равно как и интерфейс использующей его прикладной программе.
Нужна прокладка между ними. "Преобразователь интерфейса".
Который может преобразовать как интерфейс между программой
и драйвером, так, возможно, при необходимости, интерфейс
самого драйвера. Вот в чём суть.

[Sinus]

captain cobalt:
опять двадцать пять.

итак, я говорил

ДРАЙВЕРЫ НУЖНЫ

однако!, я говорил так же

но не всегда и не везде

как я уже говорил

как обычно следует выдирание куска текста из контекста

[CityAceE]

Похоже никто идею не поддержал. Sinus, ну ты же хотел возглавить проект! Обсуждать что-то бесполезно. Проверено неоднократно - нужно действовать!

[fk0]

Похоже никто идею не поддержал. Sinus, ну ты же хотел возглавить проект! Обсуждать что-то бесполезно. Проверено неоднократно - нужно действовать!

Действуй. Никому конкретному никто конкретный не мешает.
Только вот мне, например, есть занятия и по-интересней во-первых,
во-вторых сиди пиши целый день (не в форумы ;-), а потом придя
домой ещё писать что-то (кроме как в форумы) -- ну никакого желания.
Я думаю, у многих так.

[Sinus]

правильно. так оно и есть.
как поговаривал товарищь breeze - "PIздеть - не мешки ворочать"

[Surfin_Bird]

Жаль. Идея была рульная. Можно бы было делать DevKit-ы. Например, а бы купил AdventureGamesDevKit и т.д. Эх...