производительность 8051 котроллеров Опции

[andron86]

Вопрос к спецам!

Возникла такая ситуация - приходится разбираться с конроллером от SiLabs C8051124, контролллер на 8051 ядре. В доку стоит максимально 50MIPS, 70% команд в 1 тактовый цикл. Тут как-то прищлось у одного спеца что-то по этому uM спросить- так он мне выдал, что это ядро устарело и что производительность контроллеров на этом ядре ужасно мала, в сравнении с другими архитектурами.

Объясните пожалуйста мне или киньте ссылочки на эту тему. Действительно ли это так?

Спасибо заранее!

Сообщение отредактировал andron86 - Mar 31 2006, 08:31

[elserge]

Этот спец наверное до конца не дослушал. Да, MCS-51 стар уже, но реализация у Cygnal/Silabs и других фирм, ядра которых выполняют простые команды не за 12 тактов, а за 1 с тактовыми частотами до 100 МГц, дали вторую жизнь архитектуре. Так что на Cygnal/Silabs ты имеешь в 12 раз более быстрое ядро, чем стандартное. Плюс развитая периферия. А еще много софта и библиотек. Так что MCS-51 рано закапывать.

[andron86]

Спасибо elserge!

А всё таки, можно где нибудь независимое сравнение контроллеров посмотреть?

[Andy Mozzhevilov]

Вопрос к спецам!

Возникла такая ситуация - приходится разбираться с конроллером от SiLabs C8051124, контролллер на 8051 ядре. В доку стоит максимально 50MIPS, 70% команд в 1 тактовый цикл. Тут как-то прищлось у одного спеца что-то по этому uM спросить- так он мне выдал, что это ядро устарело и что производительность контроллеров на этом ядре ужасно мала, в сравнении с другими архитектурами.

Объясните пожалуйста мне или киньте ссылочки на эту тему. Действительно ли это так?

Спасибо заранее!

Это действительно так.

[elserge]

А всё таки, можно где нибудь независимое сравнение контроллеров посмотреть?

Что-то было на САХАРЕ. www.caxapa.ru

[andron86]

Этот спец наверное до конца не дослушал. Да, MCS-51 стар уже, но реализация у Cygnal/Silabs и других фирм, ядра которых выполняют простые команды не за 12 тактов, а за 1 с тактовыми частотами до 100 МГц, дали вторую жизнь архитектуре. Так что на Cygnal/Silabs ты имеешь в 12 раз более быстрое ядро, чем стандартное. Плюс развитая периферия. А еще много софта и библиотек. Так что MCS-51 рано закапывать.

Это действительно так.

Хммм...????

[elserge]

Смотря с чем сравнивать! Ведь есть и 32-bit MCU. Так что попроси Andy Mozzhevilov рассказать поподробнее.

[Andy Mozzhevilov]

Этот спец наверное до конца не дослушал. Да, MCS-51 стар уже, но реализация у Cygnal/Silabs и других фирм, ядра которых выполняют простые команды не за 12 тактов, а за 1 с тактовыми частотами до 100 МГц, дали вторую жизнь архитектуре. Так что на Cygnal/Silabs ты имеешь в 12 раз более быстрое ядро, чем стандартное. Плюс развитая периферия. А еще много софта и библиотек. Так что MCS-51 рано закапывать.

Это действительно так.

Хммм...????

Мнение может быть у каждого свое. У меня такое.
Тема достаточно флеймовая, один из вариантов флейма можно почитать тут:
http://electronix.ru/forum/index.php?showtopic=6890&hl=

[aforestman]

Из практического опыта.
Philips P89LPC922 (ядро 2 цикла) на частоте 7Мгц прогоняет килобайт плоского кода за 0.35мс.
Так что, если Вас устраивает только 8-битная арифметика, то можно получить вполне достойные результаты.
Далее следуют Dallas, Cygnal и им подобные перепроектированные кристаллы.
А для некоторых областей применения, например логические операции над битами (у нас это 99% процентов программы), этой старой архитектуре ой как трудно найти замену.

[=AK=]

Интересно было бы найти объективное сравнение производительности разных 8-битных архитектур. Что-то вроде EEMBC Consumer Benchmark, которая для 32-битниых выглядит так: http://www.ptsc.com/images/performance_density.jpg

Довольно очевидно, что 51-е ядро вряд ли будет даже в первой десятке, так же, впрочем, как PIC16, HC08 и пр. старые архитектуры. Ядро AVR вполне может оказаться среди лидеров, имхо, хотя тоже не все там идеально, поскольку RISC. Кстати, еще интересно где бы оказался Тесей при таком сравнении.

[vladec]

Ошибочное мнение что при одинековом быстродействии RISC архитектура дает большую производительность чем CISC архитектура (как у 51), все с точностью до наоборот. Просто RISC архитектура позволяет получить большее быстродействие легче и с меньшими аппаратными затратами.

[Charley]

Спасибо elserge!

А всё таки, можно где нибудь независимое сравнение контроллеров посмотреть?

Привет!
Есть такая книга "Системы малой автоматизации" автор О.Николайчук, М.;Солон Пресс,2003,256с.
Там на странице 171 есть раздел "Несколько слов о пиковой производительности различных микроконтроллеров", а в нем рисунок 4.1 с интересными данными. Приводится пиковая производительность различных 8-разрядных микроконтроллеров:
С8051F120-123 up to 100MIPS
C8051F124-127 50
Other SiLabs 25
ATmega128 16
M77C32 10
DS80C310 8,25
MCS1210 8,25
T89C51RB2 6,67
и.т.д. Там еще с 10 микроконтроллеров!
Только следует сделать 3 замечания!
1. Я не привел тактовые частоты, которые на рисунке присутствуют....
2. Фирма SiLabs за 3 года выпустила еще с 20-30 микроконтроллеров с производительностью от 25 до 50 MIPS.
3. Здесь приводится пиковая производительность, т.е.производительность на максимальной тактовой частоте при выполнении самых коротких операций. Реальная производительность - понятие, задаче зависимое, например одно дело если вы обрабатываете, например символы,т.е.байты, и совсем другое, если, например, 24разрядные данные от АЦП... Реальная производительность для среднего класса задач обычно на 12-24% ниже от пиковой!

[andron86]

Спасибо Charley!

Более менее понятная раскладка? Не могли бы Вы мне, Пожалуйста, ещё картинку пересканировать и на email послать. Буду очень Признателен!

[spf]

Тут как-то прищлось у одного спеца что-то по этому uM спросить- так он мне выдал, что это ядро устарело и что производительность контроллеров на этом ядре ужасно мала, в сравнении с другими архитектурами.

Это действительно так.

+1, ИМХО

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

[Alexandr]

Есть такая книга "Системы малой автоматизации" автор О.Николайчук, М.;Солон Пресс,2003,256с.
Там на странице 171 есть раздел "Несколько слов о пиковой производительности различных микроконтроллеров", а в нем рисунок 4.1 с интересными данными.

А можете этот лист отсканировать и выложить сюда?

[defunct]

Ошибочное мнение что при одинековом быстродействии RISC архитектура дает большую производительность чем CISC архитектура (как у 51), все с точностью до наоборот. Просто RISC архитектура позволяет получить большее быстродействие легче и с меньшими аппаратными затратами.

Ну во первых, C51 это чистый RICS, можно даже сказать эталон RISC процессора.

