[Палыч 10]

Да ну?

Ну - да, с ограничениями, правда (пример - МК от AD).

Кстати, вот интересно: MSP430 позиционируются как "architecture optimized for C language"?

[Rst7 5]

MSP430 позиционируются как "architecture optimized for C language"?

 

Они обычно позиционируются как новая инкарнация архитектуры PDP-11, а исторически сложилось так, что язык Си хорошо утилизировал особенности именно этой архитектуры :)

[Палыч 10]

язык Си хорошо утилизировал особенности именно этой архитектуры

И я - об этом! Однако, ни DEC в своё время, ни TI сейчас - не говорят о своих изделиях "architecture optimized for C language".

[Rst7 5]

Однако, ни DEC в своё время, ни TI сейчас - не говорят о своих изделиях "architecture optimized for C language".

 

А им не надо. У них сея фича по умолчанию и в другую сторону причинно-следственные связи :)

[SapegoAL 0]

И я - об этом! Однако, ни DEC в своё время, ни TI сейчас - не говорят о своих изделиях "architecture optimized for C language".

Практически каждый камень, вновь выходящий пропогандирует себя как "architecture optimized for C language".

Потому, что сейчас это просто необходимо. Иначе камень не продашь.

 

И с этой точки зрения - вы правы. Это маркетинговый ход на 95%. А вся правда, состоит в том, что производителям приходится создавать систему комманд с учётом данной потребности.

 

При разработке архитектуры x51 такой необходимости у разработчиков небыло. Почему?

1) Сам язык Си не был столь популярен и уж точно не являлся стандартом программирования для Embedded платформ. Не даром Intel развивало PL/M. В том числе был компилятор и для x51. Отметьте, что Intel - разработчик архитектуры x51.

2) Компиляторы Си не были столь мощным средством. Качество компилятора и оптимизатора оставляло желать лучшего. Что было приемлемо для PC, но убийственно для MK. Программные средства тоже развиваются.

3) Мощность аппаратных платформ для PC были недостаточны. Компиляция Си проекта была длительным процессом, что усложняло отладку.

4) Появление кристаллов x51 с значительным количеством памяти на кристалле произошло значительно позднее. Ещё позже появились кристаллы, позволявшие размещать стек во внешней памяти. Без этих двух условий назвать x51 "architecture optimized for C language", будет уж очень притянуто за уши. Ну а когда такие приблуды появились, семейство x51 уже не нуждалось в дополнительной рекламе. А компиляторов под неё уже было достаточно.

 

Сказать по совести, особых претензий к AVR по части Си - я не вижу (учитывая что это RISC архитектура). Доступ к стеку, прекрассно реализуется посредством 2-ого стека, что замечательно использует IAR. В рекламе Atmel писали, что систему комманд продумывали совместно. Про Tiny они честно пишут, что "не расчитана". И указано ограничение - только в кристаллах с полным стеком.

 

Претензии можно предъявить, по поводу реализации ОС - это да. Отсутствие программных прерываний - серьёзный прокол. Тоже очевидно недодумали. Сами писали - не ожидали такого спроса. Хотели удешевить. Отсюда и непродуманная политика расширения семейства.

[manul78 4]

Претензии можно предъявить, по поводу реализации ОС - это да. Отсутствие программных прерываний - серьёзный прокол. Тоже очевидно недодумали. Сами писали - не ожидали такого спроса. Хотели удешевить. Отсюда и непродуманная политика расширения семейства.

 

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

достаточно "ножкой дрыгнуть", а вот с другими ?

 

P.S. Еще заметил, что когда начинается обсуждение МК, то "по умолчанию" 90% подразумевают AVR... значит, что Atmel

занимает львиную долю МК. это радует. Нравится Гарвардская архитектура и пр. атмеловские примочки :)

 

 

Еще немножко подумал... можно ! Правда это будут "танцы с бубнами", но все равно реализуемо... :)

Изменено 15 октября, 2009 пользователем manul78

[Leka 0]

