Прилагаемый к AVR Studio ассемблер AVRASM2 тоже ругается на OR. Приходится комментировать.

Да это всё такие мелочи, что не стоит даже внимание обращать

Нет смысла рассматривать as.exe отдельно от всего набора. За условное ассемблирование отвечает тот же avr-cpp.exe, как и при условной компиляции си. Соответственно и возможности те же.
Насчет остального - не обращал внимания, т.к. на асме пишу только в крайнем случае.

А вообще это офтоп для этой темы.

Сообщение отредактировал Lepeksiy - Mar 6 2008, 20:21

Абсолютно верно!

Иногда все-таки нет-нет, да появляются люди, которым приходится объяснять с самого начала, от Адама и Евы. Ну что ж, терпите.

Ядро AVR уникальное. Разрабатывалось оно не в одиночку "железячниками", а в тесном контакте с программистами, которые пишут компиляторы. И не просто компиляторы, а Си-компиляторы. Это было сделано преднамеренно. ATMEL (и не только она одна) проанализировала стоимость конечного изделий, и пришла к выводу, что подавляюще большую долю при создании девайса занимает стоимость разработки программного обеспечениия. Итенденция эта год от года только увеличивается.

Если б АТМЕЛ заботилась только о своих проблемах, она бы родила что-то другое. Но АТМЕЛ играет в многоходовые игры, и она озаботилась уменьшением себестоимости изделий своих клиентов в целом. А поскольку наибольшая стоимость в разработке изделий падает на ПО, то было бы не плохо это как-то уменьшить. Как?

Еще один анализ, теперь уже касающийся разработки ПО. Программисты сейчас пишут ПО в основном на Си. Почему? -- Да, опять же исходя из экономических сооображений! Программа написанная на Си будет стоить дешевле, проги написанной на ассемблере. (Я сейчас не хочу вдваться в дискуссию по поводу отвязанных от типа ядра программистов Си-шников, и жестко привязанных к типу ядра программистов-ассеблеристов, и количества их на рынке труда.) Важно понять то, что если удастся сделять ядро такое, что при написании программ на Си будет генерироваться объем кода незначительно худший, чем при написании программ на ассемблере, то это будет весьма востребованное на рынке ядро. АТМЕЛу удалось сделать такое ядро.

Резюме будет следущее.

Господа-товарищи, АВР -- уникальное ядро. Оно "заточено" под Си-шное программирование. А то обстоятельство, что для АВР можно писать на ассемблере, так это факультативно, хотите -- пишите!

Если "полистать" и-нет, то можно заметить, что для АВР программы в основном люди пишут на Си. Как сказал starter48, только критические участки кода пишутся на асме. И такой подход выбран это не ради религиозных войн программистов, а ради снижения себестоимости изделия. Но жизнь -- богатая штука, и порой встречаются люди (кустари, волки-одиночки), которые неповязаны на экономический фактор, не озабочены вопросами прибыли и себестоимости. В основном это люди -- любители или студенты, т.е. люди не связанные с производством. Конечно, им сложно понять специфику АВР-ядра.


// Извините, если это было очень долго и нудно.

Что касается высказывания "условные пропуски оказались какими-то странными", то опять-таки надо смотреть несколько глубже.

Вместо подробного описания здесь, я очень рекомендую прочитать серию статей И.Каршенбойма http://www.compitech.ru/html.cgi/rubrikator/micros.htm

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

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

Читайте, и не смотрите на то, что многое покажется вам не понятным. Со временем вы поймете.

Удачи!

Сообщение отредактировал zhevak - Mar 6 2008, 20:52

Это Вы начитались творений маркетологов фирмы Atmel!!!! AVR ядро - студенческий прект!!!!

Как минимум 3 свойства ядра создающие трудности для генерации эффективного кода С компилятором.

1. Неравноправность регистров, для половины регистров нельзя выполнять дейсвия с константами.

2. Отсутствие атомарной записи в регистр стека. Приходиться отключать прерывания при записи в него (GCC), или использовать два стека (IAR).

3. Некоторые команды работают с фиксироваными регистрами (r0, r1) MUL*, LPM.

И это все мелочи - стандарт языка С предпологает единое адресное пространство - ни один процесор с Гарвадской архитектурой не имеет право называться С ориентированым.

Анатолий.

Сообщение отредактировал aesok - Mar 6 2008, 21:38

Как это не сделан???
BRBC s,k Перейти если флаг в SREG очищен if(SREG(s)==0) PC = PC + k + 1 None 1/2
BRBS s,k Перейти если флаг в SREG установлен if(SREG(s)==1) PC = PC + k + 1 None 1/2




Простите, но это бред. Таких претензий к ЛЮБОМУ процессору включая х86 наберётся в 10 раз больше.
1) Достаточно пары регистров. Для х86 неравноправность регистров просто вопиющая.
2) Есть возможность создавать два стека. И это само по себе уже решает проблему. Насколько я понимаю, проблема не в атомарности, а в обращении к стеку с нужным смещением. Для передачи параметров в п/п. И эта задача легко решена. Более того наличие трёх индексных регистровых пар - это более чем скажем в том же х86, я уже просто не говорю о др. МК.
3) С чем сравниваем? Тоже наблюдаем в x51, PIC, MSP!!! Понятно что умножение и деление - не совсем ядро, а довесок. А как это по другому реализовать? В х86 те же проблемы. Если не сопроцессор, то вообще результат в аккумуляторе, если сопроцессор, то в стеке, а отнюдь не в произвольном регистре.

Так с какой такой архитектурой вы ровняли?

Уважаемый Анатолий,

