[zltigo 1]

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

 

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

 

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

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

[lepert 0]

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

если пройти все его три тома, наступит 3й дан просветления.

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

[vitja 0]

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), где приведены доли типовых машинных операций

на реализацию операторов ЯВУ.

 

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

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

[vitja 0]

...Вам остается молчать и это правильно!

...библиографический перл типа "Начала программирования" издания 1981 Ч

...то делать с Доцентом, даже не знаю :(

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

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

 

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

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

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

- Хорошие книги по программированию изданы в основном до 80-го года и сейчас только переиздаются (Кнут, Брукс младший и т.д. список большой, см. в библиотеке) .

2. Надо читать не только ДатаШиты и книги инструкции, которыми завалены полки книжных секций с литературой ?по так называемому программированию?

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

Умные ребята от Гейтса превратили программистов в общество потребителей ? нажал нужную кнопку ? получил результат.

Мы ремесленники. Этим надо гордиться?

PS/ А книга называется "Начала науки о программах" Будьте внимательнее/ пожалуйста/

[zltigo 1]

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

 

 

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

 

 

[vitja 0]

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

 

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

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

Бенчмарки, помимо того, что привносят в оценки совершенства системы команд, несовершенства используемого транслятора (и по Вашей ссылке это видно),

они

а) не дают ответа почему, такие цифры получились, поэтому

б) не пригодны для использования на этапе проектирования системы команд, когда системы команд еще нет, ее надо создать, принимая ответственные решения по выбору адресности команды, ее длине, выбору способа обработки – регистры, память или стек….и пр/

Мои предложения - это поиск ориентира для решения этих вопросов. Насколько верны эти ориентиры судить Вам.

Поэтому я предложил эту тему для обсуждения.

[vetal 0]

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

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

[MrYuran 21]

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

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

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

 

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

 

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

 

Вообще обычно при разработке нового типа МК производители берут готовое ядро (проверенное, широко известное и имеющее кучу инструментальных средств, т.к. компиляторы, симуляторы, etc)

А различия архитектуры наблюдаются на уровне функциональных блоков МК.

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

 

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

[zltigo 1]

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

 

 

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

 

 

[vitja 0]

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

- организация выполнения команд - нельзя выполнить команду за такт,

и возможно даже за два (причина указана выше).

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

[vitja 0]

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

Я читал/ признаюсь/ ДатаШит М430 по диагонали/ однако систему команд 1806 ВМ2 знаю и уважаю /опять признался/

Однако ничего личного/

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

Остальные же в/т/ч/ способы адресации только добавляют такты в выполнение команды/

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

Зачем/

а) В МК вся память внутри/

б) максимальная частота выполнения программы ограничена временем доступа к ПЗУ/

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

[GetSmart 0]

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?

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

[vitja 0]

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

Что такое архитектура процессора МК//

как не система команд /см/книгу "Организация ЭВМ" издание 5-е 2004 год Питер/

Однако если на нее посмотреть с другой стороны/ то она может выглядеть как 18-ноговый DIP корпус

первые пентиумы потом я носил как значок/ прикольно было

[vetal 0]

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

В первую очередь система команд это интерфейс ядра процессора с внешним миром. Взяли микроядро AVR без декодера и творите какую угодно систему команд.

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