Описание отличий семейства ARM7, 720, 922, 926 и т.д. Опции

[GetSmart]

Кто подскажет ссылку или PDF с заданной темой. Хорошо знаком с ARM7TDMI. Собираюсь подсесть на ARM9 и хотя бы познакомиться с 10 и 11. Но их так много расплодилось, что я в замешательстве.

Пожалуйста без ответов типа ищи на сайте arm.com. Лучше подскажите имя конкретного файла как например arm7tdmi.pdf. Нужно описание именно отличий семейств, а не полное описание каждого семейства, при том, что в них 95% может совпадать.

[aaarrr]

По системе команд некоторые 9-е ничем не отличаются от 7-х, но все имеют гарвардскую архитектуру.

[defunct]

но все имеют гарвардскую архитектуру.

Как вы отличаете архитектуры. Всмысле, что в ARM9 более или менее гарвардского чем в ARM7?

Я так понимаю все 9-ые имеют гарвардскую архитектуру и только поэтому отделены от 7-ых ?

Думаю разработчики ARM вообще не заморачиваются такой ерундой как разделение архитектур на гарвард, нейман и т.д. Они просто делают свою работу.

Что же касается вашего вопроса, разве отличий с wiki мало? :
- длина конвеера
- раздельный кеш

[aaarrr]

Всмысле, что в ARM9 более или менее гарвардского чем в ARM7?

Раздельные шины инструкций/данных у ядра.

[defunct]

Раздельные шины инструкций/данных у ядра.

Этого мало, т.к. память лежит на общей шине и адресное пространство одно - общее и для кода и для данных.
В Intel Pentium есть DIB и раздельный кеш, это тоже гарвард?
Модель программиста ARM7/ARM9 неизменна. В то время как для AVR - который классический гарвард, модель программиста значительно отличается от ARM, как раз из-за того, что код и данные лежат в разных адресных пространствах по одинаковым адресам.

[aaarrr]

Этого мало, т.к. память лежит на общей шине и адресное пространство одно - общее и для кода и для данных.

Да, надо было с самого начало добавить приставку "псевдо".
Память вовсе не обязательно сидит на общей шине - TCM, например, подключаются отдельно.

[defunct]

Да, надо было с самого начало добавить приставку "псевдо".
Память вовсе не обязательно сидит на общей шине - TCM, например, подключаются отдельно.

Не суть важно.
Есть хоть какой-то адресуемый участок памяти в котором располагается код, и куда по определению нельзя добраться как к блоку данных (прочитать/изменить)?
Все эти доп шины - это так мелкие ускоряющие фичи, не меняющие архитектуру в корне.

AVR в этом плане "убогий" гарвард. Либо "гарвард" в чистом смысле (аля AVR) убогая идея. Так как не позволяет выполнять код из рамы. И ещё ограничивает командам доступ к разным адресным простанствам.

Ну если поставить заместо Flash RAM - то нет проблем можно будет модифицировать код!
Но в этом и есть разительное отличие архитектур. Низя адресовать всю память линейно!

[aaarrr]

Есть хоть какой-то адресуемый участок памяти в котором располагается код, и куда по определению нельзя добраться как к блоку данных (прочитать/изменить)?
Все эти доп шины - это так мелкие ускоряющие фичи, не меняющие архитектуру в корне.

Угу, значит основное свойство Гарвардской архитектуры - это наличие "участка памяти, в котором располагается код, и куда по определению нельзя добраться как к блоку данных", а раздельные шины - это так, мелочь ненужная?

[defunct]

а раздельные шины - это так, мелочь ненужная?

Раздельные шины применительно к общей памяти это просто ускоритель.
Раздельные шины в комплексе с раздельной памятью - это гарвард.

Прилепите к шине инструкций непосредственно ПП, получим гарвардскую систему. Прилепите к ней AHB получим, то же, что и ARM7.

[aaarrr]

Раздельные шины применительно к общей памяти это просто ускоритель.
Раздельные шины в комплексе с раздельной памятью - это гарвард.

Хорошо, а как назовем раздельные шины с раздельным кэшем? И чем это решение будет хуже п.2?

Прилепите к шине инструкций непосредственно ПП, получим гарвардскую систему.

В случае с TCM дело именно так и обстоит.

[defunct]

Хорошо, а как назовем раздельные шины с раздельным кэшем?

Intel называет это Dual Independent Bus (DIB) и Separate code and data caches. Т.е. своими именами без подведения под какую-то черту.

И чем это решение будет хуже п.2?

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

[aaarrr]

1. Ресурс(память) один, а шины две. Ресурс надо делить - меньше производительность.

Производительность ARM926EJ при работе из TCM (честный Гарвард в вашей интерпретации) и из кэша практически одинаковая (кэш немного быстрее).

1. Ресурс(память) один, а шины две. Ресурс Кеш не панацея всю память на разместит.

Вам часто приходится работать со всей памятью? Не панацея, но и не от безделья придуман.

2. Сложнее в реализация - т.к. для дележки требуется арбитраж.
3. Раз есть арбитраж получаем - не прогнозированую латентность выборки данных и команд.

Если уж есть кэш, то эти два пункта существуют по определению.

[defunct]

Производительность ARM926EJ при работе из TCM (честный Гарвард в вашей интерпритации) и из кэша практически одинаковая (кэш немного быстрее).

Кто и как измерял? Результат тут будет сильно зависеть от множества параметров - таких как размер кода, количество branch инструкций, объем данных обрабатываемых программой и их размещение.

