_Pasha 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Доброго времени! Подскажите, как заставить компилятор в Winavr генерить правильный код. Нужно int16_t Xarg,Yarg,Zarg; ........................ Zarg= (Xarg*Yarg) >>16; Приведение к 32-битам - это безумное количество кода. Надо, чтоб генерился код примерно такой (имена регистров не важны): lds r16,Xarg lds r17,Xarg+1 lds r18,Yarg lds r19,Yarg+1 clr r6 //9 // дальше стандартное знаковое умножение muls r17,19 movw r4,r0 mul 16,r18 movw r2,r0 mulsu r19,r16 sbc r5,r6 add r3,r0 adc r4,r1 adc r5,r6 mulsu r17,r18 sbc r5,r6 add r3,r0 adc r4,r1 adc r5,r6 // и выделение старшей части 32-битного результата sts Zarg,r4 sts Zarg+1,r5 // итого 22+9 = 31 такт Бился головой о стену - ниасилил компилер такой красоты. А очень надо. Если кто уже получал такое чистым Си, поделитесь, пожалуйста, опытом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aesok 0 29 мая, 2008 Опубликовано 29 мая, 2008 (изменено) · Жалоба Бился головой о стену - ниасилил компилер такой красоты. А очень надо. Если кто уже получал такое чистым Си, поделитесь, пожалуйста, опытом. Нужно править компилятор. Анатолий. Изменено 29 мая, 2008 пользователем aesok Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Нужно править компилятор. Анатолий. А с умножением static int16_t TR1=-1039; TR0=0; static uint8_t TR2=30; .........<skipped>........................... for(;;) { TR0 = (TR1*TR2)>>8; ..<skipped>............... } Получаем такую херь: 103: TR0 = (TR1*TR2)>>8; +00000833: 91800200 LDS R24,0x0200 Load direct from data space +00000835: 91900201 LDS R25,0x0201 Load direct from data space +00000837: 019C MOVW R18,R24 Copy register pair +00000838: E065 LDI R22,0x05 Load immediate +00000839: 0F22 LSL R18 Logical Shift Left +0000083A: 1F33 ROL R19 Rotate Left Through Carry +0000083B: 956A DEC R22 Decrement +0000083C: F7E1 BRNE PC-0x03 Branch if not equal +0000083D: 0F88 LSL R24 Logical Shift Left +0000083E: 1F99 ROL R25 Rotate Left Through Carry +0000083F: 1B28 SUB R18,R24 Subtract without carry +00000840: 0B39 SBC R19,R25 Subtract with carry +00000841: 2F23 MOV R18,R19 Copy register +00000842: 0F33 LSL R19 Logical Shift Left +00000843: 0B33 SBC R19,R19 Subtract with carry +00000844: 9330031A STS 0x031A,R19 Store direct to data space +00000846: 93200319 STS 0x0319,R18 Store direct to data space Оптимизация -O2 (!) (ошибочка:оптимизация была -Os) , mega640 (это к тому, что mulsu там есть :) ) Компилер понял, что TR2 таки константа :), но это 41такт ! В то же время, при тех же условиях LDS R24,0x0200// Load direct from data space LDS R25,0x0201// Load direct from data space LDI R18,0x1E// я не говорю о том, что здесь не западло и LDS оставить и не оптимизировать ненужное // было 5 тактов mul r24,r18 movw r2,r0 mulsu r25,r18 ldi r18,0 sbc r1,r18 add r0,r3 adc r1,r18 //14 STS 0x031A,R1 Store direct to data space STS 0x0319,R0 Store direct to data space //18 составит 18 тактов. В общем, проблема серьезная, поскольку такие операции (умножить и поделить на 256) очень часто употребимы, думаю, не только мной. УПС, ошибочка в последнем коде. Исправленному верить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aesok 0 29 мая, 2008 Опубликовано 29 мая, 2008 (изменено) · Жалоба Оптимизация -O2 (!), mega640 (это к тому, что mulsu там есть :) ) А почему Вы не используете оптимизацию -Os? Анатолий. Изменено 29 мая, 2008 пользователем aesok Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Я всегда использую -Os, но здесь некоторый кусок кода не пролазил по времени, пришлось его -O2 Еще раз обращаю внимание на мой предыдущий пост - исправил ошибку в последнем коде. P.P.S Прошу прощение. Ввел в заблуждение всех. Подвожу итог, обойдя путаницу. В показанном примере оптимизация была -Os, выполнялось за 41 такт Включил обратно -O2 - выполнилось за 25 тактов, за счет замены цикла инлайнами. Это как-бы терпимо, но сама генерация кода все-же вызывает вопросы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба Бился головой о стену - ниасилил компилер такой красоты. А очень надо. Если кто уже получал такое чистым Си, поделитесь, пожалуйста, опытом.А почему нужно именно на чистом С ? напишите свою функцию на чистом asm и будет Вам полное счастье. :) Мне как-то понададобилось умножение 16бит x 16 бит на ATtiny, так там на С без mul получается вобще ужас с приведением к 32бит, ну а функция на асм DWORD mulu16by16(WORD, WORD); получилась более менее по времени. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 29 мая, 2008 Опубликовано 29 мая, 2008 · Жалоба А почему нужно именно на чистом С ? напишите свою функцию на чистом asm и будет Вам полное счастье. :) Дык я уже так и сделал, в смысле, прерывание написал. Получилось примерно следующее: 3 знаковых умножения 16х16 вида X = Beta*Y 15 умножений int16_t * uint8_t 18 операций 16-бит сложения 30 операций 16-бит сравнения (ограничение) помещается в 553 такта с учетом того, что используются 15 регистров, бесстыдно сохраняемых в стеке + SREG ( это 31+31 = 62 такта на контекст) Сишный вариант давал 1500 - с чем-то тактов. Даже с -О2. Устраивает тактов до 800 Беда, однако... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 1 июня, 2008 Опубликовано 1 июня, 2008 · Жалоба Какая же все-таки грабляндия эта арифметика! Привожу правильный и проверенный на всем множестве код для операции (int16_t) = (int16_t)*(uint8_t)/256 в виде AVR gnu-as #define arg1L r16 #define arg1H r17 #define scalar r18 #define NULL_REG r6 scale16x8: clr NULL_REG //........................... mul arg1L,scalar mov r2,r1 mulsu arg1H,scalar adc r0,r2 adc r1,NULL_REG ; result in r0:r1 Итого 7 тактов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 1 июня, 2008 Опубликовано 1 июня, 2008 · Жалоба Какая же все-таки грабляндия эта арифметика! Привожу правильный и проверенный на всем множестве код для операции Переписал для inline асссемблера: static inline uint16_t scale16x8(uint16_t a, uint8_t b) { uint16_t result; uint8_t tmp; /* %A0 - low byte of result, %B0 - hi byte of result, %1 - tmp %A2 - low byte of the first operand, %B2 - hi byte of the first operand, %3 - second operand */ asm ( "clr %1 \n\t" "mul %A2,%3 \n\t" "mov r2,r1 \n\t" "mulsu %B2,%3 \n\t" "adc r0,r2 \n\t" "adc r1,%1 \n\t" "movw %A0, r0 \n\t" "clr __zero_reg__ \n\t" : "=&r" (result), "=&r" (tmp) : "a" (a), "a" (b) ); return result; } Добавил зачистку __zero_reg__, так положено. Только вот что-то не сходится: int scale_test(void) { uint16_t a = 0; uint8_t b = 0; while (TRUE) { if (scale16x8(a, b) != ((unsigned long)a*b/256)) { nokia_puts_p("a = "); nokia_put_word(a); nokia_puts_p(", b = "); nokia_put_word(b); return FALSE; } if (a == 0xFFFF && b == 0xFF) return TRUE; if (!++b) a++; } } Ошибка при a=0x8000 и b=1. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
singlskv 0 1 июня, 2008 Опубликовано 1 июня, 2008 · Жалоба Ошибка при a=0x8000 и b=1. У Вас static inline uint16_t scale16x8(uint16_t a , uint8_t b ) а было: (int16_t) = (int16_t )*(uint8_t)/256 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 1 июня, 2008 Опубликовано 1 июня, 2008 · Жалоба У Вас static inline uint16_t scale16x8(uint16_t a , uint8_t b ) а было: (int16_t) = (int16_t )*(uint8_t)/256 Точно! Виноват :-) Исправил: static inline int16_t scale16x8(int16_t a, uint8_t b) { int16_t result; uint8_t tmp; /* %A0 - low byte of result, %B0 - hi byte of result, %1 - tmp %A2 - low byte of the first operand, %B2 - hi byte of the first operand, %3 - second operand */ asm ( "clr %1 \n\t" "mul %A2,%3 \n\t" "mov r2,r1 \n\t" "mulsu %B2,%3 \n\t" "adc r0,r2 \n\t" "adc r1,%1 \n\t" "movw %A0, r0 \n\t" "clr __zero_reg__ \n\t" : "=&r" (result), "=&r" (tmp) : "a" (a), "a" (b) ); return result; } int scale_test(void) { int16_t i = -32768; uint8_t b = 0; int16_t i1, i2; while (TRUE) { i1 = scale16x8(i, b); i2 = (signed long)i*b/256; if (i1 != i2) { nokia_puts_p(" a = "); nokia_put_int(i); nokia_puts_p(", b = "); nokia_put_word(b); return FALSE; } b++; if (!b) { i++; } if ((i == 32767) && (b == 0xFF)) break; } return TRUE; } Но всё равно, выдаёт ошибку при i=-32768 и b=1... Опять я где-то что-то проглядел? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 1 июня, 2008 Опубликовано 1 июня, 2008 · Жалоба Но всё равно, выдаёт ошибку при i=-32768 и b=1... Опять я где-то что-то проглядел? :) :a14: Про b=1 - это хорошо... Легкая неадекватность поведения замечена. А вот про -32768 то есть 0x8000, предлагаю извлечь дополнительный код из него :bb-offtopic: Меняю стакан соломы на обратный билет с Марса... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 2 июня, 2008 Опубликовано 2 июня, 2008 · Жалоба Про b=1 - это хорошо... Легкая неадекватность поведения замечена. То есть, функция таки работает не "во всём множестве"? :-) А вот про -32768 то есть 0x8000, предлагаю извлечь дополнительный код из него А зачем? :-) Или -32768 не бывает? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 2 июня, 2008 Опубликовано 2 июня, 2008 · Жалоба То есть, функция таки работает не "во всём множестве"? :-) А зачем? :-) Или -32768 не бывает? :) Таки да. Каюсь, не проверил оные значения ввиду нехватки времени и отсутсвия их практической ценности в целевом проекте. На самом деле с единицей оказалось все правильно. Возьмем -32767=0x8001 :) Для того, чтобы доказать, что 0x8001 >>8 != 0x80, приведем его в беззнаковый вид. Дополнительный код даст 0x7fff, операция сдвига на 8 бит даст 0x7f. Извлекаем обратно дополнительный код из результата, получаем 0x81. При расширении знака в старший байт имеем 0xFF81, что и наблюдаеццо в симуляторе. Как ни странно. Хотя здравый смысл подсказывает, что signed 0x8001 >>8 = 0xFF80. -32768 - счастливое исключение :) Поскольку +32768 в двух байтах не бывает, попытка привести к беззнаковому умножению 16*8 тоже ни к чему не приведет. Но на этом беда не заканчивается. Однобайтовый int8_t тоже ведь имеет встроенный баг 0x80. Видимо, придется обрабатывать как исключение. Но проще съехать с базара и сказать Таки да! Не на всем множестве! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 2 июня, 2008 Опубликовано 2 июня, 2008 · Жалоба Но проще съехать с базара и сказать Таки да! Не на всем множестве! Я отнюдь не наезжаю, боже упаси! Просто хочу знать границы применимости :) Что выходит на данный момент? Нельзя применять при b=1 и при a=-32768? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
