[eugen_pcad_ru 0]

Собственно хочу научиться писать программы под вышеупомянутый DSP. Среда разработки есть.

На сайте производителя попытался найти нечто типа prоgrаmmеrs guidе, но кроме datamanuаl-a ничего толкового не обнаружил.

Ткните плз.

Спасибо всем откликнувшимся!

[SM 0]

Собственно хочу научиться писать программы под вышеупомянутый DSP. Среда разработки есть.

На сайте производителя попытался найти нечто типа prоgrаmmеrs guidе, но кроме datamanuаl-a ничего толкового не обнаружил.

Ткните плз.

 

Сомневаюсь, что есть что-то подробнее хелпа в самом композере... (docs/hlp/54xref.hlp)

там описание CSL, DSPLIB и самого проца. Старенькое больно семейство.

Ну и апноты поискать, что-то наверное осталось...

 

и вот это:

 

SPRS079--TMS320VC5402 Fixed-Point Signal Processor

SPRU099--TMS320C54x C Source Debugger User's Guide

SPRU102--TMS320C54x Assembly Language Tool User's Guide

SPRU103--TMS320C54x Optimizing C/C++ Compiler User's Guide

SPRU131--TMS320C54x DSP Reference Set, Volume 1: CPU and Peripherals

SPRU172--TMS320C54x DSP Reference Set, Volume 2: Mnemonic Instruction Set

SPRU179--TMS320C54x DSP Reference Set, Volume 3: Algebraic Instruction Set

SPRU288--TMS320C548/549 Bootloader & ROM Code Examples Technical. Reference

SPRU420--TMS320C54x Chip Support Library API User's Guide

SPRU307--TMS320C5000 DSP Family Functional Overview (Addendum to 'C54x Data Sheets)

 

и по ссылкам из docs/hlp/cc_c54xw.hlp

[=GM= 0]

..хочу научиться писать программы под вышеупомянутый DSP

SM вам правильно сказал, с чего начать. Добавлю: найдите демоплату DSK5416 или DSK5402 вместе с диском. На диске полно примеров для начала работы и понимания.

 

А в принципе, не рекомендую вам начинать работать с этим процессором. Потратите время, намучаетесь с пайплайновыми конфликтами, а проц устареет ещё больше, в итоге останетесь у разбитого корыта. Вы даже ответов на форуме не получите толком, будете вариться в собственном соку. Яркий пример: Михаил с телесисей.

 

Мой вам совет, беритесь сразу за проц типа TMS320F2808 или подобный, вполне заменяет старый С5416.

[SM 0]

TMS320F2808 или подобный, вполне заменяет старый С5416.

Из современного все таки что-то типа 5507/9/10 ближе к 5416. Все 2000-ки значительно далеки от 5416 хотя бы по размеру RAM (у 5416 256кбайт). 28хх замена для 24хх, но не 54хх.

[=GM= 0]

Сергей, 55хх тоже устарели :-). А что ты хочешь? 55хх процы - 16-битники, а 2000 процы - чистые 32-битники. А ещё в 2000 серии есть проц с 300 МГц тактовой и 512 Кбайт оперативной памяти.

[SM 0]

Сергей, 55хх тоже устарели :-).

Сам TI так не считает, не так давно обновив семейство двумя экземплярами с high speed USB. Да и то, что в них основное АЛУ D-юнита, как и все (почти) операции, включая логику и сдвиги, 40-битные, и за такт читается из памяти и пишется в нее по 32 бита данных одновременно, никак не позиционирует их в чисто 16 битные процессоры :) 16-битность там параллельный довесок в виде A-юнита, т.е. вторая операция за такт. Советую изучить их архитектуру, прежде чем дезинформировать начинающих - исключительно 16 битные операции там только навроде экзотики типа "bit field extract", которых в 2000-ках и близко нет, да и есть (были) вообще разве что в БЭСМ-6 :), да адресные модификации, параллельные операциям с данными (т.е. выполняемые в том же такте).

[=GM= 0]

