Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: 100 байт не хватает
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Страницы: 1, 2
Petka
Ещё как идея: Попробуйте вместо буржуевского AES использовать отечественный стандарт шифрования ГОСТ. Насколько я понимаю он тоже очень прост в реализации, да и стойкость у него примерно такая-же как и у AES. Он менее производителен, зато более компактный код должен получиться.
zltigo
Цитата(Petka @ Dec 28 2008, 11:19) *
Насколько я понимаю он тоже очень прост в реализации, да и стойкость у него примерно такая-же как и у AES. Он менее производителен, зато более компактный код должен получиться.

Он отнюдь не проще и насквозь 32 битный, что вообще для AVR смерть. Параноей страдать не надо и для AVR просто надо пользовать относительно "простенькие" уровня DES и прочих середины 70x-80 годов.
Огурцов
Цитата(zltigo @ Dec 27 2008, 23:01) *
А, так Вы это бредили sad.gif! То-то я смотрю что-то про красное в крапинку начали нести... Хорошо, что предупредили, не сразу понял sad.gif.

Я так понимаю, судя по продолжающемуся хамству, оригинальный код вы уже разместили в ~1.7k на GCC или ~1.1 на IAR, да ? Так и где же он ?


Цитата(Petka @ Dec 28 2008, 08:19) *
Попробуйте вместо буржуевского AES использовать отечественный стандарт шифрования ГОСТ.

С тем же успехом можно было использовать любой другой. Но у задачи есть еще одно существенное ограничение - минимально количество телодвижений. Исходный вариант в этом смысле был очень неплох. Да в общем-то и сейчас альтернатив не вижу.


Цитата(defunct @ Dec 27 2008, 22:57) *
У AVRки всего 10K перезаписей. Поэтому 56-бит неломаемо.

С параметрами
#if KEY_COUNT == 1
#define KEYBITS 128 //!< Use AES128.
#define ROUNDS 10 //!< Number of rounds.
#define KEYLENGTH 16 //!< Key length in number of bytes.

у меня что-то не сложилось. Да и в общем-то весь выигрышь лишь в длинне ключа - 16 байт и, кажется, размере ОЗУ, которого и так вполне хватает. Алгоритм, заточенный под конкретно 56 бит, я еще и не искал. С ним, вероятно, могло бы быть гораздо лучше.
Petka
Цитата(zltigo @ Dec 28 2008, 11:53) *
Он отнюдь не проще и насквозь 32 битный, что вообще для AVR смерть. Параноей страдать не надо и для AVR просто надо пользовать относительно "простенькие" уровня DES и прочих середины 70x-80 годов.

то, что он "насквозь" 32битный не делает его большим в плане реализации. Из 32бит операций там сдвиги, XORы которые для 8битника совсем не тяжелы. А так же сложение, которое тоже не представляет проблемы. Ранее я говорил что ГОСТ не быстр, но ОЧЕНЬ прост в реализации.
zltigo
Цитата(Petka @ Dec 28 2008, 12:34) *
Из 32бит операций там сдвиги, XORы которые для 8битника совсем не тяжелы.

Для восьмибика "тяжелы" и, что в случае загрузчика более существенно - громоздки любые не 8bit операци вне зависимости от XOR это или OR... При этом он однозначно проиграет и сильно проиграет своему одногрупнику DES по размеру. Что получаем в замен? Длинный ключ? А оно это надо? Кто будет ломать этот AVR - госслужбы USA? Клуб любителей создающих кластеры в интернете? Когда есть ресурсы (загрузчик (корее BIOS) 8K c массой наворотов среди которых дешифратор просто теряется), то можно, как и я в свое время поступил, запихнуть тот-же AES и не париться.
Petka
Цитата(zltigo @ Dec 28 2008, 13:10) *
... При этом он однозначно проиграет и сильно проиграет своему одногрупнику DES по размеру....

Очень спорно. ИМХО ГОСТ компактнее получится. Если приведёте свою оптимальную реализацию (на Си, и лучше оптимизированную для winavr) DES . То попробую сделать аналогичную процедуру ГОСТ. Можно будет сравнить. Самому любопытно.
zltigo
Цитата(Огурцов @ Dec 28 2008, 12:13) *
Я так понимаю, судя по продолжающемуся хамству....

Судя по повышению требований со 100 байт прописанных в заголовке до 900 ничего другого, кроме огульного обвиненя, теперь уже в хамстве у Вас не осталось. Напомню историю вопроса
1. Пролетели на 100 байт. С кем не бывает.
2. Вы начали пустопорожние общие разговоры об оптимизации
3. Я совершенно справедливо предположив, что ничего умнее, чем взять каой-нибудь писанный левой ногой исходник из интернета не сделано, выразился в духе, что зажать его на 100 байт без проблем.
4. С Вашей стороны начались рассказы о крутых профессионалах, от одного только имени (что-то вроде истинного имени Будды) которых лично я должен если не рассыпаться в прах, то как мимимум, покрыться красными полосками и удалиться в монастырь на покаяние.
5. Вами был выложен, как и предполагалось, писанный левой ногой исходник из интернету.
6. Естественно, он (точнее даже один из его кусков - других не касался) был соверженно спокойно сокращен на 250 байт... Что даже с учетом какого-нибудь другого генерящего менее компактный код компилятора просимые первоначально 100 байт обеспечивает наверняка.
7. Тут Вы начали совсем уж глупые разговоры о том, что это был "не тот" исходник а "тот" исходник он такооой исходник, что просто всем исходникам исходник и что-бы только приблизится к "тому" шедевру нужно зажать "этот" исходник вдвое.
8. Потом, вообще, зачем-то рассказали нам всем, как Вам нравится работать кассиром....

