Просмотр полной версии : Библиотеки-модули-программы...
acidrain
17.10.2006, 21:59
Если вы будете продолжать таким образом, я пожалуюсь модераторам
вперед! я буду токо рад. место попистополить ничего более. пеши! детсадейбогу. семеро на одного накинулись...
acidrain
17.10.2006, 22:01
Вот мой вопрос, на который не было ответа и раз уж вы опять невнимательно читаете. Витамин читает внимательно и я читаю внимательно и так же как он не понимаю - и моё непонимание выражено в приведённых вопросах к вам.
как прикажете на него отвечать? в чем вопрос?
captain cobalt
17.10.2006, 22:03
Досей чтоли? Небыло доказательств - только голословные. Команда прямого вызова подпрограммы быстрее косвенного с расходом регистров.
acidrain
17.10.2006, 22:05
Команда прямого вызова подпрограммы быстрее косвенного с расходом регистров.
согласен. а сколько операций до этого прямого вызова? на спеке я имею ввиду?
А когда одна версия C, можно ли если граф импорта имеет склеенные ветки, собрать результат с одним экземпляром C?
А, Vitamin?
Здравый смысл подсказывает, что если в двух модулях есть функции с одинаковыми сигнатурами, то эти модули склеить нельзя. В случае двух разных версий с 50% (если не больше) вероятностью так и будет. Если мы имеем возможность выдерать отдельные процедуры, то мы возьмем целиком более новую версию библиотеки и добавим туда используемые неконфликтующие процедуры из более старой версии.
Вопросы от витамина - он не читает, что ему пишут. упорно продолжает твердить. а в посте http://zx.pk.ru/showpost.php?p=61553&postcount=229 я написал, что отойдем от пц и амиги. вынес предположение о том, как я понял витамина и как хотел бы это видеть на спеке.
Как это я видел бы на спеке я расписал в самом первом посте, а GriV описал еще раз по рабоче-крестьянски в середине ветки. А на свои _конкретные_ вопросы, сугубо технические и направленные на раскрытие мне глаз на все прелести амижного подхода, я ответа так и не получил. Вместо этого получил "а давайте забудем обо всем и представим, что пц не существует". Его ж тоже не дураки придумывали и под досом были объектные файлы и релокация.
Там сказанно, что зачем динамические компоновщики, когда можно проще.
Проще, насколько я понимаю- это грузить готовые кодовые скомпилированные блоки, прибитые гвоздями под конкретный адрес, зато в керналем в начале?
captain cobalt
17.10.2006, 22:27
согласен. а сколько операций до этого прямого вызова? на спеке я имею ввиду? Каких именно операций? Операций динамического компоновщика или операций скомпонованной программы?
Для любого конкретного модуля время компоновки ограничено константой.
Сэкономленные же такты стремяться к бесконечности, если время работы скомпонованного кода стремиться к бесконечности.
За конечное время сэкономленные такты могут полностью покрыть первоначальные расходы.
1 - модуль? какой экспорт? куда?
2 - куда? если ты про сигналы и сообщения то запросто. http://www.totalamiga.org/pdf/totalamiga_18.pdf страницы 24-26 немного затрагивают сей вопрос.
3 - только супер прошаренные программеры типа Stingray могут помнить все входы либл по смещениям. А все остальные (я в т.ч.) пользуются инклудами, хеадерами. См. также архив. он не полный. думаю больше не надо. разумный человек поймет что к чему. Это инклуды для асма. для си не шлю - не особо разнятся.
1. Если один модуль хочет использовать функции другого, он обязан его подключить через функцию загрузки и юзать дальше через хендл?
2. Не сигналы (они же функции, по большому счету), а именно данные. Спрайты там, шрифты, тексты.
3. Не, я не про то. Внутри бинарного файла каким-то образам хранятся символические имена экспортируемых функций или голый код?
Журнал читаю. Интересно, красиво. Ты страницы указал пдфные или журнальные?
ЗЫ. Язвительно замечу, что интерфейс слизан с Mac'a ;) Так что не надо наезжать по поводу подражательства. Я еще про бинарники макинтоша поищу что есть и посмотрю еще там! :))))
acidrain
17.10.2006, 23:30
1. Если один модуль хочет использовать функции другого, он обязан его подключить через функцию загрузки и юзать дальше через хендл?
2. Не сигналы (они же функции, по большому счету), а именно данные. Спрайты там, шрифты, тексты.
3. Не, я не про то. Внутри бинарного файла каким-то образам хранятся символические имена экспортируемых функций или голый код?
Журнал читаю. Интересно, красиво. Ты страницы указал пдфные или журнальные?
1. да
2. не могу представить как дос либрари потребуется графикс либрари. дело в том, что это не модули, а либрари, но называй их как угодно. как и прога, обмен через messages, signals, stack. только зачем?
3. бинарник - код.
ПДФные страницы.
не могу представить как дос либрари потребуется графикс либрари. дело в том, что это не модули, а либрари, но называй их как угодно. как и прога, обмен через messages, signals, stack. только зачем?
Просто потому что ты мыслишь другими категориями. Что мы имеем в случае многозадачной ОС?
-разделяемые библиотеки
-реентерабельные функции внутри
-поскольку экземпляры кода библиотек формально принадлежат разным процессам, для общения используются спецметоды типа тех же сигналов и сообщений (которые, кстати скопированы из UNIX разных реинкарнаций, правда в упрощенном виде)
Что же мы имеем на спеке? Отсутствие ОС! А это дает некоторые преимущества (недостатки относятся к другой категории, указывать их не буду):
-библиотеку использует только один процесс
-функциям не обязательно быть реентерабельными
-общение между секциями программ осуществляется прямыми вызовами с передачей параметров.
Так что, например, берем мы гипотетический модуль под амигу и пытаемся его перетащить на спек в качестве некоего универсального формата хранения бинарных данных.
Перво-наперво отрезаем нахрен керналь- ну зачем внутри сплошного куска кода нужны лишние переходы? Ладно, данный подход еще оправдан для реализации плагинов, да и то, это еще поспорить можно.
Далее. На амиге совсем не требуется релоцирумый код. Флаг ей в руки, спектрум этим похвастать не может, поэтому придется как-то хранить информацию для настройки кода под конкретные адреса. Методов- куча.
Далее. Расширение функциональности осуществляется не только за счет экспорта/импорта функций, но и данных. Инкапсуляция это конечно хорошо, но надо чтоб и без нее можно было обойтись. Итого добавляем поддержку экспорта/импорта переменных и массивов.
И что мы в итоге получаем от исходного амижного модуля? Ни-че-го! Получается обычный объектный файл, поддерживающий релоцируемость, аналоги которого существуют на всех практически платформах.
И что мы в итоге получаем от исходного амижного модуля? Ни-че-го! Получается обычный объектный файл, поддерживающий релоцируемость, аналоги которого существуют на всех практически платформах.
маленький такой комментарий, объектные файлы с платформой вообще не связаны, это "фича" среды разработки (компилятор+линкер)
Если на Амиге есть релокация, то почему нету динамической компоновки, а вместо неё "загрузчики" и "пост-компиляторы"?
ты о чем? с самого начала acidrain говорил о динамической компоновке и привел кучу примеров. в терминах MSDN на амми есть "run-time dynamic linking"
маленький такой комментарий, объектные файлы с платформой вообще не связаны, это "фича" среды разработки (компилятор+линкер)
Спорное утверждение. Под объектным файлом можно понимать как бинарник-промежуточный результат работы компилятора, так и готовый исполнимый файл или библиотеку
2. не могу представить как дос либрари потребуется графикс либрари. дело в том, что это не модули, а либрари, но называй их как угодно. как и прога, обмен через messages, signals, stack. только зачем?
витамин спрашивал можно ли хранить внутри библиотеки ресурсы: иконки, строки и т.д
ну и есть ли унифицированный способ их оттуда достать.
зачем это надо? пара примеров:
1. несколько программ используют одинаковую иконку "open file".
2. хотим программу с локализованным интерфейсом. делаем библиотеку которая хранит только тексты сообщений. соответсвенно будет иметь несколько ресурсных библиотек по одной для каждого языка
есть ли на амми стандартный механизм для "шаринга" ресурсов? (это не наезд, а вопрос)
А когда одна версия C, можно ли если граф импорта имеет склеенные ветки, собрать результат с одним экземпляром C?
А, Vitamin?
Я тут хорошо подумал, попытаюсь иначе изложить, витамин кстати сам согласен что так можно, теоретически - практически этого нет, но тем не менее
Смысл такой - пусть имеет куча модулей - А и Б
причём модуль А имеет набор публичных вызовов
public OneFunc
public TwoFunc
public ThreeFunc
Модуль Б имеет публичные вызовы
public OneFunc
public TwoFunc
public FourFunc
Приложению П которое для сборки использует А и Б надо пользоваться функциями public ThreeFunc и public FourFunc (это общие функции). Казалось бы - модули используют конфликтные имена функций, но П не использует эти функции, поэтому сборка возможна, а функции
public OneFunc
public TwoFunc
для А и функции
public OneFunc
public TwoFunc
для Б
станут контекстно-приватными (т.е. в общем то публичными, но вследствие их ненужности для П их можно сделать внутренними для модулей).
В итоге склейка произойдёт на ура и всё будет работать.
А как это связано с тем что А и Б могут использовать разные библиотеки - С1.0 и С2.0? - да очень просто. При склейке А с С1.0 и Б с С2.0 получатся A+C1.0 и Б+С2.0, причём более библиотека С не нужна (ни одна из версий). Подчеркиваю важность момента - приложение П напрямую не пользуется ни одной версией C (в этом случае опять придётся склеивать П с С и получив например П+C3.0 вязать их с А+С1.0 и Б+С2.0).
Далее, для А и Б будет список повторяющихся методов, которые тем не менее не используются в П. Тогда можно запросто сделать эти методы контекстно-приватными и работать с библиотеками без конфликтов по тем методам, которые являются контекстно-публичными.
Спорное утверждение. Под объектным файлом можно понимать как бинарник-промежуточный результат работы компилятора, так и готовый исполнимый файл или библиотеку
понимать можно что угодно под чем угодно :) но так уж получилось, что объектный файл это устоявшийся термин (по крайней мере для писюканцев :) ). по крайней мере я всегда считал что объектник это результат работы компилятора (в формате REL, OMF, whatever) который даже теоретически исполнить нельзя поскольку внешние ссылки еще не разрешены. из набора этих полуфабрикатов линкер (ln, link, иногда сам компилятор) собирает исполняемый бинарик/динамическую библиотеку
который даже теоретически исполнить нельзя поскольку внешние ссылки еще не разрешены. из набора этих полуфабрикатов линкер (ln, link, иногда сам компилятор) собирает исполняемый бинарик/динамическую библиотеку
Результатом работы gcc без параметров является файл a.out, который тут же можно запустить. Добавить ключик- получим динамическую библиотеку, другой ключик- статическую, третий- объектный файл
Результатом работы gcc без параметров является файл a.out, который тут же можно запустить. Добавить ключик- получим динамическую библиотеку, другой ключик- статическую, третий- объектный файл
Витамин, ты издеваешься? ладно давай от печки... любая разумная программа имеет зависимость как минимум от run-time библиотеки (libc на линуксе, msvcrt на винде). поскольку современные компиляторы "думают" о пользователе они позволяют позвать линкер автоматом. т.е. прога комилиться в объектник (я думаю если постараться то можно заметить что файл .o создается в текущем каталоге) и махом зовется линкер для того чтобы слинковаться с рантаймом. аналогично с динамической библиотекой (только run-time будет другой). а статическая библиотека это просто набор упакованных объектников
Витамин, ты издеваешься?
Не, к словам придираюсь :)))
Я протупил слегка с терминологией. Хотя имел в виду именно объектный файл как болванка для создания исполнимого приложения. И на каждой платформе он будет в общем случае своим изза архитектурных различий.
И на каждой платформе он будет в общем случае своим изза архитектурных различий.
скажу больше, для двух разных приложений эти файлы тоже будут отличаться :)
еще раз, формат объектного файла зависит от компилятора. например компиляторы borland и ms для виндовс используют разные расширения формата.
скажу больше, для двух разных приложений эти файлы тоже будут отличаться
еще раз, формат объектного файла зависит от компилятора. например компиляторы borland и ms для виндовс используют разные расширения формата.
Ну я ж написал- в общем случае. А если они даже в пределах одной платформы различаются, то тем более. Есть из чего выбирать и есть где подсмотреть какие полезные идеи.
captain cobalt
18.10.2006, 14:29
Можно обсудить понятие "язык загрузки", если оно понятно.
Ага. Для начала, что такое "язык загрузки"?
captain cobalt
18.10.2006, 15:52
Язык загрузки - это язык, на котором представлен объектный модуль, "формат объектного файла". Пример - файл с полуфабрикатом машинного кода и таблицами, указывающими куда в машинный код вставить значения внешних ссылок.
Динамический компоновщик - это исполнитель языка загрузки.
Динамическая компоновка - это исполнение "программы" на языке загрузки.
Результат динамической компоновки - скомпонованный модуль.
Цель - получить скомпонованный модуль.
Сделать это можно самыми разнообразными способами, не только пропатчиванием полуфабриката.
Наиболее радикально - генерировать конечный модуль по одному байту.
Итак, предположим что объектный модуль - это программа на языке загрузки, целиком создающая код скомпонованного модуля.
Какие будут идеи для такого языка загрузки?
Вот парочка идей:
1. Стековая машина. Может вычислять сложные выражения от внешних ссылок.
2. Копирование кусков кода из уже сгенерированной части кода. Как в LZ77. Более компактный объектный модуль.
1. Стековая машина. Может вычислять сложные выражения от внешних ссылок.
Это конечно хорошо, но придется задавать выражения в ОПЗ ручками. Или лепить транслятор в нее, что не есть хорошо.
2. Копирование кусков кода из уже сгенерированной части кода. Как в LZ77. Более компактный объектный модуль.
Нахрена? Сжатием пускай занимаются упаковщики!
Я вообще придерживаюсь мнения, что линкер (сиречь исполнитель языка загрузки) должен быть как можно проще (то есть надежнее) и легче.
captain cobalt
18.10.2006, 16:45
Это конечно хорошо, но придется задавать выражения в ОПЗ ручками. Или лепить транслятор в нее, что не есть хорошо. А если эти значения нужны? Какова альтернатива?
Вычислять выражения во время выполнения и увеличивать размер клиентского кода?
Нахрена? Сжатием пускай занимаются упаковщики!
Я вообще придерживаюсь мнения, что линкер (сиречь исполнитель языка загрузки) должен быть как можно проще (то есть надежнее) и легче. Тогда попробуем пойти от упаковщика.
Типичный распаковщик LZ77 занимается тем, что копирует байты из входного и выходного потока в выходной поток.
А что если обучить его вычислять выражения от внешних символов и записывать их в поток?
Распаковка и компоновка сможет быть выполнена за один проход!
Какие ещё преимущества? Подход пропатчивания полуфабриката требует одновременно держать в памяти полуфабрикат, таблицы импорта и пропатчивания. Распаковывающий компоновщик может создавать код прямо поверх упакованного. Нужен лишь обычный для такого дела "разрыв" в десяток байт.
Итак, предположим что объектный модуль - это программа на языке загрузки, целиком создающая код скомпонованного модуля.
Какие будут идеи для такого языка загрузки?
ну я предлагаю использовать brainf*ck (http://www.muppetlabs.com/~breadbox/bf/) или whitespace (http://compsoc.dur.ac.uk/whitespace/)
затем делаем виртуальную машину, для которой этот язык будет родным. потом надо реализовать эту машину в силиконе и поставить в качестве сопроцессора на панельку ПЗУ.
Наиболее радикально - генерировать конечный модуль по одному байту.
надо еще радикальней - по одному биту
беда... запретить все книги про абстрактное программировани нафиг...
Нахрена? Сжатием пускай занимаются упаковщики!
сжатие тут не причем... автор предлагал использовать ссылки "назад" на уже сгенереный код
Какие ещё преимущества? Подход пропатчивания полуфабриката требует одновременно держать в памяти полуфабрикат, таблицы импорта и пропатчивания. Распаковывающий компоновщик может создавать код прямо поверх упакованного. Нужен лишь обычный для такого дела "разрыв" в десяток байт.
"Папа, а ты с кем только что сейчас разговаривал?" (С)
Борщ отдельно, мухи отдельно. Отдельно распаковка (опциональная), отдельно компоновка (обязательная).
А если имелось ввиду:
сжатие тут не причем... автор предлагал использовать ссылки "назад" на уже сгенереный код
то мы получаем обычный упаковщик (далеко не факт что оптимальный и стандартный). А как насчет того, что одинаковые куски кода патчатся по разному в разных местах?
Таблицы релокации/экспорта/импорта должны быть. Без них никак.
captain cobalt
18.10.2006, 17:31
ну я предлагаю использовать brainf*ck (http://www.muppetlabs.com/~breadbox/bf/) или whitespace (http://compsoc.dur.ac.uk/whitespace/)
затем делаем виртуальную машину, для которой этот язык будет родным. потом надо реализовать эту машину в силиконе и поставить в качестве сопроцессора на панельку ПЗУ. Это чтобы хоть что-нибудь сказать?
надо еще радикальней - по одному биту Спековые распаковщики, такие как Hrust, распаковывают по одному байту, а упакованный поток в определённых случаях читают по одному биту.
И широко используются при сборке софта. Файл размером на всю память распаковывается одну-две секунды.
сжатие тут не причем... автор предлагал использовать ссылки "назад" на уже сгенереный код Результат - компактность объектного модуля. Сжатие.
ЗЫ. Стою на асфальте я, в лыжи обутый...
captain cobalt
18.10.2006, 17:40
А как насчет того, что одинаковые куски кода патчатся по разному в разных местах? Копируется уже пропатченый код.
Если код надо пропатчить по-другому, то создаётся код какой надо, и патчится как надо.
Таблицы релокации/экспорта/импорта должны быть. Без них никак. Это просто список внешних символов.
Часто один символ нужно пропатчить более чем в одно место. Все эти места перечисляются в таблице пропатчивания. Так вот она не нужна. Каждое место пропатчивания определяется текущей точкой распаковки.
Вообще, как только каждый из внешних символов использован хотя бы один раз, дальше их можно копировать из распакованного куска, и таблицу импорта можно затирать. :)
Это чтобы хоть что-нибудь сказать?
нет, целей было две:
1. чтобы модераторы срочно перенесли эту тему во флейм. поскольку в очередной раз начинается обсуждение "сферических коней в вакуме"
2. дать ссылки на интересные языки программирования
единственно что меня интересует в рамках новой темы обсуждения: где вам удалось найти этот термин "язык загрузки" и как это будет по английски. остальное в приложении к спеку - чистое теоретизирование
Копируется уже пропатченый код.
Если код надо пропатчить по-другому, то создаётся код какой надо, и патчится как надо.
В таком случае, нахрена? Для реализации этой фигни надо разрабатывать новый пакер. Ты готов? Вперед и с песней, я подожду с результатами. Заодно поменяешь свои взгляды на проблему.
Каждое место пропатчивания определяется текущей точкой распаковки.
Предлагаешь битовую карту пропатчивания? У нее фиксированный размер, явно зависящий от размера кода с коэффициентом 1/8. Не жирно ли? В предлагаемом мною методе на каждую точку пропатчивания расходуется 4 байта, при этом автоматически поддерживаются ссылки на внешние точки. В таком случае размер таблицы не привязан к размеру кода, а зависит от его структуры.
Вообще, как только каждый из внешних символов использован хотя бы один раз, дальше их можно копировать из распакованного куска, и таблицу импорта можно затирать.
Не забывай, что модулей может быть больше чем один. Как ты заранее предусмотришь все варианты раннего/позднего использования символов? Кстати, их отношение (внешний/внутренний) зависит от текущего рассматриваемого модуля.
нет, целей было две:
1. чтобы модераторы срочно перенесли эту тему во флейм. поскольку в очередной раз начинается обсуждение "сферических коней в вакуме"
2. дать ссылки на интересные языки программирования
Лыжи! Лыжи!!! :)
Оффтоп: http://rsdn.ru/article/philosophy/languages.xml
captain cobalt
18.10.2006, 18:02
единственно что меня интересует в рамках новой темы обсуждения: где вам удалось найти этот термин "язык загрузки" и как это будет по английски. Из советской кибернетики 70-80-х годов. :)
По английски наверное никак не будет.
Выше была дана ссылка на варезный .djvu где понятие объясняется и приводится конкретный пример языка загрузки (со стеком но без сжатия).
остальное в приложении к спеку - чистое теоретизирование Практика обычно следует за теорией.
captain cobalt
18.10.2006, 18:14
Предлагаешь битовую карту пропатчивания? Нет.
Пусть у нас есть LZ77 распаковщик. Он может выполнять команды (с аргументами) :
1. Скопировать из входного потока в выходной
2. Скопировать из выходного потока в выходной
3. Конец распаковки.
Теперь мы добавляем к нему стек и команды:
4. Положить константу на стек
5. Положить значение из таблицы импорта на стек
6. Переписать число со стека в выходной поток
7. Сложить два числа на стеке
... и т.д. команды стековой машины
Не забывай, что модулей может быть больше чем один. Как ты заранее предусмотришь все варианты раннего/позднего использования символов? Кстати, их отношение (внешний/внутренний) зависит от текущего рассматриваемого модуля. Хорошо, пусть таблица импорта для простоты остаётся.
Всё равно она меньше чем таблица пропатчивания от которой мы избавились.
acidrain
18.10.2006, 18:24
ну и есть ли унифицированный способ их оттуда достать.
нет, нету. только я так и не могу представить, зачем это надо. хотя на спеке можно унифицированные граф объекты хранить прям в либле. но это имхо сильно ограничет последующее развитие (разность и-фейсов у конечного пользователя).
Уточню - нет никаких обязательств кроме формата либлы. можно сделать ведь и хранение спрайтов и прочего, было бы желание. Можно и в теле либлы хранить все что угодно, главное чтоб программеру было удобно.
Но нахожу и некоторые плюсы в писизме. Хотя не вижу до сих пор видимых причин столь усложнять модули для спека.
нет, нету. только я так и не могу представить, зачем это надо. хотя на спеке можно унифицированные граф объекты хранить прям в либле. но это имхо сильно ограничет последующее развитие (разность и-фейсов у конечного пользователя).
Уточню - нет никаких обязательств кроме формата либлы. можно сделать ведь и хранение спрайтов и прочего, было бы желание. Можно и в теле либлы хранить все что угодно, главное чтоб программеру было удобно.
Но нахожу и некоторые плюсы в писизме. Хотя не вижу до сих пор видимых причин столь усложнять модули для спека
тогда возможно на амми есть другой способ совместного использования ресурсов? предположим есть две демы и им надо использовать общую таблицу синусов...
Выше была дана ссылка на варезный .djvu где понятие объясняется и приводится конкретный пример языка загрузки (со стеком но без сжатия).
ссылку не заметил :( можно повторить?
Но нахожу и некоторые плюсы в писизме. Хотя не вижу до сих пор видимых причин столь усложнять модули для спека.
Не усложнять, а упрощать.
Конкретный пример. Имеется гипотетическая библиотека печати шрифтом 6х8. Для пущей универсальности она должна печатать разными шрифтами. Встраивать бинарник какогото конкретного шрифта в модуль нелогично. Поэтому объявляем используемый шрифт внешней точкой. И прилинковываем модуль, содержащий только шрифт и экспортирующий его в виде точки данных. При линковке получаем щастье. Ферштейн? И заметь, при этом линкеру глубоко пофиг что склеивать- вызов с адресами функций или загрузку с адресом данных.
Теперь мы добавляем к нему стек и команды:
Вот. Уже чтото конкретное, более-менее понятное. Еще один ма-а-а-аленький вопросец- как автоматизировать создание таких вот модулей-стеков? Еще один спецкомпилятор не предлагать. Мои модули создаются на ура реально существующим компилятором. А если получится портировать, то и не одним. Создание модуля не такая частая штука как его использование.
captain cobalt
18.10.2006, 19:35
Еще один спецкомпилятор не предлагать. Тогда предлагаю "ещё одну утилиту". :)
Она будет брать твои компилированные модули и упаковывать их. :)
Тогда предлагаю "ещё одну утилиту".
Она будет брать твои компилированные модули и упаковывать их.
Попробуй сделай. Будет два независимых подхода. Сравним и синтезируем из лучшего чтото новое.
captain cobalt
18.10.2006, 20:42
Надо опубликовать последнюю версию синтаксиса сигнатур.
acidrain
18.10.2006, 22:37
Встраивать бинарник какогото конкретного шрифта в модуль нелогично. Поэтому объявляем используемый шрифт внешней точкой. И прилинковываем модуль, содержащий только шрифт и экспортирующий его в виде точки данных.
Теперь опъясни мне, почему нельзя сделать так: openfont из какой нить либлы? И зачем для этого городить огород? Зачем отдельная точка? Ты еще чанки модуль сделай.
Теперь опъясни мне, почему нельзя сделать так: openfont из какой нить либлы? И зачем для этого городить огород? Зачем отдельная точка? Ты еще чанки модуль сделай.
Нет, это ты мне объясни, зачем делать
CALL OpenFont
...
Если можно сделать
LD HL,Font
?
А если указатель на шрифт используется не в одном месте, а в нескольких? Каждый раз доставать или хранить в специальной переменной? Я вот могу неограниченное число раз загружать прямое значение указателя в регистры. Причем как сразу 2 байта, так и по отдельности старший или младший.
А еще ругал ООП, твой пример- типичная инкапсуляция, JavaBeans в некоторой терминологии.
А если в либе находится куча строк? Тоже будешь для каждой писать свою функцию возврата указателя? Или одну, но с передачей индекса для запроса? А я просто вытащу оттуда прямые указатели на строки по их символическому имени во время сборки.
captain cobalt
19.10.2006, 09:35
Ещё один момент о котором нужен консенсус - как квалифицировать внешние имена.
Есть такие варианты:
1. ИмяМодуля.ИмяПроцедуры. Пример:
CALL KB.ReadKey
2. Просто имя процедуры.
Меньше писать, но конфликты имён.
1. ИмяМодуля.ИмяПроцедуры. Пример:
CALL KB.ReadKey
А теперь попробуй использовать имя с точкой в разных ассемблерах. Дашь список тех, которые это прохавают
captain cobalt
19.10.2006, 10:14
Важно что это пойдёт в таблицы импорта.
Для унаследованных ассемблеров можно сделать примерно так. В таблице импорта прописываются полные имена. А в исходнике используются внутренние имена (без точки), которые и ссылаются на таблицу импорта.
Для унаследованных ассемблеров можно сделать примерно так.
Что есть "унаследованные ассемблеры"?
Давай сначала будем ориентироваться на существующие ассемблеры? А потом напишешь дополнительные утилиты как и собирался
acidrain
19.10.2006, 11:11
Если можно сделать
LD HL,Font
?
А если указатель на шрифт используется не в одном месте, а в нескольких? Каждый раз доставать или хранить в специальной переменной? Я вот могу неограниченное число раз загружать прямое значение указателя в регистры. Причем как сразу 2 байта, так и по отдельности старший или младший.
Объясню - если шрифт был один раз открыт кем-то, то любой процесс (прога, как угодно) может его использовать. Чем такое не устраивает? Ты как представляешь себе что у тебя есть шрифт, линкер (firmware, слышал вы до этого уже дошли?=) и прога которая его хочет заюзать - какие действия надо сделать загрузчику, чтоб твоя прога просто обратилась напрямую?
acidrain
19.10.2006, 11:15
А если в либе находится куча строк? Тоже будешь для каждой писать свою функцию возврата указателя?
Я видимо плохо объяснил, либо ты, как тебе передал гривка?
Не могу понять тебя, а ты меня - видимо с разных планет, хотя вроде ты тоже южанин. Объясни мне - проге нужен фонт, для его получения (открытия или еще чего) какие необходимо сделать действия мне, как кодеру?
И каких еще строк - что ты имеешь ввиду? Я не телепат и не могу не видя тебя вживую понять о чем ты подразумеваешь? Конечно я понимаю, что ты за моником еще и жестикулируешь, но я не вижу :v2_rolley
captain cobalt
19.10.2006, 11:16
Существующие ассемблеры не умеют собирать бейсики с монолоадерами и упаковкой кода.
Для автоматизации этого используются утилиты вроде mkace.
Ориентироваться на существующие ассемблеры - надо.
Ориентироваться на их ограниченные способности - не надо.
А вопрос - как квалифицировать внешние имена?
captain cobalt
19.10.2006, 11:29
Я видимо плохо объяснил, либо ты Я объясню. :)
На Амиге есть такая традиция - при каждом вызове библиотечной функции, выбирать её адрес из таблицы через хэндл.
Есть ли такая традиция для обращения к данным другого модуля.
Объясню - если шрифт был один раз открыт кем-то, то любой процесс (прога, как угодно) может его использовать. Чем такое не устраивает?
Приведи пример "кого-то", кто будет открывать эти шрифты, чтобы прога могла их использовать.
На всякий случай, напоминаю, что наша платформа называется Спектрум и тут нет ОС и нет многозадачности.
Ты как представляешь себе что у тебя есть шрифт, линкер (firmware, слышал вы до этого уже дошли?=) и прога которая его хочет заюзать - какие действия надо сделать загрузчику, чтоб твоя прога просто обратилась напрямую?
Линкер в одном модуле обнаруживает ссылку на внешнюю точку и ищет ее в таблице экспортируемых точек сборки. Если находит- подставляет адреса. И все.
Не могу понять тебя, а ты меня - видимо с разных планет, хотя вроде ты тоже южанин. Объясни мне - проге нужен фонт, для его получения (открытия или еще чего) какие необходимо сделать действия мне, как кодеру?
Ты наверное совсем не читал ту документацию, что я тебе присылал и кидал ссылку в теме.
Вот как выглядит модуль:
__EXTERN "Font",font ;объявляем внешнюю точку и ее внутренний псевдоним
..
LD_ HL,font ;сюда линкер подставит реальный адрес шрифта когда будет собирать
...
LDH_ H,font ;а сюда только старший байт
И таких вот точек, использующих внешний символ, может быть сколь угодно много.
И каких еще строк - что ты имеешь ввиду? Я не телепат и не могу не видя тебя вживую понять о чем ты подразумеваешь? Конечно я понимаю, что ты за моником еще и жестикулируешь, но я не вижу
Обычных строк, последовательность байтов, представляющих текст в какой-либо кодировке. Объяснить что такое кодировка?
За моником я не жестикулирую, просто ухмыляюсь, чувствуя себя самым жалким из последних ламеров, поскольку не дано мне понять всю круть несусветную амиги. А ты объясняешь и на вопросы отвечаешь только когда на тебя наедут конкретно.
Для автоматизации этого используются утилиты вроде mkace.
Ориентироваться на существующие ассемблеры - надо.
Ориентироваться на их ограниченные способности - не надо.
А вопрос - как квалифицировать внешние имена?
У меня вместе с кодом модуля генерится специальный линковочный код, который делает сборку и списывание на диск. Как компромисс- вполне вменяемо.
Подразумевая существующий ассемблер, подразумеваем и его ограниченные способности... Внешние имена квалифицировать именно так, как ты уже написал и как делал я - определение псевдонима на время компиляции, меня просто весьма смутило использование прямого имени с областью видимости прямо в исходнике %))
Я видимо плохо объяснил, либо ты, как тебе передал гривка?
Не могу понять тебя, а ты меня - видимо с разных планет, хотя вроде ты тоже южанин. Объясни мне - проге нужен фонт, для его получения (открытия или еще чего) какие необходимо сделать действия мне, как кодеру?
И каких еще строк - что ты имеешь ввиду? Я не телепат и не могу не видя тебя вживую понять о чем ты подразумеваешь? Конечно я понимаю, что ты за моником еще и жестикулируешь, но я не вижу
Ты почитай сам что написал, я тут даже на первом предложении застрял :-D Наверное когда-нибудь ты хорошо объяснял, только нам не повезло, потому что мы это не видели (((((((-;
Ты кстате с какой планеты южанин? :-D
Объясни мне - проге нужен фонт, для его получения (открытия или еще чего) какие необходимо сделать действия мне, как кодеру?
И каких еще строк - что ты имеешь ввиду? Я не телепат и не могу не видя тебя вживую понять о чем ты подразумеваешь? Конечно я понимаю, что ты за моником еще и жестикулируешь, но я не вижу
давайте я попробую объяснить... есть либа, в ней написано что-то типа:
------------------
sin_table db 00h,ffh, ...
db 55h, aah, ...
font db 00h, 00h, ...
strings db "Hello, world!",ffh,"Welcome!",ffh
__export dw sin_table, font, strings
------------------
в программе грузим эту библиотеку, получаем ее handle и:
ld de, <handle библиотеки>
ld hl, <адрес строки "font">
call get_addr
<в hl получили адрес в памяти где лежат байтики шрифта из библиотеки>
точно так же можем получить адреса sin_table и strings
хотя на спеке было бы лучше пользоваться не именами, а индексами или идентификаторами
в программе грузим эту библиотеку, получаем ее handle и:
ld de, <handle библиотеки>
ld hl, <адрес строки "font">
call get_addr
<в hl получили адрес в памяти где лежат байтики шрифта из библиотеки>
точно так же можем получить адреса sin_table и strings
хотя на спеке было бы лучше пользоваться не именами, а индексами или идентификаторами
Не совсем так. В случае стартап-линковки программе СОВЕРШЕННО не надо ничего не надо делать для того, чтобы подключить либы. Все сделает линковщик по списку либ, заданных на этапе компиляции. Если же требуется подключить либу во время работы, то по символическому имени получаем смещение в блоке кода и используем его в своих корыстных целях. Причем это может быть смещение чего угодно- функции, строки, массива
captain cobalt
19.10.2006, 11:53
У меня вместе с кодом модуля генерится специальный линковочный код, который делает сборку и списывание на диск. Как компромисс- вполне вменяемо. Вменяемо.
Консенсус.
Не совсем так. В случае стартап-линковки программе СОВЕРШЕННО не надо ничего не надо делать для того, чтобы подключить либы. Все сделает линковщик по списку либ, заданных на этапе компиляции. Если же требуется подключить либу во время работы, то по символическому имени получаем смещение в блоке кода и используем его в своих корыстных целях. Причем это может быть смещение чего угодно- функции, строки, массива
адназначна! я привел пример run-time использования, поскольку именно оно применимо к амми
acidrain
19.10.2006, 12:01
при каждом вызове библиотечной функции, выбирать её адрес из таблицы через хэндл.
Нет, не из таблицы! Вы вапще читаете?
адназначна! я привел пример run-time использования, поскольку именно оно применимо к амми
Угу. А если кому приспичило использовать керналь, то делаем все как обычно и запрещаем генерацию символических имен (в таком случае символических ссылок на внешние точки тоже быть не должно). Остается только таблица релокации для настройки.
давайте я попробую объяснить... есть либа, в ней написано что-то типа:
------------------
sin_table db 00h,ffh, ...
db 55h, aah, ...
font db 00h, 00h, ...
strings db "Hello, world!",ffh,"Welcome!",ffh
__export dw sin_table, font, strings
------------------
в программе грузим эту библиотеку, получаем ее handle и:
ld de, <handle библиотеки>
ld hl, <адрес строки "font">
call get_addr
<в hl получили адрес в памяти где лежат байтики шрифта из библиотеки>
точно так же можем получить адреса sin_table и strings
Почти но не то
этим же синтаксисом:
модуль строк/шрифта:
sin_table db 00h,ffh, ...
db 55h, aah, ...
font db 00h, 00h, ...
strings db "Hello, world!",ffh,"Welcome!",ffh
__public dw sin_table, font, strings ; формируем точки экспорта
------------------
в программе грузим эту библиотеку и всё:
__extern sin_table, font, strings ; т.е. определяем внешние точки - точки импорта
ld hl, font ; эти точки уже импортированны на этапе склейки потому не надо никаких хандлов и вызовов для определения адреса
ld de,strings ;
ld a,<чего_нить_ещё>
call <куда_нить>
acidrain
19.10.2006, 12:05
@ griv - ты всегда всех поучаешь(http://zx.pk.ru/showpost.php?p=12438&postcount=22), а потом флеймишь (твой пост http://zx.pk.ru/showpost.php?p=61813&postcount=305 - никак не обзавешь, вроме как флейм)
???
@ griv - ты всегда всех поучаешь(http://zx.pk.ru/showpost.php?p=12438&postcount=22), а потом флеймишь (твой пост http://zx.pk.ru/showpost.php?p=61813&postcount=305 - никак не обзавешь, вроме как флейм)
Да я такой ((((-; а ещё постоянно смайлики ставлю :-D
Давай введём удельную норму флейм-сообщений на 1 тред :-D и разрешённую норму оффтопа :-D
И ещё меня обвиняли в том что я за слова цепляюсь :-D
Ты таки когда нибудь прочитаешь доки что тебе витамин выслал? ;-)
acidrain
19.10.2006, 12:12
Приведи пример "кого-то", кто будет открывать эти шрифты, чтобы прога могла их использовать.
На всякий случай, напоминаю, что наша платформа называется Спектрум и тут нет ОС и нет многозадачности.
http://zx.pk.ru/showpost.php?p=61553&postcount=229
всю круть несусветную амиги.
Я про амигу и пц давно ниче не говорил - я говорю применительно к спеку. мне тебя жаль, что ты так и не догнал, и твои одноместо лизы не догнали. Ты (читай личку)
Цитата:
Сообщение от Vitamin
Приведи пример "кого-то", кто будет открывать эти шрифты, чтобы прога могла их использовать.
На всякий случай, напоминаю, что наша платформа называется Спектрум и тут нет ОС и нет многозадачности.
http://zx.pk.ru/showpost.php?p=61553&postcount=229
И знаешь чего ты пример привел и предложил? Приложения, которое для работы тянет за собой целую однозадачную ОСь- менеджер библиотек (который без особой нужды, если не используется плагинная система). Я борюсь даже с (как ты выразился)
одноместо лизы
чтобы уменьшить этот довесок до минимума при сохранении функциональности.
мне тебя жаль, что ты так и не догнал
И до чего же я не догнал? Что просто зверски необходимо тянуть целую ось с каждым приложением? Что керналь и гвоздями прибитые адреса- это есть последний писк моды?
А вот ты не догнал вообще нифига. И даже не удосужился почитать то, что я тебе высылал эдак 20 страниц назад.
captain cobalt
19.10.2006, 12:38
Нет, не из таблицы! Откуда?
Вы вапще читаете? Да.
Откуда?
Неявно вычисляется путем умножения номера функции на константу и прибавления стартового адреса керналя библиотеки.
captain cobalt
19.10.2006, 13:14
Прыгает в керналь?
:-D в амиге - да
в модулях - нет, в модулях нет керналя :-D
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot