Архитектрура системы команд 8-разрядного МК, Оценка/Анализ/Архитектура 8-32 разрядного МК Опции

[vitja]

Передо мной поставлена задача (сам напросился) - дать предложения по архитектуре
системы команд 8-разрядного процессорного ядра для управления работой аппаратуры SOC,
совместимой с ЯВУ, удобной для программирования на ассемблере, простой в реализации
и обеспечивающей компактный программный код и малое число тактов на его выполнение.

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

Потом, как учили в аспирантуре, провел анализ влияния особенностей системы команд процессора
на его эффективность rating.pdf
http://moko.ru/mc/


Затем поступил не так, как учили, и вместо того, чтобы взять за основу архитектуру известного МК,
предложил концепт "простого" 8-разрядного процессорного ядра на базе стековой архитектуры,

который позволяет обрабатывать данные до 32-разрядов и не только на стеке, но и в памяти,
задавать в байтовой команде сколь угодно длинные поля констант и адресов,
и еще некоторые рюшечки и фишечки (там же M8.zip) плюс заявка на патент ......2008.

Концепт получился приемлемый, если сравнивать с 8051, PIC, AVR и даже ARM Thumb, но не идеальный:

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

2. Из него (концепта) торчат уши PICа - страничная организация памяти, что не позволяет обеспечить линейный доступ к данным,
AVRровские регистры косвенной адресации, а не механизм адресации данных по ссылкам и пр.
Переходить на 32-разрядный формат команды не позволяет постановка задачи, а решить эти проблемы,
оставаясь в рамках 8-разрядной системы команд у меня пока не получается.

Люди добрые, посмотрите хотя бы по диагонали moko.ru/mc и помогите "бедному" разработчику, кто чем может по делу,
без ля-ля-ля, смайликов и спама, - советом, предложением, позитивной критикой и замечаниями. Не дайте загинуть концепту.

Сообщение отредактировал vitja - Jan 16 2009, 12:07

[mikesm]

Позитивная критика. Во первых верный адрес файла http://moko.ru/mc/RatingMC.pdf
Во вторых, по моему, совершенно нет никакого смысла вот так глубоко анализировать затраты кода и производительности
на каждый МК. С практической точки зрения, критичными параметрами являются не доля затрат на некую команду,
а совершенно другие факторы: питание, тактовая частота, объем оперативной памяти, и число тактов на одну команду.
И уже существующие процессоры практически выбрали все варианты.
Т.е. типовой микроконтроллер работает при 3V на 8МГц. Мы берем сравнимые по цене процессоры.
И если он на 3.3V работает на 8МГц, выполняет пересылку регистр регистр за один такт, что еще от
него нужно?
Прирост производительности на 23% по сравнению с аналогами не сыграет никакой роли, потому что
идет массовый переход на C, а значит производительность программы будет зависеть от возможностей
компилятора. Который попросту завалит все преимущества.
Еще один ключевой момент, это наличие периферии, простота ее использования и эффективность
работы этой самой периферии. И тут мы уезжаем от теории регистр регистр к практической реализации
на уровне физики микросхемы. А вот эта тема практически Вами не раскрыта.
Если уж оптимизировать то по всем направлениям, система команд и организация памяти, как у Вас сделано,
плюс аппаратная реализация, чего не сделано, плюс эффективность компилятора, тоже не сделано.
Вот если все три направления задействовать, то возможно получится нечто хорошее, но тут вылезает
стоимость дизайна. Судя по тому, что в тексте процессор с 4КБ RAM и 16КБ Flash, этот вопрос Вы тоже
не рассматривали. Ведь в реальной продаже производители микроконтроллеров очень скупо дают
эту память. И при 16КБ Flash максимум на что можно рассчитывать это 256 или в крайнем случае 512
байт RAM. Значит она дорога в изготовлении. Еще есть вопрос энергопотребления в работе,
что тоже вопрос, к тому, для чего предназначен Ваш дизайн. Вообщем вопросов больше чем ответов.

[vitja]

Ссылку поправил// +

///Если уж оптимизировать то по всем направлениям, система команд и организация памяти, как у Вас сделано,
плюс аппаратная реализация, чего не сделано, плюс эффективность компилятора, , то возможно получится нечто хорошее

Нельзя объять необъятное
Давайте сперва Разберемся с системой команд /остальное имея в виду
Потом с этой горы ююю все стадо

Сообщение отредактировал vitja - Jan 16 2009, 13:01

[vitja]

...нет никакого смысла вот так глубоко анализировать затраты кода и производительности
на каждый МК. С практической точки зрения, критичными параметрами являются не доля затрат на некую команду,
а совершенно другие факторы: питание, тактовая частота, объем оперативной памяти, и число тактов на одну команду.

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

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

По существу Вами поднято три вопроса:
1. Что считать критерием эффективности МК.
2. Влияние системы команд на аппаратные характеристики МК
3. Взаимосвязь компилятора и системы команд МК.

1. Критериев хорошести МК много.
Для схемотехника это конструктивное исполнение, напряжение питания, потребление, встроенные в МК интерфейсы
и специальные аппаратные блоки.
Для программиста это наличие инструментальных средств, достаточность ресурсов памяти и производительности для реализации алгоритма.
Для руководителя важно, что бы все было сделано быстро, дешево и сердито (конкурентноспособно).
Мое мнение, что во все этом большую роль играет система команд.

2. Система команд влияет на объем программного кода и время выполнения программы. Опосредственно это позволяет использовать модель МК с меньшим объемом ПЗУ, работать на более низкой частоте, со всеми вытекающими последствиями.
На сколько влияет - я попытался показать в своем анализе - в некоторых случаях многократно.

3. Несовершенство транслятора действительно существенно влияет на объем программного кода.
Однако это происходит не только из-за того, что их так пишут.
Просто система команд построена так, что под нее эффективный транслятор написать невозможно.
Это привело даже к тому, что появилось (в начале 80-х годов) новое направление - RISC ЭВМ, которые построены под трансляторы, а не наоборот.
Другое дело, что есть еще более приспособленные под трансляторы архитектуры - это стековые ЭВМ, но об этом рановато будет.

[vetal]

Мое мнение, что во все этом большую роль играет система команд.

Система команд какого ядра с вашей точки зрения более эффективна: 80с31(частота 12МГц, время машинного цикла 12 тактов, время исполнения команды 1-n машинных циклов) или x51(частота 12Мгц, время исполнения любой команды - 1 такт)?

Из вашей оценки

Относительная площадь RISC процессоров сокращена по сравнению с CISC процес-
сором 8051 на 40%, доля 32-разрядного процессора ARM увеличена в 4 раза.

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

[Guest_@Ark_*]

Что считать критерием эффективности МК.

Наверное, стоит сразу разделить два понятия: эффективность процессора (микропроцессорного ядра МК) и эффективность МК в целом.
То, что у Вас описано в файле больше похоже на оценку эффективности процессора. Оценивать же эффективность МК в целом, без учета встроенной периферии и необходимой внешней "обвески" - довольно бессмысленное занятие.
Вообще, эффективность МК - больше экономическое понятие, чем техническое. С практической точки зрения, я бы определил его, как стоимость решения определенной задачи выбранными средствами. Выбор МК влияет и на схемотехническое решение задачи, и на программное.
Отсюда - имеет оценку стоимости разработки "железа" + стоимости разработки ПО. Есть еще себестоимость изделия в производстве, где, как составляющая - стоимость самого МК и дополнительных комплектующих. Если все эти вещи оценить, то наверное можно говорить о сравнении эффективности различных МК, применительно к решению данной задачи (класса задач). Ясно, что эффективность процессорного ядра, системы команд - лишь один из многочисленных факторов во всем этом наборе. Поэтому, напрямую оценивать общую эффективность МК по ним не стоит...

Несовершенство транслятора действительно существенно влияет на объем программного кода.
Однако это происходит не только из-за того, что их так пишут. Просто система команд построена так, что под нее эффективный транслятор написать невозможно. Это привело даже к тому, что появилось (в начале 80-х годов) новое направление - RISC ЭВМ, которые построены под трансляторы, а не наоборот.

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

[vitja]

1 Система команд какого ядра с вашей точки зрения более эффективна: 80с31(частота 12МГц, время машинного цикла 12 тактов, время исполнения команды 1-n машинных циклов) или x51(частота 12Мгц, время исполнения любой команды - 1 такт)?

2 Площадь 51 контроллера примерно равна площади ARM Cortex-M1, NIOSII. При том, что равный по площади 51 микроконтроллер будет работать на меньшей частоте за счет того, что у него очень тяжелая система команд.

1 Тактовую частоту байтовой системы команд переменной длины 8051 я оценивал не по оригиналу,
а по потенциальной возможности выполнения этой системы команд - байт за такт, плюс холостой такт на запись результата в командах модификации
даннах в памяти и смене счетчика команд в передачах управления.
Где близко к этому работают последние модели 51-х от ATMEL. Хотя мне кажется, что ядро процессора у них работает на удвоенной частоте,
только кажется.
Что бы предупредить такие вопросы по PIC, то в нем для расчетов числа тактов принято 2 такта на команду, по причине того,
что он обрабатывает данные в памяти (так называемом регистровом файле достаточно большого размера).

2 Спасибо за данные..++
Я предпологал, что это так, но не думал, что до такой степени.
Обязательно учту и проведу перерасчет оценок площади.
Если знаешь аналогичные отношения для процессора AVR MEGA и PIC не ниже 16-го, подскажи.

[vitja]

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

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

1 Благодарен за прочтение и правильные выводы:
а) я действительно анализирую эффективность только процессора МК, причем только его системы команд;
б) задачей этого анализа является оценка влияния особенностей системы команд на объем программного кода и тактов на его выполнения.
Для оценки были взяты статистические данные употребления операторов ЯВУ для нечисловых задач, как наиболее характерных для областей применения МК, где объем вычислений относительно невысок.
Когда я рассматривал другие показатели эффективности МК - площадь (стоимость кристалла), трудоемкость программирования на ассемблере и еще бы надо не забыть о потреблении, как функции тактовой частоты, то все это было упомянуто только в качестве примеров влияния системы команд на эти показатели.
Для всех!!!
Я думаю, что вопросы эффективности МК в целом достойны обсуждения ,но в другой теме. Договорились.

2 "В течении 1980-84 гг в Беркли разрабатывался проект RISK, целью которого был выбор архитектуры однокристального СБИС-компьютера для эффективной работы с такими языками высокого уровня, как Си и Паскаль" из статьи RISC: "Эффективные архитектуры для СБИС-компютеров" Д.Патерссон и др. Электроника СБИС под ред.Айнспрука м.мир 1989
Поэтому в начале ты был прав, но концовка ....
Если рассматривать архитектуру RISC с точки зрения требований к системе команд процессора МК, а только это мы сейчас обсуждаем,
то оно одно - команды доступа к данным должны быть отделены от команд обработки данных.
Этому требованию в полной мере удовлетворяют регистровая система команд и стековая (если стек аппаратный).

[Guest_@Ark_*]

"В течении 1980-84 гг в Беркли разрабатывался проект RISK, целью которого был выбор архитектуры однокристального СБИС-компьютера для эффективной работы с такими языками высокого уровня, как Си и Паскаль" из статьи RISC: "Эффективные архитектуры для СБИС-компютеров" Д.Патерссон и др. Электроника СБИС под ред.Айнспрука м.мир 1989
Поэтому в начале ты был прав, но концовка ....
Если рассматривать архитектуру RISC с точки зрения требований к системе команд процессора МК, а только это мы сейчас обсуждаем,
то оно одно - команды доступа к данным должны быть отделены от команд обработки данных.
Этому требованию в полной мере удовлетворяют регистровая система команд и стековая (если стек аппаратный).

" RISC (англ. Reduced Instruction Set Computing) — вычисления с сокращённым набором команд.
Это концепция проектирования процессоров, которая во главу ставит следующий принцип: более компактные и простые инструкции выполняются быстрее. Простая архитектура позволяет удешевить процессор, поднять тактовую частоту, а также распараллелить исполнение команд между несколькими блоками исполнения (т.н. суперскалярные архитектуры процессоров). Многие ранние RISC-процессоры даже не имели команд умножения и деления. Идея создания RISC процессоров пришла после того, как в 1970-х годах ученые из IBM обнаружили, что многие из функциональных особенностей традиционных ЦПУ игнорировались программистами. Отчасти это был побочный эффект сложности компиляторов. В то время компиляторы могли использовать лишь часть из набора команд процессора..."
http://ru.wikipedia.org/wiki/RISC

P.S. Возможно, какие-то из RISC-проектов были ориентированы по использование конкретных языков/компиляторов, но за всю RISC-архитектуру "расписываться" не стоит. Ее главная цель - обеспечить наилучшее соотношение производительность/цена процессора для определенного класса задач. "Удобство" для компилятора - далеко не главный фактор.

[vitja]

" RISC (англ. Reduced Instruction Set Computing) — вычисления с сокращённым набором команд.

"Удобство" для компилятора - далеко не главный фактор.

1. Не все, что написано на заборе, там можно найти.
2. Замечание я переадресую доктору Паттерсону в Беркли, который первым ввел слоган RISK, назвав им свои первые
риск машины RISK-I, II, которое прижилось в отличии от MIPS Станфордского у-ни и 801-го IBM.
3. Рекомендую читать первоисточники. В Wiku профессора не пишут, ее создает INET сообщество (толпа).
Ну вот, опять понесло. Прошу 3-й пункт не читать.

