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

под эфективностью/производительностью я имел в виду именно производительность
на 1МГц тактовой ну и набор переферии...
понятно что со старшими MIPS сравнивать нет смысла, но вот эфективность
архитектуры/ядра/переферии в комплексе, если "грубой силы" достаточно, впечатляет...
Ну и двухядерные контроллеры у них тоже уже есть SH7265

1. Да. И главное - реальная (а не рекламная) производительность (с учетом мощности потребления и разрядности). Если вычислительной мощности не хватает - все, проект помер. Нехватающую периферию/память можно приделать, а вот ресурсов CPU на реальном коде - не добавишь.
2. Очевидно, хотя тут при необходимости присобачить что-то свое довольно легко (АЦП там).
3. Библиотеки - да, хочется сэкономить время, но в результате часто быстрее написать свое.
4. ТУЛЧЕЙН - ГЛАВНОЕ. Хочется универсальный, например, GNU/GCC.
5. Отладочное железо - тоже статья расходов. Хорошо хоть живет достаточно долго.
6, 7 - понятно, хорошая разработка часто для надежности сразу делается на двух разных камнях (но по возможности с одинаковым тулчейном).


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

кажется Вы не особо в курсе с развитием 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 имеют оба.
но мне кажется это дискуссия давно вышел за пределы началного вопроса так как микроконтроллеров с такими ядрами нет.

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

Нет "полноформатных" 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 ядрами и встроенной периферией в виде готовых ИС есть.

Давайте, так, остановимся толко на "контроллерных" чипах,
официальными для 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) уже не совсем контроллеры, скорее встраиваемые процессоры. Более существенно то, что в описании, наскоро глянув с экрана, я не нашел (может и есть, но не заметил) или принудительного удержания в кэше команд кода обслуживания прерываний или наоборот, блокировки кэша для предотвращения замены его содержимого. Если это так, то из-за этого не только будет замедляться реакция на прерывание, но и увеличатся потери на замещение кэша после прерываний. Перезагрузка линеек кэша вносит задержку переключения контекста куда больше, чем время загрузки/сохранения регистров.

Romless, но все же, оптимально держать обработку прерываний в SRAM, а там кеш
не играет никакой роли...
Вы пропустили в своем описании чип 7203, а он ИМХО, как раз самый интересный.....

Если процессору можно запретить при этом трогать кэш, чтобы не было вытеснения - то да, это оправданно.
Завтра внимательнее посмотрю, гляну 7203 - но ядро у него на первый взгляд вроде такое же как у 7201, разница в периферии.
Но честно, не зная задач оценивать трудно. А как "универсальный процессор на все случаи жизни" - таких, IMHO, не бывает.
Нелишне припомнить, что "Буран" успешно был посажен 16-битным (если мне не изменяет память) процессором с производительностью менее 10 MIPS и памятью 128К.

Не очень понимаю о чем речь, для SRAM работающей на частоте проца наличие/отсутствие
кеша абсолтно пофиг... или я в чем то заблуждаюсь ?
ядро одинаковое, разные переферия и частоты ядра, ИМХО, просто очень правильный
чип/"контроллер" из топовых и при этом относительно недорогих...
Дык и AVRом наверное можно было бы посадить
Ну а если говорить о задаче, пусть это будет замена промPC...
То есть не промПЦ в чистом виде, а замена промПЦ+(ну то что удасться впихнуть)....

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


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

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

Разработка софта что к ПромПЦ что к своей плате стоит намного больше чем стоимость одной
платы, так что здесь мало что съекономишь, но можно сделать просто более "правильное"
решение.... ну и тиражи не обязательно ограничиваются 50-100шт.....

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


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

На промПЦ софт уже есть,
Очень хотца сделать все на своем железе и более правильно...
А был ли мальчик ?
Вы уверенны что проц будет ждать загрузки всей строки в кеш перед тем как начать
исполнять инструкции ?
ИМХО, здесь паузы быть не должно...

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