формат хранения данных в KEIL C51, нафига данные задом наперед :) Опции

[nik_al]

Как вещь мне в кейле не нравится(может быть единственная) этот самый формат. Приходит ко мне пакет где данные лежат INTEL формате т.е. 1й байт младший и читаю я из этого пакета в переменную типа ulong вот таки некрасивым способом:

ULONG(ltemp).b[3]=rxbuf[0];
ULONG(ltemp).b[2]=rxbuf[1];
ULONG(ltemp).b[1]=rxbuf[2];
ULONG(ltemp).b[0]=rxbuf[3];

макрос:
//-----------------------------------------------------
// Type for treating 4 byte variables with byte by byte
//-----------------------------------------------------
typedef union _un_long {
unsigned long dw;
unsigned char b[4];
}un_long;

#define ULONG(x) (*((un_long*)&x))
У кого есть другие способы решения этой проблемы поделитесь пожлста

[bialix]

Под GCC есть макросы для переворота байтов, определtны в заголовке byteswap.h

[savikon]

я поступал еще некрасивее:
unsigned long lOutWord _at_ 0x20;
unsigned char cOutWord0 _at_ 0x23;
unsigned char cOutWord1 _at_ 0x22;
unsigned char cOutWord2 _at_ 0x21;
unsigned char cOutWord3 _at_ 0x20;
и получал от кейла четыре ругательства<img>

[Andy Great]

Сдвиги на 0,8,16,24 компилятор должен прооптимизировать в присваивания.

[zltigo]

Приходит ко мне пакет где данные лежат INTEL формате т.е. 1й байт младший

Ну это неправильно - в нормальных протоколах данные в машинозависимых форматах ходить не должны :-).
Ну а для разворота - классика жанра htons() "Host to Network Short" и htonl() "Host to Network Long" может существовать в поставке, как минимум реализован в виде макросов:

Код

#define htons(p)  ( *(p) = (*(p) << 8) | (*(p) >> 8))
#define htonl(p)  ( htons (&((unsigned short*)(p))[0]), \
                     htons (&((unsigned short*)(p))[1]), \
                     *(p) = (*(p) << 16) | (*(p) >> 16) )

[evg123]

В этом есть какой-то скрытый смысл. Я натыкался на объяснение, счел его разумным, и потом сразу забыл ! Но пользуюсь вегда стадартными сдвигами и встроенными функциями типа _irol()_, _iror()_ и никогда не имел проблем. Вообще, в машинно-зависимые свойства компиляторов лучше не лезть.

Сдвиги на 0,8,16,24 компилятор должен прооптимизировать в присваивания.

Кстати да! Он великолепно оптимизирует!

[savikon]

Сдвиги на 0,8,16,24 компилятор должен прооптимизировать в присваивания.

а на 7 оптимизирует в 7 сдвигов всех 32-х разрядов<img> и приходится вручную переставлять байты и сдвигать только один раз