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

[captain cobalt]

в этом случае я не вижу чем имя функции memcpy хуже memcpy_VI#43543

memcpy - это имя. VI#43543 - это то самое проверочное магическое число. Оно остаётся "за кулисами". В клиентском коде используется только memcpy. VI#43543 просто копируется в клиентский модуль с объектным кодом во время компиляции. Во время динамической компоновки они просто проверяются на равенство.

Предполагается, что автор memcpy изменив интерфейс (или внеся иную несовместимость) изменит сигнатуру. Несовместимые модули не будут компоноваться. Если автор забудет изменить сигнатуру, то вспомнит когда у него что-нибудь сломается. Если у него ничего не сломается, ему сообщит кто-нибудь, у кого сломается. Если автор забил на спек, проблема может быть опубликована.

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

[Advertiser]

[elf/2]

Предполагается, что автор memcpy изменив интерфейс (или внеся иную несовместимость) изменит сигнатуру. Несовместимые модули не будут компоноваться. Если автор забудет изменить сигнатуру, то вспомнит когда у него что-нибудь сломается. Если у него ничего не сломается, ему сообщит кто-нибудь, у кого сломается. Если автор забил на спек, проблема может быть опубликована.

если у библиотеки/библиотечной функции изменяется интерфейс, то у библиотеки меняется номер версии и линкер на основании требовании программы к ВЕРСИИ библиотеки с новой версией линковать не будет.

[captain cobalt]

Зачем сюда вообще прилеплять документацию? Да ни в жизни библиотеки не различались по версии описания.

Сигнатура - это часть документации.
Документация всё равно понадобится.
Поэтому - чтобы не плодить сущностей.

Чего???? Как раз только на этапе линковки. Чтобы знать что и с чем склеивать.

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

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

[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

[elf/2]

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

проверка сигнатур нормально работает только на этапе компиляции.

Чего???? Как раз только на этапе линковки. Чтобы знать что и с чем склеивать.

ребятушки это уже не смешно... мангленые имена функций с сигнатуруй появились в компиляторах C++ как workaround: необходимо было как-то разрешать перегруженные функции, а формат obj файлов не содержал типов аргументов. пришлось делать уникальные имена для перегруженных функций. соответсвенно в момент компиляции когда компилятор знает типы всех аргументов при вызове функции он создает это хитрое имя а линкер просто сравнивает две строчки... вы хотите делать перегруженные функции на асме? это не возможно, поскольку синтаксис ассемблера не содержит комманды вызова функции с агрументами.

В клиентском коде используется только memcpy. VI#43543 просто копируется в клиентский модуль с объектным кодом во время компиляции. Во время динамической компоновки они просто проверяются на равенство.

вот именно, попробуйте написать функцию которая имея в регистре A номер экранной линии возвращает адрес в HL и ее вызов в терминах вашего мифического компилятора. и объясните кто и как будет формировать мангленое имя _при вызове_

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


ну и главное: всемогуторы не летают!

[Vitamin]

elf/2: ты прав насчет проблем и всего-всего. Но есть одна маленькая хитрость. По крайней мере у меня. Все дело в том, что символическое имя и внутреннее имя в исходнике могут различаться!!! И все прекрасно ложится тогда!
Например, импортируем две перегруженные функции с разной сигнатурой.

__EXTERN "onefunc@B(DD)",func_ver_1
__EXTERN "onefunc@B(WW)",func_ver_2
...
;гдето в коде
CALL_ func_ver_1 ;зовем первую функцию
...
CALL_ func_ver_2 ;зовем вторую функцию

равнозначно экспортирование
__PUBLIC "myfunc@W(BB)",FUNCTION
myfunc1
....

__PUBLIC "myfunc@W(WW)",FUNCTION
myfunc2
...

Вот и все! И нет никакого конфликта!

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

Не совсем. Утилита берет исходник, генерит на базе него другой исходник, в котором внутри прописаны все таблицы релокации, вся сигнатура функций и прочая, а вот этот второй исходник уже используется для компиляции в обычный объектный код, списываемый на диск в виде модуля.
И таблицы символов из файла выкидывать нельзя. Нужно оставить хотя бы хеши сигнатур, иначе ничего не получится.

[elf/2]

__EXTERN "onefunc@B(DD)",func_ver_1
__EXTERN "onefunc@B(WW)",func_ver_2
...
;гдето в коде
CALL_ func_ver_1 ;зовем первую функцию
...
CALL_ func_ver_2 ;зовем вторую функцию

причем здесь перегрузка? ты руками назначаешь алиас для фукнкии и по нему ее вызываешь.

при настоящей перегрузке, ассемблер должен "магическим" образом проанализировать твой код перед CALL_ и понять какой из вариантов onefunc ты имел в виду и вызвать его

[icebear]

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

Т.е. CLSID - это часть доки по винапи?

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

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

[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)
...

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