Есль команды subi, sbci, где же addi, adci?

Отнять константу с минусом.
Т.е. если хочешь прибавить 1, то отними -1 ($FF):
subi r16,$FF ;прибавить 1 к r16

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

А какая разница напишешь ли ты так:

или так

Есть кстати adiw - сразу константу к регистровой паре прибавляет. Можно посмотреть (если константа небольшая)

А что значит "условные пропуски какие то странные"?
По моему наличие всех необходимых бит признаков и установка их при любой операции - самый большой прорыв, по сравнению с х51. Именно это дало такой прирост производительности при работе с арифметикой. Там сравнение - это просто пляски с бубном.

А вы знаете 8 разрядный контроллер с более удобной системой команд и архитектурой?


Это дело вкуса, вы можете написать макросы addi и adci
к тому же в тех кусках которые приходится писать на асме у меня почему то чаще используется вычитание константы и проверка флагов так получается удобнее. а обе команды не влезают в пространство 16 бит, и именно вычитание оставили не просто так.

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

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

Условные переходы сделаны в виде "переход если условие выполнено". Однако для портов и регистров предусмотрели команды "пропуск если бит установлен/сброшен". Почему бы это не сделать для битов регистра состояния? Например, получение абсолютного значения можно было бы сделать так:
tst r0
skip if pl
neg r0
; здесь в r0 его абсолютное значение

Ага, но ведь регистр состояния - тоже порт! Однако фиг - команда sbrs SREG, SREG_Z не прокатывает - SREG не попадает в диапазон адресов, допустимых в этой команде.




Да пожалуй что нет...



Кстати, у меня почему-то не работает WinAvr на Висте - пишет "avr-gcc: installation problem, cannot exec `cc1': No such file or directory"

На ХР все нормально, хотя ставил абсолютно одинаковым образом.

А какая разница с переходом???


Даже по тактам тоже самое...

А зачем она нужна если для SREG можно более цивильно использовать
BREQ / BRNE
BRTS / BRTC
BRCS / BRCC
BRHS / BRHC
BRMI / BRPL
BRVS / BRVC
BRBS / BRBC

IMHO skip'ы SBRS /SBRC, SBIC / SBIS - Pic'овый непотреб, хотя иногда (но редко) бывает полезным.

IMHO, в результате исходник загромождается метками, либо надо использовать форму $+n (что потенциально источник проблем, типа когда rjmp не хватит, и заменишь ее на jmp). Если бы были хоть локальные метки - увы, компилятора, который умеет использовать локальные метки как в spasm/cvasm для PIC, для AVR мне не попадалось...

Бывает, факт. И я бы не сказал, что редко... Ладно, хорошо хоть по растактовке обход одной команды типично одинаков. Вот на MSP430 условный переход всегда два цикла - ОЧЕНЬ неудобно...

tavrasm умеет локальные метки, но не обновляется с 2005.

Да да, tavrasm с локальными метками дружит. Если никаких багов не найдено, то зачем ему обновляться? Знаю людей, которые очень долго его юзают и нареканий не имеют. Так что проверенный временем асм.

Теперь плюсы/минусы/особенности оного:

• Поддержка локальных меток (локальная метка должна начинаться со знака подчекивания, например _label )
• Не поддерживается условное ассемблирование, типа IFDEF и т.п.
• Работает с обычными макросами, но не поддерживает условия в макросах
• Не генерит OBJ и MAP, только LST (зато красивее чем у других )
• В некоторых инклудах придется закомментировать OR и т.п. чтоб не было конфликтов с мнемониками
• И еще некоторые нюансы, например вместо adiw ZH:ZL надо писать просто adiw Z

В общем на вкус и цвет...

GNU assembler (в том числе "as.exe" из комплекта WinAVR) поддерживает локальные метки.

А что у него с вышеперечисленными мной пунктами по поводу tavrasm ?

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

Анатолий.

Как это не сделан???
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 ядра для програмирования на С.

Анатолий.

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