У меня там смайлик стоял после слова "устарели". Также прошу прощения, если кого-то ввёл в заблуждение насчёт 16-битности семейства С55хх. В некоторых операциях проц выдаёт 32-битные результаты. То есть, семейство в основном 16-битное по входу и 32/40-битное по выходу, в то время как С28хх являются 32-битными по входу и выходу. Есть также десяток операций с 64-битными операндами и десяток - с 64-битными результатами по выходу, скажем, умножение 32*32->64. (Интересно, можно ли их на этом основании считать 64-битными :-)?)

 

С55хх конечно мощное семейство, кто ж спорит, много разнообразных команд и методов адресации. А вот таких казалось бы стандартно-симметричных, как в С28хх:

 

ADDL var32,ACC ;добавить аккумулятор к 32-битной переменной

ADDL ACC,loc32 ;добавить 32-битную переменную к аккумулятору

 

что-то не обнаружил. Нашёл только

 

ADD dbl(var32),ACx,ACy

[SM 0]

В некоторых операциях проц выдаёт 32-битные результаты. То есть, семейство в основном 16-битное по входу

заканчивайте откровенную дезинформацию

 

что-то не обнаружил. Нашёл только

ADD dbl(var32),ACx,ACy

 

в 55хх это все делается примерно так:

 

        mov ac2,dbl(*ar6)    ||    add ac0<<#1,ac2
        add ac2,ac1    ||     mov dbl(*ar3-),ac0
        mov ac1,dbl(*ar0+)    ||     sub ac2<<#1,ac1        
        mov ac1, dbl(*ar1+)    ||    еще что-нить

; или

    add     dbl(*ar0), ac0,ac2
    mov     ac2,dbl(*ar0)        ||    sub     ac0,dbl(*ar0+),ac3
    mov     ac3, dbl(*ar1+)    ||    sub     ac1,dbl(*ar0), ac2
    mov     ac2, dbl(*ar1+)    ||    add     dbl(*ar0),ac1,ac3
    mov     ac3, dbl(*ar0+)    ||    add     #5, ar1

 

соотв. на месте ADD/SUB может быть и любая другая операция 40-битного D-юнита, например логическая, а не арифметическая.

 

А вот где в 2000 на базе предыдущих примеров однотактный ADD var32_1, ACC, var32_2 :) И (правда не уверен, не помню) вроде в 2000 нет "SIMD" операций с pair(), когда за счет 32-битности обрабатываются одновременно два разных 16-битных числа одним 32-битным АЛУ. В 55хх есть. т.е. 55хх может сделать три 16-битных операций за один такт, одну в A-юните, и две в pair-режиме D-юнита.

 

И вообще, опять Вы приплетаете не то и не к тому. Полнота набора операций с операндом приемником в памяти - вопрос отдельный, решаемый тут параллелизмом. Зато в 2000 нет ни механизма soft-dual параллелизма, который позволяет 55-ому читать из памяти одно совершенно параллельно с записью чего-то совсем другого, ни механизма parallel enable bit, позволяющего параллелить одну операцию, это поддерживающую (а таковы все регистр-регистр) с почти чем угодно другим. Короче - продолжайте изучать. Беглый взгляд на список команд в документе и знание архитектуры - вещи разные. просто посмотрите на кол-во шин и юнитов. Три входные 16-битные шины данных с разными шинами адреса и две выходные, тоже со своими разными адресными, позволяют читать и писать за один такт два 32 битных значение лишь как частный случай, а не как единственный возможный у 2000. Опять двойка :) за знание архитектуры.

 

С55хх выполняет за один такт (т.е. может выполнять) одновременно одну операцию с двумя 40-битными входами и 40 битным выходом, одну операцию с 16 битными входами и 16 битным выходом, два (в отдельных случаях три) чтения 16 битных операндов (включая как разновидность и чтение одного 32 битного), и запись двух 16 битных операндов (включая как вариант запись одного 32 битного). О таком 2000-кам только мечтать. Это семейство (55хх) имеет промежуточное положение между простенькими одноюнитовым 2000 без параллелизма (и соотв. с интуитивно-понятным ассемблером), и навороченными суперскалярными (с полным параллелизмом почти без ограничений, и таким ассемблером, от работы на котором с ручной программной конвейеризацией операций крышу сносит) 8-юнитовыми 6000-ками.

 