Для меня RISC это философия и методология разработки эффективных процессоров,
которую надо обсуждать отдельно, если есть интерес.
Хотя меня удивляет, что многие современные МК рядятся в тогу Риска, нарушая при этом многие его принципы.

Я не фанат риска, но и не его противник. Я прагматик.

Поэтому давайте лучше решим, когда говорим о системе команд:

А) какой должна быть система команд, чтобы конвейер работал максимально быстро.

Б) нужно ли стремиться в архитектуре процессора МК к тому, что бы его команды выполнялись за один такт, поскольку выборка команд ограничена временем доступа к FLASH памяти программ (20 нс в известных мне фабриках и известных процессорах, исключая Scenix, где тактовая частота по ТУ 50 Мгц, но утверждается, что он может работать (непонятно за счет чего) на частотах 100-150 Мгц), когда процессор (его логика, регистры и память ОЗУ) может работать на частотах вдвое и даже вчетверо выше.

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

Г) когда мы говорим о повышении тактовой частоты, то надо говорить о возможности работы на этих частотах.
Так например, в системах реального времени процессор большую часть времени простаивает.
PS? Здесь я что-то невразумительное написал. Потом переформулирую. Пример оставлю. По п.п. а и б надо бы определиться.

Сообщение отредактировал vitja - Jan 17 2009, 12:18

[mikesm]

1. Не все, что написано на заборе, там можно найти.
2. Замечание я переадресую доктору Паттерсону в Беркли, который первым ввел слоган RISK, назвав им свои первые
риск машины RISK-I, II, которое прижилось в отличии от MIPS Станфордского у-ни и 801-го IBM.
3. Рекомендую читать первоисточники. В Wiku профессора не пишут, ее создает INET сообщество (толпа).
Ну вот, опять понесло. Прошу 3-й пункт не читать.

Вообще то, когда ты используешь термины, нужно быть более точным. Просто для того, чтобы можно было найти ссылки на информацию,
которую ты тут приводишь. Профессор Паттерсон, а точнее David Patterson, вот его домашняя страничка http://www.cs.berkeley.edu/~pattrsn
Имеет отношение не к машинам RISK-I и RISK-II, а к машинам RISC-I и RISC-II.
Что интересно, и первую и вторую машины разработали его студенты
RISC-I (1982) Contains 44,420 transistors, fabbed in 5 micron NMOS, with a die area of 77 mm2, ran at 1 MHz. This project coined the term Reduced Instruction Set Computer (RISC). This chip is probably the first VLSI RISC. Designed by Dan Fitzpatrick, John Foderaro, Jim Peek, Zvi Peshkess, and Korbin Van Dyke, students of Professors David Patterson and Carlo Sequin. The RISC CAD group included Dan Fitzpatrick, Professor John Ousterhout, and Howard Landman.
RISC-II (1983) contains 40,760 transistors, was fabbed in both 3 micron and 4 micron NMOS, and in 3 micron the size is 60 mm2, and it ran at 3 MHz. Designed by Bob Sherburne and Manolis Katevenis, students of Professors David Patterson and Carlo Sequin. (RISC group picture.)

А) какой должна быть система команд, чтобы конвейер работал максимально быстро.

Б) нужно ли стремиться в архитектуре процессора МК к тому, что бы его команды выполнялись за один такт, поскольку выборка команд ограничена временем доступа к FLASH памяти программ (20 нс в известных мне фабриках и известных процессорах, исключая Scenix, где тактовая частота по ТУ 50 Мгц, но утверждается, что он может работать (непонятно за счет чего) на частотах 100-150 Мгц), когда процессор (его логика, регистры и память ОЗУ) может работать на частотах вдвое и даже вчетверо выше.

Г) когда мы говорим о повышении тактовой частоты, то надо говорить о возможности работы на этих частотах.
Так например, в системах реального времени процессор большую часть времени простаивает.
PS? Здесь я что-то невразумительное написал. Потом переформулирую. Пример оставлю. По п.п. а и б надо бы определиться.

А) Большинство фирм выпускают микроконтроллеры с RISC архитектурой, где команды выполняются за один такт. Там нет огромной памяти,
поэтому не нужна частая многоступенчатая выборка.
Б) А иначе, при многотактном конвейере как быть с ветвлениями, анализировать код на несколько ходов вперед или использовать встроенную кэш память.
Это уже не микроконтроллер получится.

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

[vitja]

Профессор Паттерсон, а точнее David Patterson, вот его домашняя страничка http://www.cs.berkeley.edu/~pattrsn
Имеет отношение не к машинам RISK-I и RISK-II, а к машинам RISC-I и RISC-II.
Что интересно, и первую и вторую машины разработали его студенты


А) Большинство фирм выпускают микроконтроллеры с RISC архитектурой, где команды выполняются за один такт. Там нет огромной памяти,
поэтому не нужна частая многоступенчатая выборка.
Б) А иначе, при многотактном конвейере как быть с ветвлениями, анализировать код на несколько ходов вперед или использовать встроенную кэш память.
Это уже не микроконтроллер получится.

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

Робята, это не я сказал - "Первые машины RISC сделал David Patterson с его студентами (аспирантами)" (mikesm)
и я с ним абсолютно согласен.
Давайте не будем уподобляться рецензентам, которые говоря о недостатках отмечают отдельные стилистические неточности.
Будем зрить в корень. Русский язык велик и могуч, а русские ...

Поэтому о Рисках забыли.

По п.А. конкретно
Какая связь между размером памяти и глубиной конвейера?
Я ее вижу только в том, что память МК расположена всегдддда внутри кристалла, какая - от 32 байт, как в Tyni или до 64 Кб и более
не важно, главное не выходить за пределы кристалла для доступа к внешней памяти (иначе получается ПиСец с КЭШами в придачу, а не МК).

По п.Б
Читаем внимательно. Пишу медленно.
Я тоже самое говорил вышее, что и ты. Зачем эти лишние ступени в конвейере?
Выбрали Гарвардское расделение памяти на программы и данные, реализовали простенький 2-ступенчатый конвейер и никаких проблем.

По п.Г.
В системах РВ процессор простаивает по определению, поскольку он работает по событиям (прерываниям), которые он ждет, а значит простаивает.
Он это делает неспроста. Когда придет необходимость (событие), он должен все сделать, что бы уложиться в заданное время реакции на него,
а потом опять уснуть (до очередного события).
Менять частоту процессора на лету? Запомню, это программируемые PLL, но у них тоже есть какое то время выхода на устойчивый режим.
По п.Г я отклонился от главной темы "система коман МК". Больше не буду.

[mikesm]

По п.А. конкретно
Какая связь между размером памяти и глубиной конвейера?
Я ее вижу только в том, что память МК расположена всегдддда внутри кристалла, какая - от 32 байт, как в Tyni или до 64 Кб и более
не важно, главное не выходить за пределы кристалла для доступа к внешней памяти (иначе получается ПиСец с КЭШами в придачу, а не МК).

Даже если память расположена внутри кристалла, если мы говорим о 8 разрядном МК, то при адресации 64К требуется два байта адреса,
которые будут выбираться из Flash. И тут все зависит от аппаратной реализации процессора и его Flash на борту.
Если рассматривать стандартное исполнение, то Flash у процессора имеет побайтовый доступ, и если она больше 64К, потребуется больше
двух байт только на адрес, получаем выборку в 3 или 4 такта. А т.к. пересылка память регистр одна из наиболее критичных команд,
и в один такт выбрать команду не получится, надо делать конвейер. И чем больше размер памяти, тем глубже конвейер.

[Guest_@Ark_*]

Робята, это не я сказал - "Первые машины RISC сделал David Patterson с его студентами (аспирантами)" (mikesm) и я с ним абсолютно согласен.
Будем зрить в корень.

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

Поэтому о Рисках забыли.

----------------------------------

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

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

[vitja]

1. по моему мнению, RISC-архитектура получила развитите из-за эффективности, а не потому, что стало проще писать компиляторы.
----------------------------------
2/ Не совсем это так, точнее не всегда.
Кстати, в Вашем анализе почему-то совсем ничего нет на эту тему...

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

2 Я тоже, как и вы, когда принимаю какое-то решение, сомневаюсь и что-то оставляю на потом (держу в уме).

Организовать вычислительный процесс в СРВ можно по разному. Я сказал об управлении по событиям (прерываниям), вы - об управлениии по
цикло-чего то (забыл как называется) - это разделение времени.
Какое отношение организация ВП СРВ имеет к системе команд, где надо:
а) отреагировать на прерывание;
б) при необходимости сохранить контекст текущей задачи, и позжее его восстановить.
Это реализуется командами PUSH,POP и RETI. Возможны другие варианты не изменяющие смысла.
Еще 3 команды в копилку системы команд процессора МК.

Давайте ближе к теме будем быть.

если мы говорим о 8 разрядном МК, то при адресации 64К требуется два байта адреса,
....Flash у процессора имеет побайтовый доступ, и если она больше 64К, потребуется больше
двух байт только на адрес

Слава богу. Наконец то мы стали говорить по теме.
Да - память ПЗУ, ОЗУ внутри кристалла МК, да - это 8-разрядный МК и адресация 64к требует 16 бит адреса как ПЗУ, так и ОЗУ,
а более 64 к - более 16 бит.
Ее можно адресовать странично или относительно базового адреса. Это не требует задания в команде всех битов адреса, можно ограничится 3,4 или другим числом биттттттттттттттофффффффф.

Сегодня все. Хочу спать.

Сообщение отредактировал vitja - Jan 17 2009, 21:36

[vitja]

Передо мной поставлена задача - дать предложения по архитектуре
системы команд 8-разрядного процессорного ядра,
совместимой с ЯВУ, удобной для программирования на ассемблере, простой в реализации
и обеспечивающей компактный программный код и малое число тактов на его выполнение.
Я дал предложения по концепции такой архитектуры с оценкой и обоснованием
http://moko.ru/mc/

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

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

Я стою на форуме с протянутой рукой уже второй день.

Подают фантики. Спасибо mikesm и vetal за позитивную критику и уточнение. Не дали умереть с голоду вчера.
Но сегодня мне снились процессоры с CISьСами и RISьCами и программист.

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

Вторые имели фиксированную длину команды, обрабатывали данные на регистрах за один такт, сопрягались с трансл

Сообщение отредактировал vitja - Jan 18 2009, 06:13

[vvvv]

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

[zltigo]

а у Вас голая наука,

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

 

[GetSmart]

RISC - отстой Грядёт эпоха сверхдлинных CISC по подобию Эльбруса E2K.
Зачем спрашивается процессору в рилтайме анализировать возможность выполнения нескольких инструкций за такт, если компилятор один раз сам может это сделать и сформировать инструкцию, исполняющуюся за 1 такт и производящую множество разных действий?!

[MrYuran]

RISC - отстой Грядёт эпоха сверхдлинных CISC

Да чё уж там, сразу надо JAVA-процессор делать, чтоб прямо исходники глотал. Слыхал, что уже есть такие.

По существу вопроса - непонятна цель данной разработки. Нет цели, соответственно, нельзя поставить задачи и тем более найти пути их решения.

[vitja]

Как студенты ... так и ... аспиранты не занимаются "наукой" .
 

Практикам.
Вы используете продукты известных фирм от Intel до Атмел, и уверен, что грамотно.
Почему используете. Потому что доступно на каждом углу, стоит дешево и решает ваши задачи.
Как в Макдональдсе - гамбургер, фри и пепси (схема, компилятор, отладчик).
Нравится. Кушайте на здоровье.
Мне хочется другого.
Не 51-го с его многоформатной и переусложненной системой команд,
не PICа с его аккумулятором и ограниченным регистровым файлом,
и даже не AVR с его регистрами (об Эльбрусе не говорим - это не процессор для 8-разрядного микроконтроллера)
Чего хочу, попытался изложить вышше (там). Если недопонятно изложил. Виноват, поправьте.

Доцент

надо JAVA-процессор делать ... уже есть такие.

По существу вопроса - непонятна цель данной разработки. Нет цели, соответственно, нельзя поставить задачи и тем более найти пути их решения.

JAVA байт-код сложен для прямой интерпретации (реализации) в ограниченной аппаратуре МК.
А вот его его подмножество ....

О цели см. http://moko.ru/mc/ но там много цифирек и текста, поэтому надо вчитываться.
В 3-х словах о цели темы - эффективная система команд (МК)

Для чего - что бы ее сделать.

Сообщение отредактировал vitja - Jan 18 2009, 12:02

[zltigo]

Мне хочется другого.
Не 51-го с его многоформатной и переусложненной системой команд,
не PICа с его аккумулятором и ограниченным регистровым файлом,
и даже не AVR с его регистрами.

При этом, Вы якобы претендуя на реализацию

8-разрядного процессорного ядра для управления работой аппаратуры SOC

