Портирование word2vec в RISC-V .. потенциальная проблема с ядром прокси?

Question

Мы пытаемся перенести word2vec в RISC-V.С этой целью мы скомпилировали word2vec с помощью кросс-компилятора и пытаемся запустить его на Spike.

Кросс-компилятор компилирует стандартные тесты RISC-V, и они без сбоев работают на Spike, но когда мы используемта же самая настройка для word2vec, она терпит неудачу с "bad syscall # 179!".Мы испробовали две разные версии, обе потерпели неудачу в одном и том же месте минуту или две во время выполнения этих инструкций.Пройдя через цикл несколько раз по 100 тысяч раз, мы видим, что C1, C2 напечатали, а затем произошел сбой.Мы думаем, что это больше проблема spike / pk, чем проблема word2vec.

Кто-нибудь сталкивался с подобным опытом при переносе кода в RISC-V?Любые идеи о том, как мы могли бы отследить, является ли это ядром прокси?

С этим связан вопрос о том, как заставить GDB работать со Spike ... опубликую это отдельно.

Спасибо.

Answer 1

riscv-pk не поддерживает все возможные системные вызовы.Вам нужно будет отследить, какой это системный вызов и можете ли вы реализовать его в riscv-pk или вам нужно перейти к запуску его на другом ядре.Например, riscv-pk не поддерживает какие-либо системные вызовы, связанные с многопоточностью, поскольку поддержка многопоточного ядра явно не является целью riscv-pk.

Я бы также опасался использовать riscv-pk в целом.Это очень простое, тонкое ядро, которое отлично подходит для запуска пользовательских приложений newlib с самого начала, но ему не требуются тщательные тесты и валидация, поэтому запускающиеся приложения, которые нагружают системы виртуальной памяти, полагаются на множество системных вызовов (iotcl и друзья),или ожидаете, что более glibc-подобные среды могут оказаться проблематичными.