Ага, у Атмеля денег дофига, что ему стоить потратиться на разработку ядра avr32 и начать промышленный выпуск. Или по Вашему они удачно пыль в глаза пускают? Тут 32х-битники потихоньку съёдают 8 битники, поэтому и у avr32 будет, по моему, такой же пик популярности как и у avr8, скорее свего, это да же не 2008, а как минимум 2009.

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

все проблемы Атмел начинаются и кончаются здесь:
http://www.advfn.com/nasdaq/StockPrice.asp?stockprice=ATML

Дела у них не столь плохи.
Это у всех американских компаний сейчас такая ситуация, связанная с падением USD...

В рецессии Америка...

Именно так. Ключ к успеху - маркетинг, а не техническая рациональность или изощренность.
А дальше - закон снежного кома. Помним историю х86? Сама Intel, понимая ее кривость, еще "в те времена" дважды пыталась перейти на другую архитектуру - не вышло.
Motorola с реально хорошими 68К - по большому счету пролетела. Мало сбыта - высокая цена - мало сбыта - нет средств на совершенствование - закрытие темы....
Я и про MIPS (наступавший на те же грабли - неумение продавать реально хороший товар) вспомнил здесь только потому, что
а) люди в MIPS Technology похоже, таки маленько поумнели (занялись периферией, "голый" проц редко кому нужен, как бы ни был сам по себе хорош), и, главное (!)
Б) за маркетинг взялся Microchip, а у них это поставлено всегда было куда лучше, чем у Atmel Соответственно, и развитие темы будет, и MIPS поможет

Только вот судя по лихорадке с маркетологами у Atmel просто никак . Ибо "-Девушка, что Вы делаете сегодня вечером? -Все" это не маркетинг , это другое...

Вот про такие ситуации, когда надо "не в принципе, а конкретно", Saymor Cray и любил говорить "Машина, про которую нельзя точно сказать, что она будет делать в каждый машинный такт - в реальном мире неконкурентоспособна по определению. Даже если она и быстра в принципе, то на практике часто подобна сороконожке в припадке эпилепсии" .
Именно поэтому ядра процов, где нет четких цифр и черт ногу сломит в оценке времен - применять стоит не всегда. К примеру, даже при чисто расчетных задачах компилятор запросто "ногу сломит" при оптимизации потоков через конвейеры и раскладке по регистрам при вычислении даже простейших последовательных операций типа

A=aaa;
for (i=xxx;i>=0;i--)
{
B=C[i]+D[i]*E[i];
A+=B;
};

и будет вынужден дожидаться прохода по конвейеру всего первого выражения перед переходом к следующему накапливающему суммированию.
В результате проц не покажет и 1/5 скорости от той, что мог бы в теории при параллельном запуске ветвей в конвейер и совмещению суммирований.
В процах Intel/AMD это пытается разгребать аппаратура. С переменным успехом и жутким (по сравнению с собственно АЛУ) энергопотреблением.
Плюс непредсказуемость точного времени выполнения вообще. Оно в рилтайме надо ?

p.s. в ядрах MIPS, как и во многих других, особенно DSP, но почему-то далеко не во всех ARM, "жесткая" диаграмма обеспечена.

А можно ссылочку на весь текст? Интересно, в контексте обсуждения какого вопроса он это говорил?

Да семидесятые годы прошлого века. Лобовое решение за государственные денюжки - 80Mhz 64Bit очень круто. Но давно мир переменился. Переменился даже спустя 10 лет - Cray2 был многопроцессорный и судя по цитате страдал не только эпилепсией, но и шизофренией с размножением личности .

Времена безумно давние, нас тогда на свете не было.
А говорил при ответе на вопрос, почему транзисторная CDC6600 1964 года работает быстрее микросхемной IBM360/91 68-го
IBM по указанию своего президента купила экземпляр CDC6600 для исследований. Но это не помогло - следующее детище CDC - CDC7600 - оставило всех "с носом" и держало "голубую ленту" 8 лет. Тоже чисто транзисторная была машина (10...30 Мфлопс в зависимости от задачи). Дальше были уже Cray.