Совсем не поминаете именно реализации ядер по жизни заточенных под SoC.
Ведете разговоры о "..если сравнивать с 8051, PIC, AVR и даже ARM Thumb,". Даже "ARM Thumb" - а какого, черта якобы говоря о SoC поминать все это а не ARM Cortex-M1, NIOS... ? В бумажных переводных книжках такие буквы не встретились? "Наука", понимаш . Посмотрите на тот-же NIOS начала этого века и подумайте насколько и почему он отличается (и разрядностью, и системой команд, и количеством регистров) от поминаемых Вами "конкурентов" и бумажных проектов восьмидесятых годов прошлого века рождененных в 10мегагерцовые времена с ограничениями и на степень интеграции, и на количество ножек у DIP корпусов.

 

[vitja]

Ведете разговоры о "..если сравнивать с 8051, PIC, AVR и даже ARM Thumb,"...
Посмотрите на тот-же NIOS ....

Посмотрел NIOS. Это не гамбургер 8-разрядный - это биг-мак 32-разрядный.
16-битная 2-адресная регистровая система команд. Оченнь простая, 16 форматов, более полусотни команд, нет условных переходов, зато есть пропуски.
Чуть-чуть румянец навести и от системы команд ARM Thumb отличить невозможно. Но все равно от этой пищи....
Минус три балла.
И вообще. Я предложил конкретно специалистам -
обсудить только вопрос эффективности системы команд 8-разрядного процессора. Предложил методику, привел оценки, как смог, дал предложения по повышению этой самой эффективности.
Все. О RISC говорить перестали, о критериях эффективности МК тоже, теперь не будем говорить о 32-разрядных процессорах.
А если Вам не нравятся 8-разрядные МК, то ..... это Ваше дело.
Однако большую часть рынка микроконтроллеров занимают именно они и это место другим уступят не скоро.

Сообщение отредактировал vitja - Jan 18 2009, 14:12

[vvvv]

Ну все верно, Вы говорите, что рынок занимают, что место не уступят. Вот только смысл этой эффективности теряется среди других вещей.
Вы пишете, давайте обсуждать эффективность ядра процессора. Смысл обсуждать эффективность ядра, если другие компоненты микропроцессора
завалят эту эффективность в два счета. Как к примеру обсуждать эффективность применения аспирина утром или вечером, что эффективнее, принять
его в 9.15 утра, или 17.15 вечера, и все это в приложении к алкашу. Нет смысла, для его здоровья гораздо эффективнее бросить пить.
Также и здесь умозрительная задача, обсуждать ради обсуждения, без какого нибудь практического выхода в обозримом будущем.
Какой смысл обсуждать эффективность структуры команд, если повышение тактовой с 8 МГц до 16МГц, на любой платформе дает прирост в 200%,
против эффективности структуры команд, которая в предельном случае даст прирост 23%.
Поэтому с практической точки зрения, обоснуйте, хотя бы теоретически, какой выигрыш даст Ваша тема, хотя бы виртуально, чего не достичь
другими методами, там повышением частоты, переходом на другую технологию чипов или еще как то. Тогда хоть будет интересно обсуждать.

[vetal]

Если Вам не нравятся 8-разрядные МК, то ..... это Ваше дело. Однако большую часть рынка микроконтроллеров занимают именно они
и это место другим уступят не скоро.

Данные фирмы Atmel :
http://www.atmel.com/dyn/resources/prod_do...nts/doc3323.pdf

Я предложил конкретно специалистам -
обсудить только вопрос эффективности системы команд 8-разрядного процессора.

Я думаю так - длина команды д.б. в районе 11-12 бит. Туда вы сможете запихать наиболее востребованные операции. Для выполнения длинных переходов добавить несколько команд из 2х слов. Больше ничего не сказать, т.к. это будет зависеть от выбранной вами архитектуры(микроархитектуры)!

[vitja]

... Ну все верно, Какой смысл обсуждать эффективность структуры команд, если повышение тактовой с 8 МГц до 16МГц, на любой платформе дает прирост в 200%, ......
против эффективности структуры команд, которая в предельном случае даст прирост 23%.

"Обсуждать эффективность структуры команд" стоит хотя бы по по трем причинам ... о чем я говорил ранее давно и не буду повторяться.

А вот вера в прогресс техники - удвоить тактовую частоту или перейти на технологию 0ю13 мк - это другое.
Почему. Удвоение частоты приведет к удвоению потребления. Переход с 0.18 мк на 0.13 занял много лет и еще больше денег, хорошо что не наших.
Так или нет.
Я утверждаю в http://moko.ru/mc/ (таблица) 32, что система команд оказывает существенное влияние на эффективность МК (в попугаях).
И эта эффективность отличается не на 23%, а в два и даже три раза.

:
http://www.atmel.com/dyn/resources/prod_do...nts/doc3323.pdf

Я думаю так - длина команды д.б. в районе 11-12 бит.

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

Ответ.
Из указанного материала я понял, что кроме двух известных древних проффессий, есть третья - аналитики (прогнозисты).
Из ссылки - "аналитическая компания Semico в 200ю году предсказала для фирмы Atmel, что к 2007(8) году
32-разрядные МК будут преобладать на рынке"

Из PC Week от 5 декабря 2008
доля рынка МК
"14% 8051
12% PIC
3% AVR
1% ARM . Остальные места занимают другие фирмы со своими проприентарными процессорами (Motorola, Zilog, Holtek, Sani...)
По прогнозу аналитической компании Semico к 2010 году дC

Сообщение отредактировал vitja - Jan 18 2009, 18:06

[zltigo]

Посмотрел NIOS. Это не ...

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

Из PC Week от 5 декабря 2008

Есть еще масса интересных журналов типа Хакер и иже с ним.

доля рынка МК


14% 8051
12% PIC
3% AVR
1% ARM . Остальные места занимают другие фирмы со своими проприентарными процессорами (Motorola, Zilog, Holtek, Sani...)

Врут. На первом месте микроконтроллеры, котрые уже и те-же москвичи выбрасывают в мусорник после каждой поездки на метро и прочая "электроная пыль" на ценниках в магазинах, карточках, картриджах.... Так о чем лично Вы пытаетесь вещать? Если не забыли, то Вы собирались просветить на счет SoC ядер.

 

[GetSmart]

Из PC Week от 5 декабря 2008
доля рынка МК
"14% 8051
12% PIC
3% AVR
1% ARM . Остальные места занимают другие фирмы со своими проприентарными процессорами (Motorola, Zilog, Holtek, Sani...)
По прогнозу аналитической компании Semico к 2010 году доля рынка 32-разрядных МК удвоится
за счет сокращения доли 16-разрядных МК (для ARM до 2%),
а рынок 8-разрядных МК сохранит свой объем".

Даже если это так (хотя я сильно сомневаюсь), то большая доля 8-битных контроллеров обусловлена привязанностью к уже написанному ПО. Из этого совершенно не следует, что будет востребована новая архитектура 8-битных контроллеров. 8-битники - прошлый век. Давайте ещё АВМ реанимируем
Я просмотрел PDF не очень подробно и заметил только совершенно непонятные (неадекватные) цифры в таблицах. Особенно удивила таблица со стоимостью МК (архитектуры). Сравнивите к примеру AVR и ARM со флэшем хотя бы 64К и удивитесь сколько необъективности в вашем PDF. Буквально по каждой таблице можно долго спорить, но не буду. Жалко своё время.

Кроме этого, есть много способов поднятия быстродействия микроконтроллера. Те же AVR при желании Atmel-a можно было бы ускорить в 4-6 раз не переделывая систему команд. Но почему-то это не делается. Может для 8-битников такая скорость и не требуется.

[vitja]

......это вообще дурдом.

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

1. Без комментариев.
Про SoCи тоже больше говорить не будем. ОК!
Только о системе команд и какая из них лучшее и объясняя почему.

2. Они выбрасывают не 32-разрядный NIOS (ARM, MIPS, R....), а простенький 4-8 разрядный процессор.
Возможно это UNC80 (усовершенствованная архитектура МК 1878ВЕ1 з-да Ангстрем), они там карточками занимаются.
Возможно это что-то другое.

3. Просвещения ждут верующие, просветления - ждут буддисты, нормальные специалисты не ждут - они самообучаются.

Давайте ближе к теме уважаемые. А то выходные кончаются.

Сообщение отредактировал vitja - Jan 18 2009, 18:56

[vetal]

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

Я думал, что это только мне так показалось

2vitja:
Создайте симулятор системы команд и оцените на нем все перечисленные вами тезисы. Для чистоты эксперимента любая команда должна будет исполняться за 1 такт - это даст возможность исключить нюансы реализации.
Если вам так хочется сравнить 8 и 32 бита - сравните стоимость вычисления постоянной составляющей синусоиды(кол-во отсчетов 32, кол-во элементов - 32, разрядность данных -16) , FIR 32 порядка, поиск числа в массиве, поиск подстроки в массиве строк и како-го нибудь алгоритма шифрования. После реализации этого всего можно будет сделать вывод о том, какие инструкции наиболее употребимы на типовых задачах микроконтроллера и их вес.

PS: http://mcu.caxapa.ru/benchmarks/

[zltigo]

Про SoCи тоже больше говорить не будем. ОК!

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

Я думал, что это только мне так показалось

Нет , там всякого полно в каждом абзаце. То тактовые частоты выбираются исходя их времени реакции на внешние события в миллисекунды, то цикл обращения к flash в контроллерах занимает до 20 нс. А как библиографический перл типа "Начала программирования" издания 1981 "использованом" для оценки трудоемкости программирования микроконтроллеров? "Анализ" тех-же PIC закончился на PIC17. 4bit контроолеры оказывается круто себя чувствуют в бытовой электронике и автомобилестроении. 8bit имеют наилучшие соотношения цены и производительности (тоже из какой-нибудь книжки издания где-то 1985 года) и с успехом используются для задач цифровой обработки сигналов. Студенту напишавшему такой труд твердый неуд. Что делать с Доцентом, даже не знаю  

[lepert]

По поводу симулятора, этим уже занимался Кнут, все примеры в книге на его собственной виртуальной машине. Там же он пишет кое что о математической составляющей процессоров. Может его почитаете. Книжка конечно высший пилотаж, я застрял на 50й странице. Но уверен,
если пройти все его три тома, наступит 3й дан просветления.

Сообщение отредактировал lepert - Jan 18 2009, 19:40

[vitja]

1) .... большая доля 8-битных контроллеров обусловлена привязанностью к уже написанному ПО

2) Я просмотрел PDF не очень подробно и заметил только совершенно непонятные (неадекватные) цифры в таблицах.
... Жалко своё время.

3) .... Те же AVR при желании Atmel-a можно было бы ускорить в 4-6 раз не переделывая систему команд. Но почему-то это не делается. Может для 8-битников такая скорость и не требуется.

Уже поздно.
Из всего отмеченного только по п.2 (по другим завтра)

2. Спасибо, что прочитали. На цифры не обращайте внимания. Статистика может обосновать все,
есть законы о нормальном распределении, есть выводы теории погрешностей ....
Поэтому цифры можно перепроверять и пересчитывать, но зачем. Важны полученные оценки.
Объем кода (табл.32) при обработке данных 8-32 разряда:
AVR 8051 ARM M8
3.3 2.4 2.0 1.0

И еще личная просьба.
Не пожалейте еще немного своего времени, раз уж посмотрели PDF.
Скажите про Ваше отношение к цифрам в таблице 19 (глава 4), где приведены доли типовых машинных операций
на реализацию операторов ЯВУ.

Всем спокойной ночи.

Сообщение отредактировал vitja - Jan 18 2009, 20:04

[vitja]

...Вам остается молчать и это правильно!
...библиографический перл типа "Начала программирования" издания 1981 Ч
...то делать с Доцентом, даже не знаю

Просил без ?ля-ля-ля.
А сам не удержался, надеюся в последний раз.

1. Все чем мы пользуемся сейчас было заложено в 50-80-е годы.
Примеры ? Ваш и мой ?пень? вырос из 8086-го (1980 год), была даже его 8-разрядная версия (это ближе к теме).
- Крутой и наисовременнейший (2000 гг выпуска) МК MSP430 ? это клон PDP11, созданного в 70-х годах.
- Хорошие книги по программированию изданы в основном до 80-го года и сейчас только переиздаются (Кнут, Брукс младший и т.д. список большой, см. в библиотеке) .
2. Надо читать не только ДатаШиты и книги инструкции, которыми завалены полки книжных секций с литературой ?по так называемому программированию?
3. После 80-х годов программирование и аппаратура ЭВМ развиваются экстенсивно и эволюционно. В основном в сторону инструментария, который делают избранные.
Умные ребята от Гейтса превратили программистов в общество потребителей ? нажал нужную кнопку ? получил результат.
Мы ремесленники. Этим надо гордиться?
PS/ А книга называется "Начала науки о программах" Будьте внимательнее/ пожалуйста/

[zltigo]

1. Все чем мы пользуемся сейчас было заложено в 50-80-е годы.

Да! Имено так, вот и лично Вы занялисть очередным переливанием из пустого в порожнее изображая пустейшее наукообразие в рассуждениях уровня экономии кремния при создании каменных топоров. Что новенького-то??? При этом лично Вам ни каменный топор, ни восьмибитовое ядро не нужно. В результате одно пустое цитирование некомпетентного и незаинтересованного человека. Что-то не слишком далеко ушедшеее от репортажа-обзора в каком-нибудь глянцевом мужском журнале сделанным журналистом по заданию редакции.  

 

