[SIA 0]

Мне не надо СПАРК - мне надо вменяемый МК на все случаи жизни, а не голое АЛУ с кучкой регистров. Мне нужна "на борту" вменяемая периферия, к которой я могу обратиться за 1 такт, а не за 83 транзакции периферийной главной шины с юго-западным мостом. Мне не нужна внешняя шина, но нужен достаточный объем опять же однотактовой RAM, да желательно с разделением на XRAM/YRAM/DMARAM. А еще мне хотелось бы вместо всех этих костылей с динамическими стеками прерываний иметь одно хорошо забытое решение - автопереключение базового смещения адреса начала регистрового блока для каждого из имеющихся прерываний, да и еще много чего. Но хотеть, как мы знаем, не вредно :)

Думаю, что этого нет по маркетинговым причинам. Хорошо сбалансировать архитектуру и периферию - долгая и кропотливая задача, некогда ей заниматься, тем более что в хорошей архитектуре нет "вычурностей", которые легко обыграть в рекламе.. Скажи спасибо, что среди процессорных ядер всего пара-тройка хорошо сбалансированы, а в обрамлении, считай, еще конь не валялся - кто во что горазд!

[singlskv 0]

По "эффективности системы команд" как раз не очень-то, с производительностью у них из-за невысокой тактовой хуже, чем у MIPS. Вот если ее достаточно, то как чип в целом - очень даже ничего за счет периферии. Но средства разаботки - засада.

под эфективностью/производительностью я имел в виду именно производительность

на 1МГц тактовой ну и набор переферии...

понятно что со старшими MIPS сравнивать нет смысла, но вот эфективность

архитектуры/ядра/переферии в комплексе, если "грубой силы" достаточно, впечатляет...

Ну и двухядерные контроллеры у них тоже уже есть :) SH7265

[SIA 0]

То есть последних два десятка постов обсуждают "критерий из последней десятки". А может хватит из себя супермена строить а взять и признать что архитектура имеет важное значение? Вы же её внимательно изучили и сравнили с другими. Так зачем людям мозг парить? Равно как и другие параметры из той же десятки.

 

А я не боюсь показаться непрофессионалом и признаю.

1) Архитектура ИМЕЕТ значение. Достаточно сравнить тот же MIPS, ARM7, AVR32. Даже слепому видно что это не одно и тоже. И при написании программы это необходимо учитывать. Причём не только когда на асме вставки делаешь. Для разных процов при оптимизации сишной проги тоже будут разные подходы.

2) Переферия тоже в пределах семейства перекликается. Таким образом внутри семейства удобнее переходить, чем скакать с камня на камень. Что бы вы не говорили про пару часов.

3) Я не буду обзывать библиотеки поставляемые разными словами, но приходится признать, что порой легче свою написать, чем воспользоваться чужой. Ну и само сабой лучше, если это свои библиотеки.

4) Не каждый легко и непринуждённо переходит со среды на среду. Или вообще работает одновременно в нескольких. Для меня, к примеру, это длительный процесс. И я думаю, что я не одинок. Может именно по этому народ выбирает максимально многоплатформенные компиляторы?

5) И Отладочные средства вместе со всякими лоадерами и прочим барахлом настроить на столе собрать, перходников настрочить разных, проги некоторые писишные подправить. Тоже время.

6) Я не снабженец конечно, но и тут переход с камня на камень ведёт к задержкам и проволочкам как правило.

7) Что-нибудь в платах накосячат по-первой обязательно.

 

Конечно, когда возникает производственная необходимость, то приходится переходить - хочешь-не хочешь, но если её нет - то не вижу смысла. Ну кроме люботытства или с целью познания нового. И переход с камня на камень всётаки нормально времени отнимает. Там пару часов - там день там два - глядишь и набегает. А где-то к концу проекта - смотришь и думаешь - выкинуть бы всё это в топку и переписать заново - сделал бы уже намного лучше.

 

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

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

2. Очевидно, хотя тут при необходимости присобачить что-то свое довольно легко (АЦП там).

