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

[Vitamin]

Какие ещё преимущества? Подход пропатчивания полуфабриката требует одновременно держать в памяти полуфабрикат, таблицы импорта и пропатчивания. Распаковывающий компоновщик может создавать код прямо поверх упакованного. Нужен лишь обычный для такого дела "разрыв" в десяток байт.

"Папа, а ты с кем только что сейчас разговаривал?" (С)

Борщ отдельно, мухи отдельно. Отдельно распаковка (опциональная), отдельно компоновка (обязательная).
А если имелось ввиду:

сжатие тут не причем... автор предлагал использовать ссылки "назад" на уже сгенереный код

то мы получаем обычный упаковщик (далеко не факт что оптимальный и стандартный). А как насчет того, что одинаковые куски кода патчатся по разному в разных местах?

Таблицы релокации/экспорта/импорта должны быть. Без них никак.

[Advertiser]

[Vitamin]

ЗЫ. Стою на асфальте я, в лыжи обутый...

[captain cobalt]

ну я предлагаю использовать brainf*ck (http://www.muppetlabs.com/~breadbox/bf/) или whitespace (http://compsoc.dur.ac.uk/whitespace/)

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

Это чтобы хоть что-нибудь сказать?

надо еще радикальней - по одному биту

Спековые распаковщики, такие как Hrust, распаковывают по одному байту, а упакованный поток в определённых случаях читают по одному биту.

И широко используются при сборке софта. Файл размером на всю память распаковывается одну-две секунды.

сжатие тут не причем... автор предлагал использовать ссылки "назад" на уже сгенереный код

Результат - компактность объектного модуля. Сжатие.

[elf/2]

Это чтобы хоть что-нибудь сказать?

нет, целей было две:
1. чтобы модераторы срочно перенесли эту тему во флейм. поскольку в очередной раз начинается обсуждение "сферических коней в вакуме"
2. дать ссылки на интересные языки программирования

единственно что меня интересует в рамках новой темы обсуждения: где вам удалось найти этот термин "язык загрузки" и как это будет по английски. остальное в приложении к спеку - чистое теоретизирование

[captain cobalt]

А как насчет того, что одинаковые куски кода патчатся по разному в разных местах?

Копируется уже пропатченый код.
Если код надо пропатчить по-другому, то создаётся код какой надо, и патчится как надо.

Таблицы релокации/экспорта/импорта должны быть. Без них никак.

Это просто список внешних символов.
Часто один символ нужно пропатчить более чем в одно место. Все эти места перечисляются в таблице пропатчивания. Так вот она не нужна. Каждое место пропатчивания определяется текущей точкой распаковки.

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

[Vitamin]

Копируется уже пропатченый код.
Если код надо пропатчить по-другому, то создаётся код какой надо, и патчится как надо.

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

Каждое место пропатчивания определяется текущей точкой распаковки.

Предлагаешь битовую карту пропатчивания? У нее фиксированный размер, явно зависящий от размера кода с коэффициентом 1/8. Не жирно ли? В предлагаемом мною методе на каждую точку пропатчивания расходуется 4 байта, при этом автоматически поддерживаются ссылки на внешние точки. В таком случае размер таблицы не привязан к размеру кода, а зависит от его структуры.

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

Не забывай, что модулей может быть больше чем один. Как ты заранее предусмотришь все варианты раннего/позднего использования символов? Кстати, их отношение (внешний/внутренний) зависит от текущего рассматриваемого модуля.

нет, целей было две:
1. чтобы модераторы срочно перенесли эту тему во флейм. поскольку в очередной раз начинается обсуждение "сферических коней в вакуме"
2. дать ссылки на интересные языки программирования

Лыжи! Лыжи!!!

Оффтоп: http://rsdn.ru/article/philosophy/languages.xml

[captain cobalt]

единственно что меня интересует в рамках новой темы обсуждения: где вам удалось найти этот термин "язык загрузки" и как это будет по английски.

Из советской кибернетики 70-80-х годов.
По английски наверное никак не будет.

Выше была дана ссылка на варезный .djvu где понятие объясняется и приводится конкретный пример языка загрузки (со стеком но без сжатия).

остальное в приложении к спеку - чистое теоретизирование

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

[elf/2]

Выше была дана ссылка на варезный .djvu где понятие объясняется и приводится конкретный пример языка загрузки (со стеком но без сжатия).

ссылку не заметил можно повторить?

[captain cobalt]

Предлагаешь битовую карту пропатчивания?

Нет.

Пусть у нас есть LZ77 распаковщик. Он может выполнять команды (с аргументами) :
1. Скопировать из входного потока в выходной
2. Скопировать из выходного потока в выходной
3. Конец распаковки.

Теперь мы добавляем к нему стек и команды:

4. Положить константу на стек
5. Положить значение из таблицы импорта на стек
6. Переписать число со стека в выходной поток
7. Сложить два числа на стеке
... и т.д. команды стековой машины

Не забывай, что модулей может быть больше чем один. Как ты заранее предусмотришь все варианты раннего/позднего использования символов? Кстати, их отношение (внешний/внутренний) зависит от текущего рассматриваемого модуля.

Хорошо, пусть таблица импорта для простоты остаётся.
Всё равно она меньше чем таблица пропатчивания от которой мы избавились.

[captain cobalt]

Еще один спецкомпилятор не предлагать.

Тогда предлагаю "ещё одну утилиту".

Она будет брать твои компилированные модули и упаковывать их.