[vitja]

Создайте симулятор системы команд и оцените на нем все перечисленные вами тезисы.

PS: http://mcu.caxapa.ru/benchmarks/

Благодарю за совет и ссылку. Воспользуюсь обязательно этим, но потом.
Бенчмарки, помимо того, что привносят в оценки совершенства системы команд, несовершенства используемого транслятора (и по Вашей ссылке это видно),
они
а) не дают ответа почему, такие цифры получились, поэтому
б) не пригодны для использования на этапе проектирования системы команд, когда системы команд еще нет, ее надо создать, принимая ответственные решения по выбору адресности команды, ее длине, выбору способа обработки – регистры, память или стек….и пр/
Мои предложения - это поиск ориентира для решения этих вопросов. Насколько верны эти ориентиры судить Вам.
Поэтому я предложил эту тему для обсуждения.

[vetal]

... выбору способа обработки – регистры, память или стек….и пр...

При чем тут это? ВЫ утверждаете, что вам нужна помощь в системе команд и тут же делаете ссылку на архитектуру процессора. Вы уж определитесь чего вы оцениваете!!! Вам уже 100 раз говорили, что система команд сама по себе не появляется нужна архитектура.

[MrYuran]

- Крутой и наисовременнейший (2000 гг выпуска) МК MSP430 ? это клон PDP11, созданного в 70-х годах.

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

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

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

Вообще обычно при разработке нового типа МК производители берут готовое ядро (проверенное, широко известное и имеющее кучу инструментальных средств, т.к. компиляторы, симуляторы, etc)
А различия архитектуры наблюдаются на уровне функциональных блоков МК.
Например, мне сейчас в голову пришла мысль: а почему бы не сделать аппаратный шедуллер? Который по флагу моментально запускал бы нужное приложение, заодно соблюдая приоритет. Вот это была бы вещь, РТОСки бы летали. А курочить процессорное ядро без цели...

Тогда уж лучше трёхбитными процессорами заняться, вот уж где новизна! Вот где оптимальность! Не секрет, что оптимальное основание системы счисления - число е, которое намного ближе к 3, чем к 2

[zltigo]

Вот это действительно вещь.

Да, кстати, про 2000 год и MSP430 опять ерунда наверное почерпнутая из журнала "Плейбой" - MSP430 лично я держал в руках с горой документации в 1996 году и сравнение c PDP за уши притянуто с не меньшим успехом можно утверждать, что это Intel. Вообще, я уже говорил, весь "анализ" реальных ядер явно строится на бумажных русскоязычных изданиях 80x-начала 90x. Вот и получается, что PIC типа умерли на PIC17. ARM - на АRM7, Atmel еще не пытается делать XMEga, MSP еще не родился, про 80251 тоже в советских книжках не написали, 32bit мы вообще не рассматриваем потому, что в тех книжках писали, что они неоптимальные, ядра для SoC вообще вообще, наверно марсиане проектируют.

 

[vitja]

MSP430 это действительно вещь. Вот его бы лучше проанализировали, а не допотопные пикушки.

Тот же компилятор может оптимизировать по быстродействию либо по размеру кода.

Сделать что-то, оптимальное по всем параметрам, невозможно. Нужны критерии оценки и весовые коэффициенты ....

Тогда уж лучше трёхбитными процессорами заняться, вот уж где новизна! Вот где оптимальность! Не секрет, что оптимальное основание системы счисления - число е, которое намного ближе к 3, чем к 2

Полковнику не по порядку.
1. Критерии указаны - объем программного кода и числа тактов на его выполнение
при реализации операторов языка высокого уровня при доле (весе) их употребления
для задач не вычислительного характера (основная область применения МК).
2. Я тоже об этом - современный программист бац, нажимает кнопку, получил оптимальную
программу по объему кода, нажал другую, поднял быстродействие.
Зачем думать и говорить об эффективной системе команд? За нас таммм далеко в долине все это решили.
3. Современная элементная база мало пригодна для реализации логики с тремя состояниями.
4. Утверждение о том, что "вещщь" MSP430 это клон PDP11 (СМ3-4, Электроника 100, 1806 ВМ1 и прочие
аналоги) не опровергнуто/ а значит принято
5/ В ответ на пожелание привожу упрощенный анализ эффективности его системы команд по оценка объема кода
относительно 8051 (при обработке байтовых данных).
- длина команды - 16-разрядная переменной длины - 2.0
- адресность команды - 2-адресная регистровая - 0.73
- организация обработки - регистры, с возможностью задания констант и адресов
операндов в следующем слове. Тут сложнее, поскольку с одной стороны регистры, но не АВэРовские.
Поэтому пусть будет 1.0.
- организация выполнения команд - нельзя выполнить команду за такт,
и возможно даже за два (причина указана выше).
- состав команд - должно быть 1.0, однако поскольку константы имеют большой вес
среди операндов (условно примем 30%) на задание одного байта будет тратится
целое 16-разрядное слово, Поэтому 1.0 не получается, а получается где-то 1.15.
Итого имеем 2.0*0.73*1.0*1.15 = 1.7. Во столько раз с точностью достаточной
для практического применения МК430 уступает 8051.

Более точные оценки можно получить, если оценивать реализацию операторов ЯВУ в затратах
машинного кода М430.

[MrYuran]

- организация выполнения команд - нельзя выполнить команду за такт,
и возможно даже за два (причина указана выше).

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

[vitja]

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

Я читал/ признаюсь/ ДатаШит М430 по диагонали/ однако систему команд 1806 ВМ2 знаю и уважаю /опять признался/
Однако ничего личного/
В ней за такт можно выполнить только обработку данных на регистрах/
Остальные же в/т/ч/ способы адресации только добавляют такты в выполнение команды/
Переходы действительно сбивают конвейер/ Поэтому придумывают типа предсказания переходов и прочие навороты/
Зачем/
а) В МК вся память внутри/
б) максимальная частота выполнения программы ограничена временем доступа к ПЗУ/
в) за это время процессор сможет выполнить команду М430 за один машинный цикл/ затратив на это к примеру - четыре такта

[GetSmart]

5/ В ответ на пожелание привожу упрощенный анализ эффективности его системы команд по оценка объема кода
...
Итого имеем 2.0*0.73*1.0*1.15 = 1.7. Во столько раз с точностью достаточной
для практического применения МК430 уступает 8051.

Оценивать "эффективность" системы команд по отношению размера кода на "проделанную работу" не актуально. Флэши в современных процессорах очень много. Где-то 20..30 лет назад ситуация была другой и это имело смысл. Но не сейчас. Сейчас для всех более актуально измерять "проделанную работу" в секунду. Если по этому критерию оценивать MSP430 и MCS-51, то последний безнадёжно проиграет. Хотя с оговоркой. 430ые не делают на высокую частоту. Они специально заточены под минимальное энергопотребление. И по энергопотреблению он тоже "порвёт" 51ый.

Возьмём к примеру классический ARM7-TDMI. Он умеет работать в двух режимах. 32-битный код исполняется грубо в 1.5 раз быстрее Thumb-a, но имеет грубо в 1.5 раз больше объём кода. Вопрос на засыпку - какой режим эффективней?

б) максимальная частота выполнения программы ограничена временем доступа к ПЗУ/
в) за это время процессор сможет выполнить команду М430 за один машинный цикл/ затратив на это к примеру - четыре такта

А если за один доступ к ПЗУ считывать сразу две команды, то что? А если сразу 4?

Сообщение отредактировал GetSmart - Jan 19 2009, 10:50

[vitja]

////система команд сама по себе не появляется - нужна архитектура.

Что такое архитектура процессора МК//
как не система команд /см/книгу "Организация ЭВМ" издание 5-е 2004 год Питер/
Однако если на нее посмотреть с другой стороны/ то она может выглядеть как 18-ноговый DIP корпус
первые пентиумы потом я носил как значок/ прикольно было

[vetal]

как не система команд

В первую очередь система команд это интерфейс ядра процессора с внешним миром. Взяли микроядро AVR без декодера и творите какую угодно систему команд.
Если бы вы поставили вопрос по другому: что лучше регистровый, стековый, регистровый с плавающим окном, аккумуляторный с одной или несколькими одновременно доступных памятей данных и т.д. то можно было бы судить. А так - все процессоры умеют складывать, вычитать, прыгать, загружать/выгружать данные куда-либо и создать систему команд под незнамо какую зверушку будет очень сложно.

[vitja]

430ые не делают на высокую частоту.

Возьмём к примеру классический ARM7-TDMI. Он умеет работать в двух режимах. 32-битный код исполняется грубо в 1.5 раз быстрее Thumb-a, но имеет грубо в 1.5 раз больше объём кода. Вопрос на засыпку - какой режим эффективней?

А если за один доступ к ПЗУ считывать сразу две команды, то что? А если сразу 4?

1/ на первые два вопроса вы ответили сами - а) не делают потому/ что у них система команд такая - переменной длины да еще с возможностью
обработки данных в памяти/ что в принципе не позволяет реализовать однотактный конвейер/
б) 32-битный код исполняется в 1.5 раз быстрее Thumb-a (критерий число тактов),
имеет в 1.5 раз больше объём кода (критерий затраты программного кода).
Насчет одновременной выборки я подумаю/
Действительно/ если процессор может работать на частоте более высокой
чем выборка команд из ПЗУ то и пусть работает
Однако как быть с потреблением/ Оно тоже вырастет
В сигнальниках и VLIM архитектурах действительно одновременно выбирается несколько команд /
однако они /при возможности/ выполняются за один такт /за счет параллельной работы независимых обрабатывающих блоков
Мне кажется это более правильное решение/ а не такое лобовое/ как то что вы предложили

[GetSmart]

Мне кажется это более правильное решение/ а не такое лобовое/ как то что вы предложили

Гы Я предложил то, что уже реализовано в LPC2xxx (ARM7). "Лобовое" иногда самое эффективное. Тем более если ядро может работать на частоте в 5-10 раз большей чем флэш/ПЗУ.

[_Pasha]

регистровый с плавающим окном

Лучше некуда. 

[vitja]

M430 - это действительно вещь.

Только дополнение по поводу клонирования
См.формат двух-адресной команды
BKKK mmmRRR mmmRRR (PDP11) и KKKK RRRRmB mmRRRR (MSP430)
В-байт или слово, R-регистр источник и приемник, m-мода адресации.
При непосредственной адресации следующее слово команды содержит константу, при косвенной-адрес.
В чем принципиальные отличия. В числе регистров? 8 и 16. В их использовании - в PDP11 PC и SP это R7,R6, а в MSP430 - R0,R1.
Вобщем содрали архитектуру, надеюсь не испортили, навесили рюшки, фишки и назвали все это RISCом, иначе не модно
И сделали это 26 лет после DEC (в 1996 году)

[_3m]

Просил без ?ля-ля-ля.

Без ля-ля не получится потому что вы несете полную ахинею, причем ахинея в самой постановке вопроса.

1. Все чем мы пользуемся сейчас было заложено в 50-80-е годы.
[...]
3. После 80-х годов программирование и аппаратура ЭВМ развиваются экстенсивно и эволюционно. В основном в сторону инструментария, который делают избранные.
[...]
Мы ремесленники. Этим надо гордиться?

Вопросы выбора процессорной архитектуры были закрыты в XX веке. Ничего концептуально нового в области традиционных процессоров уже не придумать, поэтому мы и пользуемся разработками 80-х или 90-х.
Важность инструментария в связи с этим стала превышать важность архитектуры. Плохой компилятор ЯВУ угробит любую процессорную архитектуру, а хороший вытянет даже убогий процессор. Трудоемкость разработки компилятора генерирующего высокооптимизированный код на порядки превышает трудоемкость разработки процессорной архитектуры. Для нового самопального процессорного ядра компилятора у вас либо не будет либо он будет неэффективным. Отсутствие или плохое качество компилятора - смерть для процессорной архитектуры.
Именно поэтому разработка новой архитектуры процессора сейчас либо самоубийство либо чистый попил бабла.

Да, с конца 80-х микроконтроллеры стали ремеслом, сейчас и компьютерщики тоже становятся ремесленниками.

Ваши утверждения о том что MSP430 клон PDP11 смехотворны. PDP11 имеет ортогональную систему команд, а MSP430 - не ортогональную. Отличие концептуальное! MSP430 создан "по мотивам", но он отнюдь не клон.

[vitja]

1 В первую очередь система команд это интерфейс ядра процессора с внешним миром.
2 Взяли микроядро AVR без декодера и творите какую угодно систему команд.
3 Если бы вы поставили вопрос по другому: что лучше регистровый, стековый, регистровый с плавающим окном, аккумуляторный с одной или несколькими одновременно доступных памятей данных и т.д. то можно было бы судить. А так - все процессоры умеют складывать, вычитать, прыгать, загружать/выгружать данные куда-либо и
4 создать систему команд под незнамо какую зверушку будет очень сложно.

С Pashe не согласен/ Однако и Вы тоже/
1 Мне казалось/ что система команд это интерфейс программиста с процессором/ как я был не прав
2 см M8.zip в вывешенном каталоге/ на AVR это не похоже и на другие тоже
3 Именно я так ставлю вопрос и делаю попытку дать на него ответ/ не слушают
4 Создать систему команд для 8-разрядного МК/ сопрягаемого с транслятором/ удобного для программирования на ассемблере/
достаточно простого в аппаратной реализации

