Сообщество

рассмотрим работу с комплексными числами (Manual_Soft.pdf, стр 98):
в файле mul.asm запишем
.data

B:
        .float\
            0f1.0,    0f0.0,\
            0f1.0,    0f0.0

.text

A:
        rdq B
        rdq B + 8
        mulc @1, @2
        wrq @1, B + 16
    complete

будем компилировать командами
mc-as --arch=MCp0411100101 mul.asm -o mul.o
mc-ld -M -o mul.b mul.o

в модели
mc-model -inst-asm -inst-strange -dump-raw -dump-addr -dump-byte -dump-length 4 -dump-from 0x00000000 mul.b
получаем результат:

0.000000003f800000 <= 003e000077c1c024, 0000000000000000 : rdq 0x0
0.000000003f800000 <= 003e000077c1c024, 0000000000000008 : rdq 0x8
0.bf80000000000000 <= 000000003f800000, 000000003f800000 : mulc @1, @2
0.00000000000080bf <= bf80000000000000, 0000000000000010 : wrq @1, 0x10
--- complete ---------------------
00000000 : 00 00 80 3f
00000004 : 00 00 00 00
00000008 : 00 00 80 3f
0000000C : 00 00 00 00

.float\
         0f1.0,    0f0.0,\<-- предположим, что первое число это реальная,а втрое число это мнимая часть комплекного числа
         0f1.0,    0f0.0

тогда непонятно
0.bf80000000000000 <= 000000003f800000, 000000003f800000 : mulc @1, @2 почему полученное значение стоит на первых 32 позициях

Допустим другой вариант. предположим что реальная часть комплекного числа - это второе число в .float

.data

B:
.float\
0f0.0, 0f1.0,\<-- предположим, что второе число это реальная,а первое это мнимая часть комплекного числа
0f0.0, 0f1.0

.text

A:
rdq B
rdq B + 8
mulc @1, @2
wrq @1, B + 16
complete

тогда, после компиляции и запуска бинарника в модели
mc-model -inst-asm -inst-strange -dump-raw -dump-addr -dump-byte -dump-length 4 -dump-from 0x00000000 mul.b
получаем результат:
0.3f80000000000000 <= 003e000077c1c024, 0000000000000000 : rdq 0x0
0.3f80000000000000 <= 003e000077c1c024, 0000000000000008 : rdq 0x8
0.3f80000000000000 <= 3f80000000000000, 3f80000000000000 : mulc @1, @2
0.000000000000803f <= 3f80000000000000, 0000000000000010 : wrq @1, 0x10

т.е. результат совпадает с предположением 1*1 = 1.

вернемся к первому результату bf80000000000000. мы должны получить i*i = -1
выясним как представляется -1 в виде float
для этого составим
.text

A:
clf -1
wrl @1, 0
complete

после запуска в модели
mc-model -inst-asm -inst-strange -dump-raw -dump-addr -dump-byte -dump-length 4 -dump-from 0x00000000 mul.b

0.000000004f800000 <= 003e000077c1c024, 00000000ffffffff : clf 0xFFFFFFFF
0.000000004f800000 <= 000000004f800000, 0000000000000000 : wrl @1, 0x0

4f800000, которое мы получили, отличается от bf800000 в первом примере. почему?

как извлечь из комплексного числа реальную и мнимую часть? как построить из двух вещественных чисел комплексное?
какое представление чисел типа float и комплекных чисел в памяти?

По первому вопросу:

для этого составим 
.text

A:
clf -1
wrl @1, 0
complete

-1 является signed long, т.е. необходимо использовать cslf вместо clf.

По второму вопросу:

B:
.float\
        0f1.0,  0f0.0

0f1.0 - мнимая часть
0f0.0 - реальная часть

После выполнения команды:

    rdq B

Получим число в виде реальной и мнимой части (байты 4-7 Re)(байты 0-3 Im), т.е. 0f0.0 займёт биты 32-63, а 0f1.0 будет находиться в битах 0-31.

Спасибо!
.text

A:
cslf -1
wrl @1, 0
complete

результат работы в модели
8.00000000bf800000 <= 003e000077c1c024, 00000000ffffffff : cslf 0xFFFFFFFF
0.00000000bf800000 <= 00000000bf800000, 0000000000000000 : wrl @1, 0x0
--- complete ---------------------

совпадает с bf800000 в первом примере.