Нет, как раз не лобовое. Лобовое - это ILLIAC. И не на государственные денюжки (госзаказ из Ливермора пришел потом, после успешной демонстрации - более 100 Мфлопс на реальной задаче, при том что в описании обещалось "up to 80"). До этого Крэю пришлось все делать "на свои" (для чего пришлось продать свою долю в СDC). Все делали сами - и микросхемы (топологию ИС) рисовали, и схемы, и платы, и документацию. Весь коллектив создателей Cray1, при том, что это была разработка с нуля - от элементной базы включительно - меньше 20 человек, и денег было в обрез, экономили даже на рубилите (15 баксов лист - в 1975 году это были ДЕНЬГИ).
Зато продавались Cray как горячие пирожки именно потому, что цена выполненной полезной операции у машин Cray до начала 90-тых была наименьшей на рынке.
Плюс отличный компилятор, мало проигрывавший в циклах "ручному" коду, а местами и обставлявший его на распараллеливании.
До 90 года даже массовый ПК давал много меньше 1К флопс на доллар при несравнимых прочих характеристиках (у Cray Y-MP в те годы было ~ 800 флопс на доллар).
Сейчас самый дешевый полноценный (64-битный) флопс получается на MIPS64 и некоторых Power PC (IBM750СL ~$25 за Гфлопс).

p.s. Жесткая (предсказуемая) временная диаграмма - необходимое условие нормальной работы любого WLIW/EPIC процессора. Даже Intel такой сделала для серверов.

Посему не стоит серьезно относится к мемуарной литературе.

Даже самые продвинутые ошибаются (я про Saymor Cray). Не жёсткая и непредсказуемая временная диаграмма уже победила. Оглянитесь вокруг. Но это только начало долгого пути.

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

Так что к чёрту ностальжи - двигаем вперёд! Я, например, хотел бы поработать с многопроцессорными системами и побороться с непредсказуемостью.

Дык кто Вам мешает ?
ИМХО, ну начните с многопоточных приложений под windows, там все проблеммы как на
ладони....
Те если хочеш рабочую прогу то разобраться с многопоточностью придется....



Ну если не видите причин...
Предлагаю Вам проект вывода графики на телик(телеметрия например...)
Какой АРМ выберем ? Как будем выводить ?

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

А насчет "сложности компиляторов" - к сожалению, дело не в "программных технологиях" как таковых (кстати, компилятор для практически любой машины уже давно научились писать за разумные сроки, особенно после работ Гриса, Ахо/Ульмана и появления Lex/Yacc). Компилятор чистого С на них делается не больше, чем за месяц, дальше - "раскрутка" (трансляция написанного на С С++), и пошло-поехало. Задачу оптимальной раскладки регистров решил еще Ершов И "параллельных" языков довольно много (см. по ссылке в конце).

Дело в другом - в конфликте парадигм - "последовательное" написание кода и сильно распаралленное/конвейеризованное исполнение. Т.е. в человеческих мозгах, наработках и тоннах уже написанного кода.

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

А прорыв, кстати, уже есть, и именно для WLIW/EPIC, где есть жесткая диаграмма, которую компилятор может учесть при планировании трасс. Началось все с проекта Multiflow в 1980-х, затем доведено до живого продукта Дитцелом и компанией в Transmeta.
Но важно не это, а то, что Intel вложила в это направление большие деньги, и провела много НИОКР. О результатах части из них я знаю, выигрыш в производительности на единицу мощности потребления/площади кристалла действительно огромный - на порядок-полтора при той же технологии.

Идея именно в том, чтобы убрать из процессора дающую большие задержки логику планирования команд/загрузок/отслеживания конфликтов и фактически оставить только набор АЛУ/память, все планирование выполняет компилятор, генерирующий "длинные" команды для прямого управления аппаратурой. Кстати, примерно так (и по тем же самым причинам) и были сделаны крэевские машины, особенно последние, разработанные при его непосредственном участии.
Так что идея не устарела и вполне здравая. Похожим образом делаются как самые мощные DSP TMS, так и "бытовые" зверушки PNX1300/1500/1700.

На рынок ПК эта технология в полной мере вряд ли придет скоро. Проблема и в маркетинге, и в технике. Первое, при таком подходе нет 100% бинарной совместимости. Нужна перекомпиляция (пусть даже и "невидимая" для пользователя). Но желательно, с анализом исходника. Техническая проблема - для реализации достигаемого выигрыша в быстродействии для больших объемов данных предъявляются более высокие требования к пропускным способностям подсистем памяти. Т.е. нужна куча DIMM, чтобы был эффект - кеши не всесильны, их грузить откуда-то надо и быстро. А если всего этого нет и хочется оставить х86 бинарную совместимость, без анализа исходников - то получится Crusoe со всеми его недостатками (экономичный, но более-менее быстрый только на "родном" коде).
Для мощных же контроллеров с большими вычислительными возможностями - вполне то, что надо. Собственно, упомянутые PNX - и есть такие контроллеры.

За чисто параллельные и многопроцессорные вещи - это скорее в www.parallel.ru