Архитектура AVR подталкивает к ведению раздельных стеков для данных и для вызовов п/п, как совершенно правильно поступает IAR. Описанная проблема при этом просто неактуальна, обращение к 8-бит переменной на стеке данных - 1 инструкция.
Разработчики AVR-GCC решили обойтись одним стеком, видимо, чтобы сэкономить усилия по адаптации кодогенератора, как результат - медленные прологи/эпилоги.

Думаю что для С-компилятора идеально подходит архитектура PDP-11. Правда, скорее всего дело обстоит наоборот - так как С разрабатывался на этой архитеркуре, то он получился таким, чтобы максимально ей соответствовать.

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

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

Добавлю, в PDP-11 почти всё было передовым и оригинальным. Проц был 16-разрядным, но работать с байтами было очень комфортно. Двенадцать (!) режимов адресации с почти любым регистром(!), их и сейчас не во всех микроконтроллерах и микропроцессорах можно найти. Было всего 8 РОНов, в число которых входили PC и SP на общих правах. Адреса области ввода-вывода были частью адресов памяти и т.д., всего не перескажешь. Это был шедевр, который интеловские уроды зарыли.

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

1) Ортогональность, при 16 битах не позволяла работать с ОЗУ превышавшем 64К. Требовалось либо вводить регистры страниц, либо переходить на 32 бита.
2) Общее адресное пространство для устр-в ввода вывода, решение удобное для МК, но никак не для компов.
3) Асинхронная шина, на мой взгляд, тоже очень неудачное решение.

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

К =GM= А с ВМ3 работали?

Ну тут видимо Вы не сталкивались с продолжением идеи PDP11 - VAX. Советская цельнотянутая копия - CM1700.

16 ортогональных 32-хбитных регистров, около 20 методов адресации - даже больше, чем в PDP-11, система комманд устроена была весьма хитро - байт кода операции и дополнительные байты режимов адресации, т.е. нефиксированная длинна (как в 80x86, однако, намного более аккуратная и последовательная, а не нагромождение расширений, как у Intel). Хотя, конечно, нефиксированная длинна черевата усложнением разбирателя, но и это можно побороть (борет же тот же Intel). Ну и конечно это CISC в чистом виде - чего стоят расчеты полиномов одной коммандой проца

С другой стороны - IBM360/370 и MC680x0 - 8 регистров данных и 8 адресных регистров. Фиксированные длины комманд (почти). Правда, в более поздних версиях 680x0 (начиная с 030) были более уравнены в правах регистры данных и регистры адреса, но GCC на то время делал отличный код для 68000, не хуже асма.

Ныне из всего этого жив и здоров 680x0 в виде своей реинкарнации - ColdFire.

На ниве RISC-процессоров IBM и Motorola родили в результате PowerPC - на данный момент видимо самые быстрые камни такого класса, давно шагнувшие за ГГц.

Да. Вот ведь прикол. Неоднократно удивлялся.
Хорошая идея и отличная реализация, а в результате - пшик. Недостаточно этого для рынка.

Возьмём тот же х86. Система команд, адресация памяти и прочее - найдерьмовейшее. Многое, очевидно, притянуто за уши. Возьмём саму PC XT. На определённом этапе - серьёзные проблемы с расширением и развитием. Нет вообще никакого подхода к переферии. Даже реализация шины, не была продумана. Возьмём винду, - очевидные ошибки в самом подходе.

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

Только причина этого не в аппаратуре и не в софте.

AVR GAS?

--
WBR, Andrew

Было у нас несколько ДВК-3 с ВМ-3, но особенной разницы на своих задачах я не замечал. Если вы говорите о диспетчере памяти, там было по-моему 256 КБ памяти, то я его не использовал. Позже и недолго была у меня ещё Электроника-85, там по-моему тоже ВМ-3 стоял, я её брату подарил. Надо будет как-нибудь поспрашивать его о судьбе микрокомпьютера.