Что означает в модели каждая из колонок:
8.00000000bf800000 <= 003e000077c1c024, 00000000ffffffff : cslf 0xFFFFFFFF

что такое "8."
"00000000bf800000" - это, как я понял содержимое коммутатора. по остальным колонкам у меня только предположения.
и что и в какой последовательности находится в файлах DMin.txt и DM.txt?

PS:
после такой команды
mc-model -inst-asm -inst-strange -dump-raw -dump-addr -dump-byte -dump-length 4 -dump-from 0x00000000 mul.b > 1

содержимое DMin.txt и DM.txt отсутствует, а не должно бы отсутствовать.

-inst-strange

Выводит два аргумента команды и полученное в коммутаторе значение, после выполнения команды.

8.00000000bf800000 <= 003e000077c1c024, 00000000ffffffff : cslf 0xFFFFFFFF

00000000bf800000 - значение в коммутаторе после операции cslf, 003e000077c1c024 - мусор в первом аргумента(должен быть ноль раз команда имеет только один аргумент - скоро поправим и будет 0), 00000000ffffffff - второй аргумент (значение аргумента одноаргументной команды помещается во второй аргумент); cslf 0xFFFFFFFF - команда с аргументом

что такое "8." 

Это представление флагов(8 -> 1000, выставлен флаг SF - знаковый флаг).

содержимое DMin.txt и DM.txt отсутствует, а не должно бы отсутствовать

Если пользователь сам выбрал, что направить результат работы модели в свой файл, то результат и уходит только в указанный файл

P.S. Можете попробовать запустить модель с ключом -d

Для такой программы
.text
A:
cslf -1
wrl @1, 0
complete

Результат выполнения в модели с ключом -d
mc-model -d mul.b
следующий

PM0:
i=0 cslff 0xffffffff; ir = eac01000ffffffff opcode=3a suf=2 type=c F1=0 F2=0 V=ffffffff arg1=3e000077c1c024 arg2=ffffffff *sb=bf800000 flag.f=8

PM1:
i=0 wrl @1,0x0; ir = 8a28004000000000 opcode=22 suf=2 type=2 F1=1 F2=0 V=0 arg1=bf800000 arg2=0 *sb=bf800000 flag.f=0

Это код операции: opcode=22 suf=2 type=2
Это флаги: flag.f=8
*sb - читаем бинарное значение
V - часть 64-битного значения, которое используется для команд AV

Насколько верны догадки? Поясните, что означает в выводе:
i=0
ir = eac01000ffffffff
F1=1 F2=0

i = 0 - номер команды для каждой клетки
ir = закодированная команда в формате AV
F1 - адрес в коммутаторе значения первого операнда
F2 - адрес значения второго операнда
*sb - это значение в коммутаторе в шестнадцатеричном представлении 0xbf800000

Подробнее можно прочитать тут о формате команды
http://multiclet.com/community/projects/examples/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4

Пример "Отличие индексных регистров от РОНов" в
http://multiclet.com/community/projects/examples/wiki/%D0%9E%D0%B1%D0%B7%D0%BE%D1%80_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B_%D1%81_%D0%B8%D0%BD%D0%B4%D0%B5%D0%BA%D1%81%D0%BD%D1%8B%D0%BC%D0%B8_%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D0%BC%D0%B8

дает ошибку при компиляции строки
addl #32, 5

error: expected switchboard reference, got '#'

В файле Manual_Soft.pdf на стр 55 первый аргумент должен быть ссылкой на результат предыдущего вычисления.
И более того, это правило работает для всех двухаргументных команд. На стр 48. там же: в качестве первого аргумента двух-аргументной команды всегда используется результат выполнения одной из 63-х предыдущих команд, содержащийся в коммутаторе и заданный ссылкой на это значение. хотя, самая нижняя ветка рис 15 показывает, что может быть
mnemonic #IR, v32
т.е. не обязательно первый элемент ссылка на результат. Пример можно переписать так

paragraph1:
getl 5
addl @1, #32
setl #32,@1
jmp paragraph2
complete

исправленный вариант
.text

pre:
getl 4
setl #32, @1
getl 6
wrl @1, @3
jmp paragraph1
complete

paragraph1:
getl 5
addl @1, #32
setl #32, @1
getl #32
; jmp paragraph2
complete

