Упаковщики

[gid]

Но сам же себя он не ломает? Что мешает эту пересылку отрезать?

Алгоритм мешает. Он возвращает в начало, взамен модуля автораспаковщика, тот участок упакованных данных, которые должны там находится.
Чтобы всё это исправить, надо по сути написать новую версию упаковщика.

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

Нет. Основное назначение бкпака - сжатие исполняемых файлов, т.е. файл загрузился, распаковался в памяти и запустился.
Если нужно многократное использование сжатых массивов, то в случае бкпака делали так - копировали сжатый массив в нужное место, и запускали автораспаковщик. Там у него был режим "сжатие данных", когда после распаковки делался не запуск, а просто возврат из п/п RTS PC.
Ну и существенный минус - нужна область для таблиц распаковки.

Для данных, особенно, если массив надо распаковать куда-то в определённое место, на БК использовали самарский Crunch/Decrunch.

Или, как тут советуют, использовать ZXn/DZXn, правда сперва придётся написать нужный упаковщик конкретно для БК.

[Advertiser]

[ivagor]

использовать ZXn/DZXn, правда сперва придётся написать нужный упаковщик конкретно для БК.

Чем не устраивает имеющиеся? Проверял их в том числе в эмуляторе БК, работали. Или какие-то проблемы на реале?

[Manwe]

да

Спасибо! А можешь объяснить что такое "match"? Просто документация автора рассчитана на тех, кто знаком с другими его алгоритмами - описаны только особенности lzsa2, а базовые понятия не описаны.
Про биты LL (literals length) я понял: сколько байт из входного потока копировать в выходной поток. Но не понял как при этом используется XYZ (offset). И что делать когда literals length = 0 - пропускать этот токен или разбирать биты MMM?
Про биты MMM (match length) вообще не врубился: что если задано значение и LL, и MMM? Выполнять и то, и другое? Если да, то в каком порядке? Чем match length отличается от literals length и что делать если match length = 0?

[ivagor]

Возможно несколько запутывает то, что автору пришлось объединить в "токене", с которого начинается каждый отдельный фрагмент все сразу - и информацию о литералах и о ссылках, все чтобы избежать дробления служебной информации на более мелкие небайтовые куски.
LL отдельно, сколько литералов скопировать, там может быть и 0.
XYZ и MMM отдельно, соответственно смещение и длина ссылки в уже раскодированном блоке, чтобы взять оттуда фрагмент и скопировать его в текущую позицию. Конечно по 3 бита мало на все случаи жизни, поэтому он там расписал, когда и как берутся дополнительные байты для длинных совпадений и дальних ссылок.

[Manwe]

LL отдельно, сколько литералов скопировать, там может быть и 0.

А что если LL=1 и MMM=1? Сначала копируем один байт из входного потока, а потом применяем оффсет (1+2)?

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

Спасибо. По названию "match" я догадывался, но в описании прямо об этом не сказано. Мне кажется немного странным, что нужно устанавливать старшие биты в 1, а потом прибавлять оффсет. Было бы логично биты не трогать и отнимать оффсет. Может быть так и сделаю. Тогда, вроде, надо предварительно увеличить оффсет на 1 (преобразование отрицательных чисел в положительные).

[ivagor]

А что если LL=1 и MMM=1? Сначала копируем один байт из входного потока, а потом применяем оффсет (1+2)?

Да, ну и смещение из XYZ (и при необходимости из следующих байт) надо взять.

Мне кажется немного странным, что нужно устанавливать старшие биты в 1, а потом прибавлять оффсет. Было бы логично биты не трогать и отнимать оффсет.

Для pdp11 это без разницы, а вот для z80 и особенно 8080 это очень важная оптимизация. У z80 команда 16 битного вычитания длиннее и медленнее 16 битного сложения, а у 8080 нет команды 16 битного вычитания. Раньше я даже кое-какие упаковщики переделывал на эту тему.

[Manwe]

У z80 команда 16 битного вычитания длиннее и медленнее 16 битного сложения, а у 8080 нет команды 16 битного вычитания.

Было у меня такое подозрение.

Для pdp11 это без разницы

В данном случае можно было бы в распаковщике сэкономить несколько инструкций, если бы оффсеты во входном потоке хранились положительные. А это плюс к быстродействию.

[gid]

Чем не устраивает имеющиеся?

Тем, что по данной вами ссылке нету упаковщиков под pdp-11, только распаковщики. А самому писать лень. Ибо не приспичило.
Не, может, где-то когда-то кто-то давал ссылки на упаковщики zx0..2, lzsa2, написанные для pdp-11, но это как-то мимо меня прошло.

[ivagor]

нету упаковщиков

Ошибся. Для lzsa2 еще можно представить упаковщик для pdp-11, а вот для zxов нет, соответствующие упаковщики были бы или невыносимо медленны или уступали бы имеющимся для ПК. Все же фишка оптимальных упаковщиков в том, что они опираются на мощь современных компьютеров.

[jerri]

Тем, что по данной вами ссылке нету упаковщиков под pdp-11, только распаковщики. А самому писать лень. Ибо не приспичило.
Не, может, где-то когда-то кто-то давал ссылки на упаковщики zx0..2, lzsa2, написанные для pdp-11, но это как-то мимо меня прошло.

Ну они изначально существуют только под ПЦ
вот исходники - можно в С собрать.
есть С под БК?