За прошедший год я немного улучшил оба декомпрессора. Компактный распаковщик удалось сократить до 88 байт (если у кого-то будут мысли, как его можно ещё сократить — буду очень благодарен, так как
у меня там уже начались реально неприятные оптимизации). Быстрый распаковщик тоже удалось ускорить на несколько процентов, ещё и сократив его до 229 байт, в т.ч. благодаря идеям uniabis.
Последний компактный распаковщик (88 байт): unmegalz_small.asm
Последний быстрый распаковщик (229 байт): unmegalz_fast.asm
Внимание, я немного поменял систему нумерования версий, теперь версия указана внутри файла. Поэтому по этим ссылкам всегда можно будет взять самые последние версии распаковщиков.
В процессе обсуждения на другом ресурсе родилась забавная, имхо, идея.
Единственный формат инструкции Simpleton (2.0) содержит трёхбитовое поле условности инструкции COND:
И сама инструкция в процессе середины выполнения его в схемотехнических кишках должна отвлечься на его проверку и откинуть результат если условие не сработало.
Но как мы знаем побеждают всё-таки архитектуры где не каждая инструкция может быть условной, а всё-таки небольшое подмножество JMP, а всё остальное как правило работает плотнее если условности нет.
Но идеологическим примативом Simpleton является единственный формат инструкции «взять SRC (и возможно DST), поместить их в АЛУ с кодом операции INSTR и результат записать в DST. Это единственное что этот процессор умеет по своей идеологии и делать отдельный формат инструкций для него ну прям то не ради чего он придумывался.
И вот тут и рождается идея — а что если условность выполнения перенести в АЛУ?
Сделать код инструкции который делает следующее — воспринимает SRC как составную величину — 3 бита код условия и 13 бит знакового данного с расширением до 16 бит. И если код условия срабатывает, то складывает SRC с DST и выдаёт результат наружу — иначе наружу выдаётся неизменённый DST.
Тогда код такой операции „conditional 13-bit addition“ в случае если в качестве DST будет подставлен PC сработает как „relative conditional jump“!
Итого за счёт введения новой такой инструкции мы полностью освобождаем 3 бита COND в инструкции и можем, например, увеличить количество регистров с 8 до 16! И всё равно еще остаётся 1 бит. И при этом главное кредо Simpleton остаётся неизменным — правда АЛУ набухает и набухает, т.к. вся сложность и вариативность заметается в него. :)
Но это уже будет Simleton 3.0 пожалуй, ибо я всё еще в раздумьях как поэффективнее воспользоваться возникшими тремя битами (16 регистров, имхо, процессору в духе 8 бит только вредят).
Что интересно — не встречал ранее такого нигде — что код условия в операции становится частью операнда где хранится смещение условного перехода.
Это довольно необычно для меня и даже странновато. Но получается, что можно, например извлекая смещения переходов из таблицы динамически формировать и условность перехода где то в ключевой точке типа switch. Это даже что-то новенькое для меня и явно чувствуется, что может послужить источником каких то интересных полухаков. :)
а как любые переменные пихают куда-нибудь, между процедурами, например?
кстати, там рабочую инфу по спрайтам можно хранить — снаружи цикла половина адреса уже в d
Тут я, кстати, всё ещё не догоняю, как ты насчитал +7 байт? Я ещё раз посчитал, никак у меня 7 не выходит: ld a,h: add 7: ld h,a: jr…
Про таблицу дошло. Но твой код, где ты будешь пихать байты между байтами своей таблицы я даже представлять себе не хочу. Я бы заплатил и 200 тактов, только чтобы никогда у себя такого не видеть. Но как решение, вообше, ок, почему нет, действительно может пригодиться когда всё будет совсем плохо.
потому что 7*inc+add лучше, чем 8*inc+add хоть в развёрнутом, хоть в неразвёрнутом варианте
но если ты к $47XX прибавишь $F820, то получишь $3FZZ/$40ZZ, а не $40ZZ/$48ZZ
у тебя не +6, а +7 без обрезки; у меня 26 с обрезкой, 17 без обрезки
но из них нужны реально лишь 8/5, а промежутки можно использовать
то есть у тебя реально больше места даже без обрезки уйдёт
проиграть и в скорости, и в размере, лишь бы не планировать таблицу, really?
это даже без учёта, что вероятность перехода сегмента может сильно изменяться от геймдизайна
например, сайдскроллер на 2/3 экрана, где в основном движуха по центральной оси
Хорошо. Допустим, связи нет. У тебя цикл, делающий inc h внутри (см. последние 2 примера кода в заметке). Почему мой выбор константы в de неправильный?
у меня там уже начались реально неприятные оптимизации). Быстрый распаковщик тоже удалось ускорить на несколько процентов, ещё и сократив его до 229 байт, в т.ч. благодаря идеям uniabis.
Последний компактный распаковщик (88 байт): unmegalz_small.asm
Последний быстрый распаковщик (229 байт): unmegalz_fast.asm
Внимание, я немного поменял систему нумерования версий, теперь версия указана внутри файла. Поэтому по этим ссылкам всегда можно будет взять самые последние версии распаковщиков.
Единственный формат инструкции Simpleton (2.0) содержит трёхбитовое поле условности инструкции COND:
И сама инструкция в процессе середины выполнения его в схемотехнических кишках должна отвлечься на его проверку и откинуть результат если условие не сработало.
Но как мы знаем побеждают всё-таки архитектуры где не каждая инструкция может быть условной, а всё-таки небольшое подмножество JMP, а всё остальное как правило работает плотнее если условности нет.
Но идеологическим примативом Simpleton является единственный формат инструкции «взять SRC (и возможно DST), поместить их в АЛУ с кодом операции INSTR и результат записать в DST. Это единственное что этот процессор умеет по своей идеологии и делать отдельный формат инструкций для него ну прям то не ради чего он придумывался.
И вот тут и рождается идея — а что если условность выполнения перенести в АЛУ?
Сделать код инструкции который делает следующее — воспринимает SRC как составную величину — 3 бита код условия и 13 бит знакового данного с расширением до 16 бит. И если код условия срабатывает, то складывает SRC с DST и выдаёт результат наружу — иначе наружу выдаётся неизменённый DST.
Тогда код такой операции „conditional 13-bit addition“ в случае если в качестве DST будет подставлен PC сработает как „relative conditional jump“!
Итого за счёт введения новой такой инструкции мы полностью освобождаем 3 бита COND в инструкции и можем, например, увеличить количество регистров с 8 до 16! И всё равно еще остаётся 1 бит. И при этом главное кредо Simpleton остаётся неизменным — правда АЛУ набухает и набухает, т.к. вся сложность и вариативность заметается в него. :)
Но это уже будет Simleton 3.0 пожалуй, ибо я всё еще в раздумьях как поэффективнее воспользоваться возникшими тремя битами (16 регистров, имхо, процессору в духе 8 бит только вредят).
Что интересно — не встречал ранее такого нигде — что код условия в операции становится частью операнда где хранится смещение условного перехода.
Это довольно необычно для меня и даже странновато. Но получается, что можно, например извлекая смещения переходов из таблицы динамически формировать и условность перехода где то в ключевой точке типа switch. Это даже что-то новенькое для меня и явно чувствуется, что может послужить источником каких то интересных полухаков. :)
— Pussy Lovers by zeebr^demarche
— Witch from Hell by shuran33 (от этой работы ваще в полнейшем восторге)
— Void by Invaders
1. [so sad that] covfefe is outta here! by scalesmann/march[ing]_cats
2. -ViKi ViKa- by Slash ^ AtD/RPSG
3. Rain by Mikael ^ Pretzel Logic
Вот бы в 2021 было больше фоток, чем в 2020.
а как любые переменные пихают куда-нибудь, между процедурами, например?
кстати, там рабочую инфу по спрайтам можно хранить — снаружи цикла половина адреса уже в d
Про таблицу дошло. Но твой код, где ты будешь пихать байты между байтами своей таблицы я даже представлять себе не хочу. Я бы заплатил и 200 тактов, только чтобы никогда у себя такого не видеть. Но как решение, вообше, ок, почему нет, действительно может пригодиться когда всё будет совсем плохо.
но если ты к $47XX прибавишь $F820, то получишь $3FZZ/$40ZZ, а не $40ZZ/$48ZZ
но из них нужны реально лишь 8/5, а промежутки можно использовать
то есть у тебя реально больше места даже без обрезки уйдёт
проиграть и в скорости, и в размере, лишь бы не планировать таблицу, really?
это даже без учёта, что вероятность перехода сегмента может сильно изменяться от геймдизайна
например, сайдскроллер на 2/3 экрана, где в основном движуха по центральной оси