в модели
mc-model inst-asm -inst-strange -dump-raw -dump-addr -dump-byte -dump-length 4 -dump-from 0x00000004 mul.b
0.0000000000000004 <= 080e802000000008, 0000000000000004 : getl 0x4
0.0000000000000004 <= 0000000000000020, 0000000000000004 : setl #20, @1
0.0000000000000006 <= 0000000000000020, 0000000000000006 : getl 0x6
0.0000000000000006 <= 0000000000000006, 0000000000000004 : wrl @1, @3
0.0000000000000002 <= 0000000000000006, 0000000000000002 : jmp 0x2
-- complete ---------------------
0.0000000000000005 <= 0000000000000006, 0000000000000005 : getl 0x5
0.00000000589f170d <= 0000000000000005, 00000000589f1708 : addl @1, #20 <- начиная с этой строчки непонятно что дает модель
0.00000000589f170d <= 0000000000000020, 00000000589f170d : setl #20, @1
0.00000000589f170d <= 0000000000000020, 00000000589f170d : getl #20
--- complete ---------------------

нельзя ли пояснить, что происходит в последних трех строчках

А разве у нас есть регистр с номером 20? Насколько я помню он зарезервирован.
Вы правильно поправили пример, первый аргумент всегда должен быть ссылкой на результат в коммутаторе, если команда двухаргументная.
#IR, v32 даст просто сумму значения регистра и числа, в первый аргумент двухаргументной команды вы это не поставите.