Во вторых RISC архитектура максимально эффективно приспособлена для работы в режиме прерываний и переключения задач.

В третьих быстродействие и производительность это синонимы. Если Вы имели в виду сравнение производительности на одинаковых тактовых частотах, то здесь взависимости от задач в равной степени может победить и RISC и CISC. Если в системе часто происходят прерывания, то победит RISC, а CISC в свою очередь может попасть в ступор и тратить все свое время лишь на переключение между задачами. Мало прерываний - однозначно победит CISC.

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

Мое мнение таково:
По сабжу - C51 даже Cygnal на своих 100Mhz с 50MIPS по производительности один из аутсайдеров, и на задачах 32х битной целочисленной арифметики отстанет от 8-ми разрядной AVRки @16Mhz с актуальными ~10MIPS раз эдак в 10.

[Andy Mozzhevilov]

Ошибочное мнение что при одинековом быстродействии RISC архитектура дает большую производительность чем CISC архитектура (как у 51), все с точностью до наоборот. Просто RISC архитектура позволяет получить большее быстродействие легче и с меньшими аппаратными затратами.

Ну во первых, C51 это чистый RICS, можно даже сказать эталон RISC процессора.

Ну уж батенька, что-то вы не то тут сказанули, или описались.

[defunct]

Ну уж батенька, что-то вы не то тут сказанули, или описались.

Я писал эмулятор оного и архитектуру его знаю прекрасно. Но, конечно же, если Вы меня сможете переубедить ссылкой на документ от Intel'а где сказано, что C51 это CISC, тогда я заберу свои слова
обратно.

Приводится пиковая производительность различных 8-разрядных микроконтроллеров:
С8051F120-123 up to 100MIPS
C8051F124-127 50
Other SiLabs 25
ATmega128 16
M77C32 10
DS80C310 8,25
MCS1210 8,25
T89C51RB2 6,67

MIPSы разные бывают. К примеру 16 битное сложение: A(R1:R0) = A(R1:R0)+B(R2:R3)

C51:
XCH A, R0
ADD A, R2
XCH A, R0
XCH A, R1
ADDC A, R3
XCH A, R1

AVR:
ADD R0, R2
ADC R1, R3

Простейшее сложение и то первый тратит 6 инструкций, второй всего две. При работе с 32-х битными данными разница еще более существенная. И выливаются те 100MIPS в реальных (полезных) 5MIPS.

[Andy Mozzhevilov]

Ну уж батенька, что-то вы не то тут сказанули, или описались.

Я писал эмулятор оного и архитектуру его знаю прекрасно.

Ну какой же это RISС. Длина команд может быть 1 2 или 3 байта.
Работа напрямую с внутренней памятью, когда для RISC характерна load-store
архитектура и работа с данными через регистровый файл.
Тот же AVR для достижения своей RISС-овости имеет 16-битную длину команды,
чтобы эффективно паковать в нее инструкции.

Вот выдержка с сайта интела по отличительным признакам CISC-RISK:

A different line, derived from CISC, is represented by the RISC
(Reduced Instruction Set Computing) processors introduced in the
1980s, which are characterized mostly by how they differ from CISC
processors. The instructions are of fixed length, and of a regular format.
Operations are performed on registers only, of which a larger number
are available than on CISC processors. The only memory operations are
load and store. The hardware in RISC processors is simpler in principle
than in CISC ones, because a RISC architecture relies more on the compiler
for sequencing complex operations.

Но, конечно же, если Вы меня сможете
переубедить ссылкой на документ от Intel'а где сказано, что C51 это CISC, тогда я заберу свои слова
обратно.

Неплохо бы также увидеть ссылку на документ интела, где сказано, что x51 это RISC.

[dxp]

Ну уж батенька, что-то вы не то тут сказанули, или описались.

Я писал эмулятор оного и архитектуру его знаю прекрасно.

Ну какой же это RISС. Длина команд может быть 1 2 или 3 байта.
Работа напрямую с внутренней памятью, когда для RISC характерна load-store
архитектура и работа с данными через регистровый файл.
Тот же AVR для достижения своей RISС-овости имеет 16-битную длину команды,
чтобы эффективно паковать в нее инструкции.

Вот выдержка с сайта интела по отличительным признакам CISC-RISK:

A different line, derived from CISC, is represented by the RISC
(Reduced Instruction Set Computing) processors introduced in the
1980s, which are characterized mostly by how they differ from CISC
processors. The instructions are of fixed length, and of a regular format.
Operations are performed on registers only, of which a larger number
are available than on CISC processors. The only memory operations are
load and store. The hardware in RISC processors is simpler in principle
than in CISC ones, because a RISC architecture relies more on the compiler
for sequencing complex operations.

Вообще-то, тут спор из серии является ли тот или иной чип МК или DSP. Вон MSP430, про него явно указано фирмой производителем, что он RISC, 27 инструкций (в комбинациях способов адресации, ессно, их больше получается). Тем не менее операции регистр-память (и даже память-память - копирование) и разная длина инструкций присутствуют в полный рост. Правда, разная длина инструкций там отчасти обусловлена тем, что в опкоде могут храниться длинные литералы (полные адреса), сам опкод имеет структуру регулярную. Насколько мне всегда было известно, 51-й - это CISC.

[vladec]

51 контроллер, это типичнейший представитель CISC архитектуры. Что же касается понятий быстродействие и производительность, это также не одно и тоже. Быстродействие характеризует только среднее чило операций вылолняемых за единицу времени. А производительность, характеризует объем выполняемых задач определенного класса. То есть, у 8-битного и 32-битного контроллеров с одинаковым быстродействием будет разная производительность, например, на арифметических задачах.

[defunct]

Andy Mozzhevilov @ Apr 6 2006, 11:10)
Ну какой же это RISС. Длина команд может быть 1 2 или 3 байта.
Работа напрямую с внутренней памятью, когда для RISC характерна load-store
архитектура и работа с данными через регистровый файл.
Тот же AVR для достижения своей RISС-овости имеет 16-битную длину команды,
чтобы эффективно паковать в нее инструкции.

Обычный RISC.
Тут дело не в длине команды. load/store и работа с памятью напрямую - это одно и тоже. Чтение-модификация-запись - немного другое, но оно и не важно. если уж идти по такому пути SRAM в C51 можно считать большим регистровым файлом, а с внешней памятью он работает с помощью load/store. Все команды (кроме mul/div) выполняются не дольше 2х машинных циклов. CISCом его может сделать не длина команды в 3 байта и даже не трехоперандовая команда cjne (у AVR кстати есть команды длиной 4 байта), а всего лишь две команды mul ab и div ab которые выполняются "микропрограммным" путем. Если принебреч этими двумя командами или сделать их аппаратно, что в новых вариантах ядра C51 уже сделано, то чип становится классическим представителем RISC. Регистровые банки, быстрый переход на обработчик прерывания, небольшой (всего 111 меньше чем у AVR) набор команд.

если идти по пути подсчета байт в команде, то AVR явно бъет C51 своими 4х байтными командами.

