JPEG 8080

[ivagor]

Тема началась здесь и продолжилась тут, а теперь пришло время отделить ее от zpu8080.
Скомпилировал TJpgDec с использованием z88dk и такой вариант работает порезвее.
Лена - 2:19
Попугаи - 2:02
Резервы для ускорения еще есть.

[Advertiser]

[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.

Репозиторий, тема на форуме, думаю из этих ссылок в основном понятно, может и 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 довольно стабильный, но не удивился бы какому-то багу в сложном коде со вложенными циклами. Такой баг и воспроизвести-то трудно - стОит убрать пару строчек кода, и он исчезает.