Это точно. Сатанинское изобретение.Цитата:
Сообщение от Error404
Вид для печати
Это точно. Сатанинское изобретение.Цитата:
Сообщение от Error404
Все-таки это был далеко не предел скорости ZPU. Теперь загрузка страницы 13сек, реакция на клик 1сек.
https://www.youtube.com/watch?v=tR0Pt9IzWmg
и накой это надо?Цитата:
Сообщение от svofski
А зачем вообще заниматься ретрокомпьютерами?Цитата:
Сообщение от NEO SPECTRUMAN
Благодаря zpu8080 теперь и 8080 может декодировать jpeg (используется TJpgDec). Практичным этот вариант для компов без (хотя бы) High Color и аппаратного умножения (без него очень медленно) не назовешь, но прикольно. Вектористам думаю будет приятно, что хотя и без хи- или тру колора, но на векторе выглядит сильно лучше, чем на большинстве других советских 8-биток.
Вложение 74490Вложение 74491
ФЕГНЯЦитата:
Сообщение от ivagor
давай адаптируй mp4 плеер
который будет выдавать 0 FPS :v2_lol:
шоб было
- - - Добавлено - - -
кстате время декодирования не озвученоЦитата:
Сообщение от ivagor
часы?
дни?
Нормальный такой precalc, ничего особенного =)
Все же сравнить с ACK когда-нибудь в будущем было бы интересно. С одной стороны ACK дает нативный код, с другой стороны мы знаем, что арифметика там при этом необязательно однозначно побеждает.
Я не стал бы и z88dk совсем сбрасывать со счетов, пусть он немного игрушечный, но возможно picojpeg получится под него адаптировать.
У тех, кто хочет побыстрее, есть довольно специфический вариант - заменить проц на z80 и воспользоваться sdcc. JPEG при этом резко ускорится, но надо отметить, что такой эффект будет не для всех программ, например intmand работает примерно одинаково в sdcc и gcc zpu8080.
В виндовом gcc освоил picojpeg, возможно он добавит прыти zpu, но это я смогу проверить не раньше субботы.
Пара слов про (сравнительно) новую ветку 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 намного лучше, просто корректнее сравнивать по более сложным программам.