Вообще-то, тут спор из серии является ли тот или иной чип МК или DSP. Вон MSP430, про него явно указано фирмой производителем, что он RISC, 27 инструкций (в комбинациях способов адресации, ессно, их больше получается). Тем не менее операции регистр-память (и даже память-память - копирование) и разная длина инструкций присутствуют в полный рост. Правда, разная длина инструкций там отчасти обусловлена тем, что в опкоде могут храниться длинные литералы (полные адреса), сам опкод имеет структуру регулярную. Насколько мне всегда было известно, 51-й - это CISC.

Спор действительно как раз из той серии. И не было бы никаких проблем если бы Intel классифицировал свой чип сам.

[defunct]

51 контроллер, это типичнейший представитель CISC архитектуры.

В чем? Где типичность CISC?

Берем CISC x86 берем первую попавшуюся команду Add Al, CS:[BX + SI + 4]. Может C51 хоть отдаленно похожее сделать?

Что же касается понятий быстродействие и производительность, это также не одно и тоже. Быстродействие характеризует только среднее чило операций вылолняемых за единицу времени. А производительность, характеризует объем выполняемых задач определенного класса. То есть, у 8-битного и 32-битного контроллеров с одинаковым быстродействием будет разная производительность, например, на арифметических задачах.

Не знаю. Там где я учился, быстродействие и производительность были синонимами. Может сейчас уже все не так. А вот получить эту производительность(быстродействие) можно двумя путями:
1. увеличив тактовую частоту,
2. распараллелив вычисления.

[bialix]

на самом деле CISC от RISC отличается набором возможных методов адресации: у CISC количтество методов адресации гораздо больше и они более хитровывернутые, чем у RISC.

51й CISC по той причине, что CISC. Сравните с PIC (разработанный примерно в тоже время) и почувствуйте разницу. Сравнивать с AVR тяжело, потому что последний относится к "продвинутым" RISC, сегодня грань между разными типами по-простому становится все менее и менее заметна.

[defunct]

на самом деле CISC от RISC отличается набором возможных методов адресации: у CISC количтество методов адресации гораздо больше и они более хитровывернутые, чем у RISC.

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

Сравните с PIC (разработанный примерно в тоже время) и почувствуйте разницу. Сравнивать с AVR тяжело, потому что последний относится к "продвинутым" RISC, сегодня грань между разными типами по-простому становится все менее и менее заметна.

Сравнивать с AVR и с ARM нужно, потому что эти семейства сегодня определяют RISC архитектуру. Сравнивать же с разработками древних времен, когда еще не было разграничения на RISC и CISC как раз не стоит.

[dxp]

CISCом его может сделать не длина команды в 3 байта и даже не трехоперандовая команда cjne (у AVR кстати есть команды длиной 4 байта),

там 2 байта - это просто тупо полный адрес. Сам опкод вегда 16 бит.

а всего лишь две команды mul ab и div ab которые выполняются "микропрограммным" путем. Если принебреч этими двумя командами или сделать их аппаратно, что в новых вариантах ядра C51 уже сделано, то чип становится классическим представителем RISC. Регистровые банки, быстрый переход на обработчик прерывания, небольшой (всего 111 меньше чем у AVR) набор команд.

У AVR просто в табличке расписано много однитипных команд - типа установить бит-такой-то, сбросить бит-такой-то. Фактически там все сводится к операциям загруке из памяти в регистры/сохранения значений регистров в память, а все остальные операции произоводятся непосредственно с регистрами (за исключением нескольких команд для работы с I/O. Т.е. у AVR совершенно четко прослеживается разделение инструкций по разным классам.

Если речь идет о современных однотактовых клонах, то там внутри уже совсем не 51-й, действительно бодрый RISC. В классическом же 51-м все не так круто. Вдумайтесь, почему у него такая длинная растактовка - 1 цикл из 12 тактов. Не иначе микроавтомат там по этим тактам работает. И инструкций там 256 штук - в смысле 256 опкодов, на каждый вариант какого-нибудь мува - свой опкод. Полный набор инструкций - он и есть Complete. И если у RISC'ов в опкоде операнды кодирутся, то у 51-го по большей части все проще - просто выделен отдельный опкод и все.

если идти по пути подсчета байт в команде, то AVR явно бъет C51 своими 4х байтными командами.

Никого он там не бьет. 4-байтные команды, где тащится полный адрес - lds/sts никто использовать не заставляет. Можно грузить указатель и от него работать, что, кстати, прекрасно делает IAR'овский компилятор. lds/sts удобнее и чуть выгоднее при разовом обращении. Если хотя бы надо к двум байтам обратиться, то уже паритет. Если больше, то уже проигрывает.

[defunct]

Если речь идет о современных однотактовых клонах, то там внутри уже совсем не 51-й, действительно бодрый RISC. В классическом же 51-м все не так круто. Вдумайтесь, почему у него такая длинная растактовка - 1 цикл из 12 тактов. Не иначе микроавтомат там по этим тактам работает. И инструкций там 256 штук - в смысле 256 опкодов, на каждый вариант какого-нибудь мува - свой опкод. Полный набор инструкций - он и есть Complete. И если у RISC'ов в опкоде операнды кодирутся, то у 51-го по большей части все проще - просто выделен отдельный опкод и все.

Не совсем верно. У C51 как раз именно 111 опкодов. Первый байт команды даже не может принимать все 256 значений байта. Навскидку по памяти пример invalid opcode - $A5. А большое число как бы опкодов первого байта команды из-за того, что там располагается адрес 11 битного операнда для команд ACALL/AJMP, а также в первом байте кодируются и номера регистров, т.е. и второе утверждение (насчет того, что у 51-го по большей части все проще - тоже не совсем верно).

если идти по пути подсчета байт в команде, то AVR явно бъет C51 своими 4х байтными командами.

Никого он там не бьет. 4-байтные команды, где тащится полный адрес - lds/sts никто использовать не заставляет. Можно грузить указатель и от него работать, что, кстати, прекрасно делает IAR'овский компилятор. lds/sts удобнее и чуть выгоднее при разовом обращении. Если хотя бы надо к двум байтам обратиться, то уже паритет. Если больше, то уже проигрывает.

Я имел в виду бъет по длине команды.

PS: ну если все хотят считать C51 CISCом - Аминь.

[=AK=]

Andy Mozzhevilov @ Apr 6 2006, 11:10)
Ну какой же это RISС. Длина команд может быть 1 2 или 3 байта.
Работа напрямую с внутренней памятью, когда для RISC характерна load-store
архитектура и работа с данными через регистровый файл.
Тот же AVR для достижения своей RISС-овости имеет 16-битную длину команды,
чтобы эффективно паковать в нее инструкции.

Обычный RISC.
Тут дело не в длине команды. load/store и работа с памятью напрямую - это одно и тоже.

Не могу согласиться. Архитектура 51-го никаким боком не подходит под RISC. Даже Мелкочип свои PIC-и осторожно называл RISC-like. Вот не самое плохое определение RISC:

(Reduced Instruction Set Computer) A computer architecture that reduces chip complexity by using simpler instructions. RISC compilers have to generate software routines to perform complex instructions that were previously done in hardware by CISC computers. In RISC, the microcode layer and associated overhead is eliminated.

RISC keeps instruction size constant, bans the indirect addressing mode and retains only those instructions that can be overlapped and made to execute in one machine cycle or less. The RISC chip is faster than its CISC counterpart and is designed and built more economically.

Проверяем 51-й:

-- Проще набор инструкций. Соглашаться или нет - дело вкуса, однако по здравому размышлению я бы соглашаться не стал. Инструкций в 51-м много, и они сильно разномастные, неструктурированные. Просто из "большого набора" возможных CISC-инструкций выбраны те, которые наиболее употребительны в embedded-приложениях, чтобы общее количество не превышало 256 (один байт кода команд). Что явно не RISC. Про AJMP размусоливать не буду, на мой взгляд, это явный ляп разработчиков, ненужная по жизни команда, которая зазря съедает множество кодов.
Здесь я бы добавил такой характерный признак: из набора RISC команд выброшены те, которые удобны для программирования на ассемблере, но неудобны при написании компиляторов ЯВУ. При таком уточнении 51-й - совершенно точно не RISC, его система команд явно создавалась с заботой об ассеблерщиках. Для настоящего RISC-а писать программы на ассемблере должно быть мучением и мазохизмом. В идеале - брэйнфак с одной командой. Для 51-го это условие не выполняется, для него вполне приятно на ассемблере писать.

-- Отсутствует микрокодирование команд. Насколько мне известно, в оригинальном 51-м оно имело место быть. По крайней мере, когда я пытался заказать в МЭП-е советский клон i8044 (это 51-й с SDLC), разработчики сразу же сказали что будут делать с микрокодом, да еще хотели растактовку сделать не на 12 клоков, а на 16

-- Постоянный размер команд. В 51-м этот наиболее характерный признак RISC отсутствует, размер команд переменный.

-- Нет косвенной адресации. На мой взгляд, не самый важный признак, но все же: в 51-м она есть, однако...

-- В определении об этом забыли, но вообще-то RISC должен любую команду выполнять за 1 такт, что неверно для 51-го. Имхо, поэтому PIC и не называли настоящим RISC-ом, хотя по другим признакам он подходит. Еще у старых PIC-ов система команд тоже оптимизировалась для ассемблерного написания программ, а не для ЯВУ.

[Stanislav]

...Для настоящего RISC-а писать программы на ассемблере должно быть мучением и мазохизмом. В идеале - брэйнфак с одной командой.

Простите, но с этим вынужден не согласиться. Например, ADSP-21xx от AD - типичный RISC-процессор, кроме того, истинно однотактовый (хотя внутренний генератор имеет 4 фазы, но это несущественно). Более приятного и лёгкого для освоения ассемблера, чем у ADSP, я до сих пор не встречал. Однотактовость и отсутствие конвейера делает процесс создания софта на асме гораздо менее трудоёмким занятием, чем для любого другого известного мне процессора, как RISC, так и CISC.

[Evgeny_CD]

...В идеале - брэйнфак с одной командой. ...

Их там вроде 8
http://www.caxapa.ru/mcu/wwwboard.html?id=56255

[defunct]

Проверяем 51-й:

Хорошо, давайте проверим. Заодно чтобы проверять было легче, возьмем для сравнения AVR ибо RISC.

-- Проще набор инструкций. Соглашаться или нет - дело вкуса

Набор инструкций C51 проще чем AVR, AVR - RISC, следовательно C51 этому параметру удовлетворяет.

-- Отсутствует микрокодирование команд. Насколько мне известно, в оригинальном 51-м оно имело место быть. По крайней мере, когда я пытался заказать в МЭП-е советский клон i8044 (это 51-й с SDLC), разработчики сразу же сказали что будут делать с микрокодом, да еще хотели растактовку сделать не на 12 клоков, а на 16

Про выполненение команд микропрограммно, я уже отмечал. Да в оригинальном C51 есть микропрограммыный блок управления, но он обусловлен лишь несовершенством технологий на то время. Наличие усовершенствованных однотактовых ядер C51 говорит о том, что сегодня система команд C51 - удовлетворяет параметрам RISC. А если из оригинала убрать div/mul то и оригинальный C51 процессор удовлетворяет этому параметру. Неужели только из-за пары команд стоит переводить процессор в класс CISC процессоров, которые совсем не предназначены для решения задач, которые решают МК. Битовый CISC процессор звучит по крайней мере глупо.

-- Постоянный размер команд. В 51-м этот наиболее характерный признак RISC отсутствует, размер команд переменный.

Размер команды практически постоянный 1/2 байт. 3 байта относится только к тем командам где работа производится с 16-битным адресом или 16-битными данными. Исключение, такое же как и в других RISC процессорах, где исп. команды дальнего (far) вызова и перехода.

-- Нет косвенной адресации. На мой взгляд, не самый важный признак, но все же: в 51-м она есть, однако...

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

-- В определении об этом забыли, но вообще-то RISC должен любую команду выполнять за 1 такт, что неверно для 51-го. Имхо, поэтому PIC и не называли настоящим RISC-ом, хотя по другим признакам он подходит. Еще у старых PIC-ов система команд тоже оптимизировалась для ассемблерного написания программ, а не для ЯВУ.

Неправда! В определении RISCа нет ограничений в 1 такт, есть ограничение в 1-2 цикла. У PIC'а цикл исполнения команды - 4 такта, у C51 - 12, невелика разница. А насчет якобы оптимизации системы команд PIC'a для якобы "удобства написания программ на ассемблере" я могу сказать лишь: PIC ассемблер - наиболее "козий" и неудобный в использовании из всех с которыми мне доводилось работать.


Мое мнение таково - практически любой 8 битный MK это RISC, как минимум по двум причинам -
1. система команд (как даже вы заметили для C51) сокращена
напомню ваши слова:

Просто из "большого набора" возможных CISC-инструкций выбраны те, которые наиболее употребительны в embedded-приложениях

Когда что-то оставляют, а все остальное выбрасывают - это называется сокращение "reduction" не так ли? Так вот для C51 из CISC навыбрасывали столько всего, что от CISC осталось меньше инструкций, чем напихано в современных RISC процессорах. Да и ставить C51 в одну шеренгу с современными CISC - P4/AMD64 просто смешно.

2. быстрая реакция на прерывания (основная особенность характерная для всех RISC процессоров).
Про регистровые банки, которые способствуют быстрому пререключению задач характерной для RISC вы в своем сравнении почему-то забыли. А ведь по этому параметру C51 гораздо ближе к RISC чем тот же AVR.
Еще разок повторюсь: хотите считать C51 CISCом вопреки здравому смыслу - Аминь.

[andron86]

Кстати, для более осмысленного спора 3 странички с data sheet (8051uM)!

Прикрепленные файлы

 8051_1.pdf ( 39.76 килобайт ) Кол-во скачиваний: 249

 

[Kopa]

Прочитал топик и решил высказать свое мнение

что RISC, что CISC архитектуры применительно к MK имеют свои недостатки и преимущества.

Определяющие факторы здесь следующие
1. Желание максимально эффективно использовать для хранения команд байты памяти
Если увеличивать размер команды, то будет возрастать при работе потребление кристалла.
2. Основные признаки отнесения MK к RISK:
- разделение команд на арифметические и команды пересылки данных в/из регистров AЛУ
- большой регистровый пул.

Другие менее принципиальные признаки.

- фиксированный размер команд
- однотактное выполнение команд
- ортогональность системы команд.

3. Производительость и удобство программирования MK не взаимосвязанные понятия.

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

Микрокод работы процессоров еще никто не отменил и на какой реально частоте работают
внутри контроллеры не всегда ясно при однотактном выполнении команд.

