...взять и поделить (двухбайтное число).

[retas]

Может кто подскажет как поделить двухбайтное число - былоб однобайтное,дёрнул бы на разряд на право и все дела,а как дёрнуть двухбайтное (никаких запятых,на asm).
Спасибо.

[vdlab]

Телепаты в отпуске, поэтому хоть бы указал какой контроллер, на сколько делить...
Я так понимаю нужно делить на 2? Нет ничего проще - сдвигаешь вправо старший байт, потом младший, две команды(ну это для ПИКов, для АВР и других точно не знаю, но все примерно также должно быть).

[tempora]

былоб однобайтное,дёрнул бы на разряд на право и все дела,а как дёрнуть двухбайтное (никаких запятых,на asm).

Если сдвигами, значит степень двойки. Так и тут та же история, только нужно позаботиться, чтобы бит 0 старшего байта попал в бит 7 младшего, вот и вся недолга. Обычно, в асме для этого используют инструкции сдвига через флаг переноса - выдвигаемый бит попадает в CarryFlag, а в следующей инструкции - вдвигаемый бит берется из CarryFlag'а. Перед всей операцией сдвига нужно очистить флаг переноса, а-то, он попадет в 15-й бит результата.

Нет ничего проще - сдвигаешь вправо старший байт, потом младший

А вот так делать не следует - результат будет ошибочным (даже для пиков). Кстати, если результат неважен, то неверно и то утверждение, что "Нет ничего проще" - тогда уж проще вообще ничего не делать - результат будет столь же неверным.

[nokazus]

Арифметика для AVR. Взята из аппноутов.
Удачи

Прикрепленный файл: 8217750.rar

[NemoCut32]

Сообщение от vdlab

Нет ничего проще - сдвигаешь вправо старший байт, потом младший

А вот так делать не следует - результат будет ошибочным (даже для пиков). Кстати, если результат неважен, то неверно и то утверждение, что "Нет ничего проще" - тогда уж проще вообще ничего не делать - результат будет столь же неверным.

Вопрос. Почему деление на 2 нельзя заменять сдвигом на 1 вправо? Я везде так пользуюсь для сокращения времени работы и кода. Операция сдвига выполняется существенно быстрее чем операция деления. Можно поподробней. Сдвиг ес-но не циклический.

[urry]

простите, никакой ошибки. Сдвигается первым именно старший байт - сдвигом, учитывающим перенос -заем

95:                unsigned int q=0x4181;
   0BD    3081     MOVLW 0x81
   0BE    1283     BCF 0x3, 0x5
   0BF    1303     BCF 0x3, 0x6
   0C0    00A4     MOVWF 0x24
   0C1    3041     MOVLW 0x41
   0C2    00A5     MOVWF 0x25
96:                q ›› =1; 
   0C3    1003     BCF 0x3, 0 // чистим бит переноса 
   0C4    0CA5     RRF 0x25, F //сдвигаем старший
   0C5    0CA4     RRF 0x24, F//сдвигаем младший, учитывая бит переноса от старшего, который попадает в D7 младшего

[nml]

Т.е. сначала сдвигаем младший, затем старший - и бит заема-переполнения старшего байта идет в д7 младшего.

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

Для АВРок это выглядит так:

asr Rhi
ror Rlo

PS меня уже опередили

[tempora]

Вопрос. Почему деление на 2 нельзя заменять сдвигом на 1 вправо?

А почему этот вопрос адресуется мне? Я как раз давал последовательность действий со сдвигом вправо, а не с делением, которого, кстати, в ассемблере чаще всего и нетути.

... здесь имелась в виду ошибка - ...
Бит заема старшего байта после сдвига должен уйти в старший битт младшего. Т.е. сначала сдвигаем младший, затем старший - и бит заема-переполнения старшего байта идет в д7 младшего.

Дружище, ты сам себя запутал! В воскресенье утром, впрочем, это даже хорошо!
Если сдвигать (вправо, не так ли?) сначала младший, то его нулевой бит попадет в CF, а со следующей инструкцией - в старший бит старшего байта (там же тоже будет сдвиг вправо, не так ли?).
Я говорил совсем о другой ошибке... Даже если ограничиваться пиками младших и средних моделей (про старшие ничего не знаю), где всего один способ сдвигать - через CF, то всё равно описанная последовательность действий содержит мину случайного действия - человек забыл предусмотреть очистку флага переноса перед началом сдвигов... а процессор совсем не так догадлив, как нам того хотелось бы - если после предыдущих операций флаг будет установлен, проц, вопреки нашим планам, таки-засунет его, нимало не мохая, в старший бит результата! И будет потом человек, поверивший vdlab'у, дооолго дебажить свой кристалл, чтобы обнаружить эту трудноуловимую и неповторяющуюся ситуацию. Как говорится - дьявол кроется в мелочах! Меньше бита в этом алгоритме ничего нет, но разделив, скажем, 256 на 2, будет несколько непонятно получать иногда 128, а иногда - 32896. 8O


Добавлено: Ого, оказывется все в сборе!

[tempora]

Для АВРок это выглядит так:

Код:

asr Rhi ror Rlo

Во-во, именно! Сдвиги-то бывают раазные!

[urry]

.

Сообщение от vdlab

Нет ничего проще - сдвигаешь вправо старший байт, потом младший

А вот так делать не следует - результат будет ошибочным (даже для пиков).