3. Библиотеки - да, хочется сэкономить время, но в результате часто быстрее написать свое.

4. ТУЛЧЕЙН - ГЛАВНОЕ. Хочется универсальный, например, GNU/GCC.

5. Отладочное железо - тоже статья расходов. Хорошо хоть живет достаточно долго.

6, 7 - понятно, хорошая разработка часто для надежности сразу делается на двух разных камнях (но по возможности с одинаковым тулчейном).

 

под эфективностью/производительностью я имел в виду именно производительность

на 1МГц тактовой ну и набор переферии...

понятно что со старшими MIPS сравнивать нет смысла, но вот эфективность

архитектуры/ядра/переферии в комплексе, если "грубой силы" достаточно, впечатляет...

Ну и двухядерные контроллеры у них тоже уже есть :) SH7265

Не все так очевидно. Не все то, что красиво выглядит, оправданно на деле. Тщательно просчитанный "брутальный" подход, как правило, более эффективен.

Эффективность ядра на реальном коде лимитируется ветвлениями и латентностью памяти, поэтому по моей оценке, SH2 хорошо если в среднем выполнит 1.2-1.3 команды за такт. Но бОльшее количество доступов в память из-за меньшего числа регистров запросто съест этот выигрыш. В итоге получаем примерное равенство в производительности на мегагерц с MIPS, но гораздо больше логики в процессоре - в результате минус в тактовой и энергопотреблении (что и имеет место).

А вот то, что это цельный камень, и периферия довольно хорошая - безусловный плюс.

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

[proba 0]

Ну против Renesas-овских чипов я вроде ничего не говорил :). Разве что поддержки никакой и не особенно быстрые они - максимальная тактовая не выше 200 МГц.

кажется Вы не особо в курсе с развитием SH. старшие из них IP core, как и MIPS. поэтому, корректно сравнить mips64 с SH5 ( 64bit IP core)

http://www.renesas.com/fmwk.jsp?cnt=sh5_ch...&title=SH-5

или SH4A. представитель: SH77850.

http://www.renesas.com/fmwk.jsp?cnt=sh7785...s/sh7785_group/

что касается подержки то тут SH и MIPS равны, gcc/gnu и linux имеют оба.

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

[SIA 0]

кажется Вы не особо в курсе с развитием SH. старшие из них IP core, как и MIPS. поэтому, корректно сравнить mips64 с SH5 ( 64bit IP core)

http://www.renesas.com/fmwk.jsp?cnt=sh5_ch...&title=SH-5

или SH4A. представитель: SH77850.

Если Вы заметили, в контроллерном контексте я говорил про SH2(А) и MIPS32, как самые экономичные. Кстати, официальные удельные производительности - 1,5 DMIPS/МГц у них как раз одинаковы, так что получается, что моя оценка подтверждается и официальными данными. Тактовую частоту в 200 МГц оценил навскидку, не смотря на roadmap, просто из очевидных особенностей реализации системы команд. Смотрю - для SH2, судя по roadmap, так и есть.

Про старшие SH4/SH5, к сожалению, могу только посмотреть картинки, подробной доки нет и шансов на ее приобретение тоже немного, тем более что это скорее "индпошив". Что же касается сравнения SH4/5 и MIPS64, то не очень высокочастотные чипы MIPS64 (RM5231/61, 400 МГц, не более 1.2 Вт, реально меньше) - вполне доступны и документация на них есть. Это не контроллер, но embedded вычислитель сделать на них можно. Достать и запустить SH7785, вероятно, тоже можно. FPU у него выглядит поспециализированнее на графике и подохлее на обычной полноразрядной математике, остальное - примерно баш на баш с учетом тактовой. Периферия побогаче у Renesas.

http://www.renesas.com/fmwk.jsp?cnt=sh7785...s/sh7785_group/

что касается подержки то тут SH и MIPS равны, gcc/gnu и linux имеют оба.

но мне кажется это дискуссия давно вышел за пределы начального вопроса так как микроконтроллеров с такими ядрами нет.