Короче,если-бы Вы дейсвительно, как Вам говорили несколько человек, выложили свой не влезающий на тот момент в 2K исходник, то возможно и был-бы повод для обсуждения. А так, так sad.gif. Хотя нет, небольшая польза есть, если у кого были иллюзии, что в Интернете, пусть даже у "профессионалов" именитой фирмы, можно найти реально приличные исходники sad.gif, то, надеюсь, они хоть слегка развеялись.

Цитата(Petka @ Dec 28 2008, 13:19) *
Очень спорно. ИМХО ГОСТ компактнее получится. Если приведёте свою оптимальную реализацию (на Си, и лучше оптимизированную для winavr) DES .

Ну сишные DES более, чем доступны, а "своими" и уж тем боле под AVR не занимался, ГОСТ реализация как-то на глаза не попадалась, но явно должна где-нибудь лежать. Для начала можете сравнить их и не в оптимизированном виде. По идее, когда-то давно использовал некий более простой, нежели DES (но его уровня) алгоритм - могу,когда вернусь домой, поискать в своих архивах.
Petka
Цитата(zltigo @ Dec 28 2008, 13:57) *
Ну сишные DES более, чем доступны, а "своими" не занимался.

для сравнения нужна не просто "реализация из интернета". Хотелось-бы иметь уже толковую версию DESа.
Цитата
ГОСТ реализация как-то на глаза не попадалась, но явно должна где-нибудь лежать. Для начала можете сравнить их и не в оптимизированном виде.

в неоптимизированном виде ГОСТ выигрывает.
Цитата
По идее, когда-то давно использовал некий более простой, нежели DES (но его уровня) алгоритм - могу поискать в своих архивах.

Искать не надо. т.к. нужна доказательная база о "его уровня" защищённости. Либо классический DES (к классическими "ослаблениями"), либо ничего (в рамках данного исследования об размере кода).
zltigo
Цитата(Petka @ Dec 28 2008, 14:04) *
в неоптимизированном виде ГОСТ выигрывает.

Тогда, хотелось-бы взглянуть,что там для 8bit получилось. Ссылку на сишный исходник ГОСТ, пожалуйста. После sad.gif Нового Года посмотрю.
Цитата
Искать не надо. т.к. нужна доказательная база о "его уровня" защищённости.

Ну это тоже был не доморощенный - тех-же времен и с такой-же теоретической "подпоркой". Разница в основном в том, что официально принят штатами был DES.
P.S.
Вспомнил волшебные буквы smile.gif TEA и XTEA. Там исходников дешифратора строк десять на C - думаю легко найдете.
Petka
Цитата(zltigo @ Dec 28 2008, 14:09) *
Тогда, хотелось-бы взглянуть,что там для 8bit получилось. Ссылку на сишный исходник ГОСТ, пожалуйста. После sad.gif Нового Года посмотрю.

ссылки нет. это моя реализация.
Цитата
Ну это тоже был не доморощенный - тех-же времен и с такой-же теоретической "подпоркой". Разница в основном в том, что официально принят штатами был DES.

хотя-бы название?
zltigo
Цитата(Petka @ Dec 28 2008, 14:16) *
хотя-бы название?

Выше....
Огурцов
Цитата(zltigo @ Dec 28 2008, 10:57) *
Судя по повышению требований со 100 байт прописанных в заголовке до 900 ничего другого, кроме огульного обвиненя, теперь уже в хамстве у Вас не осталось.

Нет, еще есть вариант - в глупости. 100 нехватало мне. А 900 нехватает вам, чтобы иметь право хотя бы встать в один ряд с тем профи. Насколько потребовалось бы ужать еще, чтобы сметь писать оскорбления в его адрес, я даже не говорю. Но вы ж этого все равно не понимаете. Так что одно из двух. Или и то и другое вместе.

Цитата(zltigo @ Dec 28 2008, 10:57) *
2. Вы начали пустопорожние общие разговоры

Знаете, я вас персонально в этот топик не приглашал. Более того, еще раз настоятельно требую покинуть его и почистить за собой все ваши посты, потому как они целиком и полностью являются офф-топиком, постоянно провоцируют и оскорбляют других участников форума.

Цитата(zltigo @ Dec 28 2008, 10:57) *
8. Потом, вообще, зачем-то рассказали нам всем, как Вам нравится работать кассиром....

Резонно. Затем же, зачем и вы рассказали про свою жену, которая прилетела из риги.
zltigo
Цитата(Огурцов @ Dec 28 2008, 15:29) *
почистить за собой все ваши посты...

Уже один раз ответил.
Цитата(Огурцов @ Dec 28 2008, 15:29) *
в его адрес...

Раговор веду исключительно о Вас и оцениваю исключительно Вас по Вашим-же постам (за неимением сколь-нибудь внятного Вашего исходника - ну не считать-же право вот это
Цитата
Код
void Bus_transmit_packet(uint8 aStatus)
{
    uint16 vCrc;

    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_packet_end);
    Bus_transmit_byte(Slp_sysdev_program | Slp_response_mask);
//    vCrc = vxl_get_crc16(Vxl_crc_ccitt_initial_value, Slp_sysdev_program | Slp_response_mask);
    Bus_staff_n_transmit_byte(aStatus);
    vCrc = vxl_get_crc16(0x7976, aStatus);
    Bus_staff_n_transmit_byte(vCrc >> 8);
    Bus_staff_n_transmit_byte(vCrc & 0xFF);
    Bus_transmit_byte(Slp_packet_end);
}

достойным разговоров об оптимизации smile.gif?
И "профи" написавшего присланный Вами исходник.
Никаких мифических персонажей не обсуждаю. Да и Вам отвечать по мамнадцатому разу на перепевки "у нас есть такие ракеты, но мы вам о них не расскажем" и про мифических персонажей написавших мифический исходник в общем-то утомило. Больше лично я эти "песни" не слушаю, и уж тем более не отвечаю.
Цитата
Резонно. Затем же, зачем и вы рассказали про свою жену, которая прилетела из риги.

