как на С (АВР) лучше скомпоновать 4 байта в long ? («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

как на С (АВР) лучше скомпоновать 4 байта в long ?

Отправлено ыфефт 22 марта 2007 г. 16:34

делаю так :

part_info->sectors = ((uint32_t)buf[35] << 24) | ((uint32_t)buf[34] << 16) | ((uint32_t)buf[33] << 8) | ((uint32_t)buf[32]);

получается страшное :

69e: 83 a1 ldd r24, Z+35 ; 0x23
6a0: 99 27 eor r25, r25
6a2: aa 27 eor r26, r26
6a4: bb 27 eor r27, r27
6a6: b8 2f mov r27, r24
6a8: aa 27 eor r26, r26
6aa: 99 27 eor r25, r25
6ac: 88 27 eor r24, r24
6ae: 22 a1 ldd r18, Z+34 ; 0x22
6b0: 33 27 eor r19, r19
6b2: 44 27 eor r20, r20
6b4: 55 27 eor r21, r21
6b6: a9 01 movw r20, r18
6b8: 33 27 eor r19, r19
6ba: 22 27 eor r18, r18
6bc: 82 2b or r24, r18
6be: 93 2b or r25, r19
6c0: a4 2b or r26, r20
6c2: b5 2b or r27, r21
6c4: 21 a1 ldd r18, Z+33 ; 0x21
6c6: 33 27 eor r19, r19
6c8: 44 27 eor r20, r20
6ca: 55 27 eor r21, r21
6cc: 54 2f mov r21, r20
6ce: 43 2f mov r20, r19
6d0: 32 2f mov r19, r18
6d2: 22 27 eor r18, r18
6d4: 82 2b or r24, r18
6d6: 93 2b or r25, r19
6d8: a4 2b or r26, r20
6da: b5 2b or r27, r21
6dc: 20 a1 ldd r18, Z+32 ; 0x20
6de: 33 27 eor r19, r19
6e0: 44 27 eor r20, r20
6e2: 55 27 eor r21, r21
6e4: 82 2b or r24, r18
6e6: 93 2b or r25, r19
6e8: a4 2b or r26, r20
6ea: b5 2b or r27, r21
6ec: 8c 83 std Y+4, r24 ; 0x04
6ee: 9d 83 std Y+5, r25 ; 0x05
6f0: ae 83 std Y+6, r26 ; 0x06
6f2: bf 83 std Y+7, r27 ; 0x07

Составить ответ | Вернуться на конференцию

Ответы

еще так : part_info->sectors = (((((buf[35] << 8) | buf[34]) << 8) | buf[33]) << 8) | buf[32]; — ыфефт (22.03.2007 18:29:38 194.187.229.9, 738 байт)
- Тут грех обвинять компилятор - через union ни одной лишней команды ! Ведь есть правило, что-то вроде : типы данных и обьектов, а также действия над ними надо описывать как можно более естественно. — Юрий_СВ (22.03.2007 19:51:11 91.124.108.186, пустое)
- нда, фигню нагенерировало — ыфефт (22.03.2007 19:42:8 194.187.229.9, пустое)
Используй union, а если в long порядок расположнния байт волнует (ногами вперед, или наоборот) - поставь селектор через #define #if #else #endif. Порядков расположения всего два для всех известных процессоров и особенностей С- компиляторов (последнее для 8-битников). — Щ.C. (22.03.2007 17:46:16 144.206.186.102, пустое)
Может, так: — K A A (22.03.2007 16:49:4 213.132.80.164, 203 байт)
- Нет, кажется не будет переносимости — K A A (22.03.2007 17:00:23 213.132.80.164, пустое)
- А вообще, если так уж важна переносимость, лучше определить #define BIG_ENDIAN и сделать условную компиляцию для того и другого варианта. Или макрос написать. Универсальное - не оптимально — K A A (22.03.2007 16:51:58 213.132.80.164, пустое)
А что это за компилятор ? Такие чудеса только в Softune WorkBench (под Fujitsu MB90) умеет делать :) — Юрий_СВ (22.03.2007 16:46:15 91.124.108.186, пустое)
- WinAVR 2006.04.21, OPT = S — ыфефт (22.03.2007 16:47:56 194.187.229.9, пустое)
  - Хороший компилятор. С union всё получается отлично >> — Юрий_СВ (22.03.2007 17:09:15 91.124.108.186, 340 байт)
    - Это присваивание из union в long //part_info =un.lll; // — Юрий_СВ (22.03.2007 17:11:15 91.124.108.186, пустое)