Это очень хорошо, что Вы очень осведомленный человек. Очень не хочу с вами вступать в бессмысленную полемику. Но поскольку Ваш пост -- это почти персональный вызов, позволю себе отметить только три момента.

1. "Это Вы начитались творений маркетологов фирмы Atmel!!!! AVR ядро - студенческий прект!!!!"
Этот выпад я просто проигнорирую. Но порошу Вас указать конкретные источники, которые бы мне следовало "почитать", дабы не вступать с Вами в столь яростное противоречие. Я -- парень неленивый, и даже где-то упорный. Пожалуйста, перечислите здесь, что Вы читали. Я думаю, что приведенный Вами список будет полезен всем, а не только мне.

2. Где было сказано, что АВР -- идельное ядро? Такого я не говорил. Другими словами, ядро АВР --нормальное рабочее ядро. Но как и в любой вещи в нем тоже есть недостатки. Некоторые из них Вы перечислили. Конечно, не все удалось сделать "на отлично" АТМЕЛ-овским разработчикам. Если б ядро было идеальное, т.е. не содержало недостатков, то наверное бы другие 8-разрядные ядра занимали бы еще меньшую долю на рынке.

3. "ни один процесор с Гарвадской архитектурой не имеет право называться С ориентированым."
Ну это уже придирки! Вы же не можете утверждать, что ПО "для Фон-Неймана" пишется на чистом Си, а ПО "для Гарварда" -- на чем-то другом, но точно -- не на Си. Синтаксисы языка и для той, и для другой архитектур сильно совпадают, поэтому, какая разница -- чистый-ли это Си, или это Си, расширенный для работы с "Гарвардом". Суть от этого не меняется. Си он и в Африке Си, разве что только черный!

http://www.avrtv.com/2007/09/09/avrtv-special-005/
http://savannah.nongnu.org/project/memberl...?group=avr-libc

Савнивать их не корректно, x86 это CISC просессор, AVR- это RISC.



Место под локальные переменные выделяеться в стеке. Общая пратика С компиляторов использовать один общий стек и для хранения адресов возврата и для хранения локальных переменных. Для выделеления памяти под локальные переменые необходимо изменить значение регистра указателя стека, и эта опрерация (по крайней мере операция записи в SP) должна быть атамарной. Нельзя допускать вызова обработчика прерывания между операциями записи в регистры SPL и SPH. В GCC для изменения SP приходиться применяеть такой код:



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



В идеальной RISK все регистры равноправны, и уж темболее нет никакого акумулятора. Акумулятор - это преригатива CISC архитектур.

У меня нет ни каких комплексов когото с кемто сравнивать, я пишу о тех проблемах которые вставали перед разработчиками avr порта в GCC. И для которых рекламные флаеры фирмы Atmel просто бумажки... Я излазил его вдоль и поперек (не весь GCC , всего лиш) avr backend.

Анатолий.

Воздержусь от комментариев. Пусть другие участники форума оценят полезность "списка".

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

Я читал статьи на заре возникновения RISC архитектуры. Можно поискать, но думаю вы заблуждаетесь. Изначально основные особенности данной архитектуры определялись следующими особенностями.
1) Выполнение команд за 1 такт.
2) Высокая тактовая частота.
3) Большое количество регистров.
4) Аккумулятор w для операций в обе стороны.
5) Малое количество команд (обосновывалось тем, что 20 процентов команд используются при написании 80 процентов кода)

Основные - п.1 и 2. Типичным представителем является PIC.

Но собственно, я не собираюсь обсуждать теоретику.
Ответьте просто. Какой МК, по-вашему идеально подходит для Си компилятора?

Высказывания разработчиков кристаллов не в счёт. 99% кристаллов общего назначения, по словам разработчиков, заточены под Си. Встречал ещё Ява ориентированные и Форт ориентированные. Но это единицы.

Дал поиском сейчас запрос. Получил след ссылки
http://www.intuit.ru/department/hardware/csorg/10/
http://www.computer-museum.ru/technlgy/risc.htm
http://www.terralab.ru/system/235190/

В третьем, к примеру, можно прочитать такую фразу:

Ну и так далее.

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

Я не применяю эпитеты хороший или полохой применительно к контролерам, это не инженерные понятия, оставим их для фанатов.

Да Вы правы, эта дискусия выходит за рамки этого форума. Здесь обсуждают применение AVR-ок а не проблемы написания для него компиляторов.

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

Анатолий.

PS: Ещё одно дополнение.
Вот выдержка из последнего источника:

В то же время выдержка из Главы "Набор команд ARM7" раздела "Команды обработки данных" (стр.25) книги Т.Мартина "Микроконтроллеры ARM7.Семейство LPC2000 компании Philips.".


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

Все архитектуры я не изучал.

Когда я смотрел набор инструкций AVR32 (после AVR) у меня было ощущение что он просто идеально ложиться в кодогенератор GCC. Но я не смотрел AVR32 backend и не знаю настолько ли все хороно на самом деле и нет ли каких то подводных камней.



Разработчика не волнует сложноть компилятора, его волнует эффективноть кода. Но когда запизь в регистр стека требует не 2 инструкции а 5, а эта операция выполняеться дважды для любой функции которая имеет локальные переменые - пользователь вправе сказать - код не эффективный. И это особенность архитектуры "заточеной" под Си-шное программирование.

Но опять же это есть только несколько проблем при всех пложительных свойствах AVR ядра для програмирования на С.

Анатолий.

Сообщение отредактировал aesok - Mar 7 2008, 01:11

А кто тебе мешает написать макросы adi и adci ?
Я так и делаю, когда мне "не хватает" некоторых команд