Из Праги smile.gif, но резонно. Признаю 8 пункт необоснованными наездом с моей стороны - прошу за него извинить sad.gif, был не прав.


Цитата(Petka @ Dec 28 2008, 14:16) *
хотя-бы название?

Почти канонический исходник поминаемого XTEA из интернета
Код
void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long sum=0, delta=0x9E3779B9;
    for(i=0; i<num_rounds; i++) {
       v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
        sum += delta;
        v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
    }
    v[0]=v0; v[1]=v1;
}

void decipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long delta=0x9E3779B9, sum=delta*num_rounds;
    for(i=0; i<num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

Кстати, в лоб скомпилированный 'cipher' под ARM/ARM Mode почти вдвое меньше, чем под AVR. Причем для заточенного под 8bit AES разницы практически нет, а если не подправить слегка хоть местами под 32bit, то на ARM толще sad.gif но резонно. Признаю 8 пункт необоснованными с моей стороны.


Цитата(Petka @ Dec 28 2008, 14:16) *
хотя-бы название?

Почти канонический исходник поминаемого XTEA из интернета
Код
void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long sum=0, delta=0x9E3779B9;
    for(i=0; i<num_rounds; i++) {
       v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
        sum += delta;
        v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
    }
    v[0]=v0; v[1]=v1;
}

void decipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
    unsigned long v0=v[0], v1=v[1], i;
    unsigned long delta=0x9E3779B9, sum=delta*num_rounds;
    for(i=0; i<num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

Кстати, в лоб скомпилированный 'cipher' под ARM/ARM Mode почти вдвое меньше, чем под AVR. Причем для заточенного под 8bit AES разницы практически нет, а если не подправить слегка хоть местами под 32bit, то на ARM толще sad.gif
Сколько у Вас Гостов
Сколько у Вас Гостовский 'движек' на AVR занял?
Petka
Цитата(zltigo @ Dec 28 2008, 17:15) *
Сколько у Вас Гостовский 'движек' на AVR занял?

Никогда его ещё не пробовал на AVR. "В лоб" получилось:
ГОСТ 786 байта. (кодер+декодер)
XTEA 972 байта. (кодер+декодер)

Никаких оптимизаций не делал для 8ми бит.
Огурцов
Цитата(zltigo @ Dec 28 2008, 14:15) *
Уже один раз ответил.

Контрольный - мало ли, вы опять не поняли.

Цитата(zltigo @ Dec 28 2008, 14:15) *
Раговор веду исключительно о Вас

Опять ложь.

Цитата(zltigo @ Dec 28 2008, 14:15) *
ну не считать-же право вот это достойным разговоров об оптимизации

Вы наконец-то решили вернуться к теме ? Тогда мне непонятно: "это" недостойно оптимизации, потому что вы можете написать в несколько раз лучше ? Так напишите. 10 строчек кода вместо 10 строчек болтовни - и всем все сразу понятно.
Или же напротив, "это" написано настолько хорошо, что ни о какой дальнейшей оптимизации не может идти разговор ?

Цитата(zltigo @ Dec 28 2008, 14:15) *
Никаких мифических персонажей не обсуждаю

С чего вы вбили это себе в бошку ? Повторить еще раз, что реальный профи реальный ?
zltigo
Цитата(Petka @ Dec 28 2008, 18:59) *
XTEA 972 байта. (кодер+декодер)

Очень странно. Сейчас посмотреть не могу, но вышепреведенный исходник движка декодера откомпилировлся для AVR в немногим больше 200 байт. Кодер там практически такой-же...200 + 200 = 972????
Petka
Цитата(zltigo @ Dec 28 2008, 19:05) *
Очень странно. Сейчас посмотреть не могу, но вышепреведенный исходник движка декодера откомпилировлся для AVR в немногим больше 200 байт. Кодер там практически такой-же...200 + 200 = 972????

за что купил, за то продаю:
CODE


00000388 <encipher>:



void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
388: 2f 92 push r2
38a: 3f 92 push r3
38c: 4f 92 push r4
38e: 5f 92 push r5
390: 6f 92 push r6
392: 7f 92 push r7
394: 8f 92 push r8
396: 9f 92 push r9
398: af 92 push r10
39a: bf 92 push r11
39c: cf 92 push r12
39e: df 92 push r13
3a0: ef 92 push r14
3a2: ff 92 push r15
3a4: 0f 93 push r16
3a6: 1f 93 push r17
3a8: df 93 push r29
3aa: cf 93 push r28
3ac: cd b7 in r28, 0x3d; 61
3ae: de b7 in r29, 0x3e; 62
3b0: 2a 97 sbiw r28, 0x0a; 10
3b2: 0f b6 in r0, 0x3f; 63
3b4: f8 94 cli
3b6: de bf out 0x3e, r29; 62
3b8: 0f be out 0x3f, r0; 63
3ba: cd bf out 0x3d, r28; 61
3bc: 7a 87 std Y+10, r23; 0x0a
3be: 69 87 std Y+9, r22; 0x09
3c0: ba 01 movw r22, r20
unsigned long v0=v[0], v1=v[1], i;
3c2: a9 85 ldd r26, Y+9; 0x09
3c4: ba 85 ldd r27, Y+10; 0x0a
3c6: 2d 90 ld r2, X+
3c8: 3d 90 ld r3, X+
3ca: 4d 90 ld r4, X+
3cc: 5c 90 ld r5, X
3ce: 13 97 sbiw r26, 0x03; 3
3d0: 14 96 adiw r26, 0x04; 4
3d2: 6d 90 ld r6, X+
3d4: 7d 90 ld r7, X+
3d6: 8d 90 ld r8, X+
3d8: 9c 90 ld r9, X
3da: 17 97 sbiw r26, 0x07; 7
3dc: 19 82 std Y+1, r1; 0x01
3de: 1a 82 std Y+2, r1; 0x02
3e0: 1b 82 std Y+3, r1; 0x03
3e2: 1c 82 std Y+4, r1; 0x04
3e4: aa 24 eor r10, r10
3e6: bb 24 eor r11, r11
3e8: 65 01 movw r12, r10
unsigned long sum=0, delta=0x9E3779B9;
for(i=0; i<num_rounds; i++) {
3ea: 9c 01 movw r18, r24
3ec: 40 e0 ldi r20, 0x00; 0
3ee: 50 e0 ldi r21, 0x00; 0
3f0: 2d 83 std Y+5, r18; 0x05
3f2: 3e 83 std Y+6, r19; 0x06
3f4: 4f 83 std Y+7, r20; 0x07
3f6: 58 87 std Y+8, r21; 0x08
3f8: 83 c0 rjmp .+262 ; 0x500 <encipher+0x178>
v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
3fa: f5 01 movw r30, r10
3fc: e3 70 andi r30, 0x03; 3
3fe: f0 70 andi r31, 0x00; 0
400: ee 0f add r30, r30
402: ff 1f adc r31, r31
404: ee 0f add r30, r30
406: ff 1f adc r31, r31
408: e6 0f add r30, r22
40a: f7 1f adc r31, r23
40c: e0 80 ld r14, Z
40e: f1 80 ldd r15, Z+1; 0x01
410: 02 81 ldd r16, Z+2; 0x02
412: 13 81 ldd r17, Z+3; 0x03
414: ea 0c add r14, r10
416: fb 1c adc r15, r11
418: 0c 1d adc r16, r12
41a: 1d 1d adc r17, r13
41c: d4 01 movw r26, r8
41e: c3 01 movw r24, r6
420: f5 e0 ldi r31, 0x05; 5
422: b6 95 lsr r27
424: a7 95 ror r26
426: 97 95 ror r25
428: 87 95 ror r24
42a: fa 95 dec r31
42c: d1 f7 brne .-12 ; 0x422 <encipher+0x9a>
42e: a4 01 movw r20, r8
430: 93 01 movw r18, r6
432: e4 e0 ldi r30, 0x04; 4
434: 22 0f add r18, r18
436: 33 1f adc r19, r19
438: 44 1f adc r20, r20
43a: 55 1f adc r21, r21
43c: ea 95 dec r30
43e: d1 f7 brne .-12 ; 0x434 <encipher+0xac>
440: 82 27 eor r24, r18
442: 93 27 eor r25, r19
444: a4 27 eor r26, r20
446: b5 27 eor r27, r21
448: 86 0d add r24, r6
44a: 97 1d adc r25, r7
44c: a8 1d adc r26, r8
44e: b9 1d adc r27, r9
450: e8 26 eor r14, r24
452: f9 26 eor r15, r25
454: 0a 27 eor r16, r26
456: 1b 27 eor r17, r27
458: 2e 0c add r2, r14
45a: 3f 1c adc r3, r15
45c: 40 1e adc r4, r16
45e: 51 1e adc r5, r17
sum += delta;
460: 89 eb ldi r24, 0xB9; 185
462: 99 e7 ldi r25, 0x79; 121
464: a7 e3 ldi r26, 0x37; 55
466: be e9 ldi r27, 0x9E; 158
468: a8 0e add r10, r24
46a: b9 1e adc r11, r25
46c: ca 1e adc r12, r26
46e: db 1e adc r13, r27
v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
470: a2 01 movw r20, r4
472: 91 01 movw r18, r2
474: 05 e0 ldi r16, 0x05; 5
476: 56 95 lsr r21
478: 47 95 ror r20
47a: 37 95 ror r19
47c: 27 95 ror r18
47e: 0a 95 dec r16
480: d1 f7 brne .-12 ; 0x476 <encipher+0xee>
482: d2 01 movw r26, r4
484: c1 01 movw r24, r2
486: 14 e0 ldi r17, 0x04; 4
488: 88 0f add r24, r24
48a: 99 1f adc r25, r25
48c: aa 1f adc r26, r26
48e: bb 1f adc r27, r27
490: 1a 95 dec r17
492: d1 f7 brne .-12 ; 0x488 <encipher+0x100>
494: 28 27 eor r18, r24
496: 39 27 eor r19, r25
498: 4a 27 eor r20, r26
49a: 5b 27 eor r21, r27
49c: 22 0d add r18, r2
49e: 33 1d adc r19, r3
4a0: 44 1d adc r20, r4
4a2: 55 1d adc r21, r5
4a4: d6 01 movw r26, r12
4a6: c5 01 movw r24, r10
4a8: fb e0 ldi r31, 0x0B; 11
4aa: b6 95 lsr r27
4ac: a7 95 ror r26
4ae: 97 95 ror r25
4b0: 87 95 ror r24
4b2: fa 95 dec r31
4b4: d1 f7 brne .-12 ; 0x4aa <encipher+0x122>
4b6: 83 70 andi r24, 0x03; 3
4b8: 90 70 andi r25, 0x00; 0
4ba: 88 0f add r24, r24
4bc: 99 1f adc r25, r25
4be: 88 0f add r24, r24
4c0: 99 1f adc r25, r25
4c2: 86 0f add r24, r22
4c4: 97 1f adc r25, r23
4c6: fc 01 movw r30, r24
4c8: 80 81 ld r24, Z
4ca: 91 81 ldd r25, Z+1; 0x01
4cc: a2 81 ldd r26, Z+2; 0x02
4ce: b3 81 ldd r27, Z+3; 0x03
4d0: 8a 0d add r24, r10
4d2: 9b 1d adc r25, r11
4d4: ac 1d adc r26, r12
4d6: bd 1d adc r27, r13
4d8: 28 27 eor r18, r24
4da: 39 27 eor r19, r25
4dc: 4a 27 eor r20, r26
4de: 5b 27 eor r21, r27
4e0: 62 0e add r6, r18
4e2: 73 1e adc r7, r19
4e4: 84 1e adc r8, r20
4e6: 95 1e adc r9, r21


void encipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
unsigned long v0=v[0], v1=v[1], i;
unsigned long sum=0, delta=0x9E3779B9;
for(i=0; i<num_rounds; i++) {
4e8: 29 81 ldd r18, Y+1; 0x01
4ea: 3a 81 ldd r19, Y+2; 0x02
4ec: 4b 81 ldd r20, Y+3; 0x03
4ee: 5c 81 ldd r21, Y+4; 0x04
4f0: 2f 5f subi r18, 0xFF; 255
4f2: 3f 4f sbci r19, 0xFF; 255
4f4: 4f 4f sbci r20, 0xFF; 255
4f6: 5f 4f sbci r21, 0xFF; 255
4f8: 29 83 std Y+1, r18; 0x01
4fa: 3a 83 std Y+2, r19; 0x02
4fc: 4b 83 std Y+3, r20; 0x03
4fe: 5c 83 std Y+4, r21; 0x04
500: 89 81 ldd r24, Y+1; 0x01
502: 9a 81 ldd r25, Y+2; 0x02
504: ab 81 ldd r26, Y+3; 0x03
506: bc 81 ldd r27, Y+4; 0x04
508: 2d 81 ldd r18, Y+5; 0x05
50a: 3e 81 ldd r19, Y+6; 0x06
50c: 4f 81 ldd r20, Y+7; 0x07
50e: 58 85 ldd r21, Y+8; 0x08
510: 82 17 cp r24, r18
512: 93 07 cpc r25, r19
514: a4 07 cpc r26, r20
516: b5 07 cpc r27, r21
518: 08 f4 brcc .+2 ; 0x51c <encipher+0x194>
51a: 6f cf rjmp .-290 ; 0x3fa <encipher+0x72>
v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
sum += delta;
v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
}
v[0]=v0; v[1]=v1;
51c: a9 85 ldd r26, Y+9; 0x09
51e: ba 85 ldd r27, Y+10; 0x0a
520: 2d 92 st X+, r2
522: 3d 92 st X+, r3
524: 4d 92 st X+, r4
526: 5c 92 st X, r5
528: 13 97 sbiw r26, 0x03; 3
52a: fd 01 movw r30, r26
52c: 64 82 std Z+4, r6; 0x04
52e: 75 82 std Z+5, r7; 0x05
530: 86 82 std Z+6, r8; 0x06
532: 97 82 std Z+7, r9; 0x07
}
534: 2a 96 adiw r28, 0x0a; 10
536: 0f b6 in r0, 0x3f; 63
538: f8 94 cli
53a: de bf out 0x3e, r29; 62
53c: 0f be out 0x3f, r0; 63
53e: cd bf out 0x3d, r28; 61
540: cf 91 pop r28
542: df 91 pop r29
544: 1f 91 pop r17
546: 0f 91 pop r16
548: ff 90 pop r15
54a: ef 90 pop r14
54c: df 90 pop r13
54e: cf 90 pop r12
550: bf 90 pop r11
552: af 90 pop r10
554: 9f 90 pop r9
556: 8f 90 pop r8
558: 7f 90 pop r7
55a: 6f 90 pop r6
55c: 5f 90 pop r5
55e: 4f 90 pop r4
560: 3f 90 pop r3
562: 2f 90 pop r2
564: 08 95 ret

00000566 <decipher>:

void decipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) {
566: 2f 92 push r2
568: 3f 92 push r3
56a: 4f 92 push r4
56c: 5f 92 push r5
56e: 6f 92 push r6
570: 7f 92 push r7
572: 8f 92 push r8
574: 9f 92 push r9
576: af 92 push r10
578: bf 92 push r11
57a: cf 92 push r12
57c: df 92 push r13
57e: ef 92 push r14
580: ff 92 push r15
582: 0f 93 push r16
584: 1f 93 push r17
586: df 93 push r29
588: cf 93 push r28
58a: cd b7 in r28, 0x3d; 61
58c: de b7 in r29, 0x3e; 62
58e: 2c 97 sbiw r28, 0x0c; 12
590: 0f b6 in r0, 0x3f; 63
592: f8 94 cli
594: de bf out 0x3e, r29; 62
596: 0f be out 0x3f, r0; 63
598: cd bf out 0x3d, r28; 61
59a: 7c 87 std Y+12, r23; 0x0c
59c: 6b 87 std Y+11, r22; 0x0b
59e: 5a 87 std Y+10, r21; 0x0a
5a0: 49 87 std Y+9, r20; 0x09
unsigned long v0=v[0], v1=v[1], i;
5a2: db 01 movw r26, r22
5a4: 2d 90 ld r2, X+
5a6: 3d 90 ld r3, X+
5a8: 4d 90 ld r4, X+
5aa: 5c 90 ld r5, X
5ac: 13 97 sbiw r26, 0x03; 3
5ae: 14 96 adiw r26, 0x04; 4
5b0: 6d 90 ld r6, X+
5b2: 7d 90 ld r7, X+
5b4: 8d 90 ld r8, X+
5b6: 9c 90 ld r9, X
5b8: 17 97 sbiw r26, 0x07; 7
unsigned long delta=0x9E3779B9, sum=delta*num_rounds;
5ba: 9c 01 movw r18, r24
5bc: 40 e0 ldi r20, 0x00; 0
5be: 50 e0 ldi r21, 0x00; 0
5c0: 2d 83 std Y+5, r18; 0x05
5c2: 3e 83 std Y+6, r19; 0x06
5c4: 4f 83 std Y+7, r20; 0x07
5c6: 58 87 std Y+8, r21; 0x08
5c8: ca 01 movw r24, r20
5ca: b9 01 movw r22, r18
5cc: 29 eb ldi r18, 0xB9; 185
5ce: 39 e7 ldi r19, 0x79; 121
5d0: 47 e3 ldi r20, 0x37; 55
5d2: 5e e9 ldi r21, 0x9E; 158
5d4: 1d d5 rcall .+2618 ; 0x1010 <__mulsi3>
5d6: 5b 01 movw r10, r22
5d8: 6c 01 movw r12, r24
5da: 19 82 std Y+1, r1; 0x01
5dc: 1a 82 std Y+2, r1; 0x02
5de: 1b 82 std Y+3, r1; 0x03
5e0: 1c 82 std Y+4, r1; 0x04
5e2: 87 c0 rjmp .+270 ; 0x6f2 <decipher+0x18c>
for(i=0; i<num_rounds; i++) {
v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum>>11) & 3]);
5e4: d6 01 movw r26, r12
5e6: c5 01 movw r24, r10
5e8: fb e0 ldi r31, 0x0B; 11
5ea: b6 95 lsr r27
5ec: a7 95 ror r26
5ee: 97 95 ror r25
5f0: 87 95 ror r24
5f2: fa 95 dec r31
5f4: d1 f7 brne .-12 ; 0x5ea <decipher+0x84>
5f6: 83 70 andi r24, 0x03; 3
5f8: 90 70 andi r25, 0x00; 0
5fa: 88 0f add r24, r24
5fc: 99 1f adc r25, r25
5fe: 88 0f add r24, r24
600: 99 1f adc r25, r25
602: 49 85 ldd r20, Y+9; 0x09
604: 5a 85 ldd r21, Y+10; 0x0a
606: 84 0f add r24, r20
608: 95 1f adc r25, r21
60a: dc 01 movw r26, r24
60c: ed 90 ld r14, X+
60e: fd 90 ld r15, X+
610: 0d 91 ld r16, X+
612: 1c 91 ld r17, X
614: ea 0c add r14, r10
616: fb 1c adc r15, r11
618: 0c 1d adc r16, r12
61a: 1d 1d adc r17, r13
61c: d2 01 movw r26, r4
61e: c1 01 movw r24, r2
620: 75 e0 ldi r23, 0x05; 5
622: b6 95 lsr r27
624: a7 95 ror r26
626: 97 95 ror r25
628: 87 95 ror r24
62a: 7a 95 dec r23
62c: d1 f7 brne .-12 ; 0x622 <decipher+0xbc>
62e: a2 01 movw r20, r4
630: 91 01 movw r18, r2
632: 64 e0 ldi r22, 0x04; 4
634: 22 0f add r18, r18
636: 33 1f adc r19, r19
638: 44 1f adc r20, r20
63a: 55 1f adc r21, r21
63c: 6a 95 dec r22
63e: d1 f7 brne .-12 ; 0x634 <decipher+0xce>
640: 82 27 eor r24, r18
642: 93 27 eor r25, r19
644: a4 27 eor r26, r20
646: b5 27 eor r27, r21
648: 82 0d add r24, r2
64a: 93 1d adc r25, r3
64c: a4 1d adc r26, r4
64e: b5 1d adc r27, r5
650: e8 26 eor r14, r24
652: f9 26 eor r15, r25
654: 0a 27 eor r16, r26
656: 1b 27 eor r17, r27
658: 6e 18 sub r6, r14
65a: 7f 08 sbc r7, r15
65c: 80 0a sbc r8, r16
65e: 91 0a sbc r9, r17
sum -= delta;
660: 27 e4 ldi r18, 0x47; 71
662: 36 e8 ldi r19, 0x86; 134
664: 48 ec ldi r20, 0xC8; 200
666: 51 e6 ldi r21, 0x61; 97
668: a2 0e add r10, r18
66a: b3 1e adc r11, r19
66c: c4 1e adc r12, r20
66e: d5 1e adc r13, r21
v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
670: a4 01 movw r20, r8
672: 93 01
zltigo
Цитата(Petka @ Dec 28 2008, 19:35) *
за что купил, за то продаю:

