WinAVR продолжение :) - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: WinAVR продолжение :)
Привет Dmitry!

29 Sep 05 08:56, Dmitry Orlov писал Alexander Panasovsky:

 AP>>  есть переменная типа uint16_t, необходимо выкусить из нее
 AP>> первые 8бит

 AP>> Может кто знает как это сделать?

 DO> Разделить на 256.

    Это даст 8 _старших_, а не 8 _первых_ бит.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Слепой Пью, Глухой Ем...

WinAVR продолжение :)
Thu Sep 29 2005 13:05, Alex Mogilnikov wrote to Dmitry Orlov:

 AP>>>  есть переменная типа uint16_t, необходимо выкусить из нее
 AP>>> первые 8бит

 AP>>> Может кто знает как это сделать?

 DO>> Разделить на 256.

 AM>     Это даст 8 _старших_, а не 8 _первых_ бит.

если для uint16_t 8 старших и 8 первых бит не одно и то же, то
можно услышать определение 8 первых бит?


WinAVR продолжение :)
Привет, *Andy*!

/четверг, 29  сентября 2005/ *Andy Mozzhevilov* писал(а) к *Alex Mogilnikov*
по поводу *WinAVR продолжение :):*

[кусь]
 AM> если для uint16_t 8 старших и 8 первых бит не одно и то же, то
 AM> можно услышать определение 8 первых бит?

Кстати, возможно я тупой.
Но я тоже подумал вначале, что первые - это *младшие*.
Поэтому, ИМО, безопаснее говорить "старший" и "младший" байт. ;)

--
Всего наилучшего,
Андрей.

We've slightly trimmed the long signature. Click to see the full one.
WinAVR продолжение :)
Привет Andy!

29 Sep 05 12:35, Andy Mozzhevilov писал Alex Mogilnikov:

 AM>>     Это даст 8 _старших_, а не 8 _первых_ бит.

 AM> если для uint16_t 8 старших и 8 первых бит не одно и то же, то
 AM> можно услышать определение 8 первых бит?

    Я понимаю это как октет с меньшим адресом. Hапример, если переменная
разположена по вдресу 0x1234, то первые 8 бит - это октет по адресу 0x1234, а
вторые - октет по адресу 0x1235. А будут эти биты в числе младшими или старшими
- другой вопрос, действительно зависящий от роста индейцев.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Мы не можем ждать почты от аплинка. Взять ее у него - наша задача.

Re: WinAVR продолжение :)
Quoted text here. Click to load it
Hе, WinAVR тупит, подставляет лишнюю загрузку и очистку старшего байта:
 b = a/256;
 a2c: 89 81        ldd r24, Y+1 ; 0x01
 a2e: 9a 81        ldd r25, Y+2 ; 0x02
 a30: 89 2f        mov r24, r25
 a32: 99 27        eor r25, r25
 a34: 8b 83        std Y+3, r24 ; 0x03

Так же он поступает для моего первого варианта. В случае с union все
делается как надо, просто берется соответствующий байт.

 b = a.BYTE.HI;
 a2c: 8a 81        ldd r24, Y+2 ; 0x02
 a2e: 8b 83        std Y+3, r24 ; 0x03

Через указатель тоже получается нормальный машинный код, но исходный, скажем
прямо, не для меня:
b = (U8)*(((U8*)(&a))+1);
 a2c:   8a 81           ldd     r24, Y+2        ; 0x02
 a2e:   8b 83           std     Y+3, r24        ; 0x03

Денис.



Re: WinAVR продолжение :)
Thu Sep 29 2005 19:29, Dennis Opanasenko wrote to All:

 >> bar = var/256;
 >> не эфективен? PICC просто подставляет старший байт.

 DO> Hе, WinAVR тупит, подставляет лишнюю загрузку и очистку старшего байта:
 DO>  b = a/256;
 DO>  a2c: 89 81        ldd r24, Y+1 ; 0x01
 DO>  a2e: 9a 81        ldd r25, Y+2 ; 0x02
 DO>  a30: 89 2f        mov r24, r25
 DO>  a32: 99 27        eor r25, r25
 DO>  a34: 8b 83        std Y+3, r24 ; 0x03

Ну дык тип данных по-умолчанию в языке Си - int. Если нужен другой тип, нужно
указать это явно.

С уважением, Денис


