ZPU на Векторе

[svofski]

квазисокеты и квазитреды на дефайнах, слишком сложных для нормального человека и компилятора.

Это точно. Сатанинское изобретение.

[Advertiser]

[svofski]

Все-таки это был далеко не предел скорости ZPU. Теперь загрузка страницы 13сек, реакция на клик 1сек.

[NEO SPECTRUMAN]

Теперь загрузка страницы 13сек, реакция на клик 1сек.

и накой это надо?

[ivagor]

и накой это надо?

А зачем вообще заниматься ретрокомпьютерами?

[ivagor]

Благодаря zpu8080 теперь и 8080 может декодировать jpeg (используется TJpgDec). Практичным этот вариант для компов без (хотя бы) High Color и аппаратного умножения (без него очень медленно) не назовешь, но прикольно. Вектористам думаю будет приятно, что хотя и без хи- или тру колора, но на векторе выглядит сильно лучше, чем на большинстве других советских 8-биток.

[NEO SPECTRUMAN]

может декодировать jpeg

ФЕГНЯ
давай адаптируй mp4 плеер
который будет выдавать 0 FPS

шоб было

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

без него очень медленно

кстате время декодирования не озвучено
часы?
дни?

[svofski]

Нормальный такой precalc, ничего особенного =)

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

[ivagor]

Я не стал бы и z88dk совсем сбрасывать со счетов, пусть он немного игрушечный, но возможно picojpeg получится под него адаптировать.

[ivagor]

У тех, кто хочет побыстрее, есть довольно специфический вариант - заменить проц на z80 и воспользоваться sdcc. JPEG при этом резко ускорится, но надо отметить, что такой эффект будет не для всех программ, например intmand работает примерно одинаково в sdcc и gcc zpu8080.
В виндовом gcc освоил picojpeg, возможно он добавит прыти zpu, но это я смогу проверить не раньше субботы.

[ivagor]

Пара слов про (сравнительно) новую ветку FastImNoFlip, которая ориентирована на ускорение (за скорость приходится платить размером). Отличия от Master:
1. Модификация загрузки констант для более удобной реализации с использованием 8080. Это приводит к небольшому (несколько сотен байт для программ размером 20-25 Кб) увеличению сгенерированного zpugcc кода.
2. В начале body.inc есть несколько дефайнов. FastMUL и FastComparisons в комментариях особо не нуждаются, они сравнительно недорогие по размеру. Вот FastLoadSP, FastStoreSP и FastAddSP довольно большие - первые две примерно по килобайту, FastAddSP примерно полкило (в отличие от п.1 увеличивается размер run-time части, не размер генерирвемого компилятором кода). Наибольший эффект дает включение FastLoadSP, StoreSP поменьше, AddSP еще меньше.
3. Ускоренное деление. Тут редкий случай - сильно быстрее и меньше по размеру.
Пункты 2 и 3 в принципе можно перетащить и в Master (FastMUL уже там).
Пункты 1 и 2 (при включении всех дефайнов) ускоряют примерно на 10%. Деление в имеющихся примерах почти не задействовано, но там, где оно используется, стало быстрее на 20% (это без учета других ускорений).

Если неформально сравнить скорости zpu8080 и sdcc z80 в jpegах, то с tjpgd разница примерно в 4 раза, c picojpeg - примерно в 6 раз (в zpu8080 более эффективно реализуются 32 битные вычисления, а в sdcc z80 - 8 и 16 битные). Не так уж плохо для интерпретатора с 8080 против компилятора с z80, тем более в некоторых примерах (Мандельброт) ситуация для zpu8080 намного лучше, просто корректнее сравнивать по более сложным программам.