caxapa.ru :: IAR ARM7

MegaJohn (07.09.2012 10:50, просмотров: 7213)

IAR ARM7 char a[10] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A}; unsigned int tst = 0; tst = *(unsigned int*)(&a[6]); у коллеги получается tst = 0x05040706 а нужно 0x09080706. Как бы корректно получить не ковыряясь с каждым байтом ?!

Ответить

- НИКАК. За такой код в 1937 расстреливали. На вменяемом CPU сразу исключение: "Программист допустил недопустимую ошибку и будет уволен". - fk0(07.09.2012 15:58)
  - это пик чтоли вменяемый? - Mahagam(07.09.2012 16:01)
- добавил ссылок. ARM7 ~~вроде как~~ не умеет обращаться к невыровненной памяти. кортексы вроде уже умеют. Mahagam(419 знак., 07.09.2012 11:14 - 11:20, ссылка, ссылка)
  - было бы понятно, если б было что то вроде Атмег(537 знак., 07.09.2012 11:57)
    - мои ссылки вы не открывали. - Mahagam(07.09.2012 12:09)
    - "если уж компилер "съел" такую конструкцию, он должен ее правильно реализовать, используя LDRB". Не верно. SciFi(241 знак., 07.09.2012 12:04)
      - компилятор же, оптимизируя, видит, выровнен ли адрес. должен или разворачивать через LDRB, или LDR если выровнено - Атмег(07.09.2012 12:20)
        
        А если не видит? И не имеет возможности видеть? Я в этом примере тоже не вижу: Inst выравнен или нет. Так шта не нада, всё он правильно делает. - SciFi(07.09.2012 12:24)
- Коллега что-то забористое курит, наверное. Как может получиться 0x05040706? К тому же у вас массив из 10 элементов инициализирован 11 числами. Компилятор не ругается? Что ещё переврали в этом примере? - SciFi(07.09.2012 10:59)
  - Все правильно. Получилось потому что он привел к типу int *. В школу. - Vladimir Ljaschko(07.09.2012 11:03)
    - потому что ARM7. В школу. - Mahagam(07.09.2012 11:26)
      - Может быть. Я, в силу своей тупости, обрабатываю в подобных местах ~~в столбик~~ побайтно. - Vladimir Ljaschko(07.09.2012 11:29)
        
        это надёжно, но покурить мануал на ядро все равно не помешает. с портируемостью, конечно, возникнут проблемы. - Mahagam(07.09.2012 11:34)
    - Всё равно порядок байтов какой-то чудной. Как будто внешняя память с глючным интерфейсом. - SciFi(07.09.2012 11:12)
      - внутренняя. не (int*), а *(int*). - Атмег(07.09.2012 11:20)
        
        Mahagam дал ссылки выше: "The behaviour of unaligned data loads and stores depends on the implementation ('unpredictable')." Результат операции - мусор, и анализировать его нет смысла. - SciFi(07.09.2012 11:29)
  - возможно причуды невыровненнго доступа. - amx(07.09.2012 11:02)
    - вопрос, имеется выравненный массив, хочется с ЛЮБОЙ позиции получить 4 байта как инт. Кроме memcpy есть другие варианты ? Если нет то получается к приведению е инту является не кроссплатформенным ? (на AVR и прочих 6битниках всегда будет корректно) - MegaJohn(07.09.2012 11:07)
      - С любой позиции -- никак. Пользуйся memcpy() -- об этом даже где-то в стандартах сказано. Только за такое использование memcpy(), в случае, если данные выходят за пределы CPU (например, обмен по сети) -- тоже расстреливать нужно. - fk0(07.09.2012 16:00)
      - Приведение указателя к большему размеру никогда не было кроссплатформенно. - amx(07.09.2012 11:10)
        
        если в обоих случаях LE, то должно быть кроссплатформенно. не вижу причин, кроме эндианности - Атмег(07.09.2012 11:22)
        
        ширина шины памяти не важна? - Mahagam(07.09.2012 11:25)
        
        а как влияет ширина шины? если это LE 8битник, ну положит он данные за несколько обращений, но так же - от младшего к старшему - Атмег(07.09.2012 11:34)
        
        КО сообщает, что даже 32-х битник с внешней 8-и битной шиной тоже затратит несколько обращений. и тут дело не столько в ядре, сколько в контроллере памяти. - Mahagam(07.09.2012 11:38)
        
        не могу утверждать 100%нтно, что кроме LE/BE ничего не влияет, но что может влиять пока не пойму - Атмег(07.09.2012 12:01)
        
        у 32-х битника для чтения 32-х бит из 32-х разрядной памяти по выровненной границе нужно одно чтение. из невыровненной - два, и потом склейка полученных данных. этот геморрой на аппаратном уровне в армах просто не поддержали с рождения, в то время Mahagam(380 знак., 07.09.2012 12:08)
  - все что написано это мое, а скриншот его - достоверный - MegaJohn(07.09.2012 11:01)
    - А какие типы у всех замешанных переменных? amx(124 знак., 07.09.2012 11:07)
      - проверялось, расстановка скобок не влияет - Атмег(07.09.2012 11:19)
- memcpy(&tst, &a[6], sizeof tst); - amx(07.09.2012 10:58)
  - +1 тоже так делаю. - AST(07.09.2012 14:17)

ARM, RISC-V контроллеры