nedoPC.org

Запустил в этом эмуляторчике RTOS (операционную систему реального времени) Zephyr ( Зефир : )

https://github.com/zephyrproject-rtos/zephyr/

Точнее 2 мультитредных примера, необходимых для прохождения на конкурс RISC-V
Зефирное ядро прилинковывается прямо к примеру и надо пускать получаемый файл zephyr.elf

Проблема в том, что для успешной работы нужен не совсем последний набор исходников:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.13.0

В этом эмуляторчике по ходу кроме базового набора инструкций из RV32I есть умножение-деление (RV32M) и атомарные операции (RV32A) - сделаю макрос, чтобы их отключить

Текущее состояние эмуля: https://gitlab.com/nedopc/npc5/blob/master/emu-rv32i.c

Некая компания "Esperanto" разрабатывает супербыстрый RISC-V процессор:

http://www.linleygroup.com/newsletters/newsletter_detail.php?num=5949

Он реализует RV64GC (64-битная архитектура RISC-V с плавающей точкой и т.д. плюс компактные опкоды), декодируя 4 инструкции за один цикл и посылая их в 5 вычислительных модулей в Out-Of-Order (не по порядку) через 10-шаговый конвейер и всё это работает на 2 ГГц на 7нм технологии...

P.S. У меня на днях (до прочтения вышестоящей новости) мысль мелькнула, что наряду со своим Retro-V ядром с 8-битной шиной, можно разработать супер-быстрое ядро Super-V с 64-битной шиной, которая бы читала 2 стандартные 32-битные инструкции за цикл (или даже 4 компактные 16-битные инструкции за цикл) - типа superscalar, побив все существующие опенсорцные реализации по скорости, но вот это что выше описано оно конечно не побъёт

P.P.S. Создал топик про Super-V в другом подфоруме: http://www.nedopc.org/forum/viewtopic.php?f=46&t=19210

Here are the commands I used to setup the base image:

I first tried running RISC-V Qemu on Buster, but even ls didn’t work properly and the installation failed.

When I ran it on Unstable ls works but strace doesn’t work in a chroot, this gave enough functionality to complete the installation.

When running the VM the operation was noticably slower than the emulation of PPC64 and S/390x which both ran at an apparently normal speed. When running on a server with equivalent speed CPU a ssh login was obviously slower due to the CPU time taken for encryption, a ssh connection from a system on the same LAN took 6 seconds to connect. I presume that because RISC-V is a newer architecture there hasn’t been as much effort made on optimising the Qemu emulation and that a future version of Qemu will be faster. But I don’t think that Debian/Bullseye will give good Qemu performance for RISC-V, probably more changes are needed than can happen before the freeze. Maybe a version of Qemu with better RISC-V performance can be uploaded to backports some time after Bullseye is released.

Here’s the Qemu command I use to run RISC-V emulation:



Currently the program /usr/sbin/sefcontext_compile from the selinux-utils package needs execmem access on RISC-V while it doesn’t on any other architecture I have tested. I don’t know why and support for debugging such things seems to be in early stages of development, for example the execstack program doesn’t work on RISC-V now.

RISC-V emulation in Unstable seems adequate for people who are serious about RISC-V development. But if you want to just try a different architecture then PPC64 and S/390 will work better.