[vitja 0]

Передо мной поставлена задача (сам напросился) - дать предложения по архитектуре

системы команд 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 и помогите "бедному" разработчику, кто чем может по делу,

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

Изменено 16 января, 2009 пользователем vitja

[mikesm 0]

Позитивная критика. Во первых верный адрес файла http://moko.ru/mc/RatingMC.pdf

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

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

а совершенно другие факторы: питание, тактовая частота, объем оперативной памяти, и число тактов на одну команду.

И уже существующие процессоры практически выбрали все варианты.

Т.е. типовой микроконтроллер работает при 3V на 8МГц. Мы берем сравнимые по цене процессоры.

И если он на 3.3V работает на 8МГц, выполняет пересылку регистр регистр за один такт, что еще от

него нужно?

Прирост производительности на 23% по сравнению с аналогами не сыграет никакой роли, потому что

идет массовый переход на C, а значит производительность программы будет зависеть от возможностей

компилятора. Который попросту завалит все преимущества.

Еще один ключевой момент, это наличие периферии, простота ее использования и эффективность

работы этой самой периферии. И тут мы уезжаем от теории регистр регистр к практической реализации

на уровне физики микросхемы. А вот эта тема практически Вами не раскрыта.

Если уж оптимизировать то по всем направлениям, система команд и организация памяти, как у Вас сделано,

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

Вот если все три направления задействовать, то возможно получится нечто хорошее, но тут вылезает

стоимость дизайна. Судя по тому, что в тексте процессор с 4КБ RAM и 16КБ Flash, этот вопрос Вы тоже

не рассматривали. Ведь в реальной продаже производители микроконтроллеров очень скупо дают

эту память. И при 16КБ Flash максимум на что можно рассчитывать это 256 или в крайнем случае 512

байт RAM. Значит она дорога в изготовлении. Еще есть вопрос энергопотребления в работе,

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

[vitja 0]

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

 

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

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

 

Нельзя объять необъятное

Давайте сперва Разберемся с системой команд /остальное имея в виду

Потом с этой горы ююю все стадо

Изменено 16 января, 2009 пользователем vitja

[vitja 0]

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

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

а совершенно другие факторы: питание, тактовая частота, объем оперативной памяти, и число тактов на одну команду.

 

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

компилятора. Который попросту завалит все преимущества.

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

 

По существу Вами поднято три вопроса:

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

2. Влияние системы команд на аппаратные характеристики МК

3. Взаимосвязь компилятора и системы команд МК.

 

1. Критериев хорошести МК много.

Для схемотехника это конструктивное исполнение, напряжение питания, потребление, встроенные в МК интерфейсы

и специальные аппаратные блоки.

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

Для руководителя важно, что бы все было сделано быстро, дешево и сердито (конкурентноспособно).

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

 

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

На сколько влияет - я попытался показать в своем анализе - в некоторых случаях многократно.

 

3. Несовершенство транслятора действительно существенно влияет на объем программного кода.

Однако это происходит не только из-за того, что их так пишут.

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

Это привело даже к тому, что появилось (в начале 80-х годов) новое направление - RISC ЭВМ, которые построены под трансляторы, а не наоборот.

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

[vetal 0]

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

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

 

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

Относительная площадь RISC процессоров сокращена по сравнению с CISC процес-

сором 8051 на 40%, доля 32-разрядного процессора ARM увеличена в 4 раза.

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

[Гость @Ark]

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

Наверное, стоит сразу разделить два понятия: эффективность процессора (микропроцессорного ядра МК) и эффективность МК в целом.

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

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

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

Несовершенство транслятора действительно существенно влияет на объем программного кода.

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

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

[vitja 0]

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

Наверное, стоит сразу разделить два понятия: эффективность процессора (микропроцессорного ядра МК) и эффективность МК в целом.

То, что у Вас описано в файле больше похоже на оценку эффективности процессора. .......

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

 

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

1 Благодарен за прочтение и правильные выводы:

а) я действительно анализирую эффективность только процессора МК, причем только его системы команд;

б) задачей этого анализа является оценка влияния особенностей системы команд на объем программного кода и тактов на его выполнения.

Для оценки были взяты статистические данные употребления операторов ЯВУ для нечисловых задач, как наиболее характерных для областей применения МК, где объем вычислений относительно невысок.

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

Для всех!!!

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

 

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

Поэтому в начале ты был прав, но концовка ....

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

то оно одно - команды доступа к данным должны быть отделены от команд обработки данных.

Этому требованию в полной мере удовлетворяют регистровая система команд и стековая (если стек аппаратный).

[Гость @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 0]

" 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? Здесь я что-то невразумительное написал. Потом переформулирую. Пример оставлю. По п.п. а и б надо бы определиться.

Изменено 17 января, 2009 пользователем vitja

[mikesm 0]

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

Профессор Паттерсон, а точнее 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 0]

По п.А. конкретно

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

Я ее вижу только в том, что память МК расположена всегдддда внутри кристалла, какая - от 32 байт, как в Tyni или до 64 Кб и более

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

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

которые будут выбираться из Flash. И тут все зависит от аппаратной реализации процессора и его Flash на борту.

Если рассматривать стандартное исполнение, то Flash у процессора имеет побайтовый доступ, и если она больше 64К, потребуется больше

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

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

[Гость @Ark]

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

Будем зрить в корень.

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

Впрочем, можете не соглашаться - Ваше дело...

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

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

 

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

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

[vitja 0]

1. по моему мнению, RISC-архитектура получила развитите из-за эффективности, а не потому, что стало проще писать компиляторы.

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

2/ Не совсем это так, точнее не всегда.

Кстати, в Вашем анализе почему-то совсем ничего нет на эту тему...

 

1 Поскольку мы о RISC-философии больше писать (говорить) не будем,

позволю себе, в последний раз нарушить это соглашение и привести полное название первоисточника "RISK:Эффективные архитектуры

СБИС-компьютеров", остальное в его тексте, в т.ч. о целях разработки (см.вышее, и еще вышее)

Надо знать и уважать авторов.

 

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

 

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

цикло-чего то (забыл как называется) - это разделение времени.

Какое отношение организация ВП СРВ имеет к системе команд, где надо:

а) отреагировать на прерывание;

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

Это реализуется командами PUSH,POP и RETI. Возможны другие варианты не изменяющие смысла.

Еще 3 команды в копилку системы команд процессора МК.

 

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

 

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

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

двух байт только на адрес

Слава богу. Наконец то мы стали говорить по теме.

Да - память ПЗУ, ОЗУ внутри кристалла МК, да - это 8-разрядный МК и адресация 64к требует 16 бит адреса как ПЗУ, так и ОЗУ,

а более 64 к - более 16 бит.

Ее можно адресовать странично или относительно базового адреса. Это не требует задания в команде всех битов адреса, можно ограничится 3,4 или другим числом биттттттттттттттофффффффф.

 

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

Изменено 17 января, 2009 пользователем vitja