Bye.,

[=AK=]

Набор инструкций C51 проще чем AVR, AVR - RISC, следовательно C51 этому параметру удовлетворяет.

В качестве контраргумента: набор команд PIC намного проще и меньше, чем у 51-го, и все равно микрочип называет его "недо-RISC". Если следовать Вашей логике, это дает основания называть 51-й "недо-недо-RISC", или, что короче, "не-RISC".

Однако спорить на таком уровне аргументации я могу разве что для смеха. Я уже указывал, что, с моей точки зрения, для RISC-а важной являеется цель, ради которой его система команд "уменьшена", а не само по себе количество команд. И для RISC цель эта одна: переложить заботы "микропрограммирования" сложных команд на компилятор ЯВУ. У 51-го же набор команд оптимизировался совсем не для этого.

Еще пример, процессор Ignite фирмы PTSC. У него код команд вообще 6-битный (или даже 5-битный, запамятовал). И что, кто-нибудь называет его RISC-ом? Ни в коем случае, под определение RISC он не подходит, цели преследовались другие. Этот процессор относится к классу MISC - "компьютер с минимальным набором команд", но никак не RISC.

Цель, поставленная при проектировании, а также совокупность использованных приемов, вот что главное. Приколотил, скажем, Лютер к двери церкви свои 10 (или сколько там) тезисов, каждый сам по себе возражений ни у кого не вызовет, так что - на этом основании всех надо записать лютеранами?

Мое мнение таково - практически любой 8 битный MK это RISC, как минимум по двум причинам -
1. система команд (как даже вы заметили для C51) сокращена

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

2. быстрая реакция на прерывания (основная особенность характерная для всех RISC процессоров).

Ну никаким боком это к RISC-ам не относится, совершенно ортогональное свойство. Cтоит заметить, что RISC-и вообще говоря как раз медленно реагируют на прерывания, поскольку должны сохранять в стеке свои здоровенные регистровые файлы, а потом восстанавливать их. Лучше всего на прерывания реагируют стековые процессоры определенного вида, т.к. им для сохранения-восстановления контекста вообще ничего делать не надо.

Про регистровые банки, которые способствуют быстрому пререключению задач характерной для RISC вы в своем сравнении почему-то забыли. А ведь по этому параметру C51 гораздо ближе к RISC чем тот же AVR.

Потому что банки эти - вовсе не прерогатива RISC-ов, а как раз-таки наоборот, вовсю использовались именно в CISC-ах, в том числе в таком типичном CISC-е как 51-й

[Andy Mozzhevilov]

Мое мнение таково - практически любой 8 битный MK это RISC, как минимум по двум причинам -
1. система команд (как даже вы заметили для C51) сокращена

Самый рисковый риск - это Z80 )), а также все производные от него кролики.

Вообще, 8 и 16 битные uC максимально могут претендовать только на RISC-like, но не более того.
И то, даже те из 8 битников, которые заявлены как RISC имеют ширину команды более 8 бит, (например, 12 для pic и 16 для avr).
А для 16-битников заявка на risc - это не более чем маркетинговый ход, дань моде.
А вообще, как хотите, так и считайте, пошел уже спор ради спора.

[defunct]

По поводу вышесказанно спорить просто не хочу т.к. бесполезно. А вот насчет последнего утверждения позвольте в корне несогласиться.

2. быстрая реакция на прерывания (основная особенность характерная для всех RISC процессоров).

Ну никаким боком это к RISC-ам не относится, совершенно ортогональное свойство. Cтоит заметить, что RISC-и вообще говоря как раз медленно реагируют на прерывания, поскольку должны сохранять в стеке свои здоровенные регистровые файлы, а потом восстанавливать их. Лучше всего на прерывания реагируют стековые процессоры определенного вида, т.к. им для сохранения-восстановления контекста вообще ничего делать не надо.

Во первых, напомню, что любой процессор первым делом при запросе на прерывание, дожидается завершения выполения текущей команды. У CISC команды могуть быть и 12-ти и 20-ти и более байтовыми, соответсвенно колоcсальные временнЫе затраты уходят не только на их испольнение, но и на выборку. Следовательно как минимум в этой фазе CISC уступает RISCу по скорости реакции на IRQ.
Во вторых, процессор (RISC), имеющий в своем распоряжении много регистров, может вообще ничего не сохранять в стеке (кроме адреса возврата), т.к. регистров предостаточно, и каждая задача может использовать исключительно свой набор регистров. Если компиляторы не используют эту возможность, значит они гнилые.

Про регистровые банки, которые способствуют быстрому пререключению задач характерной для RISC вы в своем сравнении почему-то забыли. А ведь по этому параметру C51 гораздо ближе к RISC чем тот же AVR.

Потому что банки эти - вовсе не прерогатива RISC-ов, а как раз-таки наоборот, вовсю использовались именно в CISC-ах, в том числе в таком типичном CISC-е как 51-й

Извините, но "не смешите тапочки" ;>

[=AK=]

Во первых, напомню, что любой процессор первым делом при запросе на прерывание, дожидается завершения выполения текущей команды. У CISC команды могуть быть и 12-ти и 20-ти и более байтовыми, соответсвенно колоcсальные временнЫе затраты уходят не только на их испольнение, но и на выборку. Следовательно как минимум в этой фазе CISC уступает RISCу по скорости реакции на IRQ.

Неубедительно. CISC не обязан иметь длинные команды в системе команд. Некоторые CISC-и имеют такие команды, другие - нет. CISC, выполняющий любые команды за 1 такт, не станет от этого RISC-ом.

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

Это не решение. Оно годится только для очень простых приложений, где количество задач у уровней вложения прерывания ограничено каким-то смешным минимумом, обязательно статическим. Для динамически создаваемых задач этот довод вообще не в кассу.

В общем случае решение есть только одно - сливать регистры в стек. И здесь RISC-и ковыляют далеко позади многих других.

[defunct]

Во первых, напомню, что любой процессор первым делом при запросе на прерывание, дожидается завершения выполения текущей команды. У CISC команды могуть быть и 12-ти и 20-ти и более байтовыми, соответсвенно колоcсальные временнЫе затраты уходят не только на их испольнение, но и на выборку. Следовательно как минимум в этой фазе CISC уступает RISCу по скорости реакции на IRQ.

Неубедительно. CISC не обязан иметь длинные команды в системе команд. Некоторые CISC-и имеют такие команды, другие - нет. CISC, выполняющий любые команды за 1 такт, не станет от этого RISC-ом.

CISC не может выполнять команды быстрее RISC'a, т.к. команды сложные. Если же он выполняет команды за 1 такт, то это значит, что как минимум у него есть конвеер, который при обработке запроса на прерывание придется сбросить.

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

Это не решение. Оно годится только для очень простых приложений, где количество задач у уровней вложения прерывания ограничено каким-то смешным минимумом, обязательно статическим. Для динамически создаваемых задач этот довод вообще не в кассу.

В общем случае решение есть только одно - сливать регистры в стек. И здесь RISC-и ковыляют далеко позади многих других.

Тут без коментариев.

[Evgeny_CD]

Народ, а не проще "заезд" устроить:
* 51 100 Мгц от SiLabs
* AVR 20 Мгц от Atmel