Нет "полноформатных" SH4/SH5, но MIPS-контроллеры есть. У PMC есть как экономичные 400 МГц MIPS32 - микроконтроллеры (MSP8110|20), так и более быстрые (до 1 ГГц) суперскалярные с FPU - MSP8510, это процессоры-контроллеры со встроенными 10|100|1000EthernetMAC, SDRAM int, нормальным контроллером прерываний, UART с FIFO, Watcdog/timers/SPI и т.п.. Еще Cavium делает быстрые и экономичные, в том числе многоядерные контроллеры с архитектурой как MIPS32, так и MIPS64 с кучей интерфейсов, правда, без FPU - а оно-то, IMHO, и представляет самую сильную сторону MIPS64.

Т.е. микроконтроллеры с быстрыми MIPS ядрами и встроенной периферией в виде готовых ИС есть.

[singlskv 0]

Если Вы заметили, в контроллерном контексте я говорил про SH2(А) и MIPS32, как самые экономичные. Кстати, официальные удельные производительности - 1,5 DMIPS/МГц у них как раз одинаковы, так что получается, что моя оценка подтверждается и официальными данными. Тактовую частоту в 200 МГц оценил навскидку, не смотря на roadmap, просто из очевидных особенностей реализации системы команд. Смотрю - для SH2, судя по roadmap, так и есть.

Давайте, так, остановимся толко на "контроллерных" чипах,

официальными для SH2A являются 2,4DMIPS/МГц, ну и это конечно сильно завышено, но 1,8-2.0

это уже где-то ближе к реальности...

Хотелось бы услышать Ваши коментарии конкретно про чипы 7201,7203,7263,7265.

[SIA 0]

Давайте, так, остановимся толко на "контроллерных" чипах,

официальными для SH2A являются 2,4DMIPS/МГц, ну и это конечно сильно завышено, но 1,8-2.0

это уже где-то ближе к реальности...

Хотелось бы услышать Ваши коментарии конкретно про чипы 7201,7203,7263,7265.

1. По поводу ядер и реальной производительности - я ее нашел только на SH2, на SH2А пока стороннего результата нету. Учитывая разницу 2 и 2А плюс доработку кодогенератора, ~1.8 DMIPS/МГц при небольшой "доводке" компилятора вполне реальны.

К примеру, для того же MIPS, даже самого простенького ядра 4Kс, в той бумаге, что я выкладывал, приведены как "тупые" 1.39 DMIPS/МГц, так и при разрешенной компилятору глубокой оптимизации, 1.8DMIPS/MГц. Для более сложных ядер там есть и 2.2, и 2.4 DMIPS/МГц для кода из-под компилятора (не "ручного").

 

По частотам и отчасти архитектуре на MIPS32 больше похоже более совершенное (чем SH2) семейство SH4, у них (с сайта Renesas) http://www.renesas.com/fmwk.jsp?cnt=sh4_ch...&title=SH-4

....

SH-4 family performance

The SH-4 family delivers impressive performance across a range of multimedia applications.

Benchmark Performance

Dhrystone 2.1 1.5 DMIPS / MHz (SuperH gcc)

.....

Недостаток - маловато регистров в FPU, из-за чего трудно использовать полную производительность FPU при цепочечных операциях в цикле, особенно при двойной точности, т.к. для этого нужно примерно 2,5...4*(длина конвейера) регистров.

 

Введение в качестве базовой операции FPU умножения матрицы на вектор - весьма рационально, у меня самого так было сделано в 1989 году. Выигрыш - существенное снижение запросного отношения (отношения числа доступов к памяти к числу полезных - алгоритмических - операций) при преобразованиях координат, выполнении ДКП/ДПФ/БПФ (особенно комплексного или вещественного с основанием 4) и на матричной алгебре типа решения СЛАУ (чем контроллер вряд ли будет заниматься).

 

Общее резюме - архитектура целочисленных ядер SH переусложнена, что снижает эффективность ее реализации.

Пока по рациональности архитектуры, похоже, что лучше MIPS ядер реально нет.

 

2. На 7265 доки пока нет, комментировать пока нечего. Выигрыш от двуядерности в среднем порядка 1.5, но иногда может быть даже больше двойного, если удается разрезать задачу поровну, за счет сокращения числа переключений контекста.

