OSDev

DSP -- это обработка сигналов (аналоговых, непрерывно изменяющихся во времени), к изображениям никакого отношения не имеющая (ну, если не обрабатывать видеосигнал -- не путать с декодированием всяких там MPEGов и т.д. и т.п., это абсолютно разные вещи). Такие процессоры появились задолго до того, как компьютеры стали запрягать для обработки изображений, монтажа видео и т.д. и т.п. Например, DSP является основным обработчиком информации в сколько-нибудь современных радиолокационных и гидроакустических станциях, и лишь совсем примитивные установки 1930-50-х годов (и отчасти 1960-х у буржуев и 1970-х у нас) их лишены. Они выполняют, например, анализ поступающих сигналов, отфильтровывают помехи и т.д.

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

Кстати, с полгода назад Гриндарс для чего-то заглянул в даташит по какому-то из современных DSP, заодно сказав мне об этом по жаберу. Я ответил нечто вроде: "Буду сильно ржать, если окажется, что архитектура этого DSP близка к древним, 1960-х годов, супер-мэйнфреймам Control Data". Пришлось ржать: как оказалось, идейно архитектура этих DSP совпадала с означенными машинами CDC чуть ли не на 100% (разница в разрядности, числе регистров и т.д., но не в "идеологии"). Правда, в истории CDC проиграли конкурентную борьбу мэйнфреймам от IBM, но, пока они были живы, именно им принадлежали рекорды производительности на вычислительных задачах, в т.ч. связанных с обработкой сигналов. Ну а у IBM машины оказались значительно универсальнее (в частности, прекрасно подходили для решения "экономических" задач) и дешевле, но хуже для таких сравнительно узких задач -- поэтому живут до сих пор, но в роли суперсерверов, а не числодробилок.



На практике она появилась незначительно раньше, чем DirectX 10, и далеко не в таком удобном виде. Использование графических процессоров для выполнения неграфических работ возможно только в случае, если эти самые графические процессоры имеют более-менее универсальный набор команд, в частности, поддерживают динамические ветвления и т.п. Всем этим требованиям в достаточной степени соответствовали только видюхи последнего перед официальным появлением DirectX 10 поколения (у АТИ не помню что, а у Невидии -- ГеФорце 7ххх). Тем не менее, гибкость их была намного меньше, чем у ориентированных на ДиректХ 10 (в частности, не было виртуальной памяти, что сильно усложняло жизнь). Отсутствие поддержки этого на уровне АПИ ОС (т.е., если говорить о Винде, в ДиректХ) я в данном случае не рассматриваю вообще, поскольку речь идёт о технических ограничениях железа.

Ну а что там разрабатывали студенты-аспиранты -- это вообще никакой роли не играет. Если на то пошло, никаких принципиально новых идей с 1970-х годов так и не возникло; совершенствуется (или доводится до маразма, в чём особо преуспела Intel, если говорить о процессорных архитектурах) лишь то, что было придумано несколько десятилетий назад. Речь идёт исключительно о том, что стало доступным на практике для широкого круга потенциальных пользователей, а не о том, что придумали в какой-то лаборатории.

http://www.ixbt.com/news/hard/index.shtml?15/33/83
С учётом того что производство шаблонов вещь дорогая. (Неужели Японци это не автоматизировали?) Походу это лидер на долгие времена.

А ещё АРМ уже анонсировал версию 8 своей архитектуры -- 64-разрядную. Правда, пока подробного описания нет, и, судя по всему, до идеала ей будет далеко, но всё лучше, чем уродство от Интел и АМД.

Пы.Сы. Вот интересно, всем более-менее современным процессоростроителям религия не позволяет при увеличении разрядности кардинально поменять систему команд, отказавшись вообще от какой бы то ни было совместимости с предыдущими архитектурами? ДЕК в своё время так и сделала, получив из прекрасной 16-разрядной архитектуры прекрасную 32-разрядную...

О, я всё хотел спросить, а чем? Чем плох intel я знаю. Но ARM ихмо ничем не лучше. Чего вы там хорошего нашли?

Архитектура АРМ намного стройней, чётче и проще. В частности, из 16 прямо адресуемых регистров в "родной" системе команд АРМ 13 полностью равноправны, а специальное назначение имеют только три. У ИА-32, как помните, все 8 регистров неравноправны -- у каждого есть специфические функции, проявляющиеся в определённых командах. Более того, у системы команд АРМ нет миллиона вариаций кодов для одной и той же по сути инструкции в зависимости от того, какие там регистры используются и т.п. Конечно, в случае с Тумбой стройность нарушается, но всё ж не до такой степени, как это имеет место в ИА-32. Так, во всех командах обработки данных Тумбы всегда доступны младшие 8 регистров, которые при этом полностью равноправны, ну а остальные 8 регистров доступны лишь в нескольких командах и посему практически не используются. Кодирование команд в Тумбе сложней, чем в АРМе, но многократно проще, чем в ИА-32, причём логика кодирования запомниается очень быстро, а посему не возникает проблем при выборе оптимальной для любого случая последовательности команд. Даже расширение Тумбы (система команд Thumb-2, появившаяся в 7-й версии архитектуры), по своим возможностям почти соответствующее родной системе команд АРМ, запоминается легко и просто, хотя там команды кодируются то двумя, то четырьмя байтами. Самих команд тоже в несколько раз меньше, и нельзя сказать, что это плохо: вспомните, какая часть системы команд ИА-32 используется на практике. Правда, необходимость для обработки данных предварительно загрузить эти самые данные из памяти в регистр (это, кстати, единственное, в АРМах осталось от РИСК-архитектуры) несколько напрягает, но к этому быстро привыкаешь. В общем, АРМ в железе получается много проще, чем ИА-32 с одинаковой степенью суперскалярности, за счёт намного более простого и стройного кодирования команд (ну а исполнительные блоки одинаковы вообще у любой архитектуры: правила двоичной арифметики от неё не зависят). Добавьте к этому намного более простое управление памятью (естественно, там, где оно вообще есть) -- никаких дурацких сегментов, таблицы переадресации проще, чем у ИА-32, и т.д. А в итоге получаем резкое уменьшение стоимости кристалла и потребления энергии.