Не сомневаюсь какой-то крайний случай типа:

while( temp--);

может работать из кеш памяти быстрее.

Вам часто приходится работать со всей памятью? Не панацея, но и не от безделья придуман.

В пределах работы программы, да - часто вся память используется. Другой вопрос, что на конкретном временном интервале выполняющем какой-то конкретный алгоритм/обработку чего-то, задействовано немного памяти, и на этом получается эффект от кеша. Правда данные которые надо обрабатывать разбросаны по разным участкам памяти, и часто получены через DMA, т.е. львиная доля данных требует invalidate изначально, либо лежит в некешируемом регионе памяти.

[aaarrr]

Кто и как измерял? Результат тут будет сильно зависеть от множества параметров...

Ну, я, например, измерял dhrystone'ом. Аналогичные результаты можно увидеть и у Атмела.
Не спорю, можно придумать задачу, на которой TCM получит преимущество, но в общем случае работа с памятью напрямую и через кэш очень слабо отличается.

[defunct]

Не спорю, можно придумать задачу, на которой TCM получит преимущество, но в общем случае работа с памятью напрямую и через кэш очень слабо отличается.

Подытожив, я хочу сказать, что словосочетанием Гарвардская Архитектура отличия между ARM7 и ARM9 выражать неправильно. Применительно к ARM9 ядру - да можно построить на нем гарвардскую систему, но применительно к существующим МК, т.е. к конкретным системам на ARM9 ядре слово Гарвардская Архитектура может не иметь никакого отношения.

[GetSmart]

... т.е. к конкретным системам на ARM9 ядре слово Гарвардская Архитектура может не иметь никакого отношения.

Если можно, приведите конкретные примеры ARM9 без гарварда.

IMHO, если планируете работать с конкретными готовыми МК, то лучше не на ядро смотреть, а на то, что на нем слеплено.

Я вообще-то также думаю. К примеру фича NXP с 128 битной флэш могла бы претендовать на новое семейство ARM То есть она вполне сопоставима с улучшениями вроде гарварда и 5-стадийности.

Просто меня мой шеф напряг своей новящевой идеей про ARM9. Как и все "потребители" (в противовес разработчикам) он искренне верит, что ARM9 в 3-5 раз круче ARM7. Именно семейство круче. То есть если у проца есть "лейбл" ARM9, то это то, что надо. К примеру он предлагает закладываться на LPC31xx и LPC32xx, которые даже внутреннего флэша не имеют. У меня же есть большие сомнения что этот кастрированный ARM9 будет выполнять большой линейный код (без циклов), находящийся во внешней 32 битной флэш быстрее к примеру Cortex-M3 с внутренней флэш. То, что определёнными усилиями можно заставить выполняться небольшую часть кода (десятки кб) на полной частоте проца (266 МГц) конечно я понимаю. Но остальная бОльшая часть кода (сотни кб) будет выполняться даже медленней (в 2 и более раз) чем даже на LPC21/22/23/24. Я прав?

[defunct]

Если можно, приведите конкретные примеры ARM9 без гарварда.

Мне проще привести с классическим гарвардом - STR91x.
Все остальное, что строится на кеше и общей внешней SDRAM - это гибриды. Чем такая система отличается от системы на базе Intel P? да ни чем. А почему тогда IP не гарвард?

Просто меня мой шеф напряг своей новящевой идеей про ARM9. Как и все "потребители" (в противовес разработчикам) он искренне верит, что ARM9 в 3-5 раз круче ARM7. Именно семейство круче.

Сравните STR91x и high-end ARM7 (разница там в районе ~40%). И покажите шефу эту разницу.

То есть если у проца есть "лейбл" ARM9, то это то, что надо.

Если у проца есть лейб ARM9, то можно расчитывать на тактовую много больше 100Mhz, ARM7 на такой частоте не найти.

меня же есть большие сомнения, что этот кастрированный ARM9 будет выполнять большой линейный код (без циклов), находящийся во внешней 32 битной флэш быстрее к примеру Cortex-M3 с внутренней флэш.

Ну скопируйте содержимое флеш в SDRAM и будет быстро.

[GetSmart]

Мне проще привести с классическим гарвардом - STR91x.

Вы вопрос изначальный помните? Я спрашивал есть ли ARM9 без гарварда и является ли это основным отличием от ARM7.

Все остальное, что строится на кеше и общей внешней SDRAM - это гибриды. Чем такая система отличается от системы на базе Intel P? да ни чем. А почему тогда IP не гарвард?

Может и гарвард. Может из-за своей давней истории развития от 8086 к более новым. Хотя пример с ARMом вроде абсолютно аналогичный, но там вроде никто не скрывает и не спорит про гарвард.

Сравните STR91x и high-end ARM7 (разница там в районе ~40%). И покажите шефу эту разницу.

40% попугаев? Если сравнивать два конкретных проца, то у каждого есть своя предельная тактовая, которая может перевесить скорость архитектуры конкурента.

Если у проца есть лейб ARM9, то можно расчитывать на тактовую много больше 100Mhz, ARM7 на такой частоте не найти.

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

Ну скопируйте содержимое флеш в SDRAM и будет быстро.

Это я знаю. Спрашиваю пока о флэш.

1000 разных процедур - тоже фантастика.

100 процедур по килобайту устроит?
Я клоню к тому, что все они в кэш не влезут. А так как они вызываются по очереди, то когда исполнение вернётся к первой, то она из кэша уже сотрётся.

Сообщение отредактировал GetSmart - Mar 27 2009, 15:34