Описание отличий семейства 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. Я прав?