Сообщество

Добрый вечер.

Расхождение в работе функциональной модели с железом связана с тем, что модель при выполнении операции adc лепит флаг CF там, где не следует. В связи с этим к данным добавляется лишний бит в строчках: 13,18,20.

1 rdl sl1
2 rdl sl2
3 addl @1,@2
4 wrl @1,sum
5 rdl sl1+4
6 rdl sl2+4
7 addl @1,@2
8 adcl @5,@1
9 wrl @1, sum+4
10 rdl sl1+8
11 rdl sl2+8
12 addl @1,@2;
13 adcl @5,@1
14 wrl @1, sum+8
15 rdl sl1+12
16 rdl sl2+12
17 addl @1,@2
18 adcl @5,@1
19 wrl @1, sum+12
20 adcl @2,0
21 wrl @1, sum+16

Мы выложим исправленную версию на сайт в ближайшее время.

Версия с исправленными командами adc и add доступна в разделе 'Программное обеспечение для MULTICLET P1' на сайте:
http://multiclet.com/index.php/ru/support/technical-documents

Некоторые рекомендации по группировке команд в ассемблере, повышающие производительность:

Старайтесь избегать коротких ссылок в коммутаторе (короткие ссылки приводят к тому, что клетки вынуждены простаивать ожидая друг друга). В начало параграфа можно вынести операции чтения потому, что они независимы друг от друга и могут выполняться параллельно, если располагаются в разных блоках. Также следует стремиться указать адрес следующего параграфа пораньше, чтобы раньше началась выборка команд следующего параграфа.

Вот пример параграфа, выполняющего сложение 128 битных беззнаковых чисел:

add_128:

rdl sl1
rdl sl2
rdl sl1+8
rdl sl2+8

rdl sl1+4
rdl sl2+4
rdl sl1+12
rdl sl2+12

addl @7,@8
addl @4,@5
addl @7,@8
addl @4,@5

wrl @4,sum
adcl @5,@4
adcl @5,@4
adcl @5,@4

jmp end
adcl @4,@3
adcl @4,@3
wrl @6, sum+4

adcl @2,@3
wrl @4, sum+8
wrl @2, sum+12

complete

Большое спасибо за оперативную работу и заинтересованность).

Но мы бы хотели прояснить ещё один вопрос:
Подобная структура алгоритма(представленная Вами)представляется нам невыгодной, с той точки зрения, что при возрастании разрядности операндов, на сложение каждой следующей пары слов (например long=32 разряда) с номером n, для фиксации переполнения будет требоваться ещё n-1 сложений с переносом adcl. Таким образом число adcl будет равно 1+2+3...+(n-1), где n - количество слов в операндах.

Подобная структура алгоритма(представленная Вами)представляется нам невыгодной, с той точки зрения, что при возрастании разрядности операндов, на сложение каждой следующей пары слов (например long=32 разряда) с номером n, для фиксации переполнения будет требоваться ещё n-1 сложений с переносом adcl. Таким образом число adcl будет равно 1+2+3...+(n-1), где n - количество слов в операндах.

Это действительно так.
Корень проблемы заключается в том, что команде adc (как и любой другой) флаги передаются только через первый аргумент. В параграфе, приведенном вами в первом посте при выполнении команды adc Arg1,Arg2 вы скорее всего ожидаете получить на выходе Arg2+CF (от Arg1)+CF (от Arg2), однако фактически вы получите Arg2+CF (от Arg1). По этой причине в приведенном вами параграфе теряется часть переносимых бит, следовательно сложение реализуется не в полной мере.

Приведенный мной параграф, на мой взгляд, является наиболее оптимальным решением для реализации 128 битного сложения. Если необходимо сложение чисел большей разрядности, можно рассмотреть такой вариант для К-ого сложения (К>4):

rd arg1_K-1
rd arg2_K-1
add @1,@2
adc @1,0 ; Флаг переноса K-1 сложения
rd arg1_K
rd arg2_K
add @1,@2
add @1,@4
adc @2,0
adc @2,@1; Флаг переноса K сложения

Однако этот вариант распараллеливается хуже, чем приведенный мной первый пример, поэтому имеет смысл реализовать оба и проверить на практике, что будет быстрее для вашего N.

