IAR Embedded Workbench

[gary2007]

Это зачем?

m можно сделать 8-ми битным.
На строку конечно много тактов.
Но я повешу АЦП на прерывания - пусть читает и суммирует, а обработку результата сделаю по флагу, вне прерывания.
Пока он насобирает, должно успеть посчитать.

[tempora]

m можно сделать 8-ми битным.

Ааффигенный выигрыш.

На строку конечно много тактов.

Вот и я о чём - там еще до 8 делений на 10. Получается, что вволю натрахавшись с переводом короткого кода "(i+500)/1000" в последовательность сдвигов/сложений, мы получаем выигрыш порядка 10 процентов (грубо) от общего времени вывода на дисплей. Стоит ли овчинка выделки? Если очень хочется, то можно и все деления на 10 также выполнять сдвигами/сложениями, тогда экономия за счет полного отказа от делений достигнет максимума, но... так ли она велика, вот вопрос...

Посмотрим на задачу с другой стороны:

Есть 20-ти битное число ... т.е максимум 7 знаков. Мне нужно вывести его на LED семисегментный индикатор, и только старшие 4 цифры, но при этом еще и округлить.

Было предложено два варианта деления с округлением - с делением и со сдвигами/сложениями:

unsigned int Calc1(unsigned long N)
{
    return((N+500)/1000);
}
unsigned int Calc2(unsigned long N)
{
unsigned int a,b,c,d,res;
#define     MulBy24(val)    (((val)‹‹4)+((val)‹‹3))

        a = N ›› 10;
        b = MulBy24(a) + (N & 1023) + 500;
        c = b ›› 10;
        d = MulBy24(c) + (b & 1023);
        res = a+c;
        if (d›1000) ++res;

        return(res);
}
void	main()
{
unsigned int v;
        ...
        v = Calc1(1048575);	// 199 clocks
        v = Calc2(1048575);	// 114 clocks
        ...
}

Разница времени выполнения указанных процедур составляет (199-114)=85 тактов (средний уровень оптимизации на скорость). Если частота вывода на LED-дисплей равна 25 раз в секунду, а тактовая частота меги - 8МГц, то наш трахач со сдвигами и сложениями привел к нев****ной экономии в двацать семь тысячных процента (0,027%). А если еще потрахаться с процедурой преобразования строки, переведя и её в сдвиги/сложения, то выигрыш увеличится в десять раз (грубо) и составит аж 0,27%. Достойный результат!
А как только мы накупим плюшек и заварим рюмочку чаю, чтобы отпраздновать свою победу, дверь откроется и заказчик бодрым голосом сообщит, что ширину LED-дисплея нужно увеличить (вариант - уменьшить) на один символ.
Мне, в моей процедуре, достаточно будет убрать (вариант - добавить) один нолик в делителе и еще один - в слагаемом, например - "(i+50)/100", а Вам, в супер-пупер-оптимизированной процедуре, придется переписать всё. И это ради выигрыша в 0,027% !!!

Напоминает историю о том, как два ковбоя, совершенно бесплатно, наелись коровьих лепешек.

[Boba_spb]

Маленький вопрос

Вот это вот для 20 битного N и 8 битного проца
unsigned int Calc1(unsigned int N)
не написать ли так
unsigned int Calc1(unsigned long N)

[tempora]

Там разумеется д.б. long и не для Calc1, а для обеих процедур.

[Boba_spb]

Ну во второй то 4 байта разнести на два слова - затрат то мало. А в первой то вся арифметика попрет по 32 битам - экономия то увеличится

[Boba_spb]

А на каком проце это работает то все?

[tempora]

экономия то увеличится

Да, если грубо, то время возрастет в 4 раза. Только результата в целом это не изменит - что цепляться за соломинку?
Тем более, что все предположения брались в пользу варианта со сдвигами/сложениями. Например, выводить данные на LCD-дисплей 25 раз в секунду - это слишком часто, глаз совместит разные показания в одну кашу. Нужно уменьшить, скажем, до 2. И не все числа будут иметь максимальное значение, при этом время деления сократится, а время сдвигов/сложений останется неизменным.
Так что, вывод прежний - тратить ресурсы нужно на оптимизацию тех процедур, которые отнимают основную долю процессорного времени.
__________________________________________________ ___
Upd:

А на каком проце это работает то все?

А какая разница? Даже если тактовая там не 8 МГц, а только 1, все равно речь будет идти лишь о долях процента.

[gary2007]

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

Да тут до заказчика еще далеко.
Я просто хотел поиграться с апнотом AVR121, неспеша, с разными вариантами. Инфы в сети мало, а открытого кода разработок вообще не видел, поэтому неизвестно что там потребуется.
А до таких сдвигов, как показал Boba_spb, я сам вообще бы никогда не додумался.

[tempora]

Да тут до заказчика еще далеко.

Ну, причем здесь заказчик и как до него далеко? Суть в том, что Вы тратите непропорционально много времени на процедуру, которая и ресурсов берет мало и повторяемостью не обладает. *)

А до таких сдвигов, ... вообще бы никогда не додумался.

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

[tempora]

Инфы в сети мало, а открытого кода разработок вообще не видел, ...

Ммм, то есть как это "мало" и "вообще не видел"? Я правильно понял, что речь об оверсэмплинге? Мало того, что Атмел предоставляет исходники, так еще и Гугл на "AVR121" выдал 39'400 результатов. Первый кажет на Атмел, второй - на Chipenable.Ru. Или нужно что-то другое?