@ZhikSooM

Тем временем, чтобы коллективный разум совсем не задубел, загружу его полезной работой :)
Итак, имеем:
где X, Y - знаковые числа.
Задача проста: получить в R16 значение выражения (X-Y)/2.
На первый взгляд все просто, но в итоге... Решение выложу после некоторого количества догадок :)

0

@miyvir

Для знаковых чисел:
Для беззнаковых:

0

@SOWushko

sub r16, r17
ror r16
miyvir теряете знак при сдвиге.

Сложность задачи сильно преувеличена. Это не трюки, а так, шуточки. Трюков вы еще не видели = ))

0

@ZhikSooM

sub r16,r17
BST r16,7
lsr R16
BLD r16,7

Тоже неправильный код, фэйлит при X= -103, Y=72 :)

0

@mos80

ASM не увлекаюсь но судя по всему нужно сначала поделить, а потом уже вычетать..

0

@SOWushko

да, действительно, из за переполнения, потеряется бит. Что в принципе не делает задачу сложнее )
Трюки начинаются тогда, когда начинаем делить 16-32 разрядные знаковые числа, вот там трюки так трюки.
Числа с плав. запятой тоже ничего.

0

@ZhikSooM

Вариант неплохой, но округление там будет немного не красивое

0

@stt

BST r16,7
lsr R16
BLD r16,7
BST r17,7
lsr R17
BLD r17,7
sub r16,r17

Команды сохранения/восстановления флагов и логического сдвига тут можно заменить командой ASR

0

@ZhikSooM

Ну что ж, смотрите мой вариант:
Честное вычитание, но с хитрой коррекцией (хотя никакой хитрости тут нету, все по правилам).

0

@Ymk

а вот так не покатит?

0

@qbyt

sub R16, R17
brvc PC+2
sec
brbc 4, PC+2
sec
ror R16
Честное вычитание, но с хитрой коррекцией (хотя никакой хитрости тут нету, все по правилам).Не работает при X=1, Y=-2. Чтоб заработало, надо после sub поставить clc.

ldi r18,0x80
add r16,r18
add r17,r18
sub r16, r17
ror r16

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

Вот мой вариант:

0

@ZhikSooM

qbyt, ваш код тоже не рабочий - последние 4 команды в итоге вырождаются в ASR R16.
А вот код Инка потряс - просто и со вкусом!!!

0

@Ymk

шпашыбо! это мой дебют на avr-asm:)
а призы будут?:)))))

0

@qbyt

Да, согласен. Фишка вот в чём. Для примеров, в частности, для X= -103 и Y=72, происходит переполнение динамического диапазона промежуточного результата. Получаем, X-Y=-103–72=-175. Для типа char числа должны быть в диапазоне:
положительные: 1...127, отрицательные -1...-128. Как видно, промежуточный результат вываливается за пределы представления отрицательных чисел. Т.е. решение вида:работает только, если промежуточный результат не выходит за границы представления чисел. Получается, что X и Y для этого примера могут принимать следующие значения: положительные: 1...62, отрицательные -1...-64.

Мысль mos80 о том, что сперва делим, а потом вычитаем, так же гуд. Вот, что получается:
Решение от Ymk можно оптимизировать, заменив регистр R18 на арифметику с константой:
Если разность X и Y, представленных как char, положительна, то флаг S, бит 4 регистра статуса, всегда будет в “0", если отрицательна, то всегда флаг S будет выставлен. Собственно, вот код:
Получается, что код, в котором сперва делим, а потом вычитаем – самый оптимальный, всего 3 команды.

0

@pspost

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

0

@Ymk

x=0, y=1
должно быть: (0 - 1)/2 = (-1)/2 = -1.
будет: (0/2) - (1/2) = (0) - (0) = 0.

разное округление как бы.
вот же факиншыт! искал же я с константой, не нашел. omd и or видел,а eor нет. и сложения с вычитанием не нашел...
залез щас в даташит и... нашел SUBI только со второго раза:)))

0

@mos80

