long int A, B, C, D, E, F, G, H, X;
int main()
{
A = 9;
B = 9;
C = 9;
D = 9;
E = 9;
F = 9;
G = 9;
H = 9;
X = A; // Прибавили еденицы
X = X + (B<<3) + (B<<1); // Прибавили десятки
X = X + (C<<6) + (C<<5) + (C<<2); // Прибавили сотни
X = X + (D<<9) + (D<<8) + (D<<7) + (D<<6) + (D<<5) + (D<<3); // Прибавили тысячи
X = X + (E<<13) + (E<<10) + (E<<9) + (E<<8) + (E<<4); // Прибавили десятки тысяч
X = X + (F<<16) + (F<<15) + (F<<10) + (F<<9) + (F<<7) + (F<<5); // Прибавили сотни тысяч
X = X + (G<<19) + (G<<18) + (G<<17) + (G<<16) + (G<<14) + (G<<9) + (G<<6); // Прибавили миллионы
X = X + (H<<23) + (H<<20) + (H<<19) + (H<<15) + (H<<12) + (H<<10) + (H<<9) + (H<<7); // Прибавили десятки миллионов
printf ("%d\n", X);
}
занимает 3758 Instruction Cycles на MCC18. Ушёл спать, оптимизирую потом.
HHIMERA писал(а):Вспомните, о чём писал вопрошающий...
Не на то внимание обращаешь!
Chettuser писал(а):У меня не суперкомпьютер! А всего лишь скромные PIC16/18.
Chettuser, если в МК есть аппаратное умножение, то такое лучше написать как есть. Перевод на сдвиги может быть только хуже, так как элементарных операций получается значительно больше. Если умножителя нет, тогда со сдвигами может быть лучше.
Могу продемонстрировать на примере AVR.
gcc version 4.3.3 (WinAVR 20100110)
Спойлер
unsigned int bcd4_int2(unsigned char d, unsigned char c, unsigned char b, unsigned char a) {
unsigned int x;
unsigned int tmp;
x = a | (d<<8) + (d<<9);
b = b << 1;
x+= b;
b = b << 1;
b = b << 1;
x+= b;
c = c << 1;
c = c << 1; // c << 2
x+= c;
c = c << 1; // c << 3
c = c << 1; // c << 4
tmp = c;
tmp = tmp << 1; // c << 5
x+= tmp;
tmp = tmp << 1; // c << 6
x+= tmp;
d = d << 1;
d = d << 1;
d = d << 1; // d << 3
x+= d;
d = d << 1; // d << 4
tmp = d;
tmp = tmp << 1; // d << 5
x+= tmp;
tmp = tmp << 1; // d << 6
x+= tmp;
tmp = tmp << 1; // d << 7
x+= tmp;
return ( x );
}
134 байт, 75 тактов
Варианты с аппаратным умножением и со сдвигами имеют ещё такое преимущество как фиксированное время выполнения.
Ну вот, пока я писал, Chettuser сам получил результат.
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
При увеличении разрядности чисел, аппаратное умножение может уже не давать преимуществ перед сдвигами. Т.к. процедура умножения 16x16=32 при наличии аппаратного умножения 8x8=16 не такая уж и быстрая.
Просто при реализации многоразрядного умножения так или иначе сдвиги тоже используются. Лучше уж два сдвига использовать вместо большего количества в рамках универсальной процедуры умножения.
И к чему придём??? К постоянному битью по рукам компилятору???
Так можно получить то, что после малейших изменений в проге придётся всё время что-то поправлять...
И если уж так много операций многоразрядного умножения, то и МК нужно брать соответствующий... иначе вся эта возня может оказаться пустой тратой времени...
А если операции многоразрядного умножения единичны и не особо критичны по времени, то и смысла особо заморачиваться нет...
Посмотрите на реализацию сдвига в восьмибитниках... и в PIC24, PIC32 или в STM32 и LPC1XXX - две большие разницы...
"Я не даю готовых решений, я заставляю думать!"(С)
Chettuser, на твоем месте сделал бы асмовставку в сишник, чтобы была как отдельная процедура конвертации, а 32-битная всего раза в три больше 16-битной и по скорости также, примерно в три раза.
FreshMan писал(а):в AVR, в режиме Normal при разрешении прерывания по совпадению счетчик продолжает считать дальше или сбрасывается ?
Дальше считает до переполнения. Отделите мух от котлет прерывания от режимов таймера. Прерывания не влияют на таймер, а таймер на прерывания - влияет (он их вызывает).
Этот пост оказался полезен? Не поленись, нажми слева!
Куплю индикаторы ИТС-1А, ИТС-1Б, ИГВ1-8х5Л, ИГПС1-222/7, ИГПС1-111/7 и подобные.
Ты, вроде, по делу писал. Не срывайся.
Я в том сообщении вполне ясно свою мысль описал. И Chettuser только подтвердил её для PIC с умножителем.
HHIMERA писал(а):у ПИКовых СИ есть ещё и свои заморочки...
Типа, если не пишу под PIC-и, то и знать не могу? Да, про заморочки ПИКовых Си не знаю. Но их (заморочек) и не надо знать чтобы предположить, что наличие аппаратного умножителя позволит получить более быстрый код (даже на Си). Для задачки Chettuser-а это главное, что надо было иметь в виду. Дальше уже на вкус и цвет - оптимизация, подгонка под компилятор, асм ...
HHIMERA писал(а): в недоразвитых МК...
Навеяло. Не помню где прочитал.
Это только на русских форумах, когда человек обращается со своей проблемой, ему не помогают её решить, а "объясняют", что это так не делают и, вообще, оно ему не надо.
Давайте так делать не будем.
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
Собираюсь приобрести ALTERA Cyclone Development Board для изучения.
Возник вопрос что брать: Altera Cyclone I EP1C3T100C8N или Altera Cyclone IV EP4CE10F17C8N.
Кто что посоветует?
Здравствуйте уважаемые!
Извините за то что вмешиваюсь в ваш разговор, просто не хочу заводить новой темы.
Суть вопроса такова - имеются блоки управления опрыскивателей, частая проблема с ними это выход с строя управляющей блоком микросхемы
MC705C9ACPE или mc68hc705c9acp купить их не проблема, а вот чем их клонировать и можно ли их вообще клонировать ни где так и не нашел информации.
Помогите кто чем может, пожалуйста, может кто то имел дело с такими процессорами?
слева!
