Сжатие данных

[svofski]

а пока жмем дампы

Заметьте, не я это предложил. Декодирование 14 параллельных потоков на ходу -- вчерашний пример на 17.5кб усох до 2.5кб. Пришлось написать маленькую RTOS. Не очень эффективно вышло, в 39 экранных строк. Можно бы все-таки не на каждый байт переключать задачи. А еще лучше переписать распаковщик в более подходящем виде -- хотя этот вид оказался совершенно замечательным с точки зрения адаптации: параметр offset на стеке -- это настоящий xthlъ. Сначала я хотел уступать планировщику после LDIR-а, но так выходило не понятно, как синхронизировать потоки -- одни медленно ползут, другие за два лдира пролетают. Проще всего оказалось вставить переключение контекста при сохранении байта. Очень жирно, но зато решает вопрос синхронизации всех потоков. Ржачно получилось по-моему, особенно в Базыре эта шарманка лихо смотрится.

[Advertiser]

[ivagor]

Вот так, решил музычку поиграть, и бац - многопоточность с элементами ОС, впечатляет.

[ivagor]

Возможно ты сам уже оптимизнул, но у меня руки чесались кое-что сократить

[parallelno]

Класс! Я правда мало что понимаю пока. Но стриминг штука интересная особенно в несколько потоков! Клёва!

[svofski]

ivagor, я вот заметил, что на многих музонах, где есть что-то напоминающее бас, у меня получается страшное тарахтение. При этом остальные звуки в порядке, так что я не думаю, что тут что-то с распаковкой. Может быть есть какие-то особенности вывода регистровых дампов в AY, которые я не учитываю?

Оптимизацию пока не смотрел, постараюсь попозже.

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

P.S. Догадываюсь, что это сброс огибающей при записи в R13.
P.P.S Правда, в YM файле в R13 кроме всего прочего записывается FF в пропусках.

[ivagor]

Здорово, что ты доразобрался с YM, и многопоточность - это круто. Но для полноты картины хорошо бы сравнить с нерасщепленным примерноравнобуферным (256*16=4096, 256*14 неудобно) вариантом. Даже можно не реализовать распаковку (понятно, что будет быстрее и компактнее), просто интересно, до скольки сожмется.

[svofski]

Этот же пример -- 2069 байт сумма всех потоков если по колонкам и 7742 байт если сохранить по строкам и окно 4096. Вариант по строкам может оказаться полезным если не хватает времени на распаковку всех потоков, например, он однозначно проще и быстрее. Хотя, покумекав, можно было бы и 14-поточный сделать допустим чтобы он сохранял по 16 байт, а не по одному.

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

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

Кстати, вот скрипт, которым я превращаю xyz.ym в xyz.inc. Он рассчитывает, что salvador.exe лежит в том же каталоге и промежуточный хлам складывает в tmp там же. ym6 сохраняет тот же Ay_Emul. Единственное, что он сохраняет его сразу в lha и надо сначала вынуть оттуда Ay_Emul.ym (я это делаю просто фаром).

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

P.S. обновил в гисте gigachad.asm с новыми лдирами и выводом в AY. Создание тасков оставил как было, потому что нагляднее. Для практики конечно твой вариант лучше подходит.

[parallelno]

А можешь поподробнее написать что эта фраза означает. Все никак понять не могу.
"параметр offset на стеке -- это настоящий xthlъ. Сначала я хотел уступать планировщику после LDIR-а,"
Ldir это что? И что означает фраза"offset на стеке -- это настоящий xthlъ"?

[svofski]

А можешь поподробнее написать что эта фраза означает. Все никак понять не могу.
"параметр offset на стеке -- это настоящий xthlъ. Сначала я хотел уступать планировщику после LDIR-а,"
Ldir это что? И что означает фраза"offset на стеке -- это настоящий xthlъ"?

В процедуре dzx0 есть локальная переменная last_offset, которая задает смещение в буфере, откуда брать данные (см. сишный сорец). Обычно когда мы пишем код на ассемблере, мы не думаем о том, где держать переменные и кладем их куда-нибудь в статическую ячейку памяти поблизости. А в ivagor-овском dzx0 локальная переменная сделана по-взрослому локальной, расположенной на фрейме стека, откуда она достается с помощью довольно редко встречающейся инструкции XTHL. Так бы я и не заметил, но здесь если бы переменная была глобальной, адаптировать процедуру для нескольких контекстов было бы значительно труднее.

LDIR - это инструкция Z80, которая позволяет одной инструкцией скопировать кусок памяти. В версии для 8080 на ее месте подпрограмма с циклом. Это тоже оказалось удобно, потому что если бы у нас была инструкция LDIR, мне пришлось бы ее заменять на подпрограмму самому.

Ъ это просто потому что XTHL такая очень редкая и трудная для понимания инструкция с адской мнемоникой и твердый знак добавляет ей карикатурного анахронизма. Редкий случай, когда я считаю, что у z80 получилось лучше и проще -- EX (SP), HL.

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

Планировщик -- это часть программы, которая вызывает задачи. Во взрослой ОС он был бы в ядре и немного посложнее. Тут он просто перебирает все задачи подряд по кругу.

Когда задача считает, что ее дело сделано, она вызывает yield. yield сохраняет все регистры в контексте задачи и возвращается в планировщик.

Планировщик переходит к следующей задаче -- берет ее контекст (это указатель стека), восстанавливает состояние процессора, делая pop всем регистрам со стека и исполняет ret. И так далее.

С точки зрения каждой задачи, она просто делает волшебный вызов "call yield". Когда он возвращается, она продолжает свое исполнение как ни в чем не бывало.

Теперь на более высоком уровне, почему я это упомянул. Каждое переключение задачи обходится дорого, потому что нужно сохранить контекст одной задачи и восстановить контекст следующей. Лучше их делать как можно реже. Поэтому я изначально надеялся делать это например после подпрограммы LDIR. Но это оказалось плохой идеей потому что потоки распаковываются неравномерно и совершенно непонятно, как их потом сводить в один.

На самом деле я уже знаю, как это сделать более оптимально, хотя это необязательно будет хорошо с точки зрения монотонности фреймрейта. Идея очень простая:
- LDIR уступает всегда на границе 16 байт
- в основном коде строка регистров AY собирается прямо из буферов. Текущая строка = номер кадра, и перебираем столбцы.

Дальше есть варианты. Можно просто вызывать планировщик один раз в 16 кадров. Нормально, если есть возможность пожертвовать значительной частью кадра.
Другой вариант -- вызывать по одной задаче на кадр. С задержкой в 16 кадров у нас будут все те же самые строки в буферах, но на каждый кадр времени будет уходить значительно меньше. Еще два кадра останутся пустыми, или можно еще пару каких-нибудь интересных потоков туда запихать.


Казалось бы, не проще бы было уж на этом этапе сделать обычный pt3-плеер? =)

[svofski]

Ну вот, вариант gigachad16. Каждая таска декодирует по 16 байт за тик. Каждый тик запускается только одна таска. Два тика пропускаем для выравнивания. Получается музыка за 20 строк (худшее, что попадалось пока, обычно 5-15).