Упаковщики

[Manwe]

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

Не подскажешь как в LZSA2 это устроено? Read a nibble... then read a byte. После чтения токена (байта) нужно прочитать ниббл (4 бита), а потом байт. Получается, этот байт сдвинут на 4 бита? То есть расположение данных в памяти выглядит так (побитно, где | означает границы байтов в памяти)?

| tokenmmm | niblbyte | byte.... |
                 ^^^^   ^^^^

[Sandro]

Распаковщик BKPACK существует в версии, которая пригодна к многократной распаковке архива и не портит сама себя?

Насколько я помню, он вообще ничего в себе не изменяет, поэтому можно хранить в памяти кучу данных и распаковывать им по мере надобности. Благо алгоритм неожиданно удачный. Он близок по степени сжатия к ZIP/DEFLATE, и при этом вообще не использует побитовой упаковки!

[ivagor]

близок по степени сжатия к ZIP/DEFLATE

Спорное утверждение, например TITR1.PIC и TITR2.PIC zip/deflate сжал в полтора раза лучше, чем bkpack.

пара слов про нибблы в lzsa2

как в LZSA2 это устроено

Про формат lzsa2 я вряд ли напишу лучше автора, но если ограничиться нибблами, то можно сказать, что есть как бы параллельный поток нибблов (это как поток битов во многих других упаковщиках), перемежающийся с потоком байтов. Если нужен ниббл, то мы проверяем текущее состояние "буфера нибблов", и
1. если там пусто, читаем следующий байт, берем оттуда один ниббл, а второй - в буфер нибблов.
2. если там не пусто, берем ниббл и помечаем, что "буффер нибблов" пуст.

[свернуть]

[Manwe]

Про формат lzsa2 я вряд ли напишу лучше автора, но если ограничиться нибблами, то можно сказать, что есть как бы параллельный поток нибблов (это как поток битов во многих других упаковщиках), перемежающийся с потоком байтов. Если нужен ниббл, то мы проверяем текущее состояние "буфера нибблов", и
1. если там пусто, читаем следующий байт, берем оттуда один ниббл, а второй - в буфер нибблов.
2. если там не пусто, берем ниббл и помечаем, что "буффер нибблов" пуст.

То есть нибблы всегда хранятся парами, чтобы занимать ровно байт?

P.S. мне кажется, обсуждение распаковки - НЕ оффтопик в теме про упаковку, так что можно не прятать обсуждение в спойлер.

[ivagor]

То есть нибблы всегда хранятся парами, чтобы занимать ровно байт?

да

[grf]

Насколько я помню, он вообще ничего в себе не изменяет, поэтому можно хранить в памяти кучу данных и распаковывать им по мере надобности. Благо алгоритм неожиданно удачный. Он близок по степени сжатия к ZIP/DEFLATE, и при этом вообще не использует побитовой упаковки!

Распаковщик изначально выглядит так:


Он пересылает часть кода в назначенную рабочую область, потом делает JMP на начало этого кода, и первым делом затирает свое начало, пересылая туда 572 байта из конца архива:



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

[jerri]

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

можно было бы использовать 1 распаковщик на все файлы.
Но нет так нет.

[Sandro]

Распаковщик изначально выглядит так:
Таким образом, повторный запуск уже не имеет смысла, потому что там нет изначального кода.

Но сам же себя он не ломает? Что мешает эту пересылку отрезать? Она нужна только для того, чтобы можно было запускать программу со стандартного адреса 1000, и одновременно там в начале был бы распаковщик. если этого требования нет, то и так фокусничать не надо.

[grf]

Но сам же себя он не ломает? Что мешает эту пересылку отрезать? Она нужна только для того, чтобы можно было запускать программу со стандартного адреса 1000, и одновременно там в начале был бы распаковщик. если этого требования нет, то и так фокусничать не надо.

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

[Sandro]

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

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