распространение этой информации нужно немедля запретить — она подрывает основы. вместо того, чтобы оптимизировать код люди будут сетовать на несовершенность компрессора, лишающего их шансов принять участие в size-compo
«Down with rules 256b» использует чуть подпиленный ZX7mini. Лично для меня это было важной частью задачи — показать, что компрессия актуальна в 256b, тем более что бут-сектор для Atari ST, послуживший моим вдохновением, занимал 512б и распаковывался, по словам автора, до 39438 байт: www.pouet.net/prod.php?which=57063
«Splash 1K» и «Chaos Construction 1K» используют ZX7 со стандартным распаковщиком.
Возможно ошибаюсь, у меня все жИ как бы не-настоящий TS, но зато хорошо отключать хоть чипы, хоть каналы по одному\оптом.
Так вот, первый и второй чип как бы перепутаны. Когда все 6 каналов сведены в стерео, попробуй догадайсО, какой чип звучит.
Авот когда выходы второго чипа отключены, и при этом первый молчит, а второй работает(судя по тесту) — тут я и задумываюсь, у меня ли перепутано или все же в сабже. На скорость конечно не влияйет, но все жЫ…
«Я делаю миниинтры (от 256б» — хотелось бы продолжать верить, что в sizecoding вплоть до 512 байтов никакие типовые упаковщики-распаковщики не используются.
Да, тоже этим занимался :) Хотя это очень быстро меня утомляет, экспоненциальный рост сложности такой оптимизации всё же парит :)
Ещё возил программу по памяти, чтобы константы брать из случайных регистров. Ещё, в самом конце уже, модифицировал распаковщики, чтобы сберечь несколько бит на настройках уже самого распаковщика (скажем, zx7mini копирует первый байт вслепую, а потом уже следит по битовому потоку. У меня выходило, что всё равно первые 6-8 байт не паковались, поэтому я просто копировал их автоматом, меняя настойки самого распаковщика).
это можно делать ifdef и сразу несколькими вариантами кода в исходнике, потом автоматический перебор всех вариантов включенных/выключенных definе, автокомпиляция-упаковка каждого состояния, сравнение всех и автовыбор минимальной интры… ;)
Упаковщик Hrum в составе mhmt УЖЕ оптимальный. Нет, Hrust 1 объективно лучший пакер Пьянкова на данный момент. Но по сжатию их вроде выжали на 100%. Теперь есть запас только по скорости.
Хотя, нужно будет расследовать, как именно там выбираются моменты для вставки кодов расширения ссылок в Hrust 1, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.
Для ловли блох такого рода, рекомендую пересобрать избранный оптимальный пакер, добавив к нему функцию печати итогового числа бит. Часто бывает, что есть 2-3 варианта кода, вроде примерно одно и то же, на итоговый размер в байтах не влияет, но в таком упаковщике с битами видишь, какой вариант был реально оптимальнее. Я много сберёг используя такой подход в «Down with the rules». Очень много циклов развернул и т.д. У меня гораздо больше итоговый неупакованный размер интры, по сравнению с тем, что делал ты. Подозреваю, что на 4кб должно получаться 6-7кб кода «оптимизированного под упаковщик». Например, вместо декранчера писать хорошо жмущийся код — ну, ты понимаешь.
Т.е. для себя я сделал такой вывод: нужно переписать Hrust 1 и Hrum для работы с битовым потоком в байтах (вместо битов) и переписать их распаковщики примерно по той же схеме, по которой написаны сейчас ApLib, Exomizer и ZX7. Думаю, это уменьшит их размер Hrust 1 и сделает его вполне конкурентными в чём-то вроде 4K; в случае с Hrum я думаю больше смысла пытаться конкурировать с пакерами типа ZX7, т.е. брать размером распаковщика и скоростью распаковки.
Чото подумал, если все так хотят реальных чипов, чо б не сделать девайс в формате «бутерброда».
Плюсы:
— вставляется в панельку, отстутствует шлейф, приводящий шину данных з80 в состояние «кровь-кишки-говно-распидорасило»,
— занимает меньше места в пространстве.
Минусы:
— чуть габаритнее по высоте и совсем чучуть по ширине.
— чипы видимо придется запаивать — панельки особого смысла не имеют (как доставать нижний чип?).
Т.е. Exomizer однозначный лидер, ZX7 скорее всего уже на этом масштабе неактуально использовать.
ApPack, Hrum, MegaLZ на этом масштабе почти неразличимы, чего и следовало ожидать по итогам больших тестов.
«Splash 1K» и «Chaos Construction 1K» используют ZX7 со стандартным распаковщиком.
Так вот, первый и второй чип как бы перепутаны. Когда все 6 каналов сведены в стерео, попробуй догадайсО, какой чип звучит.
Авот когда выходы второго чипа отключены, и при этом первый молчит, а второй работает(судя по тесту) — тут я и задумываюсь, у меня ли перепутано или все же в сабже. На скорость конечно не влияйет, но все жЫ…
Ещё возил программу по памяти, чтобы константы брать из случайных регистров. Ещё, в самом конце уже, модифицировал распаковщики, чтобы сберечь несколько бит на настройках уже самого распаковщика (скажем, zx7mini копирует первый байт вслепую, а потом уже следит по битовому потоку. У меня выходило, что всё равно первые 6-8 байт не паковались, поэтому я просто копировал их автоматом, меняя настойки самого распаковщика).
Хотя, нужно будет расследовать, как именно там выбираются моменты для вставки кодов расширения ссылок в Hrust 1, потому что я что-то не совсем понимаю как это можно сделать оптимально, особенно с учётом того, что укорачивать коды вроде тоже декомпрессор позволяет.
возможно, возможен «optimal hrum packer», как для hrust'а? ;)
мы это все проходили в 2012 году, прям 1в1
Плюсы:
— вставляется в панельку, отстутствует шлейф, приводящий шину данных з80 в состояние «кровь-кишки-говно-распидорасило»,
— занимает меньше места в пространстве.
Минусы:
— чуть габаритнее по высоте и совсем чучуть по ширине.
— чипы видимо придется запаивать — панельки особого смысла не имеют (как доставать нижний чип?).
sp_save: ld sp,0
->
sp_save: ld sp,__sp
ifdef FORPACK
__sp equ #3131
__hl equ #2121
__de equ #1111
__bc equ #0101
else
__sp equ 0
__hl equ 0
__de equ 0
__bc equ 0
endif
при паковке hrum'ом, — лучше было оставлять ld sp,0, иначе наоборот + 3 байта на всю интру еще и добавит :)
c exomizer'ом же — 3 байта уберет.
;)
ApPack, Hrum, MegaLZ на этом масштабе почти неразличимы, чего и следовало ожидать по итогам больших тестов.