Ну и задачи разные
* FIR/IIR фильтры
* FFT (например, 256)
* вычисления в плавучке
* рисование текста в GUI (взять какой-нибудь гуй простенький, например 128х64 1bit per pixel, и работать с виртуальным frame buffer в памяти)
* ...

Хотя, вероятно, C код универсальным не получится - слишком уж разные архитектуры...

А то так можно долго спорить...Некие тесты обсуждались тут - но они достаточно спорные...
http://www.telesys.ru/wwwboards/mcontrol/1...es/104416.shtml
http://www.caxapa.ru/mcu/wwwboard.html?id=35158
http://electronix.ru/forum/index.php?showtopic=6279&hl=

[=AK=]

CISC не может выполнять команды быстрее RISC'a, т.к. команды сложные,

Сложные команды нельзя выполнять за один такт? Обоснование не представите?

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

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

Конвеер равно фиолетово относится как к CISC-ам, так и к RISC-ам. То есть, и там и там он может быть или не быть. В RISC-ах конвеер встречается чаще.

Неплохая статья: http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html
1. RISC was not a specific technology as much as it was a design strategy that developed in reaction to a particular school of thought in computer design. It was a rebellion against prevailing norms--norms that no longer prevail in today's world.
2. "CISC" was invented retroactively as a catch-all term for the type of thinking against which RISC was a reaction.
3. We now live in a "post-RISC" world, where the terms RISC and CISC have lost their relevance (except to marketing departments and platform advocates). In a post-RISC world, each architecture and implementation must be judged on its own merits, and not in terms of a narrow, bipolar, compartmentalized worldview that tries to cram all designs into one of two "camps."

[defunct]

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

Распишите (хотя бы для себя на листочке) по шагам как должно быть построено железо, чтобы сделать за 1 такт команду: например, чтение (пусть будет 128-битного, хотя здесь неважно пусть разрядность будет равна разрядности шины данных) слова из памяти, умножение на слово в регистре и запись удвоенного по разрядности результата обратно в память. (для CISC такая команда вполне возможна).

Я извиняюсь, но вести далее спор мне не интересно, т.к. аргументы чем дальше тем больше становятся все более и более голословными. А сам спор превращается в трату времени.
могу предложить вам ознакомиться с информацией о CISC и RISC для начала хотя бы из толкового словаря:
http://helpcomp.net/dictionary/r/risc.php
http://helpcomp.net/dictionary/c/cisc.php

[=AK=]

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

Распишите (хотя бы для себя на листочке) по шагам как должно быть построено железо, чтобы сделать за 1 такт команду: например, чтение (пусть будет 128-битного, хотя здесь неважно пусть разрядность будет равна разрядности шины данных) слова из памяти, умножение на слово в регистре и запись удвоенного по разрядности результата обратно в память. (для CISC такая команда вполне возможна).

Это чем-то отличается от команды умножения с операндами в регистрах? То есть, по-вашему, регистры чем-то принципиально отличаются от памяти? Так же точно и сделаю за один такт, как делается на регистрах. Гарвардская архитектура, слова в памяти данных 256-разрядные, шина данных тоже, обращение возможно к половине слова (128 разрядов) или к целому слову. Для чистоты мысленного эксперимента при этом регистров как таковых вообще не буду иметь, и при этом пусть любая ячейка памяти может использоваться так же, как в привычных нам процах используется аккумулятор. Чтоб совсем не было сомнений, что это CISC, вместо умножения предлагаю сделать команду извлечения квадратного корня. Для простоты и устрашения, делать буду табличным методом, для 256-разрядных операндов. Раззудись плечо, размахнись рука, ресурсы-то по условию задачи даны немеряные!

[defunct]

Это чем-то отличается от команды умножения с операндами в регистрах? То есть, по-вашему, регистры чем-то принципиально отличаются от памяти?

Конечно. Хотя бы тем, что операция чтения из памяти как минимум требует одного такта (хотя в действительности может быть больше). В то время как регистры могут быть непосредственно подключены к входам и выходу АЛУ. Для выполнения такой команды потребуется на мой взгляд как минимум 4 цикла обращения к памяти (хотя может быть и больше).

Так же точно и сделаю за один такт, как делается на регистрах.

Ну давайте Вы вначале сделаете набросок, а потом расскажете, какой длины получился у Вас конвеер.
Я вас не тороплю с ответом.


Не подумайте, что я проигнорировал Ваш вопрос.

Сложные команды нельзя выполнять за один такт? Обоснование не представите?

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

CISC не может выполнять команды быстрее RISC'a, т.к. команды сложные. Если же он выполняет команды за 1 такт, то это значит, что как минимум у него есть конвеер, который при обработке запроса на прерывание придется сбросить.

т.е. CISC, при некоторой длине конвеера, может обеспечить фактическое время выполнения команды - 1 такт, может и быстрее 0.5 такта и т.п., но при запросе на прерывание конвеер сбросится, что приведет к потере сразу множества команд находящихся на разной стадии исполнения. И не нужно забывать, что фактическое время совсем несоизмеримо с реальным временем выполнения команды.

Самый рисковый риск - это Z80 )), а также все производные от него кролики.

Смайлик заметил, но для полноты картины Z80 это не МК, а МП.

[=AK=]

Это чем-то отличается от команды умножения с операндами в регистрах? То есть, по-вашему, регистры чем-то принципиально отличаются от памяти?

Конечно. Хотя бы тем, что операция чтения из памяти как минимум требует одного такта (хотя в действительности может быть больше). В то время как регистры могут быть непосредственно подключены к входам и выходу АЛУ. Для выполнения такой команды потребуется на мой взгляд как минимум 4 цикла обращения к памяти (хотя может быть и больше).

Не согласен. Регистры принципиально ничем от памяти не отличаются. Память - это просто регулярный массив регистров. Из экономических соображений "обычная" память делается как можно проще, поэтому ее возможности более ограничены по сравнению с регистрами. По условию задачи у меня этого ограничения нет, я могу прокладывать сколько угодно шин и подключать память к АЛУ как мне заблагорассудится. Без конвейера, который ставится опять-таки только лишь из экономии, чтобы можно было использовать более медленную (по сравнению с регистрами) память.

Представляю еще один вариант воплощения, в котором используется строго 128-битная шина данных.
Каждая 128-битная ячейка памяти имеет ассоциированный с ней умножитель 128х128. Например, старшее 128-битное слово результата с выхода умножителя прописывается назад в саму ячейку, младшее 128-битное слово прописываеется в соседнюю с ней ячейку. Для чего между всеми соседними парами ячеек проложен свой специальный 128-битный пук проводов, и к каждой ячейке добавлен еще мультиплексор. То есть, под эту конкретную команду у меня кусочек АЛУ встроен прямо в каждую ячейку памяти, но при этом память осталась регулярным массивом, как ей дОлжно быть. Расточительно? Конечно. Однако технически реализуемо? Несомненно. За 1 такт. Безо всяких конвейеров.

[defunct]

Не согласен. Регистры принципиально ничем от памяти не отличаются.

Ок, вносим ясность, память - не регистровая и не ассоциотивная, обычный SRAM или DRAM.

Представляю еще один вариант воплощения
...

Интересно, только IMHO такой реализацией вы сделали очень крутой RISC процессор. Кроме того, Вы забываете про выборку команды, т.к. CISC это не спец процессор и его возможности не заканчиваются на одной команде. Этапы, которые проц. должен реализовать: "выборка команды", "декодирование", "загрузка операндов", "выполнение действия АЛУ", "запись результата".