31 вернусь домой - повторю и выложу "двухсотбайтовый" из под IAR.
Petka
Цитата(zltigo @ Dec 28 2008, 19:39) *
31 вернусь домой - повторю и выложу "двухсотбайтовый" из под IAR.

IARом не обладаю, так что может будем лучше сравнивать в доступном gcc? Я Вам верю что 200 с копейками байт получалось под IARом. С другой стороны тогда ГОСТ получится ещё более кучерявым чем 200 байт wink.gif
zltigo
Цитата(Petka @ Dec 28 2008, 20:19) *
IARом не обладаю, так что может будем лучше сравнивать в доступном gcc?

Что-то мне не хочется GCC toolchain под AVR себе добавлять, тем более имеет быть проблема выбора...
Для AVR я пишу редко, под несерьезных (которых не волнует лицензионность) заказчиков, а для своих целей, мне на самом деле хватит самых мелких (которые конкурентноспособны) AVR и 4K.
Цитата
Я Вам верю что 200 с копейками байт получалось под IARом.

А вот мне что-то кажется очень странным такой провал с GCC. Для того-же ARM, не говоря об 386 он весьма неплох. Какой версией/сборкой компилировали?
Petka
Цитата(zltigo @ Dec 29 2008, 14:06) *
Что-то мне не хочется GCC toolchain под AVR себе добавлять, тем более имеет быть проблема выбора...

