Опубликован эмулятор архитектуры Эльбрус на основе QEMU

7. staa реализованы. ldaa нет, но они не нужны, по крайней мере я не встречал их использования в коде.
8. stap и ldap нужны для защищённого режима, но он вроде и так не поддерживается.

staa реализованы. ldaa нет, но они не нужны

А почему так происходит? Запись нужна, а чтение - нет. Шо за дичь?

Чтение массивов выполняется инструкциями mova* (перемещает данные из APB в регистр и может дополнительно продвигать указатель дальше). Эти инструкции идут отдельно в свои специализированные каналы (если это можно так назвать), а не в универсальные АЛК0-5.

То есть, чтение массивов через APB - это норм, а запись через APB - моветон?

APB (Array Prefetch Buffer) это префетч буффер, в него не записывают, а только читают.

Вообще, похоже есть недопонимание как это всё работает в Эльбрусах. Поясню кратко и своими словами.

У каждого ядра есть AAU (Array Access Unit). Это устройство условно состоит из:

1. AAU регистров в которые входят: дескрипторы массивов, индексы, инкременты и прочая лабуда для работы APB.
2. APB - это буфер куда асинхронно основной программе кладуться данные напрямую из L2.

staa инструкции используют базу из дескрипторов массивов и индексы чтобы записывать данные в память (так же как st). Так же эти инструкции могут продвигать индекс. staa используются для записи в AAU регистры, чтобы потом можно было запустить асинхронную подкачку массивов в APB.

ldaa по факту идентична обычному обращению с ld, но адрес вычисляется из дескриптора массива и индекса (по аналогии с staa), ну и дополнительно можно продвинуть индекс. Так же она используется для чтения AAU регистров, что нужно в ядре, но не в пользовательском коде. По крайней мере я не встречал такого пользовательского кода пока писал эмулятор. Эта инструкция кодируется в обычных АЛК и до появления аппаратного префетча не представляет никакой ценности. Да даже с аппаратным префетчем всё тоже самое можно делать с mova (ещё и данные будут префетчиться), а в 4-х освободившихся АЛК делать полезную работу.

mova инструкции перемещают данные из APB в регистровый файл и дополнительно могут продвинуть индекс. Данные в APB попадают асинхронно основному исполнению по заранее подготовленной программе с указанием дексрипторов массивов, индексов, смещением, инкрементов и прочей информацией. Программа для префетчера задаётся отдельной инструкцией ldisp и запускается инструкцией bap.

Там же конвеер…

Чот не верится в длинный конвейер в вакууме. :) У меня довольно старые знания о технологии производства микросхем, примерно пятнадцатилетней давности. Может сейчас уже и конвейер, но тогда на многих фабах роботы пластины между постами по воздуху перевозили.

Вакуум только при использовании EUV-литографии. Всё остальное «на воздухе».

ldaa по факту идентична обычному обращению с ld, но адрес вычисляется из дескриптора массива и индекса (по аналогии с staa), ну и дополнительно можно продвинуть индекс.

То есть, тут начинает работать что-то типа принципов работы RISC: зачем нам иметь отдельный машкод для CALL и RET, когда мы то же самое можем сделать, напрямую управляя регистрами PC и SP? Тем более что и CALL и RET будут по тактам совпадать с выполнением прямых команд работы с регистрами?

ldaa Эта инструкция кодируется в обычных АЛК и до появления аппаратного префетча не представляет никакой ценности. Да даже с аппаратным префетчем всё тоже самое можно делать с mova (ещё и данные будут префетчиться), а в 4-х освободившихся АЛК делать полезную работу.

Не понял, с mova ведь АЛК будут заняты, с чего бы они освободились? Они освободятся только с ldaa + префетчер. Разве нет?

Даладно! И ионная полировка пластин? И легирование переходов всяким там индием и галлием?

Ну это в вакууме… :)

Не понял, с mova ведь АЛК будут заняты, с чего бы они освободились?

Заняты будут как раз с ldaa, которые идут в АЛК0/2/3/5.

Ещё раз процицитирую своё прошлое сообщение.

Чтение массивов выполняется инструкциями mova* (перемещает данные из APB в регистр и может дополнительно продвигать указатель дальше). Эти инструкции идут отдельно в свои специализированные каналы (если это можно так назвать), а не в универсальные АЛК0-5.