Re: WinAVR продолжение :)
Hello, Dennis Opanasenko!
You wrote in conference fido7.ru.embedded to All on Thu, 29 Sep 2005 18:29:00
+0400:

 >> bar = var/256;
 >> не эфективен? PICC просто подставляет старший байт.

 DO> Hе, WinAVR тупит, подставляет лишнюю загрузку и очистку
 DO> старшего байта:  b = a/256;

А если b = (u8)(a/256) ?


 DO> Так же он поступает для моего первого варианта. В случае с
 DO> union все  делается как надо, просто берется соответствующий
 DO> байт.

Ну это-то понятно, но я недолюбливаю эти трюки.

dima
http://www.dorlov.no-ip.com


WinAVR продолжение :)
Hello Dennis.

Thu Sep 29 2005 19:29, Dennis Opanasenko wrote to All:

 DO> Hе, WinAVR тупит, подставляет лишнюю загрузку и очистку старшего
 DO> байта: b = a/256;
 DO>  a2c: 89 81        ldd r24, Y+1 ; 0x01
 DO>  a2e: 9a 81        ldd r25, Y+2 ; 0x02
 DO>  a30: 89 2f        mov r24, r25
 DO>  a32: 99 27        eor r25, r25
 DO>  a34: 8b 83        std Y+3, r24 ; 0x03

То ли дело IAR (4.10):

      6          unsigned int  UI;
      7          unsigned char UC;
      8
      9              UI = PINE+100;
   \   00000000   B101               IN      R16, 0x01
   \   00000002   E010               LDI     R17, 0
   \   00000004   590C               SUBI    R16, 156
   \   00000006   4F1F               SBCI    R17, 255
     10
     11              UC = UI >> 8;
     12
     13              PORTA = UC;
   \   00000008   BB1B               OUT     0x1B, R17


А без ввода-вывода он вообще всё нафиг выкидывал. :)


Dimmy.


Re: WinAVR продолжение :)
Thu Sep 29 2005 19:29, Dennis Opanasenko wrote to All:

 >> bar = var/256;
 >> не эфективен? PICC просто подставляет старший байт.

 DO> Hе, WinAVR тупит, подставляет лишнюю загрузку и очистку старшего байта:

"Premature optimization is the root of all evil" (c) Knuth

Hе надо оптимизировать отдельные операции просто из любви к искусству,
надо оптимизировать алгоритм в целом и то только при необходимости.


Re: WinAVR продолжение :)
Quoted text here. Click to load it

Это несколько другое. Дорогих операций лучше избегать.

Денис.



Re: WinAVR продолжение :)
Tue Oct 04 2005 10:55, Dennis Opanasenko wrote to All:

 >> Hе надо оптимизировать отдельные операции просто из любви к искусству,
 >> надо оптимизировать алгоритм в целом и то только при необходимости.

 DO> Это несколько другое. Дорогих операций лучше избегать.

Бессмысленно говорить что некоторые операции "дорогие" пока не проанализирован
алгоритм в целом.


Re: WinAVR продолжение :)
Quoted text here. Click to load it
Это не оптимизация, это вопрос эффективного кодирования. Заниматься этим
после написания/отладки кода несколько странно.

Денис.



Re: WinAVR продолжение :)
Thu Oct 06 2005 11:03, Dennis Opanasenko wrote to All:

 >> >> Hе надо оптимизировать отдельные операции просто из любви к искусству,
 >> >> надо оптимизировать алгоритм в целом и то только при необходимости.
 >> DO> Это несколько другое. Дорогих операций лучше избегать.
 >> Бессмысленно говорить что некоторые операции "дорогие" пока не
 >> проанализирован
 >> алгоритм в целом.

 DO> Это не оптимизация, это вопрос эффективного кодирования. Заниматься этим
 DO> после написания/отладки кода несколько странно.

"Эффективность кодирования" отдельных операций не имеет смысла в отрыве от
анализа алгоритма в целом.

Какой смысл писать "эффективный код", в неоптимизированном виде занимающий
0.2% памяти и 0.1% процессорного времени?


WinAVR продолжение :)
Hi Yuriy, hope you are having a nice day!


06 Окт 05, Yuriy K wrote to Dennis Opanasenko:

 YK> Какой смысл писать "эффективный код", в неоптимизированном виде
 YK> занимающий 0.2% памяти и 0.1% процессорного времени?

Hеправильно. Известно, что 20% кода исполняются 80% времени. Значит 0.2% -
99.8%. :)

WBR,
    AVB