какая проблема выбора? последний winavr. Знаю, что более ранние версии генерят более компактный код. Но пока ещё никогда не упирался в размер флеша из-за неоптимальной компиляции.
Цитата
Какой версией/сборкой компилировали?

WinAVR 20081205
singlskv
Цитата(zltigo @ Dec 29 2008, 14:06) *
А вот мне что-то кажется очень странным такой провал с GCC.

Чего-то сдесь не то, 400 байт на кодер/декодер не должно хватать.
IAR вынес что-то еще кроме умножения sum=delta*num_rounds; в отдельное место ?

Не хочу ставить IAR на новый комп и проверять, тч ждем Ваш листинг из №63

P.S. На GCC нужно по крайней мере заменить:
unsigned long v0=v[0], v1=v[1], i;
на
unsigned long v0=v[0], v1=v[1];
unsigned int i;

это - ~160 байт на 2 функциях

ulong i никому там не нужен...
_Pasha
C vs ASM (AVR):
Вчера переписал на одном девайсе прерывание. Несколько обработчиков вызывают одну и ту же ф-цию с разными параметрами.
Асм левой ногой "сделал всех" на 200 байт. Почему так:
- необходимость вызова функции в обработчиках тянет за собой лишние сохранения регистров, в то время как вручную это все сводится к минимуму,
- манипуляции с битами через bld/bst иногда очень экономны, компилер такое ниасилит,
- получение результата сравнения в бите переноса и его использование при сдвиге,
- более экономное использование регистров, продиктованное нежеланием порождать лишние пары push/pop, и связанный с этим порядок чтения/записи переменных и некоторые ручные оптимизации алгоритма. Компилер же тем временем осуществляет "забеги в ширину", исходя из общей стратегии "прочитал - выполнил_регистровые_операции - записал".
Так что на вопрос, где искать исчезающие байты, ответ прост. smile.gif
singlskv
Цитата(_Pasha @ Dec 30 2008, 12:48) *
C vs ASM (AVR):
...........................
Так что на вопрос, где искать исчезающие байты, ответ прост. smile.gif