Большое спасибо.
Не могли бы Вы дать более подробные рекомендации по распараллеливанию процессов. Есть ли документы на эту тему, которые можно почитать?

Для формирования общего представления о принципе распределения команд между клетками и условиях их параллельной работы можно почитать статью:
http://habrahabr.ru/post/226773/

В качестве примера хорошо оптимизированного кода можно посмотреть как реализован FFT, включенный в примеры программ для P1 и доступный по ссылке:
http://multiclet.com/docs/PO/Examples20130129.7z

Документ по общим правилам оптимизании для P1 подготовим орентировочно к 10 числу.

Ждём документ!
Но столкнулись с аналогичным предыдущей теме отличием в отладчике и железе для команды mull

Фрагмент программы:

.data

A:
.long 0x77f71a24

B:
.long 0xb07118f4

C:
.long 0x00000000

.text

...
mul_ab:
rdl A
rdl B
mull @1, @2
wrl @1, C
jmp finish
complete

...

На mc-dbg: C=0xCBDC4A50
На процессоре: С=0x3423B5B0

В случае возникновения переполнения при операции умножение, правильность результата не гарантируется, выставляется флаг OF. В отладчике OF не выставляется, поправим в ближайшее время.

• Выборка команд.
• Исполнение команд клетками.

Процесс выборки команд начинается сразу после того, как стал известен адрес начала очередного параграфа и выполнены все команды записи в текущем параграфе. Он протекает независимо от процесса исполнения команд клетками до тех пор, пока весь параграф не будет выбран. Память программ организована таким образом, что команды каждого параграфа последовательно распределяются между клетками на этапе компиляции. Таким образом первая команда каждого параграфа всегда выполняется первой клеткой, вторая команда — второй клеткой, пятая команда — снова 1 клеткой и тд. На каждом такте все клетки одновременно выбирают по одной команде. Выбранные команды размещаются в буферах команд клеток.
Исполнение команд клетками происходит по мере готовности их аргументов и исполнительных устройств. Т.е. команда будет извлечена из буфера и отправлена в исполнительное устройство, если готовы аргументы команды и выбраны все команды, которые используют результат исполняемой команды. После того, как клеткой достигнут конец параграфа, она не может приступить к исполнению следующего до тех пор, пока не будет закончена запись в регистры, а также в память, если опция контроля очередности чтения — записи не отключена.
Рекомендации по структурной организации параграфов.

1. В начале параграфа следует собирать команды, аргументы которых не содержат ссылок в коммутатор.
2. Соседние команды не должны зависеть друг от друга, в противном случае велика вероятность того, что соответствующие клетки перейдут к исполнению этих команд одновременно, однако одна из клеток будет вынуждена ожидать результата от другой клетки. Рекомендуется по возможности избегать ссылок, длиной менее четырёх.
3. Команды перехода размещать в параграфе как можно раньше, что позволит производить выборку команд с максимальным опережением. Таким образом исключается задержка в исполнении команд клетками по причине ожидания выборки команд, потребляющих результат текущей операции.
4. Размещать команды записи в регистр как можно раньше наряду с командами перехода, поскольку невыполненные команды записи в регистр препятствуют выборке очередного параграфа. Избегать неоправданно частой записи в регистры.
5. Писать как можно большими параграфами, что позволит минимизировать простои, связанные с ожиданием записей в регистры по окончанию параграфа, и контролем очередности чтения записи в память.
6. Организовывать доступ к памяти с учётом особенностей её организации. Одновременная работа клеток с памятью допускается, только если выполняются обращения к различным блокам памяти данных (см. «Руководство пользователя. Программное обеспечение мультиклеточного процессора MultiClet P1», раздел 4.1.2). В противном случае доступ к памяти будет осуществляться поочередно, что приведет к дополнительным задержкам.
7. Избегать чрезмерно длинных ссылок. Использование таких ссылок приведет к простоям в работе клеток при выполнении команды, на которую указывает ссылка, если команды будут выбираться с недостаточным опережением.

y.chemodanov wrote:

В случае возникновения переполнения при операции умножение, правильность результата не гарантируется, выставляется флаг OF. В отладчике OF не выставляется, поправим в ближайшее время.

Поправили.