WinAVR продолжение :)
Привет, Alexey !


 06 Oct 05 , 11:05  Alexey V Bugrov писал к Yuriy K:

YK>> Какой смысл писать "эффективный код", в неоптимизированном виде
YK>> занимающий 0.2% памяти и 0.1% процессорного времени?

AVB> Hеправильно. Известно, что 20% кода исполняются 80% времени. Значит
AVB> 0.2% - 99.8%. :)

(задумчиво глядя на less `ps awx`) Правда иногда этим кодом оказываются
конструкции, изоморфные
label:
halt
jmp label

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Международная туристическая организация Аль-Каида

WinAVR продолжение :)

   Dennis, ты ещё здесь сидишь?


Четверг Октябрь 06 2005 10:03, Dennis Opanasenko wrote to All:

 >> DO> Это несколько другое. Дорогих операций лучше избегать.
 >> Бессмысленно говорить что некоторые операции "дорогие" пока не
 >> проанализирован
 >> алгоритм в целом.
 DO> Это не оптимизация, это вопрос эффективного кодирования. Заниматься
 DO> этим после написания/отладки кода несколько странно.

 Hе всегда. Встречаются задачи, которые непонятно, как решать. Тогда может
быть сперва делаться "экспериментальная" реализация, на ней убеждаются в том,
что "общий алгоритм" решения работает правильно, а потом на основании этого
алгоритма создаётся "рабочая" реализация, в которой "вылизывается" как сам
алгоритм решения, так и код...


                                                   Георгий


Re: WinAVR продолжение :)
Hello, Alex Mogilnikov!
You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 29 Sep 2005
12:05:13
+0400:

 AM> Привет Dmitry!

 AM> 29 Sep 05 08:56, Dmitry Orlov писал Alexander Panasovsky:

 AP>>>  есть переменная типа uint16_t, необходимо выкусить из нее
 AP>>> первые 8бит

 AP>>> Может кто знает как это сделать?

 DO>> Разделить на 256.

 AM>     Это даст 8 _старших_, а не 8 _первых_ бит.


Это не одно и тоже? Первый байт еще зависит от LE/BE, но первый бит, вроде как
всегда старший.

dima
http://www.dorlov.no-ip.com


Re: WinAVR продолжение :)
Hello Andrey.

Thu Sep 29 2005 08:03, Andrey Solomatov wrote to Alexander Panasovsky:

 AS> data = *(((*UInt8_t)(&raw)) + 1);
 AS> // или
 AS> data = ((*UInt8_t)(&raw))[1];

Жуть какая.  Вот из-за таких конструкций у меня и сложилось предубеждение
против C. :)

Кстати, нормальный оптимизирующий компилятор, вроде IAR-овского, правильно
воспринимает сдвиги на 8.  Hапример, для MSP430:

//  unsigned int  UI;
//  unsigned char UC;

//  UI = P1IN+300;
    MOV.B   &0x20, R10
    ADD.W   #0x12c, R10

//  UC = UI >> 8;
    SWPB    R10
    AND.B   #0xff, R10

 AS> Правда вариант с объединением наверное будет эффективнее.

Вряд ли, там ведь лишнее присваивание... Хотя, от оптимизации зависит.

Hо корректнее и понятнее будет написать что-то вроде

typedef  unsigned int    word;
typedef  unsigned char   byte;

#define HIGH_BYTE(xw)  (byte)((word)(xw) >> 8)
#define LOW_BYTE(xw)   (byte)((word)(xw) & 0xFF)

Конечно, это для случая 16-битного int.


Dimmy.


Re: WinAVR продолжение :)
Quoted text here. Click to load it
Тут еще сильно зависит от построения программы имхо. Такие вещи очень часто
требуются в функции навроде
void foobar(void)
{
    BW bw;
    bw.WORD = MySuperSensor;
    MySuperLCD = Convert2HumanReadable(bw.BYTE.HI);
}
Все это очень эффективно оптимизируется, так что лишних присваиваний нет.


Денис.



Re: WinAVR продолжение :)
Hello Andrey.

Thu Sep 29 2005 13:37, Andrey Solomatov wrote to Alex Mogilnikov:

 AM>> Оба выражения синтаксически некорректны.

 AS> Ага. СинтАксис у Си такой, что провоцирует ошибки.

Так не надо на провокации поддаваться.  Hе в смысле "не делать ошибок" :), а не
использовать write-only фичи и криптографический стиль.


Dimmy.


Site Timeline