П*здец не лечится :)) — =AVR= (22.03.2007 16:42:57 80.92.96.19, пустое)
- Это надо прямиком на форум rsdn.ru засылать — Codavr (22.03.2007 16:49:28 213.187.126.26, пустое)
оптимизация в off что-ли? — NickViz (22.03.2007 16:40:52 87.244.186.66, 386 байт)
- оптимизация OPT = s, сейчас сделал так : part_info->sectors = *(uint32_t *)(&buf[32]); , но так могут быть проблемы с big/little endian и выравниванием данных по адресам... — ыфефт (22.03.2007 16:44:54 194.187.229.9, пустое)
  - Да надуманные эти проблемы, с большими и маленькими концами. — -=ВН=- (22.03.2007 16:47:50 193.125.71.140, пустое)
    - возможно. AVR, x86 - little endian, а PIC, MSP, ARM - ? — ыфефт (22.03.2007 16:52:12 194.187.229.9, пустое)
      - Тем более надуманная. Хотя бы потому, что у MSP конец совершенно маленький, причем в пределах 16-ти разрядов он железно маленький . А выше 16-ти его компилятор маленьким делает. Т.е. реальных проблем у Вас ним нет, Вы их выдумали. — -=ВН=- (22.03.2007 17:03:58 193.125.71.140, 106 байт)
        
        "Не бей яйцА с тупого конца!" :)) — =AVR= (22.03.2007 17:08:41 80.92.96.19, пустое)
      - PIC и AVR - ни Little, ни Big - ну нету у них концов, поелику нету команд обращений к таким данным, которые длиннее байта. Матчасть надо учить, а не компиляторы насиловать — =AVR=   (22.03.2007 17:01:58 80.92.96.19, пустое)
        
        Хорошо, тогда научи как объяснить Кейлу, что для 51-го тоже нет концов. А то он, такой нехороший, хранит числа в памяти как большие индейцы. — vmp   (22.03.2007 18:57:16 87.245.155.195, пустое)
        
        Я что-то не знаю таких МК - "Кейл". И "Лйек" тоже :)) — =AVR=   (22.03.2007 19:34:21 80.92.96.19, пустое)
        
        Ну а вдруг какой-нибудь Лйек сделал 51-му маленький конец, в пику Кейлу? Если бы наши Лйек или Кейл попытались бы сменить ориентацию концов у 430-го, например, то потерпели бы неизбежный финансовый убыток, навсегда бы отбивший у них охоту к таким экспериментам. А с маленькими безобидными 8-ми битниками конечно можно извращаться как бог на душу положит.Они за себя постоять не могут. Вот Кейл и извернулся. — -=ВН=-   (22.03.2007 19:21:24 193.125.71.140, пустое)
        
        Ну есть такой маленький конец у Яра-51. Только вот код он генерит намного хуже. — vmp   (22.03.2007 20:24:54 83.167.112.204, пустое)
        
        Ну это уж другой вопрос. В данном случае качество кода от конца не зависит, да и довольно субъективно оценивается:-) Не освоился Яр, не освоился он с 51-м:-) Я когда с 51 работал, то писал практически все время на ассемблере (фирмы 2500AD), при этом использовал 51 в его малоконцовой ипостаси, при этом у меня есть полная уверенность, экспериментально подтвержденная, что код сгенерированный мной сушшшественно лучше кода Кейла:-)) — -=ВН=-   (22.03.2007 20:47:37 193.125.71.140, пустое)
        
        MOVW :) — Codavr   (22.03.2007 17:27:45 213.187.126.26, пустое)
        
        Это регистры - про них нет речи. Я про ЧЕСТНОЕ ОЗУ, которое с 0х60 — =AVR=   (22.03.2007 19:33:20 80.92.96.19, пустое)
    - вполне реальные, хотя и лечатся =) — DASM (22.03.2007 16:51:22 212.58.192.14, пустое)
      - Лечить что-либо принято при болезни, а не вместо болезни --> — =AVR= (22.03.2007 17:04:1 80.92.96.19, пустое, ссылка)
про union прочти — pau62 (22.03.2007 16:37:42 88.86.64.165, пустое)
- это понятно, но что делать на big/little endian процессорах - данные читаются из бут-сектора, тут важна последовательность байтов — ыфефт (22.03.2007 16:41:20 194.187.229.9, 518 байт)
  - а куда последовательность денется? объявить лонг и массив[4] — pau62 (22.03.2007 16:54:24 88.86.64.165, пустое)