что касается возможности упрощенного получения половинки 64-битного результата в умножениях у 2000 - это очень сомнительное преимущество (а даже скорее чаще и недостаток) перед возможностью двух параллельных MACов 16x16+40->40 с разными источниками данных и регистрами-накопителями, как в 55хх и 6ххх.

[=GM= 0]

Чёт не нашёл определения битности микропроцессора, придётся самому выдумывать :-). По-моему разумению, 32-битный проц должен "атомарно" принимать порцию данных 32-бита, обрабатывать порцию данных 32-бита и выдавать порцию данных 32-бита. Здесь под обработкой понимается набор команд проца, причём такое "ортогональное" количество, которого достаточно для комфортного программирования. Весь остальной марафет упрощает жизнь, но не меняет сути сказанного, точно также, как и количество юнитов или периферии.

 

Подходит семейство F28xx под определение? Подходит. А семейство С55хх? Не совсем. Обьясню почему. Важной частью цифровой обработки являются арифметические команды и пресловутые МАСи - умножение с накоплением.

 

В F28xx умножение 32*32 даёт 32-бита младшей или старшей части произведения. В С55хх этого просто нет, есть только 16*16->32, для 30+ разновидностей МАСов все входные данные 16-битные.

 

Теперь, по поводу возможности "упрощенного получения половинки 64-битного результата в умножениях". Повторюсь, две команды, два такта - и в сдвоенном регистре ACC:P у вас 64-битный результат умножения 32-битных переменных

 

impyl p,xt,@ya ;lower a12*ya

qmpyl acc,xt,@ya ;upper a12*ya

 

Не знаю, "сомнительное это преимущество или даже чаще недостаток", но 32-битные команды реально помогают работать с 64-битными переменными. Я так делал цепочку биквадных БИХ-фильтров. Очень удобно, коэффициенты 32-битные, а результаты операций - 64-битные, система команд проца позволяет их обработать без напряга.

[SM 0]

32-битный проц должен "атомарно" принимать порцию данных 32-бита, обрабатывать порцию данных 32-бита и выдавать порцию данных 32-бита.

 

вот вам атомарное принятие порции 32-битных данных, обработка и выдача, все происходит за один такт (или Вас запись с "||" смущает? Так посмотрите запись инструкций 6000-ков, вообще засмущаетесь):

mov     ac3, dbl(*ar1+)    ||    sub     ac1,dbl(*ar0), ac2

 

А одна это команда, две, или сколько - это уже казуистика. Факт - есть 32-битный LOAD, есть 32-битный STORE, и есть полный набор 32-битной логики и арифметики - все, проц 32-битный. И есть приятный довесок в виде параллельно работающего с этим как бы дополнительным 16-битником. Вот ARM вообще не умеет сделать столько всего одновременно/атомарно 32-битного, LOAD отдельно, арифметика отдельно, однако тоже 32 битный, и никто с этим даже спорить не думает. Просто RISC, а не CISC.

 

насчет 32х32 -> пол-64 это те же 2 параллельных умножения 16х16. Да, где то оно выгоднее, а где-то увы... Т.е. реализовать 32-битный FIR с 64-битным результатом на 2000 и на 5000 и на 6000 будет примерно сравнимо по тактам, если еще и 2000-к не облажается за счет отсутствия подходящего MAC. Просто запись программы будет выглядеть по-разному. У 2000-ков будут считать две частичные суммы, а у 5000 и 6000 накопят 4 частичные суммы в четырех регистрах и потом сложат со сдвигом. А по тактам будет тоже самое, только 2000-к сделает как бы вдвое меньше умножений, но именно как бы, так как 5000 и 6000 сделают по два за такт, а 2000 по одному, но более "толстому". Зато 2000-к "облажается" ровно в два раза при расчете двух разных 16-битных фильров на одном массиве входящих данных. Так что два параллельных мака 16х16 да ДСП-задачах как правило все таки эффективнее одного 32х32 с полурезультатом. Но, конечно, тут вопрос частного случая.