x=0, y=1
должно быть: (0 - 1)/2 = (-1)/2 = -1.
будет: (0/2) - (1/2) = (0) - (0) = 0.

А почему (-1)/2 = -1 а (1/2) = (0) ?
Разве знак как-то влияет?

0

@ZhikSooM

Машинное округление до меньшего будет правильнее.

0

@Ymk

mos80, еще как влияет!

0

@ZhikSooM

Итак, начнем разбор полетов.
Первым идею подал miyvir:
Этот код совершенно не подходит для нашего случая, но он эксплуатирует одну идею: прямое использования флага переполнения как девятого бита числа. Эта фишка хорошо прокатывает для сложения беззнаковых числел и последующего деления на 2:
Такой код работал бы идеально: при сложении может произойти переполнение, при этом устанивится флаг C, что аналогично установке 9-го бита в числе большей разрядности. А команда ROR сдвигает результат вправо на один бит, а содержимое флага (считай что 9-й бит числа) ставит на место 8-го бита - получается тоже такой своеобразный сдвиг (2-й бит на место 1-го, 3-й - на 2-е, ... , 9-й - на 8-е).

Следующая идея была подана г-ном SOWushko:
Этот код был сильно избыточен, т.к. три последние команды аналогичны команде ASR R16.
А эта команда, как известно, не учитывает каким-либо образом содержимое флагов и просто делит знаковое число на 2.

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

Начнем с представления знаковых чисел в пределах одного байта. Об этом кратенько писал Ди в заметке про флаг V, но сейчас об этом по-подробнее.
Тут можно провести аналогию с Земным шаром. Предположим, вы стоите на экваторе на стыке восточного и западного полушарий. Это место считаем нулем. Чуть шаг влево - вы уже на западном, вправо - на восточном. Причем ваше положение определяется не как +- пройденный путь, а как полный путь через восточное полушарие, по часовой стрелке. Т.е. если вы шагнули на 17 метров на запад, то ваша координата не -17 считая от нуля, а (Длина экватора минус 17). Ведь и правда - чтобы прийти к вам из нуля, можно шагнуть 17 метров на запад, а можно обогнуть весь экватор и подойти к вам с другой стороны. На первый взгляд бредово, но при отсутствии понятия "лево-право" очень пригодится.
Так вот, в микроконтроллерах (а в прочем и во всех ЭВМ) такая же ситуация - они не знают этих понятий и пользуются такой системой определения расстояний. Но, несмотря на то, что "лево-право" МК неизвестны, у него есть отдельные команды для движения в разные стороны - это, как можно догадаться, сложение и вычитание.

Как уже стало понятно, микроконтроллер не знает положительных чисел - они есть только у нас в головах, а в МК они хранятся в виде такого "полного" расстояния, при этом явное деление на "полушария" происходит при помощи самого старшего бита числа. Действительно, имеется ровно половина чисел (0..127), в которых этот бит не установлен, и половина (128..255), где он установлен. Бит установлен - "западное" полушарие (отрицательные числа), нету бита - "восточное" (положительные).

