Знаю, часть мнемоник инструкций АВР сделаны из комерческих или иных соображений, и приводят к одному и тому же микрокоду. Нельзя узнать : сколько и какие?

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

Скачайте документ AVR Instruction Set Reference , и поиском по ключевому тегу "(see" найдите все такие инструкции. Я насчитал всего 5.

CLR
CBR
LSL
ROL
TST

+ две неудобочитаемых команды работы с флагами
SBI A, b ; установить бит b в адресном пространстве ввода/вывода
CBI A, b ; сбросить бит b в адресном пространстве ввода/вывода
дублируются парами команд
SEC CLS
SEN CLN
SEZ CLZ
SEI CLI
SES CLS
SEV CLV
SET CLT
SEH CLH
Если вы пишите на асме, то намного удобнее использовать команду запрета прерываний CLI, чем корячиться вспоминая адрес (= 0x3F) и бит (= 7) для команды
CBI <вспомни_адрес>, <вспомни_бит>.

ИМХО, их намного больше чем 5, например:
brhc 1111 01kk kkkk k101
brhs 1111 00kk kkkk k101
brid 1111 01kk kkkk k111
brie 1111 00kk kkkk k111
идт...

те... 1111 xxkk kkkk kyyy
где:
xx=01 - if cleared
xx=00 - if set

yyy - номер бита в SREG

kkkkkkk - смещение

то есть, для всех этих команд, можно было бы писать что-нить типа
brc(s) yyy, kkkkkkk
yyy= C, I, H,.....

но по маркетинговым соображениям Атмел решил что команд дб много...

Не просвятите ли, чем может помочь в работе подобное знание?
Единственное, что приходит в голову, это при разборе листинга знать, что существуют подобные синонимы и адекватно к этому относиться.

Да ну? Вообще-то CBI и SBI работают только в диапазоне 0...31 и не достают до регистра статуса. Так что это отдельные команды для манипуляции конкретно регистром SREG.

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

Неа, там все однозначно
И я очень бы удивился если бы это было не так...

Ах, да, действительно! Фигню полную сморозил. Стыдно, блин...
Спасибо за поравку.

А почему тут два разных номера (3 и 4), хотя флаг называется V и там, и там?

В самом деле ?

Тогда, наверное, _внимательное_ прочтение "AVR Instruction Set" вызовет еще большее удивление...

потому что чисто на автомате ошибся при выборе нужных инструкций...
смотрим инструкции brbc и brbs:




Чукча не читатель - чукча писатель, хотите поспорить насчет владения
AVR Instruction Set ? предлагайте задачу... тока не очень объемную please...

Команд и должно быть много. Это удобнее.

Я не чуть бы не обиделся на Intel, в своё время, если бы вместо знаменитого "XRA A" применял бы всем понятное "CLR A".

И вообще не понимаю причины данного спора. Если вам не нравится мнемоника, то всегда можно программировать в кодах. Мне без разницы сколько реальных команд. Главное чтобы было понятно и удобно их применять.

Кроме того, маркетинг - вещь нужная. Я тоже пытаюсь использовать такие вещи. И мне как-то в голову не лезет, обвинять в этом кого-то ещё.

Самокритично...

Нет, предлагаю лишь _внимательно_ прочитать :
-----
If Rd ≥ Rr (N ⊕ V = 0) then PC ← PC + k + 1, else PC ← PC + 1
-----
Это не слишком объемная задача ?

это для команд brbc brbs ?
если нет, то и темы для обсуждения нет,
я имел в виду только их...

Вот это уже лучше. Потому как первоначально было:

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

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

суть моих высказываний от этого не изменилась...

У Intel'a JZ == JE, и что? ;>
Команды переходов это IMHO особый случай, не думаю, что их стоит приплетать. Это просто правило хорошего тона иметь большой набор мнемоник для удобства пользования.

Когда удобнее сделать переход по результату мат. опреации - берем команды мат. переходов brsh, brlo ...
Когда удобнее флаговый синоним - пользуем флаговый синоним brcc, brcs ....

А мне это нравится.

Возьмём к примеру BRCS и BRLO. Понятно, что это одно и тоже.
Но мне удобнее не парить себе голову и при сдвиге и обработке бита использовать BRCS (легко вспомнить C SET), а при сравнениях BRLO(легко вспомнить LOW).

ЗЫ: Обогнали.

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

Почему к одному и тому же микрокоду-то?
Результату!!!

вот ещё пара:
SER R16 = LDI R16, 0xFF
SBR R16, 0xNN = ORI R16, 0xNN