32-битные биквады - если они в Direct Form 1 - то считаются на 5000 и на 6000 не хуже, чем на 2000. Там выходит одна линия задержки, и суть рассчета - как КИХ, то есть 5 MACов. 5000 и 6000 накапливают в аппаратном цикле 4 частичные суммы, после чего их остается сложить друг с другом впараллель с сдвигом содержимого ЛЗ. В общем - надо сравнивать оптимальность реализации алгоритма в целом, а не "отдельно взятый обособленный MUL".

 

вот пример работы с 32-битными умножениями из 32-битного фурья DSPLIB, не думаю, что 2000-к выиграет. Отдельные команды отделены друг от друга пустой строкой, это для тех, кому сложно понять, что одна команда может быть записана более, чем одной строкой.

 

;-----------------------------------------------------------------------
; Benchmark: 15 cycles for butterfly loop
;-----------------------------------------------------------------------
   	rptb BFly;			 (ar1,cdp)

	mpy	 uns(*ar1), *(cdp+t0), ac0; ac0  = yrl*crh (1,0)
::	  mpy	 uns(*ar1(t0)), *(cdp+t0), ac1; ac1  = yil*crh (3,0)

	mac	 uns(*ar1(t0)), *cdp+, ac0; ac0 += yil*cih (3,2)
::	  mas	 uns(*ar1+), *cdp+, ac1; ac1 -= yrl*cih (1,2)
||	  swap	t0, t2; t0=-2

	mac	 *ar1, uns(*(cdp+t0)), ac0; ac0 += yih*cil (2,3)
::	  mas	 *ar1(t0), uns(*(cdp+t0)), ac1; ac1 -= yrh*cil (0,3)

	mac	*ar1(t0), uns(*cdp-), ac0; ac0 += yrh*crl (0,1)
::	  mac	*(ar1+t0), uns(*cdp-), ac1; ac1 += yih*crl (2,1)
||	  swap	t0, t2; t0=2

	mac	 *ar1, *(cdp+t0), ac0>>#16; ac0 += yrh*crh (0,0)
::	  mac	 *ar1(t0), *(cdp+t0), ac1>>#16; ac1 += yih*crh (2,0)

	mac	 *ar1(t0), *(cdp+t0), ac0; ac0 += yih*cih (2,2)
::	  mas	 *ar1, *(cdp+t0), ac1; ac1 -= yrh*cih (0,2)	

	add	 dbl(*ar0), ac0,ac2		

	sfts 	ac2, #-1
||		mar 	*cdp-	

	mov	 ac2,dbl(*ar0); new xr=ac0+xr  (0,4)
||		sub	 ac0,dbl(*ar0+),ac3;				(0,4)

	sfts 	ac3, #-1
||		mar 	*cdp-

	mov	 ac3, dbl(*ar1+); new yr=xr-ac0  (2,4)
||	  sub	 ac1,dbl(*ar0), ac2

	sfts 	ac2, #-1
||		mar 	*cdp-   

	mov	 ac2, dbl(*ar1+); new yi=xi-ac1  (2,4)
||	  add	 dbl(*ar0),ac1,ac3;				(4,4)

	sfts 	ac3, #-1
||		mar 	*cdp-   

BFly:   mov	 ac3, dbl(*ar0+); new xi=xi+ac1
||	  add	 #1, ar1;				(4,4)

 

PS.

Надо просто психологию менять, когда переходишь от простеньких процов, где одна команда = 1 операция = один такт ко всяким там суперскалярам, даже элементарным, статическим, как 6000 и 5000, где одна команда = N операций = 1 такт , и при этом остаешься в ассемблере :)

[=GM= 0]

1) Меня не смущает ни "||" , ни "::". Первое есть во всех тексасах, по-моему.

 

2) Я уже понял, что в с5500 есть 32-битная загрузка, выгрузка, +, -, и т.д. Как насчёт аналога половинного умножения 32*32 С2000 за один такт? И полного - за два?

 

3) Одна команда, две, или сколько - это не казуистика. Вместо слова "атомарный" точнее было бы сказать, за ОДИН машинный цикл, а уж сколько там параллелей, действительно не важно. В противном случае, объявляем 8051 32-, 56-, 64- или даже 80-битным процом, кому какое дело, сколько там тактов выполняется один МАС. Кстати, возможно, с точки зрения марсианина это так и есть :-).

 

4) Я не оспариваю, что С2000 слабое семейство не с точки зрения мощи, а именно с точки зрения наличия огромного количества команд на все потребности кодера.

 

5) Психологию я давно поменял, кое-где даже применил параллельно-последовательное вычисление на МК, но на работе не дают развернуться. Проц, вернее целая линейка, всё считает, и МД5, и фильтры и фурье, есть и кан, и некое подобие операционки, времени хватает. Процесс слишком далеко зашёл, не хотят вкладываться в новые разработки, хотят снять пенки с существующих.

 

6) У вас в посте #8 в первой строчке кода

 

mov ac2,dbl(*ar6) || add ac0<<#1,ac2

 

правомерно использование AC2 в параллельных командах?

[SM 0]

Как насчёт аналога половинного умножения 32*32 С2000 за один такт? И полного - за два?

Повторю еще раз - если на блочном вычислении - то аналог есть, и я его полностью расписал даже с примером кода, его использующего. Повторять не буду, штрафанут :) Если на единичном - то и 5000 и 6000 тут проиграют. Зависит от контекста применения этого умножения.

 

3) Одна команда, две, или сколько - это не казуистика. Вместо слова "атомарный" точнее было бы сказать, за ОДИН машинный цикл,

Тогда, увы, ARM не 32 битный. Он не может за один цикл загрузить, сложить и выгрузить. Только одно из трех. Вот какой облом у АРМоводов-то случился... :)

 

правомерно использование AC2 в параллельных командах?

В параллельных командах правомерно использование любых операндов. AC2 это такой же регистр общего назначения, как и AC0, AC1 и AC3, AC-ом его обозвали только за то, что MACи на них и только на них работают. Можно использовать AC0...AC3, T0...T3, AR0...AR7 как РОНы соответствующей разрядности, не забывая о том, что при 32(40)-битном приемнике операция делается на D-юните, а при 16-битном - на A-юните, и баррелев сдвигатель приделан только к D-юниту. Лишь бы правила параллелизма, описанные в документации на процессор, не нарушались (Вы их не читали?). Ну там общая длина инструкции, отсутствие межюнитовых конфликтов, ограничения по методам адресации для soft dual, и т.д.

 

 

------

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

[=GM= 0]

Тогда, увы, ARM не 32 битный. Он не может за один цикл загрузить, сложить и выгрузить. Только одно из трех. Вот какой облом у АРМоводов-то случился... :)

Не, ну скидку на РИСК/ЦИСК надо делать. Когда я давал определение, то имел в виду именно ИЛИ загрузить ИЛИ обработать ИЛИ выгрузить в любых сочетаниях, а не тупо И..И..И... Так что арм 32-битный, однозначно.

 

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

Правила я читал, и даже имею некоторое представление как это всё должно работать. Я спрашивал о другом. В первой параллельной инструкции АС2 пишется в память, а во второй тот же АС2 модифицируется. Так вроде пишется уже модифицированный АС2 или там столл какой возникает? Или я не так понимаю?

[SM 0]

Так вроде пишется уже модифицированный АС2 или там столл какой возникает? Или я не так понимаю?

нет, пишется тот AC2, который был перед исполнением команды, по пути мимо АЛУ, т.е. напрямую рег.файл->память, а тем временем модифицируется новым значением, никаких тормозов не происходит. Т.е. пути из АЛУ D-юнита прямо в память нету, приемником может быть только регистр, а вот источником - или память или регистр (или две разные памяти, но, увы 16-битные, так как в этом случае придется распополамить 32-битную шину на два входа АЛУ).

[eugen_pcad_ru 0]

Всё понял!

Всем откликнувшимся спасибо!:)