3. 7263 - "Все в одном", вплоть до CD-ROM декодера. Детально периферию не смотрел, видно, что он заточен под аудио-функции (необязательно суперкачественные, но чтобы было все - и прием данных с Toslink/AES, и с CD, и передискретизация, и всевозможные пролоджики/декодирования - 5.1 на процессоре).

4. 7201 - в целом вполне симпатичный камень. Только шин многовато - сложнее управление периферией, а так вполне.

Вообще, нужно смотреть по задаче. Если реально ничего особенного в именно вычислительном отношении не требуется - то что SH, что MIPS - это пальба из довольно громоздкой и прожорливой пушки по воробьям. При аккуратном подходе для преимущественно логических задач хватит недорогого и беспроблемного ARM, а то и быстрого х51. Реакция на прерывания у них быстрая. Лично был свидетелем того, что замена кода с кучей проверок и switch на табличноуправляемый конечный автомат позволила С8051F131 на неполной тактовой справиться с задачей, которую откровенно не успевал отрабатывать PC104 :)

5. Все упомянутые Вами процы Romless и работают от SDRAM, так что это (как и упомянутые мною MIPS) уже не совсем контроллеры, скорее встраиваемые процессоры. Более существенно то, что в описании, наскоро глянув с экрана, я не нашел (может и есть, но не заметил) или принудительного удержания в кэше команд кода обслуживания прерываний или наоборот, блокировки кэша для предотвращения замены его содержимого. Если это так, то из-за этого не только будет замедляться реакция на прерывание, но и увеличатся потери на замещение кэша после прерываний. Перезагрузка линеек кэша вносит задержку переключения контекста куда больше, чем время загрузки/сохранения регистров.

[singlskv 0]

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

Romless, но все же, оптимально держать обработку прерываний в SRAM, а там кеш

не играет никакой роли...

Вы пропустили в своем описании чип 7203, а он ИМХО, как раз самый интересный.....

[SIA 0]

Romless, но все же, оптимально держать обработку прерываний в SRAM, а там кеш

не играет никакой роли...

Вы пропустили в своем описании чип 7203, а он ИМХО, как раз самый интересный.....

Если процессору можно запретить при этом трогать кэш, чтобы не было вытеснения - то да, это оправданно.

Завтра внимательнее посмотрю, гляну 7203 - но ядро у него на первый взгляд вроде такое же как у 7201, разница в периферии.

Но честно, не зная задач оценивать трудно. А как "универсальный процессор на все случаи жизни" - таких, IMHO, не бывает.

Нелишне припомнить, что "Буран" успешно был посажен 16-битным (если мне не изменяет память) процессором с производительностью менее 10 MIPS и памятью 128К.

[singlskv 0]

Если процессору можно запретить при этом трогать кэш, чтобы не было вытеснения - то да, это оправданно.

Не очень понимаю о чем речь, для SRAM работающей на частоте проца наличие/отсутствие

кеша абсолтно пофиг... или я в чем то заблуждаюсь ?

Завтра внимательнее посмотрю, гляну 7203 - но ядро у него на первый взгляд вроде такое же как у 7201, разница в периферии.

ядро одинаковое, разные переферия и частоты ядра, ИМХО, просто очень правильный

чип/"контроллер" из топовых и при этом относительно недорогих...

Но честно, не зная задач оценивать трудно. А как "универсальный процессор на все случаи жизни" - таких, IMHO, не бывает.

Нелишне припомнить, что "Буран" успешно был посажен 16-битным (если мне не изменяет память) процессором с производительностью менее 10 MIPS и памятью 128К.

Дык и AVRом наверное можно было бы посадить :)

Ну а если говорить о задаче, пусть это будет замена промPC...

То есть не промПЦ в чистом виде, а замена промПЦ+(ну то что удасться впихнуть)....

[SIA 0]

Не очень понимаю о чем речь, для SRAM работающей на частоте проца наличие/отсутствие