Но, безусловно, АРМ очень далека от идеальной архитектуры. И сама концепция РИСК оказалась порочной (почему от неё почти полностью отошли), и даже в её рамках далеко не всё делалось грамотно...

АДД. Ещё забыл упомянуть режимы процессора. Хотя в собственно АРМах их формально больше, чем у ИА-32, реально они между собой идентичны и отличаются привилегированностью (один режим непривилегированный, все остальные -- привилегированные) и используемым набором регистров, в частности, указателей стека. С точки зрения программирования все они идентичны (ну, кроме, может быть, какого-то там нового режима в 7-й версии архитектуры: я с ним никак не сталкивался и не знакомился; он типа нужен для какой-то там безопасности, но думаю, больше для того, чтобы повысить безопасность работы изначально кривых систем типа Линуха). Ну а в ИА-32 сами знаете: что ни режим -- то куча уникальных особенностей, распространяющихся и на управление процессором в этом режиме, и на собственно программирование...

А как же FPU и SIMD сопроцессоры? Неужели стройность команд остаётся?
Ихмо ARM команд много, так что стройности мало. Просто архитектура молодая поэтому много ещё не добавили.

Режимов вы сами сказали много ещё больше чем у intel. Кто сказал что похожи? Вы описания видели там каждый режим описан так как у intel не описывается. Так что особенностей больше, что хуже. С чего-бы вдруг такие сложные описания?
Если бы всё было просто все описывалось кратко и лаконично.

MPU в процессоре присутсвует. Без него никуда. Надо будет сравнить, но не думаю что оно сделано лучше чем у intel.
Сто-пудово нет динамического размера страниц?

А если еще заглянуть в ссылку что я дал выше ещё и виртуализацию добавили.

Так что ARM монстер ещё тот.

Как ни странно, остаётся.



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



Прежде чем говорить ерунду насчёт "особенностей больше", изучите внимательно предмет, а затем сравните и количество, и качество различий между режимами у АРМа и режимами ИА-32. А что касается краткости и лаконичности описания, то это, извините, никакого отношения к сложности архитектуры вообще не имеет. Вы, например, даже элементарные вещи таким языком излагаете, что зачастую невозможно понять, о чём речь; и что, на основании Вашей неспособности внятно изъясняться (письменно, во всяком случае) на русском языке надо теперь любую ерунду объявлять суперсложной?



Глупость. Ни MMU, ни MPU не являются необходимыми компонентами процессоров: мир не заканчивается на Линухе и Винде, которые без MMU жить не могут (хотя Линух есть и в обрезанном варианте, без виртуальной памяти -- ucLinux вроде зовётся; ему MMU не нужно). В одних моделях что-то из этого есть, в других -- нет. Под конкретную задачу выбирается конкретный процессор с конкретными возможностями. Если мне надо снимать показания с пяти датчиков и передавать их по RS-232, на кой ляд мне MMU сдалось? Чтоб процессор больше стоил и больше жрал? И, кстати говоря, уже то, что АРМов нет сегментации, делает их управление памятью одновременно и проще, и лучше: в ИА-32 сегментация только мешает, не принося никакой реальной пользы, а не использовать её невозможно из-за бредовости архитектуры (пускай даже использование и сводится к единоразовому заполнению таблицы дескрипторов и загрузке селекторов в соответствующие сегментные регистры).



Динамического размера страниц нет и в ИА-32, насколько помню. Вот страницы разных размеров -- они есть и там, и там, но в АРМ всё проще.



Ага, только эта самая виртуализация присутствует в 5% процессоров, а в остальных её нет за ненадобностью (у ИА-32, кстати говоря, она тоже не во всех процессорах имеется, хотя здесь есть определённые сомнения: возможно, что в младших моделях её просто искусственно блокируют из "рыночных" соображений). Как в 70% нет MMU -- за той же самой ненадобностью. Плюс остаётся открытым вопрос о сложности этой самой виртуализации (а у ИА-32 с этим точно хуже, поскольку существуют две принципиально разные схемы виртуализации: интеловская и АМДшная, которые между собой совершенно не совместимы).

Но что могу сказать с полной уверенностью, так это то, что создание для АРМа полноценной системы виртуальных машин возможно без всякой аппаратной поддержки виртуализации, достаточно лишь наличия MMU (т.е. ситуация та же самая, что в своё время была на ИБМовских мэйнфреймах, где впервые СВМ и появилась). Ну а на ИА-32 СВМ без аппаратной поддержки виртуализации невозможна в принципе: ряд системных команд являются непривилегированным, а значит, невозможно обеспечить их программную эмуляцию...

Кстати говоря, полное описание архитектуры АРМ 7-й версии (последней на данный момент) занимает 2158 страниц; а у Интела -- 4040. Не кажется ли Вам, что вдвое больший объём документации как бы намекает?

Интересно ваше мнение что скажете насчёт этой модели арма?
http://arm.com/files/downloads/Cortex-A ... ecture.pdf
Мне понравилась.

Интересно!

Мне самого интригуют АРМ процессоры. Вот буду заниматься пайкой, куплю себе такой один.
Сложно ли на базе АРМ устройство свое делать???

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