[defunct 0]

Проверяем 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 0]

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

8051_1.pdf

[Kopa 0]

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

 

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

 

Определяющие факторы здесь следующие

1. Желание максимально эффективно использовать для хранения команд байты памяти

Если увеличивать размер команды, то будет возрастать при работе потребление кристалла.

2. Основные признаки отнесения MK к RISK:

- разделение команд на арифметические и команды пересылки данных в/из регистров AЛУ

- большой регистровый пул.

 

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

 

- фиксированный размер команд

- однотактное выполнение команд

- ортогональность системы команд.

 

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

 

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

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

операнда команды.

 

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

внутри контроллеры не всегда ясно при однотактном выполнении команд.

 

Bye.,

[=AK= 12]

Набор инструкций 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 0]

Мое мнение таково - практически любой 8 битный MK это RISC, как минимум по двум причинам -

1. система команд (как даже вы заметили для C51) сокращена

 

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

 

Вообще, 8 и 16 битные uC максимально могут претендовать только на RISC-like, но не более того.

И то, даже те из 8 битников, которые заявлены как RISC имеют ширину команды более 8 бит, (например, 12 для pic и 16 для avr).

А для 16-битников заявка на risc - это не более чем маркетинговый ход, дань моде.

А вообще, как хотите, так и считайте, пошел уже спор ради спора.

[defunct 0]

 

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

 

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

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

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

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

 

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

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

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

[=AK= 12]

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

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

 

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

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

 

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

[defunct 0]

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

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

 

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

 

 

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

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

 

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

 

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

[Evgeny_CD 0]

Народ, а не проще "заезд" устроить:

* 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= 12]

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 0]

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

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

 

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

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

http://helpcomp.net/dictionary/r/risc.php

http://helpcomp.net/dictionary/c/cisc.php

[=AK= 12]

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

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

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

[defunct 0]

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

 

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

 

 

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

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

Я вас не тороплю с ответом.

 

 

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

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

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

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

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

 

 

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

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

[=AK= 12]

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

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

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

 

Представляю еще один вариант воплощения, в котором используется строго 128-битная шина данных.

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

[defunct 0]

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

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

 

 

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

...

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