"The AVR Microcontroller and C Compiler Co-Design" - непредвзятый вывод д/б такой: АВР изначально не был "спроектирован под Си", а слегка модифицирован(fine tuning) под более эффективную работу с многобайтными данными(16- и 32-разрядными). Например, с 4х-разрядным смещением(первоначальный вариант) можно адресовать только 4 32-разрядных слова, что явно мало - нарастили до 6 (адресация до 16 32-разрядных слов). Называть это "оптимизацией под Си" - :cranky: .

[SapegoAL 0]

непредвзятый вывод д/б такой

Непредвзятый вывод такой - что это 8-ми битный микропроцессор. Который разрабатывался и является 8-ми битным. Программирование на Си не предпологает обязательных 32-ух битных операций. Равно как и операций с плавающей точкой. Язык Си ведь поддерживает работу с float, так что же вы претензии не предъявляете?

 

Использование языка Си не меняет задач, которые решаются на МК. Задача должна выбираться исходя из возможностей процессора, а не возможностей языка.

 

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

 

Плюс - повторюсь. На заре появления - когда появились первые приборы - они были на перечёт. 1200, 4414, 8515, 8535, 103.

 

4414 работала до 8 МГц. Я написал в поддержку фирмы - "Когда ожидать кристалл с большей тактовой?". 1200 работала от 12. Они мне прислали ответ - "Повышение тактовой частоты не планируется. Компания сосредоточится на расширении модельного ряда." Пошли 2313, 2323 и т.п. малые кристаллы. Большие вообще не выпускались. Они и 4414 выпустили только на замену 8051. Она же по ногам совместима. а 1200/2313 - на замену 89с2051. И Пик там был какой-то в таком же корпусе.

 

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

[Сергей Борщ 133]

А что насчет ARM? Как бы не самая классическая архитектура и система команд - а славится тем, что очень нужно постараться чтобы написАть лучше на asm. Всегда интересовал вопрос - "почему".

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

[Гость @Ark]

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

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

[Палыч 10]

Отсутствие программных прерываний - серьёзный прокол. Тоже очевидно недодумали. Сами писали - не ожидали такого спроса. Хотели удешевить. Отсюда и непродуманная политика расширения семейства.

Да, с политикой расширения семейства у Atmel'а - бо-о-ольшой прокол.

Итак, что же такое "architecture optimized for C language"?

 

1. "Большая" внутренняя память с возможностью размещения в ней стека без ограничений.

2. Система команд, позволяющая эффективно обращаться к данным в стеке.

 

Что ещё?

[dxp 56]

Что ещё?

Адресная арифметика. Команды типа ADIW/SBIW на AVR.

[Палыч 10]

Адресная арифметика.

Не понял - о чем речь? Наличие команд с косвенной адресацией и постинкрементом/преддекрементом? Типа таких:

LD r26, X+

LD r26, -X

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

Команды типа ADIW/SBIW на AVR.

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

В целом набор команд AVR кажется мне каким-то нелогичным.

Например: есть команда CBI A, b (A может принимать значения из диапазона 0...31). Казалось бы - размести во всех МК регистр SREG по единому адресу из этого диапазона, например, ноль, и тогда не пришлось бы вводить восемь команд сброса флагов (CLI, CLH, CLC и т.д.). Ан нет - в эту область адресов (0...31) пространства ввода-вывода напихали регистры для которых команду CBI просто глупо применять (UBRR, UDR, SPDR и т.д.). Аналогично и для установки разрядов регистров ввода-вывода (команда SBI).

Возможно, что эту нелогичность и решили свалить на "оптимизацию"...

[Leka 0]

...не пришлось бы вводить восемь команд сброса флагов (CLI, CLH, CLC и т.д.)

Это псевдокоманды, полученные из BCLR/BSET.

[LordVader 0]

Готов присоединиться к сказанному выше про АВР.

 

Кстати, как можно понять для себя, насколько архитектура под Ц оптимизированная.

 

Возьмите кусок типичной программы на Ц и откомпилируйте с выводом асмового сорца. И посмотрите. Глазами.

Станет понятно, что, например, мсп430 - вполне себе оптимизированная, а вот АВР - как бы и вообще не оптимизированная. На АРМ не довелось ещё смотреть, ничего не могу сказать.