Возможно имелось ввиду, что для этих инструкций есть синоним BSET s, а не SBI/CBI.

Если только Вам не лень. Напишите "программу", включающую все команды. Их возьмите из даташита на контроллер. Посмотрите в окно дизассемблера. И поймёте.

А чем CBR коммерчески более выгоден, чем ANDI?

Относительно проверки 2-х бит. Написано "If Rd < Rr (N [+] V = 1) then PC <- PC + k + 1, else PC <- PC + 1" Но ещё написано • Bit S: Sign Bit, S = N ⊕ V. Так что переход всё-таки по одному биту, который, правда, (из коммерческих соображений?) есть xor двух других бит того же регистра.

Помните, тут раньше встречался такой дотошный человек (забанили его), который исследовал код операции AVR на предмет оптимального распределения битов по полям(!), чтобы, значить, если сбойнёт бит в коде, так не было бы фатальных последствий.

Ни чем!
Простое здоровое не здоровое любопытство. (нужное зачеркнуть)
Надеюсь , льзя?
Просто подумал, у ближайших конкурентов Атмела где-то около 30 команд, а у него в 4 раза больше!
Сразу ощущаешь гордость. Но понятно, что есть где-то ПЗУ микрокоманд и оно при большем числе , должно занимать большее место.

У MSP430 27 "настоящих" и 24 эмулируемых.

А смысл?
А гордость-то за что?
Ладно бы команды какие особенные были - как например у Z80 были автоматические блоковые и цикловые команды - вот это я понимаю.

А я нет !
Это "вредные" команды, они по 250 тактов делались, или типа того.

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

Точно, склероз - 21 такт (загрузки или сравнение) на итерацию !

Даже если откинуть бредовые ser и т.п., и зачеркнуть дублированные - всё равно команд больше. И как не ехиднечай все они используются компилятором. movw, adiw, sbiw, ldd и т.д и т.п., что, в целом, делает прогу эффективнее.

Что-то насчёт ПЗУ микрокоманд, вы похоже загнули. Это не пентиум.
1 такт на команду. То есть обычный дешифратор команд, скорее всего.

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

а REP MOVSB в Intel-ах не забыли? за одну команду ассемблера скопировать 64К памяти можно и больше

Не придираюсь. Не заглядывал.
Но микрокоманды предполагают разбиение истинной команды на микрокоманды и выполнение её за несколько внутренних тактов. Так что тут принципиальная неточность. Обычно так реализуется CISC ядро на базе RISC.

Верю.
А по поводу внутренних тактов: "их есть у них"
См. ДС на 1200 стр. 9 рис. 12

Ну и "их нет у них". Чётко видно что все операции выполняются по переднему и заднему фронтам CLK.
Оно и понятно. МК от кнопки работает. то есть на любой частоте. Процы с умножителями - так не умеют.

К тому же видно что сама операция с ALU - одномоментная. Это видно и по системе команд. 2-ух и более тактные - только команды со сложной выборкой.

Забавно, кстати. На заглавной страничке пишут "fully static operation", а дальше "не меняйте внешнюю частоту больше, чем на 2% за раз, а то всё заглючит". А в каком-то чипе так и вообще, после смены коэф. делителя рекомендуют 8 нопов, чтоб, стало быть, не сглючило... Наводит на мысли по отсутствию-наличию умножителя.

st Y/Z - аналогично.
Скока ужЕ насчитали?

Придурки вот сидят в этом Atmel!!! Придумывают инструкции ненужные никому.
Надо было оставить вместо ld Rx,Y -- ldd Rx,Y+0 !!!

Красиво, понятно, логично, лаконичнее, удобно!!!
Особенно для тех кто пишет ассемблеры/ дизасемблеры. Им работы меньше на 0.5%. Их же больше чем тех, которые пишут на ASM.

Тогда ld/st X стали бы каким-то исключением. Все правильно сделали.

Точно. Вот какой смысл в инструкции adiw r30,0 ?
Если серьезно, то это следствие неидеальной ортогональности системы команд. Патамушо уже все укра приду микрочип, короче, красивее по системе команд. В смысле 8-битники

В проверке флагов ...
для 2 байтового слова между прочим...

Ну ето Вы загнули. Там внутри ядра все по rising edge выполгяется.

"Если кто-то кое-где у нас порой..."

Ссылку на даташит привести не затруднит?

Это исключено. Да и по диаграме видно. Видно и по работе с портами. Короче обсуждалось уже.

По работе с портами видно исключительно фронт тактового сигнала.



Ссылку на обсуждение не найдете?



