Идея b2mа (dcr старшей половины\ jp ldir для фрагментов<8100h байт), которую он потер, интересная. По скорости немного уступает выложенному варианту и практически совпадает с невыложенным (про который написал выше), только на 6 байт короче. Это здорово, но для таких специфических вещей я сейчас предпочитаю поддержку упаковщика. Или чтобы он писал при сжатии максимальную длину пересылаемого фрагмента или лучше обобщенный вариант с возможностью выбора параметров (как saukav для zx7).
Я исходил из того, что копирование 32Кб данных в адресном пространстве, которое только 64Кб, вряд-ли случится.
- - - Добавлено - - -
Хотя, если копирование используется и для повторения коротких одинаковых фрагментов (а-ля копирование вперёд с пересечением), то да, таки случится...
- - - Добавлено - - -
Поэтому и потёр.
Improver, спасибо! После многочисленных замен я зарапортавался и затупил, конечно убирание jz $+6 убавит 6 байт (по скорости практически без изменений). Заменил unlzsa1_fast.asm и unlzsa2_fast.asm. Быстрее было, когда в процедуре rz\ jmp цикл (как в небыстрых вариантах), а когда занес в тело программы, замена rz на jz ничего хорошего не дает, кроме плохого. Вариант пересылок в zx1 еще быстрее, но он и больше по размеру. b2mу тоже спасибо, заставил задуматься.
Мне сначала тоже так показалось, но я подумал, что может я чего-то не понимаю. Потом я хотел предложить inr d перед циклом, чтобы избавиться от FastLdir, но оказалось, что твой вариант всё-же быстрее. Потом я предложил хоть что-то, но подумав, взял и потёр всё. А ты, как оказалось, всё-же заметил мои поползновенияСообщение от ivagor
Твой вариант имеет смысл при двух условиях:
1. Длина пересылаемого фрагмента <8100h
2. После завершения цикла старший байт счетчика не обязан быть =0
Тогда преимущество перед вариантом, который оптимизировал Improver - можно убрать преинкремент, т.е. -1 байт и чуть быстрее
Последний раз редактировалось ivagor; 25.02.2021 в 12:12. Причина: исправил на преинкремент
Получилось неплохо ускорить zx1 без увеличения размера.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Все же "простая" быстрая пересылка не совсем правильная, пришлось доработать и усложнить. zx1, lzsa1_fast и lzsa2_fast исправил, lzsa2 и lzsa1_small вернул. Мораль такова, что пересылка все же стала быстрее, но она громоздкая и ускорение меньше, чем у простого неправильного варианта.
Досообразил более компактный (но и чуть более медленный) вариант ускорения цикла, апгрейдил unlzsa1_small и unlzsa2. Вряд ли я первым изобретаю этот велосипед, тема оптимизации циклов с 16 разрядным счетчиком актуальна и для z80 (речь не про ldir), наверняка спектрумисты и/или msxники уже писали что-то такое, интересно бы сравнить.
Из сообщений может показаться, что все упирается только в пересылку, на самом деле например в последних модификациях dzx1 основной выигрыш связан с другими модификациями. Скорость переброски наиболее важна в простых распаковщиках типа lzsa1.
- - - Добавлено - - -
Действительно, msxники писали про эту тему, и я даже когда-то давно читал, но потом забыл. Компактный вариант фактически украл с z80 (с поправкой на отсутствие djnz), а вот более быстрый я получается все же допридумал. Но с z80 просто не было необходимости, у них компактный по скорости равен быстрому, у 8080 inr/dcr/inx/dcx медленнее, поэтому есть разница.
ну обычно компактные не ускоряют а уменьшают
чтоб вставлять в 128бит демке
Главное достоинство lzsa1 - скорость и любые варианты его распаковщиков плохо подходят для sfx версий суперкомпактных программ. Для микродем и других подобных применений есть zx7mini, а еще лучше saukav с соответствующими настройками.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