Т.е. отличие индексных регистров от РОНов в текущей версии процессора я думаю вы поняли. В следующем процессоре работа с индексными регистрами и РОНами будет ещё прозрачней. Индексные регистры в новом процессоре будут отличаться от РОНов только тем, что они могут быть модифицированы автоматически в параграфах где это необходимо. Если будет нужен доступ к памяти по значению регистра, то надо будет(только в новом процессоре) указывать квадратные скобки, а именно [#IR] или [#R + v32] и т.п.

у меня число 20 подозрений не вызвало. скорее всего номер регистра записан в шестнадцатеричной системе. 20 в шестнадцатеричной как раз равна 32 в десятичной.

Ну вы обратились к зарезервированному регистру. Если вы указываете #20, то вы обращаетесь в регистру номер 20, если укажете #32, то тогда обратитесь к индексному регистру номер 32. Если хотите запись в шестнадцатеричной системе, то тогда обращение к регистру 32 будет #0x20.

программу я привел. я ее откомпилировал и запустил в модели. регистр #20 не я указываю, у меня указан #32. это вывод модели, она сама подхватывает бинарник.

Теперь понятно, сейчас проверю у себя вывод модели.

да. все верно. проверил еще раз под виндоус
программа из файла mul.asm

.text

pre:
getl 4
setl #32, @1
getl 6
wrl @1, @3
jmp paragraph1
complete

paragraph1:
getl 5
addl @1, #32
setl #32, @1
getl #32
; jmp paragraph2
complete

после следующих операций вижу #20, а не #32

mc-as --arch=MCp0411100101 mul.asm -o mul.o
mc-ld -M -o mul.b mul.o
mc-model -inst-asm -inst-strange -dump-raw -dump-addr -dump-byte -dump-length 4 -dump-from 0x00000000 mul.b

0.0000000000000004 <= 003e000077c1c024, 0000000000000004 : getl 0x4
0.0000000000000004 <= 0000000000000020, 0000000000000004 : setl #20, @1
0.0000000000000006 <= 0000000000000020, 0000000000000006 : getl 0x6
0.0000000000000006 <= 0000000000000006, 0000000000000004 : wrl @1, @3
0.0000000000000002 <= 0000000000000006, 0000000000000002 : jmp 0x2
--- complete ---------------------
0.0000000000000005 <= 0000000000000006, 0000000000000005 : getl 0x5
0.00000000083f3e05 <= 0000000000000005, 00000000083f3e00 : addl @1, #20
0.00000000083f3e05 <= 0000000000000020, 00000000083f3e05 : setl #20, @1
0.00000000083f3e05 <= 0000000000000020, 00000000083f3e05 : getl #20
--- complete ---------------------

У меня такой вывод модели:

0.0000000000000004 <= 7715605400350e78, 0000000000000004 : 0E203000 00000004 : getl 0x4
0.0000000000000004 <= 0000000000000020, 0000000000000004 : 10200801 : setl #20, @1
0.0000000000000006 <= 0000000000000020, 0000000000000006 : 0E201000 00000006 : getl 0x6
0.0000000000000006 <= 0000000000000006, 0000000000000004 : 88200043 : wrl @1, @3
0.0000000000000002 <= 0000000000000006, 0000000000000002 : 7A080000 00000002 : jmp 0x2
--- complete ---------------------
0.0000000000000005 <= 0000000000000006, 0000000000000005 : 0E201000 00000005 : getl 0x5
0.000000000000000b <= 0000000000000005, 0000000000000006 : 15201060 : addl @1, #20
0.000000000000000b <= 0000000000000020, 000000000000000b : 10200801 : setl #20, @1
0.000000000000000b <= 0000000000000020, 000000000000000b : 0D280020 : getl #20
--- complete ---------------------

Скачайте последнюю версию ассемблера и линковщика

Да модель действительно регистры выводит в шестнадцатеричном формате.

мне нужна обновленная версия ассемблера и линковщика под linux

скачал, #20 все там же. и появился непрекращающийсся вывод после последнего complete

0.0000000000000004 <= 003e000077c1c024, 0000000000000004 : getl 0x4
0.0000000000000004 <= 0000000000000020, 0000000000000004 : setl #20, @1
0.0000000000000006 <= 0000000000000020, 0000000000000006 : getl 0x6
0.0000000000000006 <= 0000000000000006, 0000000000000004 : wrl @1, @3
0.0000000000000002 <= 0000000000000006, 0000000000000002 : jmp 0x2
--- complete ---------------------
0.0000000000000005 <= 0000000000000006, 0000000000000005 : getl 0x5
0.000000000000000b <= 0000000000000005, 0000000000000006 : addl @1, #20
0.000000000000000b <= 0000000000000020, 000000000000000b : setl #20, @1
0.000000000000000b <= 0000000000000020, 000000000000000b : getl #20
--- complete ---------------------
00000000 : 00 00 00 00
00000004 : 06 00 00 00
00000008 : 00 00 00 00
0000000C : 00 00 00 00

Для linux http://multiclet.com/community/attachments/download/60/(linux)asm_ld_ploader.7z

Ну 20 всё там же(модель действительно регистры выводит в шестнадцатеричном формате), но программа отработала верно. Непрекращающийся вывод в windows связан с использованием dump и адресов, надо выложить в доступ новую модель.

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

mc-model -inst-asm -inst-strange image.bin

А нет с моделью всё в порядке, можно ничего не исправлять.
В строчке

mc-model -inst-asm -inst-strange -dump-raw -dump-addr -dump-byte -dump-length 4 -dump-from 0x00000000 mul.b

Вы не указали конечный адрес вывода содержимого памяти с помощью

-dump-to 0x........

Обратите внимание, что

-dump-byte -dump-length 4

Указывают на формат вывода - 4 байта в строку. Отладчик уже доступен для скачивания.

Установил новый multiclet SDK [[http://multiclet.com/docs/PO/MultiCletSDK.20130715.tar.gz]] c отладчиком на Fedora 19.
В файле mul.s тест такой же как на странице с описанием отладчика [[http://multiclet.com/community/projects/examples/wiki/%D0%9E%D0%B1%D0%B7%D0%BE%D1%80_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B_%D1%81_%D0%BE%D1%82%D0%BB%D0%B0%D0%B4%D1%87%D0%B8%D0%BA%D0%BE%D0%BC]]
после запуска отладчика при выборе проекта отладчик сваливается в core.

mc-as --arch=MCp0411100101 mul.s -o mul.o
mc-ld -M -o mul.b mul.o
File mul.o
section .text
LOCAL pre 0x00000000
LOCAL paragraph1 0x00000002

[user@localhost mul]$ mc-dbg

Multiclet Corp. Debugger v 0.5.0

Enter mode:
1.debugging with MC-MODEL
2.debugging with MC-JTAG

1

• glibc detected * mc-dbg: free(): invalid next size (fast): 0x0a0a05a0 *
• glibc detected * mc-dbg: free(): invalid next size (normal): 0x0a0a1f28 *
  Аварийный останов (core dumped)

Ключ -g дает тот же результат
mc-as --arch=MCp0411100101 -g mul.s -o mul.o

На Fedora 10 удалось пройти немного дальше.
- установил MulticletSDK
- добавил путь и переменную LCCDIR в файл ~/.bashrc

export PATH=$PATH:/home/user/MultiCletSDK/bin
export LCCDIR=/home/user/MultiCletSDK/bin

- выполнил команду source ~/.bashrc
[user@localhost mul]$ mc-dbg

Multiclet Corp. Debugger v 0.5.0

Enter mode:
1.debugging with MC-MODEL
2.debugging with MC-JTAG

1

Enter name of project file
mul.b

Enter full path to mc-model file:

Последнее сообщение по-видимому обозначает что порожденный shell еще не видит путь и переменную

- поэтому перелогинился
$ mc-dbg

Multiclet Corp. Debugger v 0.5.0

Enter mode:
1.debugging with MC-MODEL
2.debugging with MC-JTAG

1

Enter name of project file
mul.b
MC-MODEL was started ...
Connection with mc-model BAD...
For more information, enter 'help'

sbppm -p pre
Ошибка сегментирования

обратил внимание на фразу "Connection with mc-model BAD..." Откомпилировал с ключем -g

mc-as --arch=MCp0411100101 -g mul.s -o mul.o
mc-ld -M -o mul.b mul.o

получил
Enter name of project file
mul.b
MC-MODEL was started ...
Connection with mc-model GOOD...
For more information, enter 'help'

отладка идет как описано.

Как сделать пошаговую отладку. сейчас я ввожу пустой параграф и ставлю на него брейкпоинт, чтобы посмотреть состояние регистров в предыдущем параграфе.

отладка на удаленной машине через модель проходит как описано, а через JTAG оказалась невозможной. отладчик на выбор цифры 2 продолжает выдавать

Enter mode:
1.debugging with MC-MODEL
2.debugging with MC-JTAG

2

JTAG debugging on a work in progress...

кроме того на удаленной машине пример с выводом РОН [[http://multiclet.com/community/projects/examples/wiki/%D0%92%D1%8B%D0%B2%D0%BE%D0%B4_%D0%A0%D0%9E%D0%9D%D0%B0/1]] не производил никакого видимого эффекта. я ожидал увидеть какую-то реакцию в терминале CuteCom, но ее не было.

Компиляцию необходимо проводить с ключом -g, для того чтобы в образ памяти была включена отладочная информация(добавил описание в Сборку проекта).

не производил никакого видимого эффекта. я ожидал увидеть какую-то реакцию в терминале CuteCom, но ее не было.

Для удалённого доступа подключена плата HW1-MCp04, для которой необходимо использовать UART0, таким образом:

.alias UART_DATA    UART0_DATA
.alias UART_BDR     UART0_BDR
.alias UART_ST      UART0_ST
.alias UART_CR      UART0_CR

.alias UART_PORT_PIN  0x300
.alias UART_PORT_BPS  GPIOB_BPS

Работа отладчика через JTAG пока недоступна.

Как сделать пошаговую отладку. сейчас я ввожу пустой параграф и ставлю на него брейкпоинт, чтобы посмотреть состояние регистров в предыдущем параграфе.

Если вы ставите точку останова на параграф, то после перехода на него вы можете посмотреть состояние РОНов на момент прихода в параграф, т.е. то, что записалось в РОНы по окончанию предыдущего параграфа. Можно, я думаю, добавить в отладчик команду для прохода параграфа, чтобы не ставить точку останова на следующий, а анализировать текущий.

Пустой параграф использовался для анализа последнего параграфа программы. верно, это была бы полезная опция - анализировать текущий параграф. И можно ли анализировать состояние после какого-то шага внутри текущего параграфа?

Поправлюсь, для последнего параграфа нет необходимости создавать пустой параграф в случае отладки, достаточно просто написать команду "go". Анализировать состояние после каждого шага параграфа реализовать непросто, поскольку необходимо учитывать, что записи проходят по окончанию параграфа(хотя сделать это можно). Для удобства анализа текущего параграфа попробуем что-нибудь сделать.

насколько я понимаю еще одна трудность анализа внутри параграфа в том что порядок выполнения инструкций внутри параграфа может быть разным, например, в параграфе
paragraph1:
getl 5
getl 6
addl @2, #32
addl @2, #33
continue

строки 1,3 могут выполниться позже чем строки 2,4 и на другой клетке. а как узнать какая инструкция на какой клетке работает?