Если где и были ограничения, то у интела. Расскажу один случай. Вы наверное помните, что тогда у ибм был девиз 3М: 1 мипс, 1МБ и 1Мпиксель. Ну вот, у нас на предприятии были ибмписихт 1 МГц и стояли ваксы, тактовая 10 МГЦ (они превосходили ибм раз в 100 по производительности), и была программа-эмулятор ибмписи на ваксах. Запускалась программа, и вы не могли отличить вакс от ибм, можно было загружать дос, все программы, и т.д. Но скорость была повыше. Кстати, на ибм было много игрушек. Одна из причин, на чём они вылезли.

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

Размещение устройств ввода-вывода в общем адресном пространстве имеет слабое отношение к удобству или неудобству использования МК/компов. А вот к универсализации обмена - имеет, и самое непосредственное. В pdp-11 для любого обмена использовалась ОДНА команда MOV (плюс модификация movb) и всё! А что мы имеем даже в авр? mov, movw, ld, ldd, lds, st, std, sts, in, out. Да ужас! Я уж не говорю про 8086.

Про отрогональность. Убедитесь, что вы правильно понимаете слово ортогональность, надеюсь, не в смысле ортогонализации Грама-Шмидта(:-). Не могу понять, как она может помешать использовать озу выше 64КБ. Тот же ВМ-3 с той же самой системой команд имел диспетчер памяти и легко работал с 256 КБ памяти.

А в чем разница принципиальная? Аргумент класса "трудно запомнить" - не аргумент

Если внимательно посмотреть на написание комманд, никто не мешает исполнить название mov на все случаи жизни, например так


Что поменялось то?

Вот я и про тоже.. Люди вопят "у AVR кривая архитектура"... А проблема то решается элементарно..

Или вон один чувак орал, что ему ужас как не хватает команды adci, что мол почему команда sbci есть а adci нету.
Хотя кто ему мешал написать макрос adci на базе команды sbci? Только собственная глупость

а AVR правильно сделал, что не стал увеличивать количество команд ибо во-первых какое же это тогда RISK-ядро получиться если у него команд как и у CISK? А во-вторых, зачем вводить дополнительные код, к примеру, для команды SBR если она является частным случаем команды ANDI?

Не аргумент, ясно и ёжику пьяному(:-). Хотя, если отвлечься от авр и взглянуть на минуту на систему команд TMS320C5402 в части скажем, загрузки: dld, ld (16 модификаций), ldm, ldr, ldu, ltd, выгрузки: dst, st, sth, stl, stlm, stm или пересылки: mvdd, mvdk, mvdm, mvdp, mvkd, mvmd, mvmm, mvpd, portr, portw, reada, readw, где без поллитра не разберёшься и где программистами допускается огромное количество ошибок, то и аргумент появится.

По делу. Принципиальная разница здесь в системе команд, где на одну команду отведён ОДИН код, и которая неким образом переливается в архитектуру. Принципиальная разница в прозрачности кода, когда вам не надо задумываться КАК совершить обмен, а можно сконцентрироваться на том, ЧТО и КУДА посылать.

Отсюда и была красота и совершенство, которая изумляла и компактность кода. Обратите внимание, как красиво переключались сопрограммы. Когда я разбирал, как pdp-11 работает с плавающей точкой, то чуть не выпал в осадок, настолько красиво. Никакого сравнения с ассемблером ибм370 и 8086, где всё было коряво, всё!

Попробуйте написать swab @20(r1) - обмен байтами по адресу, лежащему по адресу r1+20, на аврке или другом каком мк и почувствуйте разницу.



Положим, это частный случай команды ORI, а не команды ANDI. Да и код команды один и тот же.

Отвлекусь. Дохтур, как же вы писали свою замечательную ртос с такими приблизительными знаниями системы команд, а? Ответьте здесь.

не надо сразу делать такие далекоидущие выводы... добрее надо быть к людям...а аписАться каждый может. ну не SBR там надо было написать, а CBR