[Rst7]

Только дополнение по поводу клонирования
...
Вобщем содрали архитектуру, надеюсь не испортили, навесили рюшки, фишки и назвали все это RISCом, иначе не модно
И сделали это 26 лет после DEC (в 1996 году)

Ну еще можете сравнить IBM360/370 и MC680x0. Тоже много интересного узнаете о "клонировании"

Плохой компилятор ЯВУ угробит любую процессорную архитектуру, а хороший вытянет даже убогий процессор.

Первое - верно, второе - неверно.

Трудоемкость разработки компилятора генерирующего высокооптимизированный код на порядки превышает трудоемкость разработки процессорной архитектуры. Для нового самопального процессорного ядра компилятора у вас либо не будет либо он будет неэффективным. Отсутствие или плохое качество компилятора - смерть для процессорной архитектуры.
Именно поэтому разработка новой архитектуры процессора сейчас либо самоубийство либо чистый попил бабла.

Плюс, как сейчас говорят, пицот

[Mahagam]

ага, мусье vitja перебрался сюда с хобота, где его "изыскания" также "неоценили"

на зачем тут повторять бред из PC Week предварительно не обдумав цифры? вы там так и не придумали - где оставшиеся 70% рынка?

Примеры ? Ваш и мой ?пень? вырос из 8086-го (1980 год), была даже его 8-разрядная версия (это ближе к теме).
вы знаете, мне очень хочется узнать, что за такая "8-разрядная версия" была у 8086 ? или это вы в порыве графоманства не закусили?

Итого имеем 2.0*0.73*1.0*1.15 = 1.7. Во столько раз с точностью достаточной
для практического применения МК430 уступает 8051.
ооох! ну и забористая трава! эк вы, Маэстро, быстро и точно оценили MSP430. а ничего, что http://mcu.caxapa.ru/benchmarks/ получается с точностью до наоборот? ну неиначе - во всём виноваты компиляторы!

да, MSP430 иногда выполняет команду длительностью аж (о боже!) целых 6 (шесть) тактов. но вы так и не удосужились понять, что за этим стоит, для какого случая это получается крайне эффективно, и сколько команд 8051 ядра нужно выполнить, чтобы произвести такое же действие.
но вы просто решили, что MSP430 - это такое неэффективное ядро. аж в 1.7 раза хуже чем 8051, а мысли о том, что все ваши наукообразные рассуждения и вычисления эффективности с точностью до сотых - бред, не приходило?

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

ну так что, будем учится, или убежим на следующий форум? где, может быть, "оценят"

[vitja]

////Ничего концептуально нового в области традиционных процессоров уже не придумать, поэтому мы и пользуемся разработками 80-х или 90-х.

////Важность инструментария
////Именно поэтому разработка новой архитектуры процессора сейчас либо самоубийство либо чистый попил бабла.

///Ваши утверждения о том что MSP430 клон PDP11 смехотворны. PDP11 имеет ортогональную систему команд, а MSP430 - не ортогональную. Отличие концептуальное! MSP430 создан "по мотивам", но он отнюдь не клон.

По первым пунктам вы меня цитируете/ спасибо/
3/// Хорошо/ что к вашему совету не прислушались в ATMELE
Немного истории и ваш прогноз на это
1980 - 8051
конец 80-х - PIC
конец 90-х - AVR
конец 2010-х - ????

4/// Более не говорю о клонировании/// буду говорить /по мотивам PDP11/
По поводу не ортогональности системы команд М430 я посмотрю - это концепция серьезная/
я всегда считал что ортогональность в системе команд это хорошо/ а не ортогональность это плохо
(это из Майерса/ если не ошибаюсь)

[_Pasha]

2 см M8.zip в вывешенном каталоге/ на AVR это не похоже и на другие тоже

Лично я бы заморочился на следующем:
1. Разбить ОЗУ на 256-байтовые банки, в которых живут все нужные регистры, т.е все регистры, в т.ч и РС и указатель стека - отображаемые на память. При этом оставить возможность байтовой адресации всего массива .
2. Оставить один неотображаемый регистр - селектор банка, в системе команд предусмотреть команду безусловного перехода с выбором банка памяти
3. Разрядность команд оставить фиксированной, но время выполнения все равно будет очень варьировать, особенно если пытаться навернуть 32 разрядную арифметику при 8 разрядной ШД. При всей абсурдности затеи с 32-разр арифметикой, получим выигрыш в компактности кода.

[vitja]

1///ага, мусье vitja

2/// мне очень хочется узнать, что за такая "8-разрядная версия" была у 8086 ? или это вы в порыве графоманства не закусили?

3///да, MSP430 иногда выполняет команду длительностью аж (о боже!) целых 6 (шесть) тактов.

будем учится

1 Здравствуй дорогой/ Рад снова встретится/хоть и с детства не люблю ябед/ однако на iXBT уже все закончилось
2 Intel 8088
3 AVR с ARMом в придачу выполняет команду за один такт/ Счет 6/1 в чью пользу?
Просьба сохранять толерантность в общении/ задавать вопросы или ответы на них/ от смайликов Вы уже отучились/ Молодец

[Mahagam]

Ваши утверждения о том что MSP430 клон PDP11 смехотворны. PDP11 имеет ортогональную систему команд, а MSP430 - не ортогональную. Отличие концептуальное! MSP430 создан "по мотивам", но он отнюдь не клон.

вообще-то - ортогональная и у MSP430. любая команда работает с любым имеющимся регистром с любым имеющимся методом адресации.

[GetSmart]

3 AVR с ARMом в придачу выполняет команду за один такт/ Счет 6/1 в чью пользу?

Теоретик
ARM выполняет команду группового сохранения регистров во внутренней раме за 17 тактов максимум, а ту же команду во внешней раме до 100 тактов (а то и более), в зависимости от настроек внешней шины.

8088 - 16 битный проц с внешней 8р шиной. Система команд и архитектура 16-битные.

[Mahagam]

2 Intel 8088

и с каких это пор он стал 8-и разрядным? оттого что у него внешняя шина данных была 8-и разрядная? тогда какой разрядности S3C4530 который может одновременно работать с 8- 16- и 32-х разрядной памятью ???

3 AVR с ARMом в придачу выполняет команду за один такт/ Счет 6/1 в чью пользу?

"воспитанный дятлами мальчик задолбал своих приёмных родителей"
подумать, что же делается в течении этих 6 тактов, видимо не судьба. и как вообще формируется время исполнения любой команды MSP430 тоже.

[vitja]

Теоретик
ARM выполняет команду группового сохранения регистров во внутренней раме за 17 тактов максимум, а ту же команду во внешней раме до 100 тактов (а то и более), в зависимости от настроек внешней шины.

8088 - 16 битный проц с внешней 8р шиной. Система команд и архитектура 16-битные.

Кто бы спорил/ Особенно по последнему/
Это приведено как пример того что даже ХХ86 не гнушался 8-разрядности и 8-разрядные МК рановато списывать в утиль

А про команду группового сохранения - это верно - сохранить 16 регистров во внутренней памяти быстрее не получается/плюс такт на команду
Вопрос вот в чем - а нужна ли эта команда?
Для переключения контекста/ Как часто это присутствует в программе простого 8-разрядного МК/
При прерываниях/ Мультизадачность - для МК это экзотика/
Далее задаем долю операций переключения контекста/ 1% мало - берем 2/ В результате мы сэкономили на этой команде в объеме кода 0.32%
В тактах не выиграли ничего/ Зато усложнили аппаратуру/ Ради чего

Вами поднят гораздо более глубокий вопрос - касающийся состава команд и его влияния
на объем программного кода и тактов на его выполнение../Брр
Если уж вводить сложные команды, то какие -
мне кажется это не команды групповой пересылки регистров.
Большую долю операторов ЯВУ составляют условные операторы (16%) и циклы - 18%
(более всего счетные). Проценты в разумных пределах можно поправить.
Из этого следует, что надо объединить в одной команде операцию тестирования операндов
и перехода по условию, надо объединить модификацию счетчика с переходом по условию
в начало цикла. Здесь экономия памяти и тактов посущественнее будет.
Однако в каком МК вы это видели. Скажите.

Сообщение отредактировал vitja - Jan 19 2009, 13:42

[MrYuran]

AVR с ARMом в придачу выполняет команду за один такт/ Счет 6/1 в чью пользу?

Шулерство чистой воды.
1) AVR != x51
2) тот же AVR имеет команды по 2, 3 и даже (о ужас!) 4 цикла.

А мне вот в связи с банками и другой посудой вспомнилась такая фишка от Z80:
там были 2 идентичных набора регистров (включая PC, SP, флаги и т.д.), которые переключались одной командой.
То есть можно было реализовать много(двух)задачность, всего лишь выполняя эту команду по таймеру.
Вот над чем бы подумать. Опять же в контексте многозадачных приложений.

Ещё нынче в моде многоголовость.
8bit Dual (Quad) Core Microcontroller - по-моему, звучит!

[_Pasha]

Мультизадачность - для МК это экзотика

Это справедливо только для pic16C54

Если все это позиционируется для SoC, то почему такое отношение к мультизадачности?

[Mahagam]

Это приведено как пример того что даже ХХ86 не гнушался 8-разрядности и 8-разрядные МК рановато списывать в утиль

ну и бред. 8-разрядная внешняя шина позволяла в те годы зверски уменьшить цену конечного изделия на этом процессоре, оставаясь в рамках 16-ти разрядной вычислительной мощности. откуда взялась связь с МК - неясно.

А про команду группового сохранения - это верно - сохранить 16 регистров во внутренней памяти быстрее не получается/плюс такт на команду
Вопрос вот в чем - а нужна ли эта команда?

не. разработчики ядра её так просто по приколу вставили. ага.

Мультизадачность - для МК это экзотика/

да-да! и всякие табуны uCOS, eCOS, FreeFTOS, CTL и прочих многозадачных примочек - это всё из области экзотики и фантазии.
конечно, раз этого не было в книжках двадцатилетней давности, то этого просто не может быть сейчас.

Далее задаем долю операций переключения контекста/ 1% мало - берем 2/ В результате мы сэкономили на этой команде в объеме кода 0.32%
В тактах не выиграли ничего/ Зато усложнили аппаратуру/ Ради чего

ой жжошь!
"1% мало - берём 2" а почему не 5 ? почему не 10? а в военное время и до 80 может подскочить!
а подумать, в какий процессорах есть команды такого типа, а в каких нет? и что даёт эта команда? а зачем такую команду ввели 80286 проц? а что она давала там?

[vitja]

Шулерство чистой воды. 1) AVR != x51

8bit Dual (Quad) Core Microcontroller - по-моему, звучит!

Не AVR = x51 а объем кода М430 в 1.7 раза больше x51
AVR по моим расчетам уступает в объеме кода 8051 на 38%/ но по производительности опережает последний почти в два раза/
если оценивать такты 8051 не по оригиналу а по более современным моделям

[Mahagam]

Не AVR = x51 а объем кода М430 в 1.7 раза больше x51
AVR по моим расчетам уступает в объеме кода 8051 на 38%/ но по производительности опережает последний почти в два раза/
если оценивать такты 8051 не по оригиналу а по более современным моделям

не. ну какая настойчивость. смотрим в книгу видим жопу.
третий раз дают тебе ссылку: http://mcu.caxapa.ru/benchmarks/
там, по практическим, а не чисто умозрительным, результатам видно, что объём кода у MSP430 меньше, чем у 8051.
например, в самом ядрёном случае - арифметические операции с 16-ти разрядными матрицами имеем 825/112 - у MSP430 кода получается меньше в 7.3 раза!
но раз факты опровергают теорию - от них надо избавиться? не так ли?

ощущение, что вы там ни разу в жизни не запускали ни один компилятор, ни разу в жизни не видели симулятора МК

"В третей комнате Николай Степанович увидел отдел изучения меча Зигфрида. Самого меча пока не дастали, но отдел занимался изучением воображаемой модели. Воображаемый Нотунг помещали в магнитное поле, травили кислотами и испытывали на разрыв..." (С) М. Успенский, А. Лазарчук, "Посмотри в глаза чудовищ".

[vitja]

ну и бред. откуда взялась связь с МК - неясно.

разработчики AТMEL так просто по приколу вставили команду группового сохранения регистров/

жжошь!
а зачем такую команду ввели 80286 проц? а что она давала там?

Только как пример того/ что 16-разрядный процессор 8086 работал на 8-разрядной шине как и современные 8-разрядные МК/

Они приколись по полной - ввели команду группового восстановления регистров/
в 80286 эти команды ввели без приколов/ а по причине необходимости поддержки мультизадачности

Типовой МК работает с таймером (1 обработчик прерывания) плюс интерфейсы (еще 1 или более обработчиков)
В каждом из них сохраняют контекст одной или большим числом команд/ Доля этих команд в общем объеме кода
программы минимальна и даже в военное время не превышает 2%/ Как сделать больше я не знаю / Научите

Сообщение отредактировал vitja - Jan 19 2009, 14:46

[GetSmart]

В каждом из них сохраняют контекст одной или большим числом команд/ Доля этих команд в общем объеме кода
программы минимальна и даже в военное время не превышает 2%/ Как сделать больше я не знаю / Научите