Читай внимательнее.

Заняты будут как раз с ldaa, которые идут в АЛК0/2/3/5.

Мммм... ldaa создан специально, чтобы работать с APB? Или mova создан специально, чтобы работать с APB?

Или mova создан специально, чтобы работать с APB?

this.

Это уже четвёртое сообщение в котором я пытаюсь тебе это объяснить. :)

Смотри на это так:

1. Настроиваешь src массив (псевдокод staa %aad0).
2. Настраиваешь dst массив (staa %aad1).
3. Говоришь где лежит программа для APB (ldisp fapb %aad0, bla, bla).
4. Запускаешь префетч (bap)
5. Ждёшь 15 тактов (если я правильно помню).
6. В цикле читаешь из src (APB, mova %aad0) и пишешь в dst (L1d(write-through)->L2, staa %aad1).

Вроде как APB появился в архитектуре Эльбрус v.6. Значит ли это, что дистр для v.5 просто не имеет инструкций mova, а значит использует ldaa, и поэтому не заведется на эмуляторе?

Вроде как APB появился в архитектуре Эльбрус v.6

Нет, APB там с самого начала. В v7 по планам должен появиться аппаратный префетчер.

Вот маленький пример как оно работает. Поставил v7 т.к. там меньше заморочек и генерирует более понятный код чтобы сильно не запутывать тебя. Смотри на моё предыдущее сообщение и ищи в сгенерированном ассемблере соотвестветствующий код. Там не сложно разобраться.

https://ce.mentality.rip/z/x4WdKE

Пы.Сы.

mova area=N это наш aadN

aaurw это на самом деле staa+mas, псевдоинструкция.

чтобы сильно не запутывать тебя

У Эльбруса мнемотика команд такая, что я хрен что понимаю. И я не нашел ни одной вменяемой документации, где бы четко были описаны:

1. Состав регистров процессора и их обозначение;
2. Особенности архитектуры (подготовка переходов, это ваше APB и прочее);
3. Синтаксис (мнемотика) команд ассемблера. Желательно чтобы для каждой мнемотики было написано откуда появилась аббревиатура и что она означает;
4. Перечень команд (группы команд), их параметры и что они делают.

Книгу «Руководство по эффективному программированию на платформе «Эльбрус»» писали марсиане Нейман-заде и Королёв, которые прыгают с пятого на десятое.

Вот к примеру, авторы пишут:

Большинство операций имеют формат

    <мнемоника>,<канал> <аргумент>, <аргумент>, … , <результат>

1. Состав регистров процессора и их обозначение;

Их очень много, разных типов и вообще всё очень запутанно.

2. Особенности архитектуры (подготовка переходов, это ваше APB и прочее);

Эльбрус сложная архитектура, особенно для тех кто не работал с VLIW до этого и имеют плохое представление о том как работают процессоры на микроархитектурном уровне. Объяснять будет очень долго. Лучше прочитай книжку от МЦСТ.

3. Синтаксис (мнемотика) команд ассемблера. Желательно чтобы для каждой мнемотики было написано откуда появилась аббревиатура и что она означает;

В открытом доступе от МЦСТ такого нет. Язык ассемблера создавался не для людей, а для рептилоидов. :)

4. Перечень команд (группы команд), их параметры и что они делают.

В открытом доступе от МЦСТ такого нет. Лучшее что могу посоветовать, это изучать доступные эмуляторы, желательно от МЦСТ, т.к. наш создавался по реверс-инжинирингу. Дополнительно можно посмотреть в e2kintrin.h из кросс-компилятора, там в комментариях кратко указывается что делает каждая из инструкций (там кажется только инструкции из АЛК, но не все), хватает для общего представления. Или поизучать выхлоп компилятора, если шаришь обычно этого достаточно.

Руководство по эффективному программированию на платформе «Эльбрус»

Это не мануал/спецификация на ISA, а руководство для оптимизации программ для Эльбрусов с высокоуровневых ЯП. Не надо искать там ответы на все вопросы по ISA.

что такое «канал»

В большинстве случаев речь идёт про арифметико-логические каналы (АЛК/ALC), за редкими исключениями (например mova, операции над логическими предикатами). За ответами на эти вопросы, опять же, могу посоветовать прочитать книжку от товарища Кима и Ко.