Битовые поля - есть ли способ поменять Little Endian на Big Endian, расположение битов Опции

[sonycman]

Осваиваю тут карты памяти, и возникла нужда поработать со структурами их регистров.
К примеру:

Код

__packed    struct    CID
{
    byte        man_ID:            8;
    byte        oem_ID[2];
    byte        product_name[5];
    byte        revision:        8;
    dword        serial:            32;
    unsigned    :                4;
    word        man_date:        12;
    unsigned    crc:            7;
    unsigned    dummy:            1;
};

Вроде бы всё хорошо, да только данные в такой структуре должны идти линейно сверху вниз - байт 0 - биты 31...24, байт 1 - биты 23...16 и т.д. (big endian).
А компилятор (RealView) считает наоборот - сначала младшие биты (little endian).

То есть читаем слово revision, в регистре должны быть данные вида 0x08070605 [31...0], а на деле имеем 0x05060708...

Есть ли способ побороть такую досадную "однобокость"?
Иначе придётся ручками обрабатывать все битовые сдвиги и маски...

[Rst7]

ARM в базовой реинкарнации - тоже....

Да там один define в HDL. Кстати, т.к. 68k - суть большой индеец, то в моторолловских телефонах ядро ARM собрано именно в BE Так что не такая уж это и редкость

[zltigo]

68k - суть большой индеец...

Вот этот мамот и имелся ввиду в первом посте.

[VslavX]

Еще PowerPC очень неплохо себя в BE чувствуют. Коммуникационные XScale тоже в BE часто используются. На самом деле, какое ядро - не особо важно, определяющим является формат периферии. Я пробовал LE на MPC83xx - лучше не надо, перешел в BE - совсем оно не так страшно оказалось. Если данные правильно типизированы - то при портировании проблем минимум.