Кстати.. О RTOS.....Тут посмотри http://electronix.ru/forum/index.php?showt...pid=377119&

Извините, дохтур, но команда CBR делает побитное И регистра с инвертированной константой, а команда ANDI делает побитное И регистра с НЕинвертированной константой. Здесь уж скорее случай вшитого макроса.

По поводу доброты. Позвольте присказку от моего друга. Если ему что-то активно не нравится у кого-то, он говорит ему: "я тебя уважаю, как человека,... но бить буду, как последнюю скотину". А я к вам, дохтур, добр (пока что).


Любите вы, дохтур, послать туда, не знаю куда, не конкретно то есть. Не на что там смотреть.

И ещё дохтур, оставьте ваше пошлое панибратство, я с вами на брудершафт не пил. Вот в июне организуем очередной съезд имбеддеров в пивном ресторане Ганс, приходите, а там посмотрим.

Вы, видимо, не сталкивались с системой комманд IBM360/370 - там все в порядке, не путайте с I80x86.



А надо ли такое в реальной жизни? Ведь вся идея RISC построенна на уходе от комманд, которые надо выполнять при помощи каких-то микропрограмм.



Комманда CBR требует в битовом представлении именно инвертированной маски - это ANDI в чистом виде, просто назван по другому.

Т.е. хотите сказать что не почерпнуЛИ для себя ничего нового касаемо реализаций RTOS?

P.S. Если будеТЕ отвечать, то я бы попросил Вас тоже без панибратства и уж тем более хамства (хотя даже если и почерпнуЛИ, но никогда не признаеТЕ этого..Да?)

А то что касаемо команды CBR , то это действительно как бы встроенный макрос, но это не суть важно, важно то, что если с помощью препроцессора и аппарата макросов можно сделать из ограниченного набора команд почти любую команду, то тогда зачем скулить (это я не Вам, а другим) о том, что эта команда не реализована в железе? Разве когда пишите программы это важно, что препроцессор или компилятор преобразует вашу команду в другую эквивалентную ей?

2 =GM=

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

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

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

Это не всегда эквивалентные команды! Например при написании и использовании макросов addi и adci надо знать что флаги эти команды будут устанавливать не так как при обычном сложении. "Встроеные макросы" тоже имеют особенности например условные переходы (типа беззнакового больше С и Z сброшены такого перехода нет и инструкция реально противоположая та же что и беззноакове меньше С установелен) при которых надо менять операнды в предыдущей команде cmp или sub, IMHO вообще лучше не использовать.

Ну почему, сталкивался. Для IBM-370, вернее IСL (английский вариант IBMки, стоял в министерстве морфлота) писал немного, в частности, подпрограммы вывода на планшетный графопостроитель и стыковал их с фортрановскими. Один оператор BALR *,14 чего стоит. Переход на ассемблер pdp-11 был как глоток свежего воздуха, поверьте.

Не пойму, почему вы говорите о микропрограммах. Так делалось раньше, сейчас можно сделать по-иному, ну и что? Суть состоит не в том, как это было реализовано, а в том, что режимы адресации, применённые в pdp-11, упрощают программирование, делают его прозрачным. Вот, например, команда JMP @20(R1) может быть легко применена в операторе switch, что на си, что на ассемблере. И так во всём. Жаль, что всё ушло безвозвратно. Не хотите работать с командой swab @20(r1), попробуйте реализовать команду JMP @20(R1) на аврке.

Никто не спорит, что код команды один и тот же. Но константа в одном случае инвертирована, а в другом - нет. Сравните сами.

Код

   cbr   r16,0b00010011
   andi  r16,0b00010011

В первом варианте сбросятся биты 0, 1 и 4, а во втором эти биты останутся. Сделано для удобочитаемости кода и только.


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

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

И, пожалуйста, не пишите P.S., если нет подписи, это моветон. P.S. буквально означает "после подписи", использовалось ещё в Древнем Риме, когда письмо было написано и подписано, и вдруг понадобилось что-то добавить.