С этим разобрались. Теперь подходим ближе к нашей проблеме, которую я сейчас сформулирую.
Дело в том, что есть еще одна точка раздела восточного и западного полушария - она находится в точке с противоположной стороны земного шара, диаметрально противоположно точке нуля. Так вот, если мы близко подберемся к этой точке, например, со стороны восточного "положительного" полушария, то неосторожное прибавление некоторого числа к нашему текущему положению переступит эту границу и мы внезапно окажимся в западном "отрицательном" полушарии! Та же самая хрень может быть и при вычитании. Беда в том, что мы не хотели такого развития событий, но у процессора нету сведений о том, в каком полушарии мы находились до сложения (вычитания). Ведь по логике, если у нас до сложения было положительное число (восточное полушарие), и мы прибавили положительное число, то и на выходе должно быть положительное число (восточное полушарие)! А у нас в результате - западное!
Хотя... нет, сведения о прошлом положении есть! И это - флаг V во флаговом регистре. Короче говоря, если он установлен, то значит произошел переход в другое полушарие, если нет - то нет (Но! Переход через нулевую точку это флаг не учитывает и не отслеживает, т.к. это "честный" переход без побочных эффектов: к отрицательному прибавили бОльшее положительное - перешли из западного полушария в восточное - все в норме! Зато этот переход через ноль отслеживается во флаге C) . И это поможет нам определить, каким должен быть результат - положительным или отрицательным.
В принципе, этого флага достаточно для компенсации этого багафичи - мы должны сделать следующее:
1)Смотрим на последний бит результата - он определяет полушарие (знак числа), как я уже сказал.
2)Смотрим на бит V во флаговом регистре.
3)Теперь думаем:
-Если бит V установлен, то тут что-то неладное и нужна коррекция. Коррекция в какую сторону? Вот тут то мы и..
- Снова смотрим на последний бит результата. Если он установлен, то мы перескачили из восточного полушария в западное (перешагнули эту чертову границу), значит нам надо вернуться в западное полушарие. Фича в том, что просто вернуться нельзя - мы как-бы вылезли за пределы байта и нам нужен 9-й бит для нашего числа. Вот этот бит и будет равен нулю, т.к. в 9-тибитном числе он теперь указатель "полушария", а не 8-й бит. Равен нулю - значит мы в восточном полушарии и ниипет. А вот..
-Если бит V установлен, но результат положительный (последний бит результата - ноль, результат в восточном полушарии), то значит мы в процессе отнимания от отрицательного числа, которое стояло у границы этого раздела полушарий, перелезли эту границу, и вместо того, чтобы стать еще более отрицательнее, внезапно стали положительными. Непорядок. Именно в этом случае мы должны установить наш 9-й бит в единицу, которая намекнет - "мы должны быть в западном полушарии как до, так и после вычитания".
-А если бит V не установлен? Значит мы не вылезли за пределы одного байта и никакие 9-е биты нам не нужны. Но все же, каким будет наше 8-мибитное число в 9-тибитном пердставлении? Ясен пень, все таким же, но что будет в 9-м бите? А в нем будет значение, определяющее текущее полушарие. Т.к. это значение сейчас в 8-м бите, то нам просто надо скопировать его в 9-й бит!

Мда, чтоб определить, какое же у нас число - положительное или отрицательное, пришлось повозиться. Но.. Я вас обрадую!!! Процессор AVR уже все сделал за вас - прошелся по этим пунктам и определил, какое же значение стоит в 9-м бите (несмотря на то, нужен он или не нужен) результата. И это будет значение флага S во флаговом регистре.
Теперь, если надо, с ним можно делать что угодно: хочешь - копируй его в другой регистр и приводи 9-тибитное число в 16-битное (целых 7 бит просрать впустую, надо же!), а можно скопировать этот бит во флаг C и использовать его для деления результата на 2, как в самом первом примере. Следовательно, полностью рабочий код будет таким (первый предложил qbyt, правда после небольшой наводки):
Подробнее:
очищает флаг С во флаговом регистре, т.к. мы будем "копировать" в него содержимое флага S. Вот только это не настоящее копирование с полным замещением содержимого, как командой MOV, а условная установка этого флага, и перед ней надо иметь заранее известное значение в этом флаге.
Код:brbc 4, PC+2
sec
Это сам код условной установки флага С в зависимости от содержимого флага S. Страшная команда brbc 4, PC+2 ничто иное как проверка флага S на установленность (создатели компилятора не удосужились выделить удобочитаемую мнемонику команде проверки этого флага, как, например, флагу С: BRCS (BRanch if Carry Set)). Если он не установлен - то прыгаем на две команды вниз и флаг C остается чистым (не зря же я говорил, что надо точно его знать содержимое перед этим делом!). Еслм установлен - то идет на следующую команду, которая и устанавливает флаг С.
Ну а последняя команда
Код:ROR R16
делает уже знакомые нам вещи: все биты сдвигает вправо на одну позицию, а бит из флага С ставит на восьмое, пустое место (т.к. сидевший на 8-м месте бит ушел на 7-е), и в итоге получается результат, деленный на 2.

0