Если Вы про диаграмму Single Cycle ALU Operation, то та диаграмма значит вот что - по фронту фиксируется дешифрированная команда, а дальше, до результата, готового на write-back все на банальных задержках между элементами. Это же все банальная комбинационная логика, синхросигналов не требует. А по следующему фронту, при необходимости, делается write-back в нужный регистр. При этом, если значение этого регистра нужно в следующем цикле, то оно так-же появится на выходе регистрового файла через некоторое время. Просто картинка нарисованна при максимальной тактовой частоте. Если бы ее нарисовать при малой частоте, то она выглядела бы как фронт синхросигнала, быстренько Register Operands Fetch, ALU Operation Execute, и потом длинный-длинный Result Write Back аж до следующего фронта. Где-то посередине Result Write Back будет и спад тактового сигнала.

Пересмотрел документ "Embedded RISC Microcontroller Core AVR".
Готов согласится с вами. В общем то я просто отрицал умножение.

Тем не менее использование обоих фронтов синхросигнала - весьма распротраннённая практика. В том числе и для CPU. Я не вижу принципиальных затруднений для использования такой синхронизации. Это отнюдь не мешает процу быть статическим. Можно проверить отсутствие этого путём тактирования проца предельной частотой с большой скважностью сигнала.

О сколько нам открытий чудных....



Простите где ? С тех пор как перестали использовать latch работа по двум фронтам не в почете.
Вникните в разницу межде ARM7TDMI и ARM7TDMI-S например. В нормальной RTL team за работу по двум фронтам (вне специально оговоренных мест которые обычно расположены поближе к ногам чипа) дают по шее(так же кстати как и за latch). Загляните кстати в RMM.



Ответственно заявляю и в AVR и в ARM (который -S) и в MIPS например 4K(лень рыть доки и искать были ли MIPS на latch но по моему не было) используется только rising edge.

Например в ОЗУ.

Простите, я не могу с вами спорить. Это спор глухого с немым. Не вы ни я не знаем используется или нет. Просто банально не знаем. Мне, к тому же, никто по шее не даёт.
Знакомых разработчиков процов у меня нет, по этому никто не жаловался.

Может у вас знакомый разработчик AVR ядра? Или вы в доке приведёте мне место, где чётко указано, что нет не единой операции тактируемой задним фронтом?

Пока это чистый выпендрёж. То есть я не утверждаю что он используется. Я за этим просто не слежу (и это по крайней мере честно), но утверждать что либо не берусь, именно по причине отсутствия знаний. В каком-то процессоре я чётко видел инвертирование CLK и использование 2 фаз.

Ещё раз - я, в предыдущем посте, согласился. Но поясните мне, пожалуйста, что случится если я применю два фронта сигнала?
По возможности доступно.

Вы удивитесь но ето так. И самопальные AVR у меня в столе лежат уже года 4. В их ядре falling edge не используктся и количество тактов на иструкцию полностью совпадает с оригиналом. Но вас же это все равно не убедит

Впрочем-
Any register in the core will update its contents only on the positive edge of cp2.

Ну почему же.
Перечитайте внимательно мой пост 44. Обратите внимание на наименование документа, на который я ссылаюсь.

Мне просто не нравится вот это ... . Почему? Да потому, что вы никто чтобы что-то ответственно заявлять. Я тоже. Но я и не заявляю. Я могу предполагать и ошибаться. И вы тоже, хотя пока, по видимому, ещё об этом не знаете.

PS: Возьмите даташит на 1200. Выберите раздел "Parallel programming". Рис. 33. Рассмотрите её. Обратите внимание на сигнал tXLWL. С такой вот расшифровкой: XTAL1 Low to WR Low. Вот кто его знает? Может всётаки где-то данный сигнал и применяется? Согласно документа, который привели выи на который ссылался я, задний фронт не применяется для работы с памятью и, соответственно, при работе с портами I/O так как они отображаются на память.

Улыбнуло.
Извините у меня род деятельности такой - проверять(прототипировать) проекты на FPGA перед тем как они на фаб уйдут и поправить уже будет ничего нельзя. Соответственно и RTL различных ядер у меня перед глазами постоянно. Впрочем я уже понял что доказать вам что либо нереально.


P.S.



В моем документе написано английским по белому что все регистры работают по фронту. Page 3 Table 1.

Да нет. Я признал свою ошибку в посте 44 сразу после поста Rst7. Причём ваших усилий не понадобилось. Я просто сам посмотрел документ, который вы привели 5 постами позже.
Я как раз человек сомневающийся в своей правоте. Поэтому стараюсь избегать категоричных заявлений.

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