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

[Vitamin]

Сигнатура - это часть документации.

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

Документация всё равно понадобится.

ППКС

Поэтому - чтобы не плодить сущностей.

Сущности и не будут плодиться.

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

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

А в ассемблере. Если мы забыли загрузить аргумент в регистр, и в регистре мусор от предыдущего использования - компилятор ничего не скажет.

А это уже везде. Вне зависимости от платформы, наличия или отсутствия ОС.

Я тут наброски делал по поводу организации сигнатуры. Часть подсмотрел, часть придумал сам. Вот что получилось.

Символьное имя точки.
Символьное имя может содержать в себе дополнительную информа-
цию о сигнатуре, типах параметров и возвращаемом значении (в
квадратных скобках указаны необязательные параметры):
PointName[@signature[(parameters)[#out_type(params_type)]]],\0

signature определяет сигнатуру точки (флаги в символьном экви-
валенте и типы входных параметров для точки-функции в скобках):
Uname;- пользовательский тип name
[type- указатель на тип type
{type- константный указатель на тип type
число скобок определяет вложенность, итоговая константность
определяется по типу последней скобки.
V- void
C- char
I- int
L- long
F- float
c- CARRY
z- ZERO
y- CARRY&ZERO
f- function
B- byte
W- word
D- dword
E- double

Типы c,z и y применяются только для точек-функций.
Также для точки-функции возможно уточнение типа передавае-
мых и возвращаемых значений после знака #. out_type определяет,
как возвращается значение, params_type определяют способ пере-
дачи параметров. Если уточнения нет, то параметры передаются
согласно компилятору (в случае ЯВУ). Следующие обозначения для
различных способов передачи данных:
a- регистр А, 8 бит
b- регистр B, 8 бит
c- регистр C, 8 бит
d- регистр D, 8 бит
e- регистр E, 8 бит
f- регистр F, 2 бита (ZERO & CARRY)
B- регистр BC, 16 бит
H- регистр HL, 16 бит
L- регистр HLDE, 32 бита (HL- старшие биты)
D- регистр DE, 16 бит
E- регистр DEHL, 32 бита (DE- старшие биты)
X- регистр IX, 16 бит
Y- регистр IY, 16 бит
m<name>- в области памяти с именем name.
sN- по смещению в стеке в N байт от SP на момент старта про-
цедуры. Для доступа к переменным может использоваться сле-
дующий код:

PointName:
ld iy,-2
add iy,sp
...
ld a,(iy+N)
...
ld l,(iy+N)
ld h,(iy+N+1)
...

Пример кодирования сигнатуры экспортируемых точек:
int integerVariable; => integerVariable@I,\0
char* strcpy(char* dst, const char* src); => strcpy@[C([C{C),\0
или, при спецификации регистров (in=de,hl, out=de):
strcpy@[C([C{C)#D(DH),\0
void myfunc(mytype** ptr); => myfunc@V([[Umytype),\0

[Advertiser]

[captain cobalt]

m<name>- в области памяти с именем name.
sN- по смещению в стеке в N байт от SP на момент старта про-
цедуры.

Ещё нужны inline константные аргументы, размещаемые в коде типа

CALL target
DB 5
DW #7ffd
; сюда возврат

,\0

Что это?

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

Рассмотрим на примере

;; @sig strcpy@[C([C{C)#D(DH)
;; Копирование строки
;; @arg HL - источник
;; @arg DE - приёмник
;; @ret DE - результат

strcpy  LD A,(HL) ; пошла сама процедура

Две точки с запятой - это комментарий документатора.

С собаки начинаются тэги документатора.

@sig - объявление сигнатуры, которое хэшируется и попадает в модуль с объектным кодом.

Остальное попадает в документацию. Без тэга - просто переписывается в документацию. @arg и @ret - оформляется в документации соответствующими разделами.

Ну разве не заглядение?

[Vitamin]

Ещё нужны inline константные аргументы, размещаемые в коде типа

CALL target
DB 5
DW #7ffd
; сюда возврат

сложна имхо реализация... смещения только последовательно и плясать от адреса возврата

Что это?

завершающий 0. сишный синтаксис приплел %)

Две точки с запятой - это комментарий документатора.

С собаки начинаются тэги документатора.

@sig - объявление сигнатуры, которое хэшируется и попадает в модуль с объектным кодом.

Остальное попадает в документацию. Без тэга - просто переписывается в документацию. @arg и @ret - оформляется в документации соответствующими разделами.

Ну разве не заглядение?

У мя не так, у мя документация отдельно, директивы компилятора отдельно. Типа:

__PUBLIC "strcpy@[C([C{C)#D(DH)",FUNCTION
ld a,(hl)
...

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

[GriV]

пересилил я себя, в который раз причём

Я витамина сразу понял а вот основная масса участников видимо не прониклась духом идеи - как говорят софисты "прежде чем отергать идею, надо проникнуть её духом"

Витамин спросил - какова вообще идея?
Я считаю что идея отличная, и ставлю за идею 5 баллов.

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

Мне кажется основная масса непоняток выходит из того, что витамин недостаточно внятно объяснил что это даст. А я попытаюсь это сделать.

Вот такая общая мысль.
Каждый из нас сталкивался при написании своих программ с тем, что надо рисовать 1 единственный символ в заданном знакоместе из заданного шрифта (расположенного в памяти). Стандартное RST 8 кажется по-моему только на заре программирования использовали - каждый сейчас пользует для этого свой код. Даже в случае, если надо рисовать символ 8x8 точек (что справедливо далеко не всегда). Вот первый претендент - процедура прорисовки символов. (здесь не торопитесь писать "опровержение", потерпите и дочитатайте тред до конца). Вызов - в программе - на внешнюю точку Call Scr.PrintChar8x8 (первая часть имени функции обозначает его модуль - модуль Scr)

Каждый из нас сталкивался с тем, что отсутствует эффективная процедура работы с диском (опять же стандартная #3D13 слишком медленнная, и даже имеющиеся в ней возможности порой значительно ограничены). Тут уж я исключаю такого рода проблемы как поддержка (полная) жёсткого диска, работа с расширенной файловой системой TRDOS Directory System и т.д. Поэтому второй претендет - бинарник для работы с носителями, в том числе с файлами. Вызов Disc.FileRead, Disc.SectorRead, Disc.SectorWrite. Кстати не факт, что даже те процедуры что сейчас есть для скачивания работают хорошо - я вот специально для себя писал очень хитрый дискожуйный процедур, который работает не посекторно а потреково, что уменьшает время решения разрешаемых ошибок чтения и уменьшает "головобуйство" дисководов, экономя их ресурс в том числе, но опять же не про это речь. Модуль - Disc.

Модуль опроса клавиатуры.
Не секрет, что клавиатурный менеджер висящий на прерываниях спекка опять же оставляет желать лучшего - нет буферизации нажатых символов, нет возможности (через него) определить нажатие функциональных клавиш - таких как SymShift, CapsShift; русскоязычная поддержка это вообще из области фантастики. KB.ReadKey - читает клавишу нажатую пользователем. KB.Clear - очищает буфер. Модуль соответственно - KB.

Модуль рисования всеразличных рамок - Window. Window.Show - прорисовывает окошко. Тут даже может быть целая система, учитывающая взаимозакрывания окошек (т.е. когда окошко одно частично закрыто другим, а потом это заднее окошко всплывает).

Модуль арифметических операций Arithm - работает с быстрой целочисленной арифметикой (скорость калькулятора ПЗУ SOS оставляет желать лучшего, хотя функционал там конечно богатый). Arithm.16mul16 - перемножает два 16битных числа. Arithm.16div16 - делает одно 16разрядное на другое.

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

И вот, я хочу написать бут, хочу написать текстовый редактор, хочу написать вьюер, хочу написать игрушку. Что из этих процедур я буду использовать? Правильно - все из них. И тем не менее, в существующей среде каждая из программ использует свой воз и тележку - где хранится это всё добро, и мало того - по причине закрытости исходов, нежелания автора заниматься программой и т.д. и т.п. в программах есть глюки, которые (90%) являются следствием криво написанных перечисленных процедур. Т.е. битком забитый диск программами спекковский диск де факто повторяет себя почти на 90%. Кроме того, часто указанные процедуры цепляются к тексту в виде некоего дополнения к каждой из запускаемых программ - в итоге и без того ограниченное количество допустимых файл-ячеек в ТРДОС используется малоэффективно.

И теперь смотрим как это может быть - на диске лежит 1 pak файл, лежит 1 boot.B и кусочек кода к нему и лежат куча стартеров - файлов скажем с расширением R (взято произвольно, кстати они тоже могут быть в виде одного файла, и вообще здесь файловая структура не так критична). Эти стартеры могут быть и бейсик программами и просто кодом - это не так важно. Важно, что boot.b загрузит при старте линковщик (или компилятор если угодно), который будет уже работать с лежащими в pak файле указанными модулями.
Хочется подчеркнуть такой немаловажный с моей точки зрения момент - модули фактически являются законченным машинным под Z80 кодом с той лишь разницей, что он сопровождается заголовком релокации для того, чтобы можно было склеить эти модули с головной программой. Впрочем, лучше почитать документацию к модулям и станет понятно что обвинения в писюканстве и амижстве здесь бессмысленные.
И вот, запускаю я свой излюбленный вьюер - и что же? фактически, загрузится МОЯ логика реализованная в коде Z80 - мой код (назову это индивидуальный код) - т.е. только то, что в общем то и надо было написать для того чтобы куча библиотек превратилась в вьюер [основная масса существующего программного зоопарка несовершенна по причинами того, что кодер реализовав свою логику, которая на самом деле является изюминкой программы должен ещё и написать процедуры для отработки указанных действий - работы с дисками, клавиатурой, арифсетика, память и т.д.] - код будет просто дёргать нужные функции и я не буду задумываться о реализации универсального драйвера памяти (кроме случая когда он будет для меня слишком медленный, но это около 1% случаев всего кодописания), я не буду задумываться куда мне обратиться за опросом клавиатуры, я не буду задумываться даже на каком устройстве я сейчас работаю - потому что драйвер уже это сделает, потому что он включен в программу - ну и т.д.

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

Кстати тут очень интересный вариант, что модули будут лежать даже не на самом диске, а скажем на ЖД, или например во втором дисководе будет лежать диск с модулями - т.е. даже отпадёт необходимость на конечный диск писать библиотеки.

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

Напоследок хочу сравнить два подхода - которые как мне кажется в некотором смысле конкурирующие - 1) когда имеются ИСХОДНИКИ всех используемых процедур и в процессе компиляции всё собирается в один конечный файл 2) когда имеется модульная структура и фактически компилируется только индивидуальный код.

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

[captain cobalt]

сложна имхо реализация... смещения только последовательно и плясать от адреса возврата

Имеется ввиду, нужен синтаксис для сигнатуры.

Технология использования таких аргументов хорошо отработана. Например:

EX (SP),HL
LD A,(HL)
INC HL
LD C,(HL)
INC HL
LD B,(HL)
INC HL
EX (SP),HL

Даже более привлекательно, чем ковыряться в стеке через индексные регистры.

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

С другой стороны, можно вспомнить о необходимости постепенной миграции со статической компононовки на динамическую.

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

Код на макросах ALASM зависит от ALASM, который не всем нравится. И лишь макросами всё равно не выкрутиться. Например, хотелось бы выражения от импортированных символов, которые сохранялись бы в компилированных модулях и вычислялись во время компоновки (опять вспоминаем обратную польскую запись в iS-DOS).

[captain cobalt]

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

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

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

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

Ну вот опять.

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

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

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

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

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

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

[GriV]

Ну вот опять.

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

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

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

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

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

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

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

[GriV]

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

[yoko_ono]

Попробуем сформулировать тезисы по результатам темы:

1. Подход библиотек Амиги - это тормоза ООП без преимуществ ООП.

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

[yoko_ono]

Тормоза на загрузку хэндла в регистр, косвеную передачу управления, и недоступность регистра для передачи аргументов.

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

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

   jsr  _LVOFunctionName(a6) ; тут безусловно тормоза, целых 2 слова выбираются из памяти, по сравнению с
   jsr  absolute_address ; абсолютным вызовом, где один только адрес занимает 2 слова

то у Амиги "просто библиотеки".