Дык с этим никто и не спорит особо,
там где нужно быстро и из-за ограничений С происходит большой оверхед,
конечно отдельные функции пишутся на АСМ.

Как пример, умножение 16бит X 16бит = 32 бит ,
в С оверхед жуткий из-за приведения всего к 32бит.
Rst7
Цитата
в С оверхед жуткий из-за приведения всего к 32бит.


Где?
Код
        RSEG CODE:CODE:NOROOT(1)
//    3 unsigned long mmm(unsigned int a, unsigned int b)
mmm:
//    4 {
//    5   return (unsigned long)a*b;
        CLR     R2
        MUL     R17, R19
        MOVW    R23:R22, R1:R0
        MUL     R16, R18
        MOVW    R21:R20, R1:R0
        MUL     R17, R18
        ADD     R21, R0
        ADC     R22, R1
        ADC     R23, R2
        MUL     R19, R16
        ADD     R21, R0
        ADC     R22, R1
        ADC     R23, R2
        MOVW    R17:R16, R21:R20
        MOVW    R19:R18, R23:R22
        RET
//    6 }
singlskv
Цитата(Rst7 @ Dec 30 2008, 14:13) *
Где?
IAR в таких случаях действительно оптимизирует,
gcc увы следует стандарту и умножает 32X32
Код
  6a:    0c d0           rcall    .+24     ; 0x84 <__mulsi3>
.................................
00000084 <__mulsi3>:
  84:    62 9f           mul    r22, r18
  86:    d0 01           movw    r26, r0
  88:    73 9f           mul    r23, r19
  8a:    f0 01           movw    r30, r0
  8c:    82 9f           mul    r24, r18
  8e:    e0 0d           add    r30, r0
  90:    f1 1d           adc    r31, r1
  92:    64 9f           mul    r22, r20
  94:    e0 0d           add    r30, r0
  96:    f1 1d           adc    r31, r1
  98:    92 9f           mul    r25, r18
  9a:    f0 0d           add    r31, r0
  9c:    83 9f           mul    r24, r19
  9e:    f0 0d           add    r31, r0
  a0:    74 9f           mul    r23, r20
  a2:    f0 0d           add    r31, r0
  a4:    65 9f           mul    r22, r21
  a6:    f0 0d           add    r31, r0
  a8:    99 27           eor    r25, r25
  aa:    72 9f           mul    r23, r18
  ac:    b0 0d           add    r27, r0
  ae:    e1 1d           adc    r30, r1
  b0:    f9 1f           adc    r31, r25
  b2:    63 9f           mul    r22, r19
  b4:    b0 0d           add    r27, r0
  b6:    e1 1d           adc    r30, r1
  b8:    f9 1f           adc    r31, r25
  ba:    bd 01           movw    r22, r26
  bc:    cf 01           movw    r24, r30
  be:    11 24           eor    r1, r1
  c0:    08 95           ret
_Pasha
Цитата(Rst7 @ Dec 30 2008, 15:13) *
Где?

Вы про IAR, а мы про GCC smile.gif

Вообще-то, если присмотреться, то необходимость сохранения контекста из-за того, что в умножении участвуют аж 11 регистров, сводит к нулю всю борьбу за красоту и скорость. Поэтому, толку от "отдельно стоЯщих правильных умножений" - чуть.
Другое дело, когда их в прерывании штук 10 надо сделать - тогда все красиво. Но асмом...
Rst7
Цитата
IAR в таких случаях действительно оптимизирует,gcc увы следует стандарту и умножает 32X32