В АРМах команды группового сохранения/загрузки регистров используются почти при каждом вызове процедуры даже в однозадачной программе. При этом сохраняюся в стеке 3..5..10 регистров. В ARM7 эта команда гораздо более универсальна в отличие от 80286. При желании этой командой можно максимально быстро копировать одну область памяти в другую, в 2..3 раза быстрее чем другим способом. Вы знаете слишком поверхностно системы команд. Поэтому все приводимые цыфры и большинство данных вами оценок архитектур необъективны. Глупости конкретные. С таким пониманием темы лучше от неё сразу отказаться.

[Mahagam]

Только как пример того/ что 16-разрядный процессор 8086 работал на 8-разрядной шине как и современные 8-разрядные МК/

да вы просто из страны эльфов! откуда вам знать какой разрядности и сколько шин внутрях у МК? это внешняя шина имеет ограничения по разрядности. что там внутрях - известно только производителям. внутрях кристалла к ядру может подходить а) 8-ти разрядная шина команд б) 8-и разрядная шина данных из памяти в) 8-и разрядная шина данных для записи в память. в итоге за 1 такт мы а) читаем команду б) получаем данные из памяти в) пишем результат предыдущих вычислений в память. МК остаётся 8-и разрядным. но эти его 8 разрядов ничего общего с внешними 8-ю разрядами 8086 не имеют. ибо по внешней шине за 1 такт происходит только одна транзакция.

Они возможно по приколу/ а в 80286 по причине необходимости поддержки мультизадачности

это вы высосали из пальца. что бы вы не сосали что-нибудь ещё, приведу пример.
пример прост: имеем понятное ограничение - одно обращение к памяти за такт (память - внешняя). имеем задачу - сохранить в стеке 10 регистров
вариант а) 10 раз мы читаем команду PUSH, 10 раз пишем в стек. итого 10 байт кода, 20 обращений к памяти
вариант б) 1 раз прочитали PUSHALL, 10 раз записали в стек. итого - 1 байт кода, 11 обращений к памяти.
эффективно? безусловно. но эта команда становится эффективной по скорости только в случае если данные и команды лежат в одной физической памяти. в случае с МК это уже не так критично.

Типовой МК работает с таймером (1 обработчик прерывания) плюс интерфейсы (еще 1 или более обработчиков)
В каждом из них сохраняют контекст одной или большим числом команд/ Доля этих команд в общем объеме кода
программы минимальна и даже в военное время не превышает 2%/ Как сделать больше я не знаю / Научите

а если на процессор валятся 20000 прерываний в секунду? если он из одного прерывания еле успевает переползать в обработчик следущего? есть ли смысл оптимизировать ядро для быстрого сохранения/восстановления контекста?
ARM7 умеет сохранять в стек одной командой произвольные регистры, что не только полезно в обработчике прерываний, но и просто при вызове функций.

[vitja]

1 ////ну какая настойчивость. смотрим в книгу видим жопу.
2/// там, по практическим, а не чисто умозрительным, результатам видно, что оарифметические операции с 16-ти разрядными матрицами имеем 825/112 - у MSP430 кода получается меньше в 7.3 раза!

1/ У Чехова в записках станционного смотрителя - написано не так "смотрю в книгу, а вижу фигу"/
Однако это было написано в прошлом веке/ интернета тогда не было/ а книга даже 81 года для Вас это библиографическая редкость
/Вы только Wiki читаете - кладезь Ваших знаний
2/ Сравнение проводилось на не вычислительных задачах обработки 8-разрядных данных поэтому такие результаты//
И вообще сравнение проводилось не ради сравнения/ а ради выявления и оценки влияния архитектурных особенностей
системы команд 8-разрядного МК на затраты кода и тактов на реализацию операторов ЯВУ по весу их употребления в типовых программах

// в конце позволю себе пофантазировать
Сейчас есть мониторы/ 3D графика/ Inet с его анонимностью/
Но вдруг появились теле-мониторы не с графикой а с материальной передачей информации
Сидишь себе за таким теле-монитором (чатишься)/ а тут тебе в ответ не словом/ а /// та так что чатится уже не захочется
Однако я бы бросил перчатку/ а результат - как у Черной речки / это там в 600-стах километрах от Москвы

[Mahagam]

vitja
давайте вы не будете словоблудить когда по существу темы сказать нечего.
вам не нравится арифметика? смотрим результаты теста по switch/case по восьмиразрядной переменной. и опять у MSP430 выигрыш в 209/178 = 1.17 раза по объёму кода. неужто незаметно, что ваша оценка не то что бы хромает - она вообще в корне не верна! вы вообще сверялись с практическими данными?

что касается библиографических редкостей - у меня на столе лежит "MICROCOMPUTERS/MICROPROCESSORS hardware, software and applications" на русском. издана в 1979. оригинал аж 1976 года. ничего кроме "энтомологического" интереса "а как оно тогда было, когда двухядерников не было" не вызывает.

[vitja]

1 пример прост: а) 10 раз мы читаем команду PUSH, 10 раз пишем в стек. итого 10 байт кода, 20 обращений к памяти
вариант б) 1 раз прочитали PUSHALL, 10 раз записали в стек. итого - 1 байт кода, 11 обращений к памяти.

2 ARM7 умеет сохранять в стек одной командой произвольные регистры, что полезно ... при вызове функций.

1. Я тоже иногда ошибаюсь и передергиваю понятия.
Однако при разделенных шинах команд и данных (в МК, как правило, это так)
Мы будем иметь 10 команд PUSH и только 10 тактов на их выполнение, а Вас почему то 11. Неувязочка получилась.

Опа!!!
2. Я так ждал, что кто нибудь это скажет. Вы первый. Поздравляю.
Именно. Я всегда считал, что одной из проблем регистровой архитектуры, несмотря на их шустрость (обработка 2 операндов за такт),
являются накладные расходы на загрузку и выгрузку регистров при вызове процедуры.
Я для расчетов брал цифру 2 (1 - входной операнд и 1 - результат).
По Вашему мнению какая цифра этих затрат будет ближе к действительности.

Однако на этот вопрос ответил заранее GetSmart - поэтому не напрягайтесь, от 3 до 10, ++++
(в среднем можно принять 5 туда и 5 обратно при каждом вызове процедуры доля которых в среднем составляет 18%)
Срочно делаю перерасчет числа тактов для AVR.

Сообщение отредактировал vitja - Jan 19 2009, 18:03

[Mahagam]

1. Я тоже иногда ошибаюсь и передергиваю понятия.
Однако при разделенных шинах команд и данных (в МК, как правило, это так)
Мы будем иметь 10 команд PUSH и только 10 тактов на их выполнение, а Вас почему то 11. Неувязочка получилась.

