Можно обсудить понятие "язык загрузки", если оно понятно.
Можно обсудить понятие "язык загрузки", если оно понятно.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ага. Для начала, что такое "язык загрузки"?
Язык загрузки - это язык, на котором представлен объектный модуль, "формат объектного файла". Пример - файл с полуфабрикатом машинного кода и таблицами, указывающими куда в машинный код вставить значения внешних ссылок.
Динамический компоновщик - это исполнитель языка загрузки.
Динамическая компоновка - это исполнение "программы" на языке загрузки.
Результат динамической компоновки - скомпонованный модуль.
Цель - получить скомпонованный модуль.
Сделать это можно самыми разнообразными способами, не только пропатчиванием полуфабриката.
Наиболее радикально - генерировать конечный модуль по одному байту.
Итак, предположим что объектный модуль - это программа на языке загрузки, целиком создающая код скомпонованного модуля.
Какие будут идеи для такого языка загрузки?
Вот парочка идей:
1. Стековая машина. Может вычислять сложные выражения от внешних ссылок.
2. Копирование кусков кода из уже сгенерированной части кода. Как в LZ77. Более компактный объектный модуль.
Это конечно хорошо, но придется задавать выражения в ОПЗ ручками. Или лепить транслятор в нее, что не есть хорошо.Сообщение от captain cobalt
Нахрена? Сжатием пускай занимаются упаковщики!
Я вообще придерживаюсь мнения, что линкер (сиречь исполнитель языка загрузки) должен быть как можно проще (то есть надежнее) и легче.
А если эти значения нужны? Какова альтернатива?
Вычислять выражения во время выполнения и увеличивать размер клиентского кода?
Тогда попробуем пойти от упаковщика.
Типичный распаковщик LZ77 занимается тем, что копирует байты из входного и выходного потока в выходной поток.
А что если обучить его вычислять выражения от внешних символов и записывать их в поток?
Распаковка и компоновка сможет быть выполнена за один проход!
Какие ещё преимущества? Подход пропатчивания полуфабриката требует одновременно держать в памяти полуфабрикат, таблицы импорта и пропатчивания. Распаковывающий компоновщик может создавать код прямо поверх упакованного. Нужен лишь обычный для такого дела "разрыв" в десяток байт.
ну я предлагаю использовать brainf*ck (http://www.muppetlabs.com/~breadbox/bf/) или whitespace (http://compsoc.dur.ac.uk/whitespace/)
затем делаем виртуальную машину, для которой этот язык будет родным. потом надо реализовать эту машину в силиконе и поставить в качестве сопроцессора на панельку ПЗУ.
надо еще радикальней - по одному биту
беда... запретить все книги про абстрактное программировани нафиг...
сжатие тут не причем... автор предлагал использовать ссылки "назад" на уже сгенереный код
"Папа, а ты с кем только что сейчас разговаривал?" (С)
Борщ отдельно, мухи отдельно. Отдельно распаковка (опциональная), отдельно компоновка (обязательная).
А если имелось ввиду:
то мы получаем обычный упаковщик (далеко не факт что оптимальный и стандартный). А как насчет того, что одинаковые куски кода патчатся по разному в разных местах?
Таблицы релокации/экспорта/импорта должны быть. Без них никак.
Это чтобы хоть что-нибудь сказать?
Спековые распаковщики, такие как Hrust, распаковывают по одному байту, а упакованный поток в определённых случаях читают по одному биту.
И широко используются при сборке софта. Файл размером на всю память распаковывается одну-две секунды.
Результат - компактность объектного модуля. Сжатие.
ЗЫ. Стою на асфальте я, в лыжи обутый...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
