Архиватор с самым быстрым распаковщиком

[Titus]

Под какой стартовый адрес?

Любой выше 0x4000.

[ivagor]

Бинарники (small и fast без unroll) со стартовым адресом 0F000h

[Titus]

Бинарники (small и fast без unroll) со стартовым адресом 0F000h

Бегло глянул. Вряд ли он быстрее распаковывает, чем мой. А по эффективности да, вполне может быть лучше.

- - - Добавлено - - -

Сравнил качество упаковки на нескольких файлах.
У LZSA на 1-3% лучше, чем у моего.
А по скорости распаковки, как я уже упоминал выше, вряд ли LZSA быстрее, а скорее всего медленнее. Но это все равно примерно один порядок скорости.

И надо не забывать, моему пакеру 25 лет)))

[ivagor]

вряд ли LZSA быстрее

Быстрее, и small и тем более fast.

[Titus]

Быстрее, и small и тем более fast.

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

Я правильно понял, что из-за того, что завершающая последовательность имеет большой размер (4 байта), исходный файл не может быть выровнен по верхнему адресу с распаковываемым?
Т.е. если я пакую область, допустим, 0x4000..0xFFFF, то я не смогу разместить упакованный файл с верхним адресом тоже 0xFFFF из-за этого?

[ivagor]

исходный файл не может быть выровнен по верхнему адресу с распаковываемым?

Да, это вряд ли получится. С опцией -v lzsa печатает safe distance - минимальное расстояние от адреса распаковки до адреса начала упакованного файла. Надо бы проверить по исходнику, но похоже что SafeDistance=UnpackedLen-PackedLen+5, т.е. минимальное сближение в финале распаковки - 5 байт.

[Advertiser]

[ivagor]

Если задача не полностью затереть упакованный файл, а распаковать с перекрытием до FFFF включительно, то можно упаковать с опцией -b и воспользоваться обратными распаковщиками.