никакой неувязочки. в тех МК, в которых шина для внешней памяти наружу не выходит (или выходит редко, или архитектура закрытая) команд множественного сохранения обычно и не наблюдается. (AVR, MSP430, PIC`и всякие), ибо выигрыша по скорости не получается вовсе.
а вот ядра ARM7/9, I80286 и выше обычно рассчитаны на жизнь с внешней памятью. посему минимум 1 такт придётся потратить на выборку этой команды. соответственно и все растактовки приведены для варианта с внешней памятью. и в этом случае эта команда ох как ускоряет работу.

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

а тут вуаля - и вылазит такой чмыримый вами MSP430.
нааааапример:
нужно в прерывании инкрементировать 16-ти разрядный счётчик
код типа
// Timer A0 interrupt service routine.
void timera_isr(void) __interrupt[TIMERA0_VECTOR]
{
time_counter++;
}

выливается в две команды:

INC &time_counter
RETI.

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

[vitja]

vitja
1 смотрим результаты теста по switch/case по восьмиразрядной переменной. и опять у MSP430 выигрыш в 209/178 = 1.17 раза по объёму кода. неужто незаметно, что ваша оценка не то что бы хромает - она вообще в корне не верна! вы вообще сверялись с практическими данными?

2 что касается библиографических редкостей - у меня на столе лежит "MICROCOMPUTERS/MICROPROCESSORS hardware, software and applications" на русском. издана в 1979. оригинал аж 1976 года. ничего кроме "энтомологического" интереса "

1. Как только Вы взяли тест для 8-разрядных данных (что ближе к теме), то с 7.3 опустились до 1.17.
Наверное можно найти еще какой-нибудь тест, где будет еще меньше.
Но этого делать не будем по причине того,
а) что единичные тесты не представительны. Выборка для оценки должна быть гораздо больше.
б) что я оцениваю не конкретные М430, 8051 и пр. и никого не хочу обижать.
Я на их примере оцениваю архитектуру системы команд - 0, 1, 2-адресной, переменной или фиксированной длины, регистровой, стековой или с командами память-память, я оцениваю в конечном счете влияние архитектурных особенностей системы команд на эффективность процессора.
Пока все.

2. Об этом я уже писал. Описания, справочники, инструкции к программным системам, наверное, издавались и тогда.
Я говорю о нетленке. Это Дейкстра, Бэкус, Кнут, Вирт, Хоар, Ритчи и др. А свою книгу убери со стола.
Хотя возможно ее можно использовать как подставку или как крышку.

[GetSmart]

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

С 51-ым незнакомы?! У него будет ровно такой же код. Только адрес переменной ограничен 8 битами.

[vitja]

в МК, в которых шина для внешней памяти наружу не выходит выигрыша по скорости не получается вовсе.
а вот ядра ARM7/9, I80286 и выше обычно рассчитаны на жизнь с внешней памятью. посему минимум 1 такт придётся потратить.

вылазит MSP430. и выливается в две команды:
INC &time_counter
RETI.

По первому договорились. Ты прав больше. Я имел в виду только МК (с внутренней память), а ты говоришь о более общем случае - использование процессором внешней памяти.

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

А пример дополнил бы - выливается в 2 команды, 6 байт и 6 тактов плюс еще такты на само прерывание.
Если на один такт ошибся извини.
Я бы тоже самое мог написать на 8051 (от ATMEL, в нем говорят байтовые команды выполняются за один такт).
Получил бы те же команды, только байтов на 3 меньше, а тактов, наверное столько же.

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

[Mahagam]

1. Как только Вы взяли тест для 8-разрядных данных (что ближе к теме), то с 7.3 опустились до 1.17.
Наверное можно найти еще какой-нибудь тест, где будет еще меньше.

да какая разница во сколько раз MSP430 выигрывает у 8051, если по вашим "экспертным" оценкам он должен солидно так проиграть.
выводы то какие? а выводы простые: весь ваш труд с вычислениями эффективности МК до сотых долей - ЛАЖА!

а) что единичные тесты не представительны. Выборка для оценки должна быть гораздо больше.

угу. в большинстве случаев достаточно оценить камень по жирному тесту drystone/wetstone и понять как он в математике. но это точно не должны быть умозрительные заключения с перемножениями чисел неясного происхождения.

Я на их примере оцениваю архитектуру системы команд - 0, 1, 2-адресной, переменной или фиксированной длины, регистровой, стековой или с командами память-память, я оцениваю в конечном счете влияние архитектурных особенностей системы команд на эффективность процессора.

ну а почему оценки нифига не кореллируют с практикой?

2. Об этом я уже писал. Описания, справочники, инструкции к программным системам, наверное, издавались и тогда.
Я говорю о нетленке. Это Дейкстра, Бэкус, Кнут, Вирт, Хоар, Ритчи и др. А свою книгу убери со стола.
Хотя возможно ее можно использовать как подставку или как крышку.

что-то вам чтение нетленки не помогает. может наоборот - у меня более правильная книга?

С 51-ым незнакомы?! У него будет ровно такой же код. Только адрес переменной ограничен 8 битами.

о. ну конечно. если добавить волшебное слово "только" - код любого проца будет "ровно такой же". с какой вероятностью интересующая нас переменная попадёт в эти счастливые 256 байт?
с 51-ым знаком крайне поверхностно.

По первому договорились. Ты прав больше. Я имел в виду только МК (с внутренней память), а ты говоришь о более общем случае - использование процессором внешней памяти.

дело не только во внешней/внутренней памяти. для начала вкури разницу между гарвардской и фон-Неймановской архитектурой. будет ясно больше.

Я бы тоже самое мог написать на 8051 (от ATMEL, в нем говорят байтовые команды выполняются за один такт).
Получил бы те же команды, только байтов на 3 меньше, а тактов, наверное столько же.

ну так напиши - покажи класс. ну так, чтобы переменная не была ограничена какими-либо адресами.

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

а может ну её - эту оценку эффективности: запустили drystone и закрыли глаза на все технические мелочи?

[vitja]

о вещи MSP430

В оценке ошибка, виноват. Выигрыш в коде у байтовой системы команд 8051
по сравнению с 16-разрядной составляет 1.22 (раздел 5.2 работы)
Поэтому имеем 1.22*0.73*1.0*1.15=1.02. Т.е они дают приблизительно равный объем кода.
Это подтверждают цифры Maxago..., который приводит данные по тесту switch...
где получено 1.17.
Согласись, что для прогноза 15% является допустимой погрешностью.
Вот так теория проверяется практикой.

смотрю в книгу, а вижу ...

Сгораю от стыда.
Написано Чехонте "Жалобная книга", а "Станционный смотритель" написал кто-то другой.
Но ведь никто не поправил...

[vitja]

нужно в прерывании инкрементировать 16-ти разрядный счётчик
код типа ///
выливается в две команды:

INC &time_counter
RETI.

Продолжаем работать над ошибками/ своими и чужими
В постановке задачи требуется выполнить инкремент 16-разрядной переменной по прерыванию/
Для обработчика прерывания маловато будет /поэтому в стеке ничего не сохраняем/ контекст не переключаем
Разработчики 8051 допустили ошибку или имели на то определенные соображения -
операция инкремента не является эквивалентом прибавления 1 и не влияет на флаги регистра состояния/
Поэтому код становится длиннее и страннее
mov A,tim0
inc A
jnz M
inc tim1
m: mov tim0,A
reti
Итого 10 байт/ Ничего другого ожидать от 8-разрядной древности нельзя/
Однако для байтового счетчика все таки 3 байта будет (на внутренней памяти)

[vitja]

Лично я бы заморочился на следующем:
1. Разбить ОЗУ на 256-байтовые банки, в которых живут все нужные регистры, т.е все регистры, в т.ч и РС и указатель стека - отображаемые на память. При этом оставить возможность байтовой адресации всего массива .
2. Оставить один неотображаемый регистр - селектор банка, в системе команд предусмотреть команду безусловного перехода с выбором банка памяти
3. Разрядность команд оставить фиксированной, но время выполнения все равно будет очень варьировать, особенно если пытаться навернуть 32 разрядную арифметику при 8 разрядной ШД. При всей абсурдности затеи с 32-разр арифметикой, получим выигрыш в компактности кода.

Вчера весь день потерял на ненужные препирательства, достали.
Поэтому пропустил Ваши предложения.
По ним видно, что Вы единственный, кто ознакомился с M8.ZIP и
отметил непохожесть предлагаемой системы команд по сравнению с известными серийными 8-разрядными МК.
Из предложений остановлюсь, пока, на последнем.
Каждое принимаемое решение определяется ожидаемым результатом с учетом последствий принятого решения.
Я хотел добиться компактного кода – поэтому выбрал байтовую систему команд, 16-разрядная увеличивает объем кода по моим прикидкам в 1.22 раза (это один из результатов анализа rating.doc и писался он для целей оценки не конкретных моделей МК – заблуждение, а для оценки влияния архитектурных решений в системе команд МК и выбора наиболее оптимальных, а для этого нужны количественные, а не качественные оценки, пусть такие какие получились).
Далее, если выбрана байтовая система команд, то одноадресная как в 8051 Или другая.
Я выбрал стековую. Однако в нее ввел префиксную команду задания операнда, что позволило в рамках стековой архитектуры реализовать двух-адресные команды обработки данных (пересылка, унарные операции и модификация данных) и тем самым обеспечить сокращение числа команд до 0.73 по сравнению с 8051 (по моим прикидкам).
Выбор стековой архитектуры обусловлен еще и тем, что она хорошо сопрягается с трансляторами ЯВУ. Вспомним промежуточный P-код или Java байт-код, на который я ориентировался.
Переход на фиксированную длину 16-разрядов – это путь повторения AVR, его можно Чуть-чуть улучшить, но не радикально.
Форум не позволяет изъяснится подробно и доходчиво. Но, если есть понимание, то много слов не надо.
А 32-разрядность введена/ что бы посягнуть 8-разрядным ядром в область применения 32-разрядных МК/ а также иметь в системе команд возможность дальнейшего развития/
Пока. Об остальном подумаю.

[Leka]

Это смотрели? http://www.ultratechnology.com/chips.htm

[_Pasha]

Выбор стековой архитектуры обусловлен еще и тем, что она хорошо сопрягается с трансляторами ЯВУ. Вспомним промежуточный P-код или Java байт-код, на который я ориентировался.

Я бы сказал, эффективность работы трансляторов ЯВУ максимальна на архитектуре с небольшим количеством регистров, вернее, с небольшим объемом сохранения контекста процесса. А уж за счет чего это можно сделать - операций память-память, регистровых файлов -  это другой вопрос.

На примере того же АВР и Си видим, что до сих пор идет бурное развитие средств оптимизации, потому что эта регистровая модель немного не вписывается в сложившиеся технологии генерации кода.

Переход на фиксированную длину 16-разрядов – это путь повторения AVR

Имхо, проще и дешевле. Думается, что при введении команд (не псевдокоманд!), "каскадирующих" арифметику до 16/32 разрядов, может этот Ваш коэффициент 1,22  опять опустить ниже плинтуса Но это так - пальцем в небо.

И еще, можно АВР допилить до нужной кондиции так : разрешить операндам [Y+d] [Z+d] участвовать не только в операциях Load/Store. 

>>поток сознания иссяк

[Mahagam]

В оценке ошибка, виноват. Выигрыш в коде у байтовой системы команд 8051
по сравнению с 16-разрядной составляет 1.22 (раздел 5.2 работы)
Поэтому имеем 1.22*0.73*1.0*1.15=1.02. Т.е они дают приблизительно равный объем кода.
Это подтверждают цифры Maxago..., который приводит данные по тесту switch...
где получено 1.17.
Согласись, что для прогноза 15% является допустимой погрешностью.
Вот так теория проверяется практикой.

теорию потиху подгоняем. под некие сферические задачи в вакууме. а практика иногда показывает и 7 кратную разницу...

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

Я хотел добиться компактного кода – поэтому выбрал байтовую систему команд, 16-разрядная увеличивает объем кода по моим прикидкам в 1.22 раза

фигасе. ну вроде уже и теорию начали перекраивать, а всё туда же. http://www.atmel.com/dyn/resources/prod_do...nts/DOC1292.PDF тут атмел рвёт всех по размеру кода, хотя у них код нифига не 8-и разрядный.
неужто по предыдущей ссылке не сходили? неужто не увидели, что нет нет никакого увеличения в 1.22 раза!

ну и вопрос на засыпку: вот описали вы архитектуру, полностью определились со всеми разрядностями, количеством регистров, набором команд, расписали какие команды как и когда меняют флаги. и прочее прочее прочее. а что дальше?

[vitja]

Это смотрели? http://www.ultratechnology.com/chips.htm

Здравствуй LEKA/ Наконец-то пересеклись/ но с бабочками/ есть такие красивые яркие на М называются

К своему большому "сожалению" смотрел и автора Форта Charles Мура знаю/ но не лично
Поэтому стал сторонником стековой архитектуры в его интерпретации/ вывешено M8.zip
Что до судьбы перечисленных там проектов/ может тогда их время еще не пришло/ см выше об истории 8-разрядных МК

1///На примере того же АВР и Си видим, что до сих пор идет бурное развитие средств оптимизации, потому что эта регистровая модель немного не вписывается в сложившиеся технологии генерации кода.

2///введении команд (не псевдокоманд!), "каскадирующих" арифметику до 16/32 разрядов, может этот Ваш коэффициент 1,22 опять опустить ниже плинтуса Но это так - пальцем в небо.

3///И еще, можно АВР допилить до нужной кондиции так : разрешить операндам [Y+d] [Z+d] участвовать не только в операциях Load/Store.

>>поток сознания иссяк

Форум не то место для основательного разговора/ Это не мозговой штурм/ не диспут - это ЧАТ
Если я имею свое мнение/ то изменить его могу только /// как и ты/ уже перешли
1/ Твои слова подтверждают мой тезис/ что любая архитектура / кроме подчеркнуто стековой/
требует специальной оптимизации/ которая решается в компилятор LCC GNU и иже с ними плохо
Возможно фирменные трансляторы для ххх86 обеспечивают большую эффективность
Однако открываю книгу "Использование ассемблера для оптимизации программ на Си" 2004 г
И читаю в предисловии "большинство серьезных приложений пишутся на /// и вызвано это тем/
что ни одно инструментальное средство программирования на ЯВУ не может дать максимального выигрыша///

Посмотри Глава 4 Там приведена реализация основных операторов ЯВУ в машинных кодах Как будто у меня списано

2/ Я предложил ввести //потактную// обработку данных до 32-разрядов на 8-разрядном ядре/
С одной стороны на будущее/ как возможность расширения//
С другой это дает многократный выигрыш в объеме кода по сравнению с серийными 8-битниками
а в производительности нет
Это плохо/ как решить пока не знаю

Сообщение отредактировал IgorKossak - Jan 20 2009, 18:28

[vitja]

По поводу симулятора, этим уже занимался Кнут, все примеры в книге на его собственной виртуальной машине. Там же он пишет кое что о математической составляющей процессоров. Может его почитаете. Книжка конечно высший пилотаж, я застрял на 50й странице. Но уверен,
если пройти все его три тома, наступит 3й дан просветления.

По вашей рекомендации обратился к Кнуту (том первый страница далековатая но нашел///159я)
«МИХ автокод очень похож на машинный код существующих машин, но
Изящнее. Он выбран достаточно мощным для реализации алгоритмов программ на ЯВУ,
Но и достаточно простым …
Читатель должен изучить его с особым вниманием…»
И я о том же говорю. Присоединяюсь к просьбе классика, читайте внимательно http://moko.ru/mc/ M8.zip
reting.pdf для просветленных
А по МИХ коду с Кнутом не согласен. Аккумулятор/ индексные регистры//// маловато будет для изящности
МИХ код (не машинный код) должен быть как минимум 2-3-адресным/ с возможностью задания операторов в памяти/ и еще более чего///

Сообщение отредактировал vitja - Jan 20 2009, 13:50

[vitja]

1/// Copy-Paste называется. попробуйте.

2//фигасе. ну вроде уже и теорию начали перекраивать,

3//ну и вопрос на засыпку: вот описали вы архитектуру, полностью определились со всеми разрядностями, количеством регистров, набором команд, расписали какие команды как и когда меняют флаги. и прочее прочее прочее. а что дальше?

1. Как читается так и пишется За кнопочки спасибо, но я привык больше ручками

2. Я исправил ошибку, а не результаты своей работы.
Вы можете признаться в своей ошибке. См выше. Ищите. Не найдете - никому не скажу.

3. Дальше надо читать М8.zip. Специально упакованный, что бы не лазали ламеры.
Однако. Почему нет. Смотрите здесь. (или поднять выше?)
На основе ... предлагается ... для тех, кому лениво вникать в 12 листов текста того, что указано
реферат - аннотация - тезисы, т.е. очень кратко:
- Универсальное процессорное ядро для 8-32 разрядных микроконтроллеров
- Система команд – стековая (патентно чистая)
- Объем ПЗУ до 64 К с возможностью расширения
- Объем ОЗУ до 64 К с возможностью расширения
- Производительность – 1 такт на байт команды (данного)
- Тактовая частота процессора до 500 МГц
- Площадь кристалла – при технологии 0.13 мк – точка на кристалле
- Потребление – в четыре раза меньше
- Имеется встроенный отладчик (трассировщик), 2-х канальный DMA

Обеспечивает сокращение программного кода по сравнению
с 32-разрядным ARM Thumb в два раза при равной с ним производительности,
превышет эффективность 8-разрядных серийных МК в 2-3 раза.

Все, lдальше будет позже, выдохся.

Сообщение отредактировал vitja - Jan 20 2009, 16:51

[GetSmart]

Обеспечивает сокращение программного кода по сравнению
с 32-разрядным ARM Thumb в два раза при равной с ним производительности,
превышет эффективность 8-разрядных серийных МК в 2-3 раза.

Товарищ размечтался. Причём он даже не знает ни одной фичи ARM7. Скорее всего никогда не видел листинги всех обсуждаемых им процессоров. А судит только поверхностно по системе команд. Бред.

А вообще, похоже на то, что он действительно учавствует в распиле бабла (российского?). Вот такие значит товарищи пилят наше бабло

[Mahagam]

Как читается так и пишется За кнопочки спасибо, но я привык больше ручками

что-то мой ник вы, Витья, ручками правильно через раз пишете. ручки не оттуда растут?

2. Я исправил ошибку, а не результаты своей работы.

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

Однако. Почему нет. Смотрите здесь. (или поднять выше?)
На основе ... предлагается ... для тех, кому лениво вникать в 12 листов текста того, что указано

читал. ПРОНИКСЯ!

- Универсальное процессорное ядро для 8-32 разрядных микроконтроллеров
- Система команд – стековая (патентно чистая)
- Объем ПЗУ до 64 К с возможностью расширения
- Объем ОЗУ до 64 К с возможностью расширения

верю.

- Производительность – 1 такт на байт команды (данного)

новая единица измерения производительности? такт на байт? и какую производительность имеют иные процессоры в этих единицах? а хватит ли такой производительности для декодирования mp3 на лету?

- Тактовая частота процессора до 500 МГц
- Площадь кристалла – при технологии 0.13 мк – точка на кристалле

есть какие-нибудь доказательства этих цифр? особенно про 500 МГц интересно - на основе каких сведений получено это число? или опять - палец пососали? сколько триггеров получилось в нет-листе?

- Потребление – в четыре раза меньше

в четыре раза меньше ЧЕГО?????? кипятильника?

- Имеется встроенный отладчик (трассировщик), 2-х канальный DMA

пока что имеются только высосанные из чего-то непонятного фантазии. чтобы говорить, что что-то там есть - как МИНИМУМ нужно построить HDL-модель нужного модуля/устройства. и только на основе результатов моделирования HDL-описания можно называть (с оговорками) и частоту, и площадь, и потребление.

Обеспечивает сокращение программного кода по сравнению
с 32-разрядным ARM Thumb в два раза при равной с ним производительности,
превышет эффективность 8-разрядных серийных МК в 2-3 раза.

какие-нибудь доказательства этого есть? или это всё на основе тех же оценок, несовместимых с практикой.

[Leka]

Зачем ходить по чужим граблям? Пример(Кнут): MIX --> MMIX --> ??? и где идеал? Лучше учиться прятать низкоуровневые детали конкретных архитектур от программистов - чтобы низкоуровневые ЯВУ(например Си) - могли, наконец, уйти на заслуженный отдых.

[en1gma]

не уж то тоже присоединиться
на хоботе не вышло, так сюда придем
если что - есть ещё http://telesys.ru/ с их конференцией..

со стороны это смотрицца так, что некто пытается написать Талмуд (на диссер не тянет) о МК, рассматривая только МП в них, причём с до сих пор непонятной целью

а так бред, так как нету базы для оценки.. код для оценки высосан из пальца..
выбор МК для разработки на том же хоботе я вам тоже описал
и все дружно объясняли зачем никто не оптимизирует 8битники

[Leka]

Кнут: "Тем не менее, нужно признать, что в настоящее время MIX полностью устарел. Поэтому в последующих изданиях данной книги он будет заменен новым компьютером под названием MMIX (номер 2009)...
...Полный и повсеместный переход в данной книге от MIX к MMIX отнимет много времени, поэтому огромная просьба к добровольцам - окажите посильную помощь в этом деле. Между тем, автор надеется, что читатели согласятся подождать еще несколько лет и пока удовлетворятся устаревшей архитектурой MIX, которая все еще заслуживает внимания, поскольку обеспечивает среду для дальнейших разработок."

Пример альтернативного подхода - Эльбрус с Эль-76.

[vitja]

искажение ников на большинстве форумов считается

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

[Mahagam]

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

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


и давайте таки вернёмся к обсуждению проекта по распилу бабла Процессора М8.
таки интересуют кучи вопросов, заданных немного ранее, но вместо ответа на которые я получил какую-то пургу про бабочек.
особенно докучают вопросы про частоту, и наличие синтезируемой HDL-модели.

[vitja]

HDL-модели.

VHDL – правильно, Verilog – тоже.
1. Про закуску – образованные люди закусывают горячим (первый совет профессора Преображенского).
2 Образованные люди начинают проект с ТЗ и разработки спецификаций. Только затем приступают к разработке, а не наоборот.

"...разруха в голове...почистите все" (второй совет профессора).
Когда почистите, тогда давайте конкретные вопросы или предложения по М8.зип (это предварительная спецификация).
А пока. Увольте.

Сообщение отредактировал vitja - Jan 21 2009, 05:00

[vitja]

Эльбрус с Эль-76.

Кнут ранний, 199Х г. Издания – я ему тоже предложил МХХ поправить, о чем указано. Зачем// попытаюсь сказать позже
если есть интерес

Эльбрус, честно признаюсь, еще не знаю. Бабаяна знаю, теперь он где-то в SAN ///
Для ознакомления с Эльбрусом, должны быть мотивы.
Чем в системе команд он отличается от других?
Позитивно или просто оригинально?
И главное - это суперкомпьютер// как его приложить к 8-разрядному МК// Какие его решения могли бы пригодиться

где идеал? Лучше учиться прятать низкоуровневые детали конкретных архитектур от программистов - чтобы низкоуровневые ЯВУ(например Си) - могли, наконец, уйти на заслуженный отдых.

Спасибо// вы подсказали мне
долой ПИКИ АВР и прочие 51-е /// даешь "Идеальную систему команд для 8-разрядного МК"
Такая система команд должна отвечать 3 требованиям//
1 Без потери эффективности сопрягаться с ЯВУ
2 Обеспечивать компактный и быстрый машинный код
3 Быть простой и эффективной в аппаратной реализации
Вы предлагаете решение по п/1 имея в виду даже языки высочайшего уровня/
Навскидку я помню Майерса/ с его объектно-ориентированной архитектурой// Интел 486//
Были наверняка и другие

Они не востребовались или обогнали свое время//
Они не выполнили пп 2 и 3// Поэтому сейчас имеем то/ что имеем

[Mahagam]

VHDL – правильно, Verilog – тоже.

http://en.wikipedia.org/wiki/Hardware_description_language
HDL-модель - правильно. это самостоятельный устоявшийся термин.

Образованные люди начинают проект с ТЗ и разработки спецификаций. Только затем приступают к разработке, а не наоборот.

когда я вижу по вашим спецификациям фантасмагорические требования типа "500 МГц на двухстадийном конвейере", встречаю высокохудожественные высказывания: "размер - точка на кристалле", мне совершенно не верится, что это писали образованные люди.
которые, к тому же, совершенно не владеют пунктуацией русского языка, повсеместно ставя непонятные наклонные чёрточки.

все оценки производительности, площади и частоты получаются минимум после этапа эскизного проектирования. где он? этот этап.

Когда почистите, тогда давайте конкретные вопросы или предложения по М8.зип (это предварительная спецификация).

абсолютно конкретные вопросы:
1. как получена оценка в 500 МГц тактовой?
2. как получена оценка площади?
3. потребление в 4 раза меньше ЧЕГО?
4. как получена оценка потребления?
5. на каком классе тестов получено сокращение объёма кода в 2 раза относительно ARM Thumb?
6. как получен результат по вопросу 5 ?

[vitja]

российское бабло и ///ARM7//

Ваши у/е и мои рубли за АРМ АВР и пр идут в Россию/// //Для меня это новость/ Атмел работает в России
Как диллер/делящий наше бабло/ вы знаете куда они идут///
Про ябед и анонимов см//выше//
Продолжайте чатится// Я не буду
Однако это ответ не GetSmart//извини ради //не туда кнопку нажал
Это написано диллеру

никто не оптимизирует 8битники

О 8-битниках - Интел в 1980г сделал 8051 потом продал лицензию
После этого все остановилось////
И Вы' /en1gma'/ утверждаете// что Филлипс Даллас Атмел не оптимизирует 8-битники
Тогда с чем Вы работаете?

подумать, что же делается в течении этих 6 тактов, видимо не судьба. и как вообще формируется время исполнения любой команды MSP430 тоже.

Действительно/ 6 тактов - это не 11 мгновений и сделать можно очень много// например
1/выбрать команду/
2/декодировать ее
3/выбрать один операнд
4/выбрать второй операнд
5/выполнить операцию
6/сохранить результат
Так каждый может/// А сделай это за такт//Слабо// тогда хотя бы за два// Только не надо говорить про АВР
При работе с памятью //см/ мой талмуд// он больше тактов тратит//
А про вызов процедур я даже не говорю// от 5 до 10 тактов только на сохранение контекста//
который потом еще и восстанавливать надо/ или я не прав//

Отвечаю тем// кто хочет знать //что делает процессор в течении тактов своей работы//
чищю конюшни//пропуски//в вопросах

ARM7

Книга «Микроконтроллеры ARM 7. Семейство LPC2000» есть в наличии
В ней содержится полное описание системы команд, регистровой структуры, а также рекомендации производителей по программированию и применению. Предназначена для /// радиолюбителей и студентов технических вузов.

Мы видимо говорим о разном// Вы об АРМе / Я об эффективной системе команд 8-разрядного процессора//
Назвать систему команд младшего брата 32-разрядного АРМ -
8-разрядного процессора АВР эффективной// я не могу //По многим причинам//и разным

Продолжаю чиститься// Отвечаю на вопрос
Про отношение частоты ПРЦ и ФЛЭШа/ Соотношение //как я и вы согласились составляет 5 к 1/
Есть только два решения
1 Хранить программу в ОЗУ// которая быстрее
2 переходить на суперскалярность - выбирать из ПЗУ одну длинную команду или несколько коротких
и за счет параллельной работы нескольких вычислительных блоков выполнять все// что выбрано
Это реализовано в некоторых DSP и VLIMS архитектруре//
Как это реализовать в системе команд 8-разрядного ПРЦ? Пока не знаю
PS Есть еще третий "лобовой путь" - выполнять выбранные команды потактно// Однако все наши пути неисповедимы
Куда я попал?

Сообщение отредактировал vitja - Jan 21 2009, 13:57

[Mahagam]

Ваши у/е и мои рубли за АРМ АВР и пр идут в Россию/// //Для меня это новость/ Атмел работает в России
Как диллер/делящий наше бабло/ вы знаете куда они идут///
Про ябед и анонимов см//выше//
Продолжайте чатится// Я не буду
Однако это ответ не GetSmart//извини ради //не туда кнопку нажал

основной язык общения в данной конференции - русский. минимальный набор правил можно посмотреть здесь (раздел "О великом и могучем"): http://caxapa.ru/rules.html
постарайтесь больше не нести подобную тарабарщину. уважайте других.

Так каждый может/// А сделай это за такт//Слабо// тогда хотя бы за два// Только не надо говорить про АВР
При работе с памятью //см/ мой талмуд// он больше тактов тратит//
А про вызов процедур я даже не говорю// от 5 до 10 тактов только на сохранение контекста//
который потом еще и восстанавливать надо/ или я не прав//

Отвечаю тем// кто хочет знать //что делает процессор в течении тактов своей работы//
чищю конюшни//пропуски//в вопросах

хотелось подвести вас к мысли, что MSP430 исполняет команду столько тактов, сколько для этого потребуется обращений к памяти. исключений всего 2 - это любые переходы и команда MOV с записью в память. причина такого расклада - фон-Неймановская архитектура, с единственной шиной. гарвардская архитектура позволяет АВР-ядру одновременно выбирать команду и производить транзакцию с памятью.
данную операцию за два такта могут произвести DSP, поинтересуйтесь на досуге, сколько шин и какой разрядности подходит к ядру BlackFin

Продолжаю чиститься// Отвечаю на вопрос
Про отношение частоты ПРЦ и ФЛЭШа/ Соотношение //как я и вы согласились составляет 5 к 1/

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

[GetSmart]

Продолжаю чиститься// Отвечаю на вопрос
Про отношение частоты ПРЦ и ФЛЭШа/ Соотношение //как я и вы согласились составляет 5 к 1/
Есть только два решения
1 Хранить программу в ОЗУ// которая быстрее
2 переходить на суперскалярность - выбирать из ПЗУ одну длинную команду или несколько коротких
и за счет параллельной работы нескольких вычислительных блоков выполнять все// что выбрано
Это реализовано в некоторых DSP и VLIMS архитектруре//
Как это реализовать в системе команд 8-разрядного ПРЦ? Пока не знаю
PS Есть еще третий "лобовой путь" - выполнять выбранные команды потактно// Однако все наши пути неисповедимы
Куда я попал?

Правильный вопрос: откуда вы явились?!

Интересно, с частотой ядра 500 МГц и частотой флэш 20 МГц какая будет скорость процессора оп/сек ? Если программа занимает 64К, то будете дополнительные 64К ОЗУ выделять для хранения программы? Вы в курсе, что площать на кристалле, занимаемая ОЗУ обычно в 2-4 раза больше флэша равного объёма? Зачем тогда ядро на 500 МГц ? Или выделите 10 КБ ОЗУ на часть программы, а остальная, бОльшая часть программы будет выполняться в 25 раз медленнее?

[zltigo]

основной язык общения в данной конференции - русский.

Moderator:

Поддерживаю.

To:vitja приведите свой "стиль" к человеческому. Считайте это устным замечанием. 

[vitja]

можно АВР допилить до нужной кондиции так : разрешить операндам [Y+d] [Z+d] участвовать не только в операциях Load/Store. 
>>поток сознания иссяк

Чищусь дальше (отвечаю на пропущенное)
1. В АВР нельзя. Они называют себя РИСКом, где по определению "команды обработки данных и комады загрузки/выгрузки регистров
разделены". Остальное - это конвейер и разделение шин доступа к командам и данным. Однако об этом лучше не писать мне, а прочитать.

Да не иссякнет поток сознания. Успехов

Moderator:
Поддерживаю.
To:vitja приведите свой "стиль" к человеческому. Считайте это устным замечанием. 

Сперва початимся.
"Все страннее и страннее" сказала Алиса. Я добавлю от себя - в обсуждении технических вопросов.
1. О русском языке
Транзакция - умное слово, означает обмен данными, включая чтение данных из памяти и запись данных в память ЭВМ
Бабло - деньги. Произошло из блатного жаргона, употребляют неформалы, маргиналы...
На конференции употреблено впервые 20.01.2009 в 22.00
Я это слово, только процитировал без указания автора. Вы еще Ж... пропустили у некоторых.
Поэтому какие замечания... Только к знакам пунктуации.
Да. Иногда приходится писать из под УБУНТУ, где все кнопки перепутаны.
2 Из жизни - Рецензент обязан написать - "есть отдельные стилистические неточности".

3. О человеческом языке - эсперанто я не знаю, поэтому говорю на русском (опять занесло - больше не буду)

Сообщение отредактировал vitja - Jan 21 2009, 18:07