[=AK=]

Ок, вносим ясность, память - не регистровая и не ассоциотивная, обычный SRAM или DRAM.

За что такая немилость? Это нечестно! Разве тот же 51-й или AVR используют DRAM? Я думаю, никто из нас толком не знает, какова встроенная память в любом проце, но уж наверняка не DRAM, и очень может быть что не SRAM в обычном понимании. Какова кэш-память в том же пентюхе?

Ну ладно, пусть будет SRAM. Скажем, для 50МГц проца возьмем SRAM или даже PSRAM с 10 нс циклом, чтобы иллюзий не было. Однако пристроим ее прямо на чип , протянем шины от каждой ячейки по надобности, и вообще добавим к каждой ячейке железа не скупясь. Не RISC же делаем

Интересно, только IMHO такой реализацией вы сделали очень крутой RISC процессор.

Ну никаким боком он не RISC. Потому что сумма целей моих при этом была прямо противоположна целям RISC-а. Я не стремился уменьшить кол-во железа и переложить исполнение сложных команд на компилятор ЯВУ. Наоборот, я стремился выполнить сложные команды в железе, не считаясь с расходом кремния. Типичный CISC подход.

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

Поэтому ничто не мешает построить CISC, в котором все команды будут выполняться за 1 такт. Что и требовалось доказать.

Кроме того, Вы забываете про выборку команды, т.к. CISC это не спец процессор и его возможности не заканчиваются на одной команде. Этапы, которые проц. должен реализовать: "выборка команды", "декодирование", "загрузка операндов", "выполнение действия АЛУ", "запись результата".

Где скрижали, на которых написано, что CISC не имеет права делать эти действия (все или часть) за один такт? Чтобы он не имел права выполнять все команды за один такт? Чтобы было прямо сказано, что RISC-у это можно, а CISC-у - ни-ни, ни в коем случае, иначе это и не CISC, а невесть что, то ли (внеклассовый?) "спец-процессор", то ли "крутой RISC".

Почему это спец-процессор не может быть CISC-ом? A RISС-ом он может быть, или тоже "низзя-а-а-а" (с) ?

[defunct]

Ну ладно, пусть будет SRAM. Скажем, для 50МГц проца возьмем SRAM или даже PSRAM с 10 нс циклом, чтобы иллюзий не было. Однако пристроим ее прямо на чип , протянем шины от каждой ячейки по надобности, и вообще добавим к каждой ячейке железа не скупясь. Не RISC же делаем

Это будет уже не SRAM, а регистровая память.

Ну никаким боком он не RISC. Потому что сумма целей моих при этом была прямо противоположна целям RISC-а. Я не стремился уменьшить кол-во железа и переложить исполнение сложных команд на компилятор ЯВУ. Наоборот, я стремился выполнить сложные команды в железе, не считаясь с расходом кремния. Типичный CISC подход.

ну как же не RISC, громадный регистровый файл, короткие однотипные команды, и аппаратная реализация команд
Волей-неволей у Вас получился именно RISC для решения монстрячей задачи ;>

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

Поэтому ничто не мешает построить CISC, в котором все команды будут выполняться за 1 такт. Что и требовалось доказать.

Ваше утверждение сомнительно. Потому что решение, представленное Вами, - НЕПОЛНОЕ, и на его основе нельзя утверждать, что у Вас получилось реализовать эту команду за такт.

"выборка команды", "декодирование", "загрузка операндов", "выполнение действия АЛУ", "запись результата".

Где скрижали, на которых написано, что CISC не имеет права делать эти действия (все или часть) за один такт? Чтобы он не имел права выполнять все команды за один такт? Чтобы было прямо сказано, что RISC-у это можно, а CISC-у - ни-ни, ни в коем случае, иначе это и не CISC, а невесть что, то ли (внеклассовый?) "спец-процессор", то ли "крутой RISC".

Вероятно таких скрижалей нет, все в руках разработчиков.
Да пожалуйста, сделайте за один такт все этапы без конвеера. Почему-то пока этого никому не удавалось.. Только тогда возникает вопрос, Вы часом не в Intel'е работаете? А если в Intel'е, так почему же до сих пор не сделали такой проц?

Почему это спец-процессор не может быть CISC-ом? A RISС-ом он может быть, или тоже "низзя-а-а-а" (с) ?

хм.. ну спец вычислитель я бы не относил ни к тому, ни к другому, т.к. есть еще названный Вами MISC и неназванный VLIW.

[=AK=]

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

Это будет уже не SRAM, а регистровая память.

Что Вы подразумеваете под словами "регистровая память"?

Вот это:
http://www.whatis.ru/hard/mem11.shtml
"Регистровая память
Registered Memory это память с регистрами, которые служат буфером между контроллером памяти и чипами модуля. Регистры уменьшают нагрузку на систему синхронизации и позволяют набирать очень большое количество памяти (16 или 24 гигабайт) не перегружая цепи контроллера.
Но данная схема имеет недостаток - регистры вносят задержку в 1 такт на каждую операцию, а значит - регистровая память медленнее обычной при прочих равных условиях. То есть - оверклокеру неинтересна (да и стОит она очень дорого)"

или же вот это:
http://www.intuit.ru/department/hardware/archhard2/5/
"На нижнем уровне иерархии находится регистровая память - набор регистров, входящих непосредственно в состав микропроцессора (центрального процессора - CPU)."

Если последнее, то почему обычные процики (AVR, PIC, Z8, и т.д) могут использовать такую память (на кристалле, непосредственно в составе проца), а мне в моем "супер-пупер CISC-е" в этом отказано? Если Вы скажете, что тот же AVR не может делать никаких арифметических и т.п. операций с операндами в памяти, я возражу, что он RISC, поэтому и не может. Разработчики пожалели железа, потому и не сделали.

Мне железа не жалко, и я сделаю проц примерно такой же, как ранние ЭВМ 50-х и 60-х годов, которые называть RISC-ами смешно. Возьму за основу, например, трехадресную БЭСМ-4м, снятую с производства в 1963 г., в которой, как я помню, регистров не было вообще, а все операции выполнялись непосредственно на памяти. Главное что изменю - поставлю быструю память и сделаю все операции однотактными. Без конвеера, ессно, т.к. в оригинале конвеера не было. Не придумали еще.

Поскольку регистров в моем CISC-е нет, то при прерываниях сохранять ничего не надо. Померявшись скоростью реакции на прерывания (которых, впрочем, в БЭСМ-4 может и не было, не буду врать, не знаю, но к своему процу я их прикручу, уж будьте покойны) , RISC-и со своими регистрами и конвеерами нервно покурят в сторонке

Если Вы и такую реинкарнацию БЭСМ-4 вопреки здравому смыслу и очевидности назовете RISC-ом, то далее убеждать Вас в чем бы то ни было я отказываюсь.

[defunct]

Что Вы подразумеваете под словами "регистровая память"?

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

Первое Ваше определение совсем не относится к микропроцессорам.

Второе определение как раз то, что надо.

Если последнее, то почему обычные процики (AVR, PIC, Z8, и т.д) могут использовать такую память (на кристалле, непосредственно в составе проца), а мне в моем "супер-пупер CISC-е" в этом отказано?

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

