Просмотр полной версии : ZPU на Векторе
Заголовком темы "современная разработка под Вектор" навеяло. Делюсь смелым экспериментом выходного дня: виртуальная машина, реализующая ZPU, исполняющая на Векторе программу, собранную GCC.
Ссылки:
прекрасм (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/44ed8cb25e77bb8cbc770d372e7dde61/raw/e44a3557cbf450f2d2f122beee3cd9452e8e1a0e/zpu8080.asm) (жать RUN)
gist (https://gist.github.com/svofski/44ed8cb25e77bb8cbc770d372e7dde61) — все файлы
Все честно, хоть и немного медленно. Например, xprintf() взят из предыдущих проектов без изменений.
Реализация ZPU самая минимальная из всех возможных, то есть половина инструкций эмулируется самим ZPU. Если реализовать полный набор инструкций, будет пободрее.
Для сборки под ZPU, например если кто-нибудь захочет запустить в этой системе эмулятор 8080 написанный на C++, потребуется тулчейн (https://github.com/zylin/zpugcc).
NEO SPECTRUMAN
01.12.2020, 18:00
и шо это за порнография? о_О
де скриношоты?
- - - Добавлено - - -
так поинмаю это чисто интерпретатор проца?
ничего готового запустить нельзя?
и единственное сомнительное преимущуство что под оно есть GCC?
- - - Добавлено - - -
и немного медленно.
а для чего это? (про критичность к скоросте)
; invert each byte and store them in reverse order -> total flip
mov h, b
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
pop h \ mov m, a
mov h, c
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
pop h \ mov m, a
mov h, d
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
pop h \ mov m, a
mov h, e
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
dad h \ rar \ dad h \ rar \ dad h \ rar \ dad h \ rar
pop h \ mov m, a
нельзя это делать таблично?
нельзя это делать таблично?
Все можно. У тебя же есть весь текст.
NEO SPECTRUMAN
01.12.2020, 18:15
У тебя же есть весь текст.
он на 8080 а я его с трудом понимать...
а конвертение в z80 мнемоники всякими тулзами я так и не освоил
на счет весь не уверен
тк этот gist.github у меня отображется не лучшим образом
если все и сразу в одном .аsm-е то весь
Все можно. У тебя же есть весь текст
и я еще вникаю в целесобразность
Целесообразность точно не в быстродействии.
Ускорение реализации инструкций дело благородное, но пока скорее бесполезное. Лучше помогает добавление недостающих инструкций. Например, я сейчас добавил callpcrel, poppcrel, neqbranch, eq, call — и время исполнения теста сократилось с 3:30 до 2:00. Пока ленюсь добавлять группу lessthanorequal. div/mul/mod тоже должны помочь, но без доработки newlib не все так однозначно.
Почему не отображается gist? Я могу запостить куда-нибудь еще, если почему-то не достучаться до github-a.
NEO SPECTRUMAN
01.12.2020, 18:48
Почему не отображается gist?
он отображается
просто выглядтит все как помойка (они ж там до обновлялись до чертиков и на старых браузерах оно уже не фурычит)
Понятно. В общем там один ассемблерный файл, остальное — это чтобы скомпилировать то, что виртуальная машина будет исполнять.
NEO SPECTRUMAN
01.12.2020, 19:09
Целесообразность точно не в быстродействии.
ну если сразу не закладывать быстродействие
то так они и останется
потом делать повтороно туже работу уже не хочетсо и все так и остается :)
ld a, b
cp $04 \ jz insn_poppc
cp $08 \ jz insn_load
cp $0c \ jz insn_store
cp $02 \ jz insn_pushsp
cp $0d \ jz insn_popsp
cp $05 \ jz insn_add
cp $06 \ jz insn_and
cp $07 \ jz insn_or
cp $09 \ jz insn_not
cp $0a \ jz insn_flip
cp $0b \ jz insn_nop
cp $00 \ jz insn_break
это надо брать и сразу переписывать под sjasm+adp
под быстрые таблицы переходов (пока немного кода)
чтоб делать
ld l,a ;4
ld h,tab ;7
ld h,(hl) ;7
jp (hl) ;4
декодер интерпретатора шняга прожорливая
и его даже небольшое ускорение таки ощутимо
- - - Добавлено - - -
а можно готовый rom из того сорца?
у меня и онлайнасм не фурычит
Заведи уже себе современный браузер. Тебе мнемоники не те, браузер не тот, процессор не тот, асм не фурычит, гитхаб не открывается, переписывать надо под sjasm. Мне переписывать под sjasm ничего не надо, хотя спасибо конечно.
Вот собранный zpu8080.com (http://sensi.org/~svo/b/zpu8080.com). Кроме того, исходник можно собрать tasm-ом.
Чтобы запустить в эмуляторе понадобится еще засунуть .com файл на образ диска с МикроДОС T34. В эмуляторе VV можно подключить каталог как диск. Ну или переделать консольный вывод под любимую систему. Там из всех внешних связей только один putchar. Например, чтобы запустить в эмуляторе https://www.tramm.li/i8080/emu8080.html достаточно изменить call putchar на out 1.
Я знаю, что декодер прожорливый и неэффективный. Это вопрос приоритетов в распределении ресурсов, прежде всего моего времени и внимания. По-моему ты не представляешь о каком порядке быстродействия тут идет речь. Мы говорим о printf(), который печатает на экран со скоростью телетайпа. Посмотри на сишную программу в исходнике и оцени, что она исполняется сейчас две минуты.
NEO SPECTRUMAN
01.12.2020, 20:18
Заведи уже себе современный браузер.
современный это сферических ахтунх
придачу современных под ХРю кот наплакал...
- - - Добавлено - - -
переписывать надо под sjasm
я уже переписал :v2_lol:
теперь сверяю бинарники которые дико отличаются
и втыкаю как на ваших векторах что либо запускают с дисководов :)
Бинарники наверное отличаются потому, что ты сконвертил не ту версию, которая у меня. Я же продолжаю с ней работать.
и втыкаю как на ваших векторах что либо запускают с дисководов
Это крайне неудобно, но для консольного вывода иначе пришлось бы приделывать полмикродоса.
Надеюсь, что твой браузер сможет осилить скачивание образа отсюда: https://github.com/svofski/vector06js/blob/master/fdd/os-t34.fdd.
В VirtualVector подключаешь его как диск A, жмешь F11, потом F12. Как диск B подключаешь каталог с .com файлом.
Вектор тут на самом деле не нужен. Ты можешь переделать консольный вывод, который тут все равно на жовке прикручен, и запускать в любой системе.
NEO SPECTRUMAN
01.12.2020, 20:29
В VirtualVector
ну все это я и сам осилил
только взял то сюда
http://sensi.org/scalar/ware/763/
но вот чота этот микродос не понимает никаких dir-ов :)
чтоб удостоверитсо
- - - Добавлено - - -
ага твой бинарник запустил :v2_dizzy_roll:
- - - Добавлено - - -
свой бинарник тоже запустил :v2_dizzy_roll: :v2_dizzy_roll:
Там все команды одной буквой. Дир - это просто D.
NEO SPECTRUMAN
01.12.2020, 21:48
спектрум же (пентагон с подключаемой ram0)
https://jpegshare.net/images/95/f4/95f4eb92e34a4860a3259c00230edbd1.png https://jpegshare.net/images/25/c4/25c454839facf0c80501f589e1aa991e.png
- - - Добавлено - - -
https://anonfiles.com/D1u8T2uap6/zpu_r0001_trd
https://dropmefiles.com.ua/ru/yazU8L
http://www.mediafire.com/file/4rsw4xm4m1h9q0l/zpu_r0001.7z/file
"консоль" с nsid-а
поэтому никаких управляющих кодов она не понимаит :)
да и кодировка не та
загружалка файлов неполноценная
больше чем $1000 байт загрузится но не переложиться по адресу $0000
тк r0001
У тебя же есть весь текст.
покурил сорец
переписывать нужно много
декодер сильно не рационально написан и тратит кучу времени в пустую
мне проще было бы написать с нуля
чем выпилить весь мусор от сюда
но зачем?
на этом гуляние во всякие там zpu я прекращаю :v2_dizzy_hello: :v2_dizzy_bye:
Круто, что у тебя получилось запустить на Спектруме!
декодер сильно не рационально написан и тратит кучу времени в пустую
Декодер занимает 40 строк из 800. Ты на мелочи распаляешься преждевременно, особенно по части классификации мусора.
Я сегодня добавил нативную реализацию многих инструкций, которые съедали время. Тест исполнялся за 3:30 сегодня утром, а сейчас за 0.59. Декодер 12 ядерных инструкций я переделал на диспатч на закуску. Это дало в лучшем случае секунду, что в моем случае с ручным секундомером просто погрешность измерения. Наверняка улучшение есть, но по сравнению с ускорением в 3.5 раза, согласись, не так существенно.
Я обновил gist и ссылку на прекрасм в оригинальном сообщении. Еще не хватает mult и может быть div/mod, но уже есть смысл заниматься более низкоуровневой оптимизацией.
Спасибо ivagorу за операции знакового и беззнакового деления!
Любопытно: стандартный ZPU предусматривает только операции DIV и MOD со знаком. А xprintf(), например, делит без знака. Поскольку такой операции в машине не определено, деление без знака транслируется в вызов __udivmodsi3, который работает так же медленно, как если бы никаких div и mod не было. Самым простым оказалось добавить инструкции UDIV, UMOD с кодами 32, 33 и добавить их поддержку в binutils и gcc. Это может быть интересно и тем, кто использует ZPU для более практичных целей.
Тесто (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/44ed8cb25e77bb8cbc770d372e7dde61/raw/85efed63817688d4191295f671e612663c01e486/zpu8080.asm) теперь проскакивает за 19 секунд.
Невероятными усилиями ivagora и меня время выполнения целочисленного Мандельброта (https://gist.githubusercontent.com/svofski/44ed8cb25e77bb8cbc770d372e7dde61/raw/faeedddb4ae276a79a279a81af44b233b47bca0a/intmand.c) доведено до 1ч 5минут.
Картинка отличается от стандартной. Я сделал ошибку, когда правил код, но картинка получилась интересней "правильной" версии и я решил ее оставить.
Прекрасм (https://svofski.github.io/pretty-8080-assembler/?https://gist.githubusercontent.com/svofski/44ed8cb25e77bb8cbc770d372e7dde61/raw/804300def4081d4d52055cc4572b1230766d6a1f/intmand.asm)
Скриншот от ivagora:
https://i.imgur.com/rilxqpO.gif
Давно не было новостей из мира zpu8080. Между тем ivagor и я даром времени не теряли, всячески его совершенствовали и ускоряли. В дополнение к старым тестам появилось еще несколько примеров его использования.
Наш главный киберпанковый бенчмарк — quicksort демо. Массив данных 4096 байт держится прямо в экранной области для зрелищности, где и сортируется. Справа — стек ZPU. Красный — нативный стек 8080. После окончания сортировки данные перетасовываются и сортировка запускается заново. Демку можно запустить в браузере: sort4k (http://sensi.org/scalar/vector06js/?roms/sort4k.rom).
https://i.imgur.com/6WEDJkK.png
Из-под Микродоса теперь можно поиграть в Star Trek:
https://i.imgur.com/aVBcTeU.png
В пока секретной сборке v06x под Линуксом Вектор стал интернет-вещью. На нем работает веб-сервер, который отдает страничку с интерфейсом, через который можно управлять светодиодом РУС/LAT. Небольшое демо:
https://youtu.be/Ylp_YzykKCY
Чтобы интернеты на Векторе вышли из виртуальности понадобится сетевая плата, этого пока нет. Сейчас она эмулируется довольно условно потоком байт на порту ПУ.
Бинарники + образ fdd в зипе:
https://gitlab.com/svofski/zpu8080/-/releases/demo1
Сорцы.
https://gitlab.com/svofski/zpu8080/-/tree/master
Можно собрать самому. Под линуксом это очень просто, нужен только docker.io. Этим же докером можно воспользоваться просто для сборки zpugcc. Под виндой это тоже можно, но плавно.
В принципе ничто не мешает запустить zpu8080 на любом другом компьютере на кр580. С наступающим!
вовсе ничего не понял
нагуглил тако на ZPU —-
Информационный гуманитарный портал "Знание. Понимание. Умение"
и на этом все
а, еще жилин зпу
но причем здесь вектор виртуальная машина и gcc
zx_, 8080 эмулирует процессор ZPU. Это виртуальная машина. Код для ZPU компилируется gcc.
Error404
26.12.2020, 01:13
В пока секретной сборке v06x под Линуксом Вектор стал интернет-вещью. На нем работает веб-сервер, который отдает страничку с интерфейсом, через который можно управлять светодиодом РУС/LAT. Небольшое демо:
https://youtu.be/Ylp_YzykKCY
Чтобы интернеты на Векторе вышли из виртуальности понадобится сетевая плата, этого пока нет. Сейчас она эмулируется довольно условно потоком байт на порту ПУ.
Делали с b2m UIP на вполне реальной RTL8019AS (эмулируется в моем эмуляторе и башкирии). Раз тут фишка в виртуальной машине ZPU (я правильно понимаю - там что-то вида интерпретатора байткода? который можно собирать gcc), то почему бы просто не взять те модули (там есть и собственно эмуляция устройства 8019 - на TAP-адаптер, т.е. через бридж можно штатно ходить в этот эмулятор по IP откуда угодно из Инета, и модуль для драйвера uIP есть).
- - - Добавлено - - -
А вообще, эмпирически - на сколько код в ZPU медленнее выполняется, чем такой же алгоритм, собранный в нативный бинарный код?
Версия для Z80 была бы быстрее, на сколько (возможно есть какие-то вещи которые лучше ложатся на индексные регистры или работу с массивами от Z80)?
А вообще, эмпирически - на сколько код в ZPU медленнее выполняется, чем такой же алгоритм, собранный в нативный бинарный код?
По производительности есть смысл сравнивать с Бейсиком. Мы сравнивали на примере Мандельброта и Эратосфена. ZPU побеждает. Предположительно за счет того, что Бейсик на Векторе не умеет в целые. Реализацию квиксорта на бейсике я бы посмотрел.
Сравнивать с собранным нативным кодом трудно по причине отсуствия того, чем собирать нативный код под 8080. Я знаю, что ACK вполне умеет собирать под 8080, но пока руки не дошли его завести. В общем не надо быть ракетным хирургом, чтобы предсказать, что нативный код с эмулируемым никто не перепутает =) Сравнить было бы интересно еще и компактность.
Я не спец по Z80, но кажется у него много дополнительных регистров. Благодаря дополнительным регистрам версия для Z80 может быть сделана ощутимо быстрее. У ZPU всего два хардовых регистра -- SP и PC. На 8080 приходится их все время класть и доставать из памяти, что конечно же медленно.
Делали с b2m UIP на вполне реальной RTL8019AS (эмулируется в моем эмуляторе и башкирии). Раз тут фишка в виртуальной машине ZPU (я правильно понимаю - там что-то вида интерпретатора байткода? который можно собирать gcc), то почему бы просто не взять те модули (там есть и собственно эмуляция устройства 8019 - на TAP-адаптер, т.е. через бридж можно штатно ходить в этот эмулятор по IP откуда угодно из Инета, и модуль для драйвера uIP есть).
Да, почему бы просто не взять. А где бы на это посмотреть?
Это немного оффтоп в этой теме, но когда-нибудь увидеть FUZIX на Векторе мне тоже было бы интересно.
svofski, ZPU этож java практически получается
Пару слов тоже хочу написать. Сначала думал, что zpu это интересный, но совершенно бесполезный (даже по ретрокомпьютерным меркам) курьез, а в итоге получилась на удивление неплохая штука. Хотелось бы побыстрее, но и в том виде как есть возможность использования современного компилятора доставляет. Ну и насчет своего "вклада" - думаю никто не сомневается, что все сделал svofski, но я поучаствовал в оптимизации.
NEO SPECTRUMAN
26.12.2020, 11:31
а в итоге получилась на удивление неплохая штука.
и чем?
и чем?
И имеющимися примерами работы (для uip просто нет альтернатив на векторе) и потенциальными возможностями.
Реализацию квиксорта на бейсике я бы посмотрел.
Проблема с рекурсией, если на basic 2.5, то нужно изворачиваться.
хе
This is a ZPU virtual machine written in Intel 8080 assembly. It executes normal ZPU code on a 8080 computer with 64K RAM. The primary target is Vector-06c. It is pretty slow, but allows writing C++ code for a 8080 computer, which is cool. Example projects include visual quicksort demo, a port of Star Trek game and an IoT-style webserver using uIP TCP/IP stack (demo video)
на железном векторе можно азернет с spi - в дип28 чипы есть
или вифи - к вектору последовательный порт
Error404
26.12.2020, 13:46
Да, почему бы просто не взять. А где бы на это посмотреть?
Вот тут исходники:
- эмуляция RTL8019AS (https://github.com/serge-404/OriZEmu/blob/master/mod8019as.pas)
- обслуга Ethernet-L2-TAP (https://github.com/serge-404/OriZEmu/blob/master/EthThrd.pas) (Pascal/Windows, но в целом понятно чокак, я на Винде использовал TAP-адаптер от OpenVPN - он при желании отдельно ставится)
- uIP через RTL8019AS (https://github.com/serge-404/AltairDOS/tree/master/App/source/uIP) - в модуле etherdev.* в zip-e
RTL8019AS была в свое время выбрана т.к. кроме того что это ISA-адаптер (и до сих пор продается на Али как в чипах так и девбордой), оно еще широко распространено в мире 8-бит, например на MSX на этом чипе выпускались картриджи сети, и была кучка софта, который b2m помнится даже запускал в своем эмуляторе в режиме MSX (в моем только Орион) и оно работало вот так вот через TAP
- - - Добавлено - - -
Логика такая: из пакета OpenVPN создается (инсталлится) TAP-адаптер, из этого ТАР-адаптера и физического адаптера средствами ОС (я использовал винду) создается bridge (мост), на котором назначается IP (через который Винда ходит в Инет, пускай и далее через NAT). В эмуляторе указывается использовать TAP-адаптер в качестве сетевой платы (это в Ethernet-L2-TAP), и на нем ставится IP из той же подсети, что и хостовая Винда. Сразу эмулятору становятся доступны все хосты в локальной подсети в обе стороны (клиент-сервер), а уж Инет сильно зависит там как настроено - изнутри наружу клиентами пойдет нормально, а обратно (если в эмуле запускать какой-то сервер слушающий IP), то тут уже сложнее схема, но в принципе реализуемо.
Проблема с рекурсией, если на basic 2.5, то нужно изворачиваться.
Рекурсивный алгоритм превращается в итеративный с помощью стека, а стек делается массивом. Но выразительные средства классического бейсика для этого крайне плохо подходят.
- - - Добавлено - - -
zx_, это похоже на jvm, тоже стековая машина. Но ZPU проще. Он хоть и софтовый, но разрабатывался для запихивания в уголок маленькой fpga и даже 8080 может его эмулировать с терпимой скоростью, хотя в этом есть что-то от Speed 3 (https://youtu.be/4uOX_hbkAMc?t=125).
- - - Добавлено - - -
Error404, спасибо! Загляну в эмуляцию RTL8019AS.
uIP собирается HiTech-C для Z80? Утверждается, что FUZIX собирается ACK-ом для 8080, но это надо сильно запариться, чтобы проверить.
Заглянул чуть чуть в драйвер uIP. Лучше бы конечно спрятать от Вектора все эти потроха, незачем ему возиться с тьмой регистров, даже если это будет не ZPU, а нативный код, все равно лишнее это. Есть два варианта: либо через ПУ перекачиваются пакеты байт за байтом (как сейчас у меня в эмуляторе), либо ethernet становится как второй кваз и буфер отображается в окно памяти. Первый проще, можно сделать систему на основе verilog-ethernet (https://github.com/alexforencich/verilog-ethernet/), сделать интерфейс со стороны Вектора максимально простым и втыкать это в ПУ.
Error404
26.12.2020, 19:00
uIP собирается HiTech-C для Z80? Утверждается, что FUZIX собирается ACK-ом для 8080, но это надо сильно запариться, чтобы проверить.
Да, я использовал HiTech-C для Z80 для uIP и для UZIX (не FUZIX). Компилер не самый свершенный (если сравнивать с современными работающими на PC), но из тех что работают на Z80 - лучший. Но он например не осиливает сложные дефайны, из-за чего мне пришлось остановиться на uIP v0.9, т.к. в 1.0 Дункель вместо православно-посконного case (который по сути и есть его псевдомультизадачность в uIP и Contiki) присочинил квазисокеты и квазитреды на дефайнах, слишком сложных для нормального человека и компилятора. :)
FUZIX вроде же собирается SDCC определенной промежуточной версии с определенными фиксами? ACK для меня вообще темная лошадка, вроде он есть у меня, но никаких проектов на нем не видел.
Заглянул чуть чуть в драйвер uIP. Лучше бы конечно спрятать от Вектора все эти потроха, незачем ему возиться с тьмой регистров
Большое количество регистров используется один раз при инициализации драйвера, а дальше только чтение статуса и чтение-запись кольцевого буфера, которая управляется очень небольшим количеством регистров. Строго говоря, все эти процедуру вообще можно вынести в движок ZPU, и вызывать их с одним-двумя параметрами, как это наверняка аналогично сделано и для консоли. Ну т.е. драйвер сетевухи подключать к движку, а не компилить целиком в ZPU-байткод (в нем только 3 вызова: init,send,get - какие и нужны для uIP)
квазисокеты и квазитреды на дефайнах, слишком сложных для нормального человека и компилятора.
Это точно. Сатанинское изобретение.
Все-таки это был далеко не предел скорости ZPU. Теперь загрузка страницы 13сек, реакция на клик 1сек.
https://www.youtube.com/watch?v=tR0Pt9IzWmg
NEO SPECTRUMAN
31.12.2020, 01:59
Теперь загрузка страницы 13сек, реакция на клик 1сек.
и накой это надо?
и накой это надо?
А зачем вообще заниматься ретрокомпьютерами?
Благодаря zpu8080 теперь и 8080 может декодировать jpeg (используется TJpgDec (http://elm-chan.org/fsw/tjpgd/00index.html)). Практичным этот вариант для компов без (хотя бы) High Color и аппаратного умножения (без него очень медленно) не назовешь, но прикольно. Вектористам думаю будет приятно, что хотя и без хи- или тру колора, но на векторе выглядит сильно лучше, чем на большинстве других советских 8-биток.
7449074491
NEO SPECTRUMAN
24.01.2021, 15:07
может декодировать jpeg
ФЕГНЯ
давай адаптируй mp4 плеер
который будет выдавать 0 FPS :v2_lol:
шоб было
- - - Добавлено - - -
без него очень медленно
кстате время декодирования не озвучено
часы?
дни?
Нормальный такой precalc, ничего особенного =)
Все же сравнить с ACK когда-нибудь в будущем было бы интересно. С одной стороны ACK дает нативный код, с другой стороны мы знаем, что арифметика там при этом необязательно однозначно побеждает.
Я не стал бы и z88dk совсем сбрасывать со счетов, пусть он немного игрушечный, но возможно picojpeg (https://github.com/richgel999/picojpeg) получится под него адаптировать.
У тех, кто хочет побыстрее, есть довольно специфический вариант - заменить проц на z80 и воспользоваться sdcc. JPEG при этом резко ускорится, но надо отметить, что такой эффект будет не для всех программ, например intmand работает примерно одинаково в sdcc и gcc zpu8080.
В виндовом gcc освоил picojpeg, возможно он добавит прыти zpu, но это я смогу проверить не раньше субботы.
Пара слов про (сравнительно) новую ветку FastImNoFlip (https://gitlab.com/svofski/zpu8080/-/tree/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 намного лучше, просто корректнее сравнивать по более сложным программам.
Error404
06.03.2021, 11:20
Будет ли версия для CP/M?
С заменой модуля с фонтами/цветами/опросами на стандартную STDIO консоль (через регистры ВМ)?
А то и может и с вводом/выводом на привод через BDOS/BIOS (через регистры ВМ)?
- - - Добавлено - - -
Без этого как-то несерьезно :) Даешь энтерпрайз 70х!
- - - Добавлено - - -
Вообще было бы круто у движка наращивать обслуживаемые регистры внешними модулями пользователя. Захотел нативную сетевуху для uIP - написал модуль
Будет ли версия для CP/M?
В каком смысле? В качестве целевой платформы CP/M был с самого начала (и есть до сих пор), а сам gcc компилирующий в CP/M представляется чем-то совершенно невероятным.
Error404
06.03.2021, 15:20
В каком смысле? В качестве целевой платформы CP/M был с самого начала (и есть до сих пор), а сам gcc компилирующий в CP/M представляется чем-то совершенно невероятным.
Насколько я вижу в коде, глянув сильно по диагонали, там какой-то самодеятельный кусок кода для вывода на экран с покраской цветом и фонтами. Какое же это CP/M? ORG 100H это еще не CP/M. Либо я что-то недопонял, тогда прошу пояснить :)
Надеюсь svofski не будет сильно против, что я лезу.
Там два варианта - или cp/m или голый вектор. Самодеятельная покраска это векторовский вариант.
CP/M не сильно развит, фактически все ограничено консольным вводом-выводом. Работы с файлами, например, нет. Протащить можно что угодно, просто охоты это делать пока ни у кого не было.
Error404
07.03.2021, 00:39
CP/M не сильно развит, фактически все ограничено консольным вводом-выводом. Работы с файлами, например, нет. Протащить можно что угодно, просто охоты это делать пока ни у кого не было.
Ну он хоть в каком-то виде есть как бинарник? Чтоб например запустить какой-то уже скомпилированный простейший пример на Орионе в CP/M? Для ознакомления. Нечто вида
zpu.com hello.zpu
Ведь CP/M на то и CP/M чтобы бинари были совместимы.
Т.к. то что я вижу например в https://gitlab.com/svofski/zpu8080/-/tree/FastIMnoFlip - там только фрагменты вида "ORG 100 / LDIR BEGZPU / JP BEGZPU " с несуществующими иннклюдами и отсутствием упоминаний о последовательности сборки самого ZPU.
- - - Добавлено - - -
А уж дальше думать как собрать сам ZPU нативно в СP/M. Вполне посильная задача для M80, зачем все эти TASM ненашенские :)
Ну он хоть в каком-то виде есть как бинарник? Чтоб например запустить какой-то уже скомпилированный простейший пример на Орионе в CP/M?
В репозитории 7 примеров, из них 5 компилируются в cp/m-овские comы: hellozpu.com, intmand.com, sieve.com, startrek.com, uip.com. Для uip нужна специальная поддержка, а вот остальные можно запустить в любом cp/m (еще насчет startrek уверен не на 100%, но скорее всего), лишь бы памяти хватало. Бинарники (несколько устаревшие на сегодняшний день) есть тут (https://gitlab.com/svofski/zpu8080/-/releases).
- - - Добавлено - - -
А уж дальше думать как собрать сам ZPU нативно в СP/M. Вполне посильная задача для M80, зачем все эти TASM ненашенские
Runtime часть можно адаптировать для сборки с использованием любого асма 8080, в т.ч. и M80. Зачем делать это в cp/m мне не очень понятно (это усложнит сборку), zpugсс все равно будет работать в linux (или в win10 в докере или хоть где в виртуальной машине с linux). Компромиссный вариант - использовать что-то вроде адаптации M80 для win b2mа, скорее всего его вариант можно собрать и для linux (если он захочет).
Деление в имеющихся примерах почти не задействовано, но там, где оно используется, стало быстрее на 20% (это без учета других ускорений).
Для оценки деления попробовал расчет пи по формуле Гаусса. Модернизированное деление ускоряет на 34%!
Error404
07.03.2021, 12:43
В репозитории 7 примеров, из них 5 компилируются в cp/m-овские comы: hellozpu.com, intmand.com, sieve.com, startrek.com, uip.com. Для uip нужна специальная поддержка, а вот остальные можно запустить в любом cp/m (еще насчет startrek уверен не на 100%, но скорее всего), лишь бы памяти хватало. Бинарники (несколько устаревшие на сегодняшний день) есть тут (https://gitlab.com/svofski/zpu8080/-/releases).
Runtime часть можно адаптировать для сборки с использованием любого асма 8080, в т.ч. и M80. Зачем делать это в cp/m мне не очень понятно (это усложнит сборку), zpugсс все равно будет работать в linux (или в win10 в докере или хоть где в виртуальной машине с linux). Компромиссный вариант - использовать что-то вроде адаптации M80 для win b2mа, скорее всего его вариант можно собрать и для linux (если он захочет).
Кажется я понял. Движок ZPU компилируется в каждый COM?
Для оценить сойдет, но надо переделывать на запуск движка ZPU с параметром выполняемого файла а в последствии возможно и посадки движка в теневом ОЗУ как расширения ядра ОС. Т.к. странно выглядит - как например JRE компилировать в каждый jar или BDOS/BIOS CPM включать в каждый COM. Вообще конечно подход имеет право на существование, в UZIX так делали с эмулятором CP/M, но я переделал на отдельный эмулятор и стало удобнее.
М80 мне привычен синтакисом (и вообще сделан более по людски чем тасм, за исключением всякого ненужного типо прочих платформ) и прекрасно работает в консоли винды с локальными файлами винды в правильном эмуляторе CP/M. Т.е. никакого проигрыша по удобству. Используя M80 всегда остается опция нативной сборки на Орионе или использования lib-ов М80 в CPM-овских С и Pascal, чего не будет в TASM.
gcc тоже есть под виндой в cygwin и подобных mingw. Зачем его тащить в контейнеры - сходу тоже не понятно (кроме желания сделать стильномодномолодежно). Называя вещи своими именами, Linux по отношению к 8бит весьма неудобен (и никогда удобен не будет). Т.е. можно попробовать сделать полный тулчейн на винде.
Да уж. Вот так начнешь и получается такая куча работы на переделывание, что глаза боятся. :) Но бинари надо будет попробовать, т.к. штука прикольная уже сама по себе.
Еще опция если движок будет отдельно от байт-кода - можно будет один и тот же байт-код приложений запускать и на 8080 и на Z80 и на 6502 к примеру (просто у у каждого будет свой runtime-движок ZPU)
Движок ZPU компилируется в каждый COM?
Да
gcc тоже есть под виндой в cygwin и подобных mingw. Зачем его тащить в контейнеры - сходу тоже не понятно (кроме желания сделать стильномодномолодежно).
Есть и он даже компилирует. То, что у меня не получилось скомпилировать виндовым вариантом ничего подходящего для zpu8080 - это ладно. Но у svofski тоже не совсем получилось, хотя он всерьез этим не занимался и если бы занялся, то наверняка смог бы. Есть еще один момент - к zpugcc для zpu8080 добавляется несколько патчей, без которых в принципе можно жить, но будет грустновато.
Еще опция если движок будет отдельно от байт-кода - можно будет один и тот же байт-код приложений запускать и на 8080 и на Z80 и на 6502 к примеру
При компиляции отдельные zpuшные бинарники создаются и для них можно написать запускалки для всяких разных процов.
Какие плюсы у текущего подхода (код zpu + runtime zpu8080 в одном флаконе):
1. При компиляции можно задать опции и убрать не нужные для данной программы фичи из runtime части. Или включить все опции и получить программу побыстрее, но и пожирнее.
2. Можно компилировать не только в com для cp/m, но и в rom для запуска на голом векторе.
3. Для человека, который не знает ничего про zpu, но знаком с cp/m проще запустить .com
У отдельной запускалки есть свои плюсы и если кто-нибудь сделает (что сравнительно просто), то это будет здорово.
gcc тоже есть под виндой в cygwin и подобных mingw. Зачем его тащить в контейнеры - сходу тоже не понятно (кроме желания сделать стильномодномолодежно). Называя вещи своими именами, Linux по отношению к 8бит весьма неудобен (и никогда удобен не будет). Т.е. можно попробовать сделать полный тулчейн на винде.
Потому что так мне проще. Я живу под линуксом. ivagor, который заинтересовался проектом и сразу принял в нем очень активное участие, под виндой. Dockerfile это рецепт, который на любой машине позволяет развернуть все зависимости по простому и понятному рецепту так, что оно будет повторяемо независимо от хоста. Так у нас получилось работать над одним проектом под разными системами, не тратя время на треш типа gcc под виндой. Вот зачем мне тратить неделю времени на то, чтобы собрать zpugcc под виндой? Нету у меня этого времени и удовольствия я от этого не получу.
Про то, что сборка через make — это стильномодномолодежно, я думаю про это было бы приятно послушать дедушкам—изобретателям юниксового тулчейна. Жаль не все из них уже живы.
Но вообще я ничего против сборки под виндой не имею. Так же как и против еще многих вещей, которых "не хватает" — та же работа с файлами. Сорцы открыты специально для того, чтобы можно было доделать то, чего нет. Вот ворчать и доказывать мне, что Линукс — это почему-то неудобно по отношению к 8бит, смысла нет никакого.
Что до отдельной запускалки байткода — это можно, но требует усилий в той области, которая никому пока не была интересна. Сейчас сборка каждого индивидуального примера затачивает рантайм под себя через дефайны. Например куча всякой ерунды сделана для uIP, но она совершенно не нужна Стар Треку. И от этого зависит распределение памяти. Получается, что если делать хорошо, надо угрохать уйму времени на то, чтобы сделать рантайм конфигурируемым в рантайме. На это просто не хватает ни желания ни времени. А проект вообще задумывался скорее как шутка.
Error404
09.03.2021, 21:51
Шутка затянулась :)
Ладно, не ворчи, я просто поделился фантазиями на тему.
Извини =)
Шутка далековато зашла и правда. Но мне-то интересней процесс, чем результат, и было прикольно. Но кто знает, что из этого получится. Например кто-нибудь, кто раньше думал, что gcc для 8080 не нужен потому что всегда можно заэмулировать какой-нибудь zpu, посмотрит на это и скажет — "ну все, терпенье мое лопнуло, пойду ретаргетить gcc на 8080". И у нас будет gcc для 8080. Опять же в процессе я открыл для себя, что ACK — не какой-то дремучий монстр, а совершенно юзабельный компилятор почти современного Си для 8080.
Из серии "А мужики-то не знают". Цитата оттуда (https://www.specnext.com/forum/viewtopic.php?f=15&t=1864): "Nobody is working on C++ for 8-bit machines". svofski может гордиться.
Бытует заблуждение, что C++ каким-то особенным образом непригоден для маленьких систем. Как правило люди, которые его распространяют, просто не очень хорошо понимают, что такое C++.
Похвастаюсь jpegовскими достижениями. Перешел на picojpeg, оптимизировал сишную часть + допинг в виде ассемблерных процедур, в итоге (сравнение с выложенными бинарниками (https://zx-pk.ru/threads/32514-zpu-na-vektore.html?p=1100823&viewfull=1#post1100823)):
Желтая Лена 7:04->4:14
Цветные попугаи 7:04->5:16
К дискуссии об интегрированном runtime/отдельной запускалке. Для цветной версии пришлось кастомизировать runtime, а то со всеми включенными разгонялками не влезало (зато какое ускорение).
- - - Добавлено - - -
После доперевода idct на асм
Желтая Лена 3:51 (почти в 2 раза быстрее относительно первого варианта)
Цветные попугаи 4:52 (ускорение на 31%)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot