Не имея опыта работы ни с тем ни с другим, хочу узнать ваше мнение.

Насколько сопоставимы (если такое сравнение вообще возможно) эти МП по производительности при обработке "сигналов"? В частности - БПФ.

И вообще почему МП называется "сигнальным"? Если из-за "оптимизации для обработки", то в чём эта оптимизация выражается? (если только (для21хх) в наличии 40 битного регистра для хранения результата умножения 16-битных множителей... )

В общем, помогите утвердится во мнении, что ARM7 "круче" ADSP21хх.

Известно, что при примерно одинаковой стоимости:
ADSP - AT91
16р - 32р(16)
ПДП - ПДП
нет - USB,UART,АЦП....
80kSRAM - 16k...
... ну и д.т.

ARM общего применения. DSP оптимизирован под обработку сигналов.
(умножение с накоплением итд). Вобщем надо смотреть ядра.

Единственное, что надо учесть, что AT91SAM7S* вещь в себе, а ADSP21* нужна еще внешняя память из которой он будет грузиться.

Спасибо.

Прочитал вот ЭТО (про DSP), и думаю, что для относительно "простых" проектов по обработке сигналов подойдет и ARM (то же умнож. со слож. в "нем" есть), а если "встроенной" памяти программ/данных не хватает из-за "сложности" (объемности) проекта, то есть смысл применять DSP.
Спасибо еще раз.

Попробую разубедить Вас в Вашем заблуждении.
Сигнальные процессоры изначально создавались для того, чтобы обрабатывать непрерывно поступающие потоки данных в реальном времени. ADSP-2181 относится именно к такому классу приборов. "Универсальные" ARM-ы - нет. При их создании, как мне кажется, сделан упор на максимальную простоту архитектуры (и дешевизну реализации ядра в на кристалле), что повлекло за собой целый ряд неизлечимых болезней. Поэтому, ADSP-2181 уделает ARM7 по производительности в несколько раз на всех практически мыслимых задачах сигнальной обработки (даже для операндов повышенной разрядности), в том числе и на БПФ. Это определяется следующими основными факторами:
1. ADSP-2181 - это "честный" однотактовый процессор. Все без исключения команды выполняются за 1 машинный цикл, равный одному такту внешнего генератора (на самом деле, внутри процессора за это время выполняются четыре фазы внутреннего генератора, но об этом пользователю знать не обязательно).
2. ADSP-2181 имеет аппаратные стеки, поэтому вызов процедур, вложение циклов, прерывания в нём выполняются максимально быстро.
3. ADSP-2181 имеет мощную систему адресации памяти, которая ARM-у и не снилась.
4. ADSP-2181 допускает распараллеливание операций вычисления и загрузки/сохранения данных, что для ARM-а не предусмотрено.
5. ADSP-2181 обеспечивает аппаратную поддержку циклов (накладные расходы на зацикливание - 0 тактов). Для ARM-а же это весьма больной вопрос.
6. Практически все команды процессорной арифметики в ADSP являются условными (накладные расходы на проверку условий - 0 тактов).
7. ADSP, в отличие от ARM-а, имеет очень быстрые внутренние и внешние шины команд/данных; кроме того, их больше, чем в ARM-е.
Это ещё далеко не всё, но и приведённого выше достаточно, чтобы сказать определённо: если хотите заниматься обработкой сигнала, об ARM-ах лучше забыть. Для этого больше подходят DSP, зачастую в связке с ПЛИС.
Правда, применять ADSP-2181 я не советую - Analog Devices несколько лет тому объявила о завершении поддержки всего семейства (а цена на эти процессоры сейчас вовсе ни деццкая). Лучше использовать BlackFin от AD, или TMS320C... от Texas Instrumrnts. Фин по соотношению производительность/цена, насколько я знаю, сейчас опережает всех конкурентов, и, кроме того, несёт богатую типично "микроконтроллерную" периферию, что позволяет с успехом использовать его в задачах управления. Поэтому, теперь уже любой ARM на любом классе задач уделывается BlackFin -ом по производительности со свистом (исключение могут составить только операции с плавающей точкой, при сравнении BF с ARM-ом, имеющим FPU, да поддержка ОСей, требующих MMU).

Нда... Все не так однозначно как я думал...

Спасибо.

Ой насмешил! И лапши стока на уши навешал!
...
2. ADSP-2181 имеет аппаратные стеки, поэтому вызов процедур, вложение циклов, прерывания в нём выполняются максимально быстро.
...
А регистр LR забыт? Сверхбыстрый одноуровневый стек.
...
3. ADSP-2181 имеет мощную систему адресации памяти, которая ARM-у и не снилась.
...
Ой ой ой! Предьявите для сравнения!
...
6. Практически все команды процессорной арифметики в ADSP являются условными (накладные расходы на проверку условий - 0 тактов).
...
Не надо ля-ля. Вы бы почитали лучше книжку по ассемблеру АРМ, а потом гнали волну. Все команды АРМа имеют в себе префикс условного выполнения что в большинстве случаях позволяет обходиться без команд условных переходов...
Что же касается вызовов прерываний то практически все доступные на рынке АРМ обладают такой конструкцией блоков прерываний, которая позволяет переходить на подпрограмму прерывания за одну команду:
ldr PC,[PC,#-0xF20]
Просто надо уметь пользоваться этим механизмом...
И так во многом остальном.
Никто не утверждает что это идеально ровный процик для ДСП, но может быть использован как дешевая альтернатива в универсальных приборах с функциональностью ДСП.

ну, например, команды МАС с аппаратным циклом и аппаратным-же доступом к двум цыкл. буферам и авто-инк-дек на нужное число. Т.е. С=С+А(j)*В(i),i+n,j+n. Все дела за такт. У гольного АРМа такого не найдёте. Мож в сопроцессоре каком только. А уж взять какого БлэчьегоФинна, так там такого барахла аж 2 шт. Да на 400-600МГц. Флэши, ессно, нет. С флэшей тока 320Ф28хх какие.

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

У финов уже тоже флешь заявлена.


И ничем это не лучше, если проц умеет одинаково хорошо и то, и другое.


Если уж на то пошло, то двухядерный проц (BF561) справляется с этим ничуть не хуже - так же можно сделать: одно ядро под осью управлением занимается, другое - поток данных обрабатывает. С той и другой задачей ядро справляется одинаково хорошо.

Поаккуратнее в выражениях, милейший.
...
И далеко вы с ним уедете?
К Вашему сведению, у ADSP-2181 аж 4 аппаратных стека, работающих параллельно. Максимальная глубина вложения их достаточна для решения типичных ДСПшных задач (для поддержки ЯВУ и ОСей этот проц не предназначен).
...
MR=MR+MX0*MY0 (SS), MX0=DM(I0, M0), MY0=PM(I4, M4);
Это одна команда, уважаемый. Выполняется за один такт. А теперь напишите то же самое для ARM7, и посчитаем такты.
Да, кстати, буферы в DM и PM могут быть циклическими (накладные расходы на зацикливание - 0 тактов), и указатели модифицируются на произвольную величину. Ну-ка посчитайте, сколько это займёт у АРМа...

Вы что-то хотели возразить, милейший? Или всё же соизволите заглянуть в Hardware Ref. Man. для ADSP?

Умейте, дорогой, умейте.
А давайте посчитаем теперь всё в тактах? Учтите, что ADSP на переход к процедуре прерывания не требует никаких дополнительных команд. А также имеет теневой набор регистров.

Простите, уважаемый, а Вы вопрос темы внимательно прочитали, али как?



По-моему, ядро ARM здесь явно лишнее. Ну, или нужно только для совместимости.

И еще в поддержку Stanislav'а и ADSP.

Только что была задача - необходимо принимать SPI на частоте 50 МГЦ и выдавать через второй SPI. ADSP c этим справится легко, достаточно адекватно настроить автобуфферизацию у SPORT. Решили сделать на SAM7x256, используя DMA. Так вот, на такой частоте тактов SAM не работает вообще, при тактах 25 МГЦ работает еле-еле со сбоями.

У BF единственная проблема - довольно трудно поднять разработку с нуля. Отладочные средства стоят дорого, про студию я вообще молчу. Да и корпус BGA в нашем захолустье применять проблематично. Но платиь за ADSP-2188 1500 рублей дороговато.

>Да и корпус BGA в нашем захолустье применять проблематично.

есть и в фага (в фпга есть даже sharc)

>Но платиь за ADSP-2188 1500 рублей дороговато.

насколко помню BF начального уровня ~17 зеленых

>У BF единственная проблема - довольно трудно поднять разработку с нуля.

ну уж точно не сложнее чем арму....( я думаю проще )

Какое-то у вас захолустное захолустье. 1500р за ДСП. Это если в милитари чтоль? Типичный БФ млачшенький $10-12. Это 800Мгц, кажысь. Или в каких попугаях они их нормируют...

Корпуса у ADSP-BF531 и 532 есть и TQFP, паяются в полпинка.
Переход же на БГА неизбежен, яко гибель капитализьму. Придётся привыкать, или рискуете отстать в элементной базе от конкурентов...
ADSP-21xx действительно дороги. Такая уж политика у фирмы - за устаревшие вещи платить приходится сполна.
Поднять с нуля проэкт на BF вовсе не проблематично, даже в одиночку - говорю по своему опыту. Реализация как аппаратной, так и программной части не составила особого труда.
Если фирма серьёзная, и рассчитывает на серийное производство, то и на средства разработки потратиться не грех. Впрочем, существуют и менее "затратные" методы.

In Master Mode, the SPI Interface uses a modulus counter to derive the SPCK baud rate from the Master Clock MCK. The Baud rate is selected by writing a value from 1 to 255 in the SCBR field. The following equations determine the SPCK baud rate:
SPCK Baudrate = MCK / SCBR
Programming the SCBR field at 0 is forbidden. Triggering a transfer while SCBR is at 0 can lead to unpredictable results.

Так что это не сбои, а тот самый, упомянутый выше, "непредсказуемый результат". Ну и причём тут Алмел?

Простите, а какой ADSP имеется в виду?
Если юзать ADSP-BF, то подобная пересылка сожрёт всего единицы процентов ресурса - контроллер DMA там могущественный.
Вообще, по возможностям ввода-вывода BF с ARM-ами (любыми) сравнивать нельзя - они здесь в разных весовых категориях.

А чем он лучше АРМовского? Я просто не в курсе. Ну например, может он в БФ умеет пересылать периферия<=>периферия?

В Атмеловском АРМе DMA имхо вполне достойный. Конечно это не прям целый event manager, как в TMS-ах каких-то я видел, но всё же.

Нет, не может. Но память BF является многопортовой по множеству 4К блоков. Если один из блоков использовать в качестве промежуточного буфера для DMA пересылок, stall-ов ядра возникать не будет.
DMA контроллер BF - это, по сути, процессор в процессоре. Имеет большое число (12 периферия-память и 2 память-память; в новых генерациях даже больше, вроде) каналов, каждый из которых может выполнять свою "программу", записанную в памяти, без участия ядра. Подробнее можно почитать в Hardware Reference Manual.
К сожалению, систему DMA процессоров ARM с 9-м и 11-м ядром я не изучал - работал только с 7-ми. Там всё плохо по сравнению с DSP.

Да, возможно. В новых генерациях процессоров, похоже, этому уделили серьёзное внимание. И всё же, недостатки архитектуры при этом должны здорово сказываться: конфликты DMA каналов друг с другом и ядром будут иметь место (память-то одна на всех), что отнимет значительную часть вычислительного ресурса. Правда, здесь могу и ошибаться: возможно, в каких-то ARM-based микроконтроллерах предусмотрено разделение DMA потоков, но мне такие неизвестны.
Во всяком случае, контроллеры DMA, как и прочая периферия, не имеют прямого отношения к архитектуре ядра, а являются самостоятельными устройствами, которыми каждый производитель старается оснастить свои произведения.
С TMS я знаком мало, но там, по-моему, контроллеры DMA тоже на высоте - положение обязывает.

Понятно. Т.е. примерно то же, что event-manager у TI.


Чессговоря не понял почему. Т.е. что значит "значительную часть"? Например по прерыванию зарядить DMA, указав ему пойнтер на буфер и сколько слать. Если буфер разумного размера, ну хотя бы 0,5-1 Кслово, то вряд ли можно назвать редкие подёргивания ядра "значительным отъёмом ресурса".

И насчёт конфликтов DMA каналов друг с другом я не понял. Речь о том, что они все вместе АМБУ насилуют? Потому что в памяти им особо конфликтовать негде. Буферы же разные. Ну либо пинг-понг. Благо у Атмела это предусмотрено. Т.е. в DMA можно зарядить одновременно буферы и для текущего, и для следующего пакетов.

Чессговоря я никогда особо не страдал от отсутствия двухпортовой памяти. Вот ФИФО штука полезная. А дуал-порт на борту...


Кстати, непосредственно по теме ветки. Неплохо бы ещё упомянуть, про средства разработки. Вот уж где АД до АРМа как до луны, каким бы "нехорошим" ни был АРМ.

Не, там 400 МГц на ядре (для TQFP), а 800 - это ММАС, соответственно. Максимальная же тактовая у финов - 750 МГц, но это уже глубокое BGA.


Нет, насколько мне известно. Event Manager у того же TMS320F28xx - это блок timer-based периферии, способный генерировать множество ШИМ (в том числе и 3-фазный синхронный), работать с квадратурными энкодерами и прочее подобное. У Blackfin'а DMA - это автомат пересылки данных, т.е. это совсем другое.


У Blackfin'а DMA позволяет не просто переслать что-то куда-то, а запрограммировать целую цепочку подобных действий. Это так называемый Descriptor-based режим. Т.е. режим работы контроллера DMA можно настроить не только с помощью прямой записи в регистры, но с помощью дескриптора. Дескриптор - это область ОЗУ, где прописаны параметры работы канала DMA: стартовый адрес, количество слов, размер слов, 1-D или 2-D пересылки (для памяти) и т.д., а также адерес следующего дескриптора. Таким образом, можно соорудить целую цепочку дескрипторов и контроллер DMA будет по окончании одной пересылки выполнянять следующюю пока не дойдет до конца цепочки. Можно цепочку закольцевать, тогда он будет работать по кругу. Т.е., хотя прямой пересылки "периферия-периферия" и нет, но можно это организовать через буфер ОЗУ (что, имхо, куда более правильно и гибко)


Что конкретно имеется в виду?

Это понятно. Только каналов может быть много, а память-то не многопортовая. При скоростном вводе-выводе DMA контроллеры и ядро проца будут "толкаться" друг с другом за шину памяти, что неизбежно приведёт к замедлению работы ядра. А в BF-е этого не происходит (по крайней мере, теоретически).

Да нормальные там средства - вряд ли хуже, чем для ARM-а.

Вообще, по-моему, пересылка "периферия-периферия" требуется редко. Мне за всё время трудовой деятельности такой режим ни разу не понадобился.

Насколько я помню, TI-шный event-manager позволял, например, опрашивать АЦП, с пересылкой сэмпла по DMA в буфер. Сейчас не полезу смотреть точнее. Речь про 24хх / 28хх камни.


Неплохо. Это действительно помощнее будет.


Средства разработки - IDE, компиляторы, e.t.c.
Собсно насколько я знаю, нормальный Си появился только с БФ. До этого, понятие Си для ADSP было скорее для галочки. Но Си-компиллер для АД как был, так и остался только один. В отличии от АРМ.

Ну и куча других "мелочей". Например помню, когда я показал человеку uCOS-плугин, встроеный в IAR, он мне сильно позавидовал. Потому как кроме uCOS-view ему на его BF ничего более не было доступно. Но это лишние телодвижения, причём ещё и аппаратные.

Почему один? Есть Гринхилс и GCC, например. Да и вообще, какое это имеет значение, если компилер хороший?
А "нормальным" С для целочисленных процов стал действительно только после появления BF - семейство ADSP-21хх под ЯВУ просто не заточено (зато на АСМе там писать очень легко ). Для "плывучего" семейства ADSP-21ххх компилер С был всегда приличным, насколько мне известно.

Да уж, легко. Мне тут третьего дня один умный человек рассказывал, про его му**ханья с банками и ещё кучку любопытностей о 21хх.

А насчёт Гринхиллс, там ихняя вроде только IDE. Сам компиллер всё тот же, АД-шный. Могу ошибаться. Просто в голове отложилось, что для АД реально есть только один компиллер. Как я понял, для реальной работы GCC не особо рассматривается. Т.е. теоретически можно, но это выйдет примерно то же, что попытаться перевести работу целой конторы с ненавистной Винды на Линукс.

Полностью поддерживаю Stanislav и mse. Всё правильно сказано. Но тенденция производителей процессоров такова, что "фишки", присущие исключительно dsp, сейчас есть и в других процессорах и контроллерах. Например, однотактная команда умножения 2х операндов, как минимум 16 бит, с последующим накоплением результата в 40, 48 и более битном аккумуляторе есть и в dspic (насколько я зная), и в avr32 (это я точно знаю).

Не знаю, отчего умному человеку пришлось м**хаться с банкам (регистров? памяти?) ADSP-21xx, если там нет вообще ничего непонятного уму простого обывателя?
Ограниченность адресного пространства - это, конечно, недостаток процессора, но для большинства чисто DSP-шных задач даже только внутренней памяти достаточно. От этого недостатка избавлен BF.

Ошибаетесь. Компилер у них свой, и, по признанию самих AD, является более предпочтительным при создании "контроллерных" приложений. В то время, как AD-шный компилер немного лучше генерит код для математических вычислений. Правда, самому сравнивать не приходилось - в настоящее время VisualDSP меня полностью устраивает.

Несмотря на иронию, если сильно интересно, я уточню, как его увижу.
Но, что б понятно было сразу, это были не "вопли пионЭра о плохом компиляторе". Первый проект на 2181 он для меня делал ещё в 98-99 году. Прошлым летом он успешно портировал uCOS на BF ( из свежих, под который порта нет ).
Ха, вспомнил. На местный фтп мюкос 2,83 им и закачан. Там его автограф есть.


Имхо "банковать" вообще дурной тон, а в DSP это чистой воды преступление.

Про компиляторы уже сказали. Их три штуки, все достойные. Есть бесплатный gcc, на котором сидит прилично разработчиков (blackfin.uclinux.org).

Что касается IDE, то оболочки, как правило, почти везде если не сказать отстойные, то уж всяко не дотягивающие до возможностей связки "программерский редактор+система сборки". В VisualDSP++ оболочка вполне сносная, ординарная. НО! Там есть очень классная вещь - СОМ-сервер! Это позоволяет писать сторонние программы для управления функциями оболочки и отладкой (начиная от руления дебаг-сессиями и заканчивая расстановкой брейкпоинтов и прочим - словом, все, что доступно из оболочки). Язык реализации при этом может быть совершенно любым - компилируемым или скриптовым, я пользовался С++ и Python. В частности, на Питоне написан скрипт, реализующий программирование флеши: схема обычаная - сначала грузим драйвер-программатор, выводим его в рабочую точку, далее грузим в буфер кусок кода для флеши, затем даем команду прошить его; далее следующий кусок, и т.д. Запускать скрипт можно хоть из редактора, хоть из командной строки, хоть из консоли оболочки.

Аналогичным путем можно автоматизировать любой процесс, связанный с отладкой и доступом к потрохам процессора. Например, автоматизировать процесс сбора каких-либо данных на целевой плате с последующим сохранением их на РС. И т.д. Тут только фантазия органичивает.

Ничего подобного нет ни в популярном IAR'е, ни во многих других оболочках. Т.ч. с программными средствами там все более-менее в порядке, получше, чем у многих, как видите. Самый большой недостаток по средствам разработки - это высокая цена на эмуляторы. Ситуацию в значительной мере улучшает отечественный EMU-AD, но и он тоже недешев.


Это говорит лишь о том, что uCOS - не самая популярная ОС для АДшных процов.

Попутно уточните, тяжело ли писать на АСМе 21хх (по сравнению с АРМом, например). Вопрос, напомню, состоит именно в этом.

Абсолютно некорректная постановка вопроса. Для 21хх кроме АСМа ничего и нет ( Си на этих камнях не рассматриваем, по причине "жалкого подобия левой руки" ). Для АРМа же наоборот, это надо сильно захотеть, что бы делать проект на асме, а не на сях. Очевидно, имхо, что каким-бы супер-пупер удобным ни был асм, сравнивать удобство работы с сями... Ну это как сравнивать BF и ARM. Разные весовые категории.

При чём здесь всё это? Прочитайте свой пост #24, и поясните, пожалуйста, что Вы имели возразить против моего утверждения.

Прочитал. Могу только повториться:
"каким-бы супер-пупер удобным ни был асм, сравнивать удобство работы с сями..."

Если и теперь непонятно, то речь о том, что неплохо бы рассматривать всё вкупе, и возможности камня, и удобство разработки. Вот последнее и имелось ввиду. Тащить проект полностью пИсаный на асме - тоскливо. Имхо в наши дни это жирный минус 21хх.

Простите за то,что встреваю в беседу. Но уж темы больно интересные.
По поводу ядер понятно. Конечно мне кажется глупо сравнивать ARM7(старое ядро) со сравнительно ноывм BF. Да и цель их создания различна. Правда непонятно и выражение, что специализированный БЛЕК ФИН вдруг делается ещё и универсальнее универсального АРМа.
С DMA после всего этого я вообще в тупике. Какой бы волшебный он ни был непонятно как физически обратитья к разным адресам в одной памяти в одну единицу времени ?
Помоему должно быть так:
Кесарю - Кесарево
Богу - Божье
АРМу - АРМого
БФ - БФного
А то что АРМ имеет в себе многое, да ещё и выполняет за такт оно ясно и из названия ядра!!!!!!!!!
Всётаки RISC!!!!!!
А по поводу использовать как ДСП у меня и PIC16F877 в позапрошлом году выполнял похожую функцию! (Правда медленно да и задача маленькая)

Ещё раз извините!
С большим уважением ковсем ВАМ
PARAMON!

Неужто настолько разница в возрасте? ARM7, помницца году в 1997-1998 пошло, Blackfin - 2001-м. Не такая уж и разница

А различие основное - калибр у них разный немного.


Тем не менее, странного тут мало. У Blackfin'а не чисто DSP'шное ядро, оно прекрасно справляется и с обычным управляющим кодом. Для этого там есть поддержка - 6 указателей для обращения в память, поддерживающих весь набор спосбов адресации, начиная от простого и заканчивая всякими со смещениями, два указателя стека, адресация гибкая - можно адресовать, хоть 8-бит, хоть 16, хоть 32. Со всеми этими операндами процессор работает эффективно. Есть инструкции работы с битами. Большинство инструкций укладывается в 16 бит, что делает контроллерный код плотным (не "рыхлым", как на том же 21хх). При этом высокая тактовая, мало потребление, приличный набор периферии - неплохой контроллер получается. АРМу 7-му точно не уступает ни в чем, кроме, наверное, цены и разнообразия корпусов QFP.

АРМ7 ввобще не чемпион по многим показателям - уж по эффективности кода его обходят чуть ли не все современные DSP процессоры и контроллеры - С55хх, TMS320F28xx, dsPIC, о чем уже было говорено. Blackfin тут не одинок.


А никто и не говорит, что там ОДНОВРЕМЕННО по ОДНОМУ адресу обращение идет. Там у всех каналов приоритеты есть. Уровень приоритета может программироваться пользователем. Кроме того, там несколько шин, и реально, например, канал DMA памяти может просто не пересекаться с каналом DMA периферийного устройства. Т.е. они работают одновременно по разным шинам и работают с разными блоками памяти. Ситуация эта полностью под контролем разработчика.


Да, так, только вот АРМово с БФным может пересекаться, и тут может возникать необходимость выбора. В моем случае, например, выбор склонился в сторону Blackfin'а. Хотя больше половины функций у него чисто микроконтроллерные.

дык такое сравнение ни кто же не проводит
Но если задача, позволяет реализовать без ДСП - почему бы и нет?

[quote name='dxp' date='Apr 19 2007, 09:25' post='239040']
Неужто настолько разница в возрасте? ARM7, помницца году в 1997-1998 пошло
Не позднее
Пришло на смену ARM6! (Первая половина 90-х)

Blackfin - 2001-м. Уж точно не раньше
Не такая уж и разница
Тем неменее ИНТЕЛ лепит новые и считает что ни месяц, то чтото устарело

А различие основное - калибр у них разный немного.
Потому-то Богу - Божье, а Кесарю - Кесарево

Тем не менее, странного тут мало. У Blackfin'а не чисто DSP'шное ядро, оно прекрасно справляется и с обычным управляющим кодом. Для этого там есть поддержка - 6 указателей для обращения в память, поддерживающих весь набор спосбов адресации, начиная от простого и заканчивая всякими со смещениями, два указателя стека, адресация гибкая - можно адресовать, хоть 8-бит, хоть 16, хоть 32. Со всеми этими операндами процессор работает эффективно.
Ничего против! Если рынок потребует то будет и побитная адресация! В такой схемотехнике
ума много ненадо! Если организация памяти 32 - то и обращение сразу ко всем битам, с точки
зрения самой памяти!

Есть инструкции работы с битами. Большинство инструкций укладывается в 16 бит, что делает контроллерный код плотным (не "рыхлым", как на том же 21хх).
Thumb Mode? про BF ничего незнаю.

При этом высокая тактовая, мало потребление
Другая технология! Ахитектура ядра Причём?


Никто не говорил что АРМ7 заменит DSP, наверное у них небыло такой цели при разработки ядра!

Извините, я не хотел грубить, но для темы важнее выбрать девайс для проекта. Я понял так!
С уважением PARAMON!

Простите, но Вы этого в данном посте не писали, и я против этого не пытался возражать. Разговор был совсем о другом.

Главный минус ADSP-21xx - отсутствие поддержки со стороны изготовителя и высокая цена на приборы. Я уже писал об этом.

А никто конкретно эти ядра и не сравнивал. Какому-то сравнению с ядром BF ещё поддаются архитектуры ARM9 и ARM11, хотя и они в несколько раз проигрывают BF в производительности. Для 7-го сравнение вообще безнадёжно...

Упрощённо: представьте, что у каждого 4К блока памяти есть своя шина адреса и шина данных. Если одновременно обращаться в разные блоки, конфликтов не будет.
Реально всё несколько хуже, но не сильно. За один такт ядра могут быть осуществлены вот такие пересылки данных (конечно, при условии, что буфера размещены в памяти "правильно"):

• Two 32-bit data loads

• One pipelined 32-bit data store

• One DMA I/O, up to 64 bits

• One 64-bit cache fill/victim access.

А вот попробуйте поработать с этим РИСКом, и увидете, насколько далеко от реальности написанное Вами.


Конечно, можно, и часто это оправданно (например, трудно представить себе DSP по цене в 2-3 доллара). Однако, в теме речь идёт о сравнении производительности двух архитектур на DSP-шных задачах. Думаю, теперь этот вопрос прояснён в достаточной мере.

2 Paramon
"Thumb Mode? про BF ничего незнаю."
Нет, не Thumb, а обыкновенные инструкции переменной длины (16, 32 или 64 бит). При этом шина данных памяти программ - 64-битная.