Если Вы скажете, что тот же AVR не может делать никаких арифметических и т.п. операций с операндами в памяти, я возражу, что он RISC, поэтому и не может.

Здесь вы перегибаете палку, в Вашем варианте решения задачки, Вы как раз и предлагаете сделать все по образу и подобию AVR. А потом почему-то говорите, что у Вас получился не RISC.

Разработчики пожалели железа, потому и не сделали.

?

Мне железа не жалко, и я сделаю проц примерно такой же, как ранние ЭВМ 50-х и 60-х годов, которые называть RISC-ами смешно. Возьму за основу, например, трехадресную БЭСМ-4м, снятую с производства в 1963 г., в которой, как я помню, регистров не было вообще, а все операции выполнялись непосредственно на памяти.

БЭСМ-4 выполняет такую команду (как мы здесь обсуждаем) за 1 такт? Из Ваших слов следует, что нет.

Главное что изменю - поставлю быструю память и сделаю все операции однотактными. Без конвеера, ессно, т.к. в оригинале конвеера не было. Не придумали еще.

Вот этого я от вас и добиваюсь. Услышать или увидеть теоретически возможное решение, где учтены все пять, приведенных выше, этапов выполнения команды. И при этом оставаться в рамках CISC архитектуры (небольшое число рабочих регистров и еще меньшее число РОН).

Поскольку регистров в моем CISC-е нет, то при прерываниях сохранять ничего не надо. Померявшись скоростью реакции на прерывания (которых, впрочем, в БЭСМ-4 может и не было, не буду врать, не знаю, но к своему процу я их прикручу, уж будьте покойны) , RISC-и со своими регистрами и конвеерами нервно покурят в сторонке

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

Если Вы и такую реинкарнацию БЭСМ-4 вопреки здравому смыслу и очевидности назовете RISC-ом, то далее убеждать Вас в чем бы то ни было я отказываюсь.

Я, к своему стыду, не знаю архитектуры БЭСМ-4, поэтому ничего не могу сказать не только про ее реинкарнацию, но и про оригинал.


Напомню, для читателей этой ветки, что у нас обсуждение идет в контексте конкретного вопроса:
"Какая архитектура лучше приспособлена для задач, в которых требуется максимально быстрая реакция на прерывание?"
Я утверждаю, что RISC архитектура специально разрабатывалась для решения таких задач и это есть ее основной козырь и в то же время отличие от CISC. Уважаемый опонент, пока что (субъективно, насколько я могу судить) неубедительно, показывает, что и CISC архитектура может обеспечивать столь же быструю реакцию на прерывания, но к сожалению (опять же субъективно) он в своих решениях приходит к RISC архитектуре.

[=AK=]

Читайте, думайте:
http://www.microprocessor.sscc.ru/great/


Еще посмотрите описание Нейрон чипа (LON) и задумайтесь, действительно ли в нем три процессора, или все-таки один стековый процессор, способный мгновенно переключать контекст, три раза за полный 6-тактный цикл. Отвечать не требуется, извините, мне Ваше мнение не интересно.

http://www.microprocessor.sscc.ru/great/app.html
"The technical term RISC has been swamped by the marketing term RISC to the point that it's lost almost all meaning as a technical term. Almost everything now is described as RISC, even when it isn't"

[defunct]

Отвечать не требуется, извините, мне Ваше мнение не интересно.

Очень жаль, что все дошло до указаний..
Вам не интересно отличное от Вашего мнение, так что с того?


За ссылки спасибо, почитаю.
Табличка кривовато скопирована или нарисована, ось смещена в сторону CISC.

[Jevys]

Если говорить о производительности 8051, то 8051 в версии Silabs на мой взгляд выглядит очень достойно для решения многих задач. По сравнению с классическим частота ядра выше в 8 раз, команды выполняются быстрее в 10 раз и плюс умножитель. Итого получается примерно в 100 раз выше чем производительность основного советского микроконтроллера 1816ВЕ31, на котором работало много неплохих устройств.

Используем Silabs уже 3года, запустили в производство целую серию устройств. Софт пишем как на ассемблере так и на Си. В целом довольны, те задачи которые в нашей области раньше решались на DSP, теперь успешно решаются на 8051. Запас производительности большой, загрузка процессора 20-40%. 8051 выбрали потому, что было много наработок для этой платформы.

Но в будущих разработках конечно планируем ARM. Ориентируемся на LPC. По скромным прикидкам у него все долно быть в 3-4 раз лучше чем Silabs.

[_Bill]

Вопрос к спецам!

Возникла такая ситуация - приходится разбираться с конроллером от SiLabs C8051124, контролллер на 8051 ядре. В доку стоит максимально 50MIPS, 70% команд в 1 тактовый цикл. Тут как-то прищлось у одного спеца что-то по этому uM спросить- так он мне выдал, что это ядро устарело и что производительность контроллеров на этом ядре ужасно мала, в сравнении с другими архитектурами.

Объясните пожалуйста мне или киньте ссылочки на эту тему. Действительно ли это так?

Спасибо заранее!

Однозначно трудно что-либо конкретно сказать. Все зависит как от характера задач, так и от критериев сравнения. Года три назад я попросил (для сравнения контроллеров) выложить результаты трансляции простенькой функции на Си для МК типа X51 и PIC. Результаты Вы можете увидеть здесь:
Телесистемы
Конечно, они могут ни о чем не сказать, а могут сказать о многом. Далее, могут быть критерии никак не связанные с производительностью. Если взять тот же SiLabs, то его производительность на частоте 50 МГц может оказаться выше чем у AVR на частоте 16Мгц. А как тут будет с потребляемой мощностью? А как тут будет с ценами контроллеров? Короче говоря, вопросов что, как и почему будет множество. И сравнивать надо в каждом конкретном случае.

[mse]

Если взять тот же SiLabs, то его производительность на частоте 50 МГц может оказаться выше чем у AVR на частоте 16Мгц.

Ну верно, смотря какая задача. Если арифметика, то АВР на 16 его и на 50 может вдуть. А если логика, типа ножкой-флажком поболтать, портами пошевелить, то Силаб 16-МГЦ АВРа и на 16 уест. Не в разы, и не везде, ессно.

[_Bill]

Народ, а не проще "заезд" устроить:
* 51 100 Мгц от SiLabs
* AVR 20 Мгц от Atmel

Ну и задачи разные
* FIR/IIR фильтры
* FFT (например, 256)
* вычисления в плавучке
* рисование текста в GUI (взять какой-нибудь гуй простенький, например 128х64 1bit per pixel, и работать с виртуальным frame buffer в памяти)
* ...

Хотя, вероятно, C код универсальным не получится - слишком уж разные архитектуры...

А то так можно долго спорить...Некие тесты обсуждались тут - но они достаточно спорные...
http://www.telesys.ru/wwwboards/mcontrol/1...es/104416.shtml
http://www.caxapa.ru/mcu/wwwboard.html?id=35158
http://electronix.ru/forum/index.php?showtopic=6279&hl=

Прошу прощения за повтор, но ...
PIC vs. X51 vs. AVR
Там приведены коды одной и той же простенькой функции. Легко можно посчитать время выполнения такой функции на разных контроллерах.
И еще здесь
Немного об арифметике.

Сообщение отредактировал _Bill - Jun 3 2006, 19:17