JPEG 8080

[ivagor]

Тема началась здесь (https://zx-pk.ru/threads/32514-zpu-na-vektore.html?p=1100823&viewfull=1#post1100823) и продолжилась тут (https://zx-pk.ru/threads/32514-zpu-na-vektore.html?p=1108483&viewfull=1#post1108483), а теперь пришло время отделить ее от zpu8080.
Скомпилировал TJpgDec с использованием z88dk и такой вариант (https://disk.yandex.ru/d/jnt2qLTV_wCvQw) работает порезвее.
Лена - 2:19
Попугаи - 2:02
Резервы для ускорения еще есть.

[ivagor]

И для полного счастья цифры по z88dk+picojpeg.
Лена - 0:57
Попугаи - 1:11
Сильно быстрее, но чего мне это стоило. Чуть выражение посложнее и sccz80 начинает генерить пургу. С gcczpu8080 такого нет, баги из него давно вычистили. На мой взгляд если переносить на 8080 что-то сложнее hello world, то надо или ориентироваться на zpu или (если очень нужна скорость) быть готовым искать и обходить ошибки sccz80 из z88dk.

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

Можно позавидовать z80никам, у них есть sdcc. В процессе адаптации picojpeg там тоже нашлась ошибка, но ее скоро исправили, с z88dk такого ждать не приходится.

[Oleg N. Cher]

Правильно ли я понимаю, что код для 8080, сгенеренный zcc из z88dk, эффективнее, чем от gcczpu8080?
Кстати, если можно, пару слов о том, что такое gcczpu8080.

[ivagor]

Правильно ли я понимаю, что код для 8080, сгенеренный zcc из z88dk, эффективнее, чем от gcczpu8080?
По критерию скорости на данной задаче - да, но надо принимать во внимание, что zpu8080 - интерпретатор, а sccz80 генерирует нативный 8080 код. Зато zpu заметно опережает по критерию размера. Да и по скорости отставание совсем не на порядок, 3-5 раз на jpeg (при работе с 32 битными ближе к 3, при работе с 8-16 битными - ближе к 5). А на некоторых задачах (например мандельброт и пи) zpu8080 даже быстрее.

Кстати, если можно, пару слов о том, что такое gcczpu8080.
Репозиторий (https://gitlab.com/svofski/zpu8080/), тема на форуме (https://zx-pk.ru/threads/32514-zpu-na-vektore.html), думаю из этих ссылок в основном понятно, может и svofski дополнительно прокомментирует.

[ivagor]

Ассемблиризировал z88dk+picojpeg до уровня gcczpu8080+picojpeg
Лена - 0:32
Попугаи - 0:43
В итоге на мой взгляд пациент (jpeg на 8080) не совсем мертв, даже без полного перевода на асм.

[ivagor]

Раз sccz80 позволяет компилировать и для z80, то почему бы не попробовать. Эффект есть, но весьма небольшой: на 284 байта короче и на 3-4% быстрее. Надо принять во внимание, что я сравнил скорости работы вариантов для 8080 и z80 в конфиге вектора с z80 (в emu80, он поддерживает векторовское торможение для z80). Если сравнивать работу варианта для 8080 в конфигах 8080 и z80, то исполнение на z80 ускоряет (за счет mov r,r; inr/dcr) на 12-15%. Хорошо бы еще и sdcc сравнить с использованием асмовских подпрограмм, но еще одной адаптации под компилятор я пока не потяну, там другие правила передачи параметров, надо переделывать.

[ivagor]

Сравнил sccz80 в режиме z80 с sdcc z80 без ассемблерных процедур. sdcc примерно на 5% быстрее (тестировал в векторовском конфиге в emu80).

[Oleg N. Cher]

Рекомендую именно ZSDCC - ту версию SDCC, которая модифицирована командой z88dk. Там более расширенный набор правил для peephole-оптимизатора. На одном моём проекте я имею выигрыш между ZSDCC и SDCC в размере кода на ~1 Кб, что очень немало.

Да, используйте высокий --max-allocs-per-node40000
Лучше не ниже 20000. Хотя это серьёзно снижает скорость компиляции. У меня уже давно два набора скриптов - под отладочную компиляцию и под релизную.


IF EXIST .debug SET Opt=--max-allocs-per-node20
IF NOT EXIST .debug SET Opt=-SO3 --opt-code-size --max-allocs-per-node100000

[ivagor]

Хотя это серьёзно снижает скорость компиляции.
sdcc и без увеличения max-allocs-per-node сравнительно неторопливый.


Рекомендую именно ZSDCC
Не следил, насколько быстро обновляют ZSDCC вслед за SDCC, а это весьма важный момент, т.к. в том же picojpeg напарывался на ошибку компилятора, но к счастью ее вскоре поправили.

Еще немного про sccz80. Кроме 8080 и z80 он умеет компилировать и для 8085 с использованием недокументированных инструкций. К сожалению с опцией -m8085 опять возникают странные проблемы с невнятными сообщениями, я не стал бороться и сравнил более раннюю версию без ассемблерных вставок. Вариант для 8085 на 162 байта короче варианта для 8080 и на 1-2% быстрее. Сравнивал в конфиге 6128Ц в emu, если сравнивать 6128 с 06Ц, то выигрыш конечно больше за счет mov, inr/dcr и переходов.
Широта охвата процов это здорово, но лучше бы эту энергию пустили на исправление ошибок компилятора.

[Oleg N. Cher]

К сожалению, компилятор слишком сложная программа, чтобы развивать её безошибочно.
Я стараюсь и не жалею на это времени как можно более подробно и на как можно меньшем исходнике воспроизвести баг и донести до разрабов в виде тикета. Даже если мои проекты не взлетят, польза от этого будет другим юзерам. Всячески призываю репортить баги.
SDCC довольно стабильный, но не удивился бы какому-то багу в сложном коде со вложенными циклами. Такой баг и воспроизвести-то трудно - стОит убрать пару строчек кода, и он исчезает.

[ivagor]

Пример (https://disk.yandex.ru/d/mlnlyHls5kzGJw) цветного JPEGа в режиме 64 цвета (https://zx-pk.ru/threads/20688-256-tsvetnyj-graficheskij-rezhim-na-vektore-06ts.html?p=830223&viewfull=1#post830223) (2 бита/канал). На реале на элт будет мерцать, на жк скорее всего не будет, там хитро, а в эмуляторе лучше смотреть (https://zx-pk.ru/threads/20688-256-tsvetnyj-graficheskij-rezhim-na-vektore-06ts.html?p=1111091&viewfull=1#post1111091) в emu80. В процессе рисования выглядит странновато (2 картинки рисуются параллельно, одна с грубыми цветами, другая психоделическая), но когда нарисует перейдет в режим 64 цвета.

[KTSerg]

На реале ч/б элт действительно мерцает, как фпс не хватает. На жк телике мерцания нет, хотя есть какое-то "брожение", типа волны - не волны... но это понятно, что от телика зависит.
Жаль картинка слишком пёстрая и пиксели крупные, контрастные. Не позволяет реально оценить количество одновременно отображаемых цветов.

[ivagor]

Цвета лучше видно на вот этой штуке (https://zx-pk.ru/threads/20688-256-tsvetnyj-graficheskij-rezhim-na-vektore-06ts.html?p=830223&viewfull=1#post830223).

[ivagor]

8 оттенков желтого это хорошо, а 16 серого - лучше. Благодаря последним достижениям в исследовании оттенков серого в ч/б режиме стало возможно сделать соответствующую версию jpegа. В качестве примера (https://disk.yandex.ru/d/O5enItHVUsmxfQ) безотказная Лена.
75236
Можно посмотреть в эмуляторах VV или Emu80 (начиная с версии 40355) в ч/б режиме или на реалах (подходят и 06Ц и .02, 06Ц подходит чуть лучше).

[ivagor]

Раз скачал текущий z88dk, значит надо было попробовать собрать Лену. После небольшой доработки напильником собралось и решил оптимизировать ассемблерные процедуры. Получилось ускорить до 23 секунд, формально прогресс есть, но все равно слишком медленно.

[CodeMaster]

8 оттенков желтого это хорошо, а 16 серого - лучше.
А 50 ещё лучше, особенно если Лена безотказная.

[svofski]

8 оттенков желтого это хорошо, а 16 серого - лучше. Благодаря последним достижениям в исследовании оттенков серого в ч/б режиме стало возможно сделать соответствующую версию jpegа. В качестве примера (https://disk.yandex.ru/d/O5enItHVUsmxfQ) безотказная Лена.
75236
Можно посмотреть в эмуляторах VV или Emu80 (начиная с версии 40355) в ч/б режиме или на реалах (подходят и 06Ц и .02, 06Ц подходит чуть лучше).

Кстати в v06x-godot в наши дни можно выбрать шейдер bw.

[ivagor]

Про поддержку обесцвеченного режима в v06x я знал, но т.к. в отличие от Emu80 и VV у тебя оттенки серого не по схеме ч/б видеовыхода вектора, а по стандартной формуле (.1B+.3R+.6G), то я думал, что не подойдет. Но оказывается, что если для градиента всех оттенков серого действительно не подходит, то конкретные "универсальные" 16 цветов (1 (https://zx-pk.ru/threads/19774-vektor-06ts-emulyatsiya-tsvetovoj-palitry.html?p=1113412&viewfull=1#post1113412), 2 (https://zx-pk.ru/threads/33043-jpeg-8080.html?p=1113548&viewfull=1#post1113548)) более-менее подходят не только для 06Ц и .02, но и для стандартной формулы. Это очень здорово и резко увеличивает смысл использования этих цветов/оттенков. Оказывается с этой палитрой можно получить сравнительно равномерные 16 оттенков серого не только при подключении 06Ц и .02 к ч/б телевизору (или в VV и Emu80), но и при подключении 6128++ к ч/б ТВ и при подключении любого вектора к цветному ТВ с зажиманием цвета до 0 (или в v06x).