кеша абсолтно пофиг... или я в чем то заблуждаюсь ?

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

 

Ну а если говорить о задаче, пусть это будет замена промPC...

То есть не промПЦ в чистом виде, а замена промПЦ+(ну то что удасться впихнуть)....

А смысл ? Разработка в целом будет долгой и соответственно достаточно дорогой, при тираже до ~50-100 шт. рентабельнее найти недорогую плату PromPC. Они более-менее приличные от $300-400 начинаются, и потребляют не так уж много. Если задача не слишком сложная - PTS DOS и вперед, при грамотной собственной программе машина виснуть не будет, и деньги от заказчиков пойдут быстрее, чем если возиться со своим железом.

[singlskv 0]

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

Ээээ... логику работы кеша которую Вы описываете, понимаю, в принципе,

не очень понимаю как это будет сказываться на работе прерывания обработка которого

лежит в SRAM, ну не будет там задержек в принципе, ну и если я чего-нить затру в области кеш

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

А смысл ? Разработка в целом будет достаточно дорогой, при тираже до ~50-100 шт. рентабельнее найти недорогую плату PromPC. Они от $300-400 начинаются.

Разработка софта что к ПромПЦ что к своей плате стоит намного больше чем стоимость одной

платы, так что здесь мало что съекономишь, но можно сделать просто более "правильное"

решение.... ну и тиражи не обязательно ограничиваются 50-100шт.....

[SIA 0]

Разработка софта что к ПромПЦ что к своей плате стоит намного больше чем стоимость одной

платы, так что здесь мало что съекономишь, но можно сделать просто более "правильное"

решение.... ну и тиражи не обязательно ограничиваются 50-100шт.....

Дело в сроке. Пока свое железо отладишь, в корпуса засунешь, интерфейсы подведешь - деньги и время на разработку уйдут. А на промПК можно сразу софт клепать

 

Ээээ... логику работы кеша которую Вы описываете, понимаю, в принципе,

не очень понимаю как это будет сказываться на работе прерывания обработка которого

лежит в SRAM, ну не будет там задержек в принципе.

Дело не в SRAM, задержку внесет контроллер кэша - ему же, прежде чем процессор начнет работать, целую строку (не одно слово) загрузить надо. Впрочем, для 200 МГц процессора в абсолютном измерении это немного, не больше нескольких сотен наносекунд (хотя и это порядка сотни команд проца).

[singlskv 0]

Дело в сроке. Пока свое железо отладишь, в корпуса засунешь, интерфейсы подведешь - деньги и время на разработку уйдут. А на промПК можно сразу софт клепать

На промПЦ софт уже есть,

Очень хотца сделать все на своем железе и более правильно...

Дело не в SRAM, задержку внесет контроллер кэша - ему же, прежде чем процессор начнет работать, целую строку (не одно слово) загрузить надо. Впрочем, для 200 МГц процессора в абсолютном измерении это немного, не больше нескольких сотен наносекунд (хотя и это порядка сотни команд проца).

А был ли мальчик ?

Вы уверенны что проц будет ждать загрузки всей строки в кеш перед тем как начать

исполнять инструкции ?

ИМХО, здесь паузы быть не должно...

[SIA 0]

Вы уверенны что проц будет ждать загрузки всей строки в кеш перед тем как начать

исполнять инструкции ?

ИМХО, здесь паузы быть не должно...

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

В быстрых процессорах не все так очевидно, многие сложившиеся исторически ранее приемы работы на них "не в кассу". Например, сильно развитая система команд, длинные конвейеры и куча слоев кэшей на задачах реального времени, где в коде между плохо предсказуемыми переходами всего по 5-10 команд, запросто приводят не к повышению системного быстродействия, а в основном лишь к повышению энергопотребления. Для рилтаймовой машины "навороты" часто вредны, а наибольшую пользу приносит предельно быстрая (по полному времени доступа!) память с небольшим (2...4) расслоением плюс процессор без "кучерявости", но с коротким конвейером, мощным АЛУ и максимальной частотой. При создании мейнфреймов это все было хорошо изучено еще 25-35 лет назад.