Причем тут стандарт? Оба компилятора поступили по стандартую Только оптимизатор иара чутьнамного более умный и понимает, что если мы преобразовали short в long, то два старших байта будут равны 0. А следовательно, результат умножения с этими байтами можно заменить на 0, а затем, рассматривая сложение с 0, банально его (сложение) убирает. Все рады smile.gif

А вообще, хотел ответить в духе "ну и пусть этот гнусь вместе со своими адептами подхода "жрите что дают" убъются апстену", ну будем считать, что сдержался smile.gif
aesok
Цитата(singlskv @ Dec 30 2008, 15:19) *
gcc увы следует стандарту и умножает 32X32


Дело не в стандарте, просто в avr back-end нет инструкций для (s/u)16x(s/u)16=32-умножения. Я смотрел это, в принципе их несложно добавить.

При их наличии может немного возрастать размер кода, но время выполнения уменьшиться.

Анатолий.

Цитата(Rst7 @ Dec 30 2008, 16:17) *
А вообще, хотел ответить в духе "ну и пусть этот гнусь вместе со своими адептами подхода "жрите что дают" убъются апстену", ну будем считать, что сдержался smile.gif


Жрите что дают, не нравиться готовте сами, не умеете платите деньги... Не сдержался.....


Анатолий.
singlskv
Цитата(aesok @ Dec 30 2008, 16:26) *
Дело не в стандарте, просто в avr back-end нет инструкций для (s/u)16x(s/u)16=32-умножения. Я смотрел это, в принципе их несложно добавить.
про стандарт я имел в виду что gcc делает строго по стандарту, те "обязан"
при таком обращении преобразовать к 32бит.

На самом деле, ИМХО, стоило бы просто добавить в libc набор функций(частично инлайн)"
16x8=32
16x16=32
24x8=32
32/8=32
32/16=16
24/8=24
24/16=16
итд.
aesok
Цитата(singlskv @ Dec 30 2008, 16:49) *
про стандарт я имел в виду что gcc делает строго по стандарту, те "обязан"
при таком обращении преобразовать к 32бит.


В GCC имеется полный набор шаблонов инструкций для описания 32 битных
операций умножения 'mulsi3', `ssmulsi3', `usmulsi3', где 'si' означеает
single integer (или 32-бит) mode 's' и 'u' signed/unsigned. Также есть набор
шаблонов для 16x16=32 бит умножения `mulhisi3', `umulhisi3', `usmulhisi3',
где 'hi' half integer (16-бит) mode размерность операндов и 'si" mode размерность
результата.

Так как последние не реализованы для avr платформы, то компилятор всегда
использует 32-битное умножение для 16- и 32-битных операндов, если необходим
32-битный результат.

Добавить эти инструкции несложно, при этом добаляются функции __mulhisi3,
__ssmulhisi3 __sumulhisi3, Но может оказаться так что в результирующем коде
вместо 4 вызовов функции __mulsi3, будет по одному вызову __mulsi3,
__mulhisi3, __ssmulhisi3 __sumulhisi3 при этом размер кода возрастет. Но все
равно в большинстве случаях должен быть выигрыш и в размере кода тоже, не
только в скорости.

Анатолий.
singlskv
Цитата(aesok @ Dec 30 2008, 17:35) *
Так как последние не реализованы для avr платформы, то компилятор всегда
использует 32-битное умножение для 16- и 32-битных операндов, если необходим
32-битный результат.
дык это все понятно, просто ИМХО, если нет реализации для avr платформы,
то можно было бы их просто в libc прописать...
ну и добавить типа 24/8=16 итд, что бывает очень актуально для авр...

усилий то для этого минимум, а в результате не нужно самописные модули организовывать.
Огурцов
Цитата(aesok @ Dec 26 2008, 07:13) *
Для этого нужно перекомпилировать под свой проект crtXXXX.o.


Пытался добавить в проект разные crt*.S компилит с ошибками типа

"stdint.h:116: Error: unknown opcode `typedef'"

В файле stdint.h такая строка:

typedef int int8_t __attribute__((__mode__(__QI__)));

Если не включать avr/io.h тогда в принципе собирается, но нужно либо самому все дефайнить, либо убирать большую часть crt*.S, ни то и ни другое не подходит. Так как правильно скомпилить crt*.S ?
ReAl
Цитата(Огурцов @ Dec 31 2008, 09:40) *
Пытался добавить в проект разные crt*.S компилит с ошибками типа

"stdint.h:116: Error: unknown opcode `typedef'"
...
Так как правильно скомпилить crt*.S ?

Да должно быть так же, как и остальные .S файлы:
Код
AS    := avr-gcc -x assembler-with-cpp

И по разбросанным по .h- файлам #ifndef __ASSEMBLER__ лишнее изымается (не из всех, в wdt.h, кажется, остаются лишние чисто С-шные вещи, но для crt должно хватать)
_Pasha
Цитата(Огурцов @ Dec 31 2008, 11:40) *
Если не включать avr/io.h тогда в принципе собирается

С оригинальным avr/io.h такого нету - он за собой stdint.h не цепляет при вызове из асма. Переставьте WinAVR
Огурцов
Цепляет, он там косвенно, через полдюжины #include цепляет. Пришлось сделать две вещи - включить common.h в gcrt1.S (после! #include "macros.inc") и добавить -D__ASSEMBLER__ к gcrt1.S.

gcrt1.o: ../Avr-libc/gcrt1.S
$(CC) $(INCLUDES) $(ASMFLAGS) -c -D__ASSEMBLER__ $<

хотя -x assembler-with-cpp были уже добавлены:

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

На мой взгляд как-то все еще не очень красиво, но таки уже компилится. Размер 1986, при том, что добавлены новые фичи - мультизагрузка всех устройств на шине, не взирая на серийник, и режим симуляции записи.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.