Явное преобразование типов в IAR, Тупой вопрос Опции

[Still Enemy]

У меня вопрос, связанный с противоположными взглядами на действительность IAR'a и моими: есть массив из 2 элементов{0x3f,0xff} типа uint8_t, при явном преобразовании (*uint16_t), у меня выходит, что конечный указатель указывает на ячейку памяти, значение которой 0xff3f. Как так то? Что за дичь то?

[mempfis_]

У меня вопрос, связанный с противоположными взглядами на действительность IAR'a и моими: есть массив из 2 элементов{0x3f,0xff} типа uint8_t, при явном преобразовании (*uint16_t), у меня выходит, что конечный указатель указывает на ячейку памяти, значение которой 0xff3f. Как так то? Что за дичь то?

Длинные переменные в памяти хранятся от младшего байта к старшему в порядке возрастания адреса. Например int var = 0x0000ff3f будет хранится в памяти условно в виде массива buf[] = {0x3f, 0xff, 0x00, 0x00};
Соответственно
*((unsigned short*) (buff+0)) == 0xff3f
*((unsigned short*) (buff+1)) == 0x00ff
*((unsigned short*) (buff+2)) == 0x0000

IAR в зависимости от типа указателя возмёт требуемое кол-во байт данных и соберёт их переменную используя для младшего байта данные по младшему адресу, для старшего - по старшему.
Это всё прекрасно видно при отладке в IAR если посмотреть на то, как переменная располагается в памяти и модифицируется при манипуляциях с нею.

[esaulenka]

Что за дичь то?

Вот тут написано чуть подробнее: википедия. С одним, правда, исключением - ядро ARM в теории поддерживает оба порядка байт, но на практике (в кремнии) реализуют только little endian.

*((unsigned short*) (buff+0)) == 0xff3f
*((unsigned short*) (buff+1)) == 0x00ff
*((unsigned short*) (buff+2)) == 0x0000

А вот это, в общем случае, плохо. Не каждый процессор умеет читать переменные длиной 2 байта с нечётного адреса. ARM7, например, от такого кода сломается.

[jcxz]

Длинные переменные в памяти хранятся от младшего байта к старшему в порядке возрастания адреса.

Необязательно. Процессорозависимо.

[toweroff]

ядро ARM в теории поддерживает оба порядка байт, но на практике (в кремнии) реализуют только little endian.

насколько помню, CM3 от NXP укладывал как little endian, а когда начал разбираться с STM32F0 - он укладывает как big endian (во всяком случае, вектора выглядели именно так, если смотреть дамп)

чуть попозже еще раз проверю

[mempfis_]

Необязательно. Процессорозависимо.

Топикстартеру уже дали ссылку, где описана разница между big и little endian.
В IAR в настройках проекта во вкладке general options/target есть возможность выбора endian.
Например при явном указании процессора с ядром CORTEX-M0 (MKL15Z128, LPC11C24) big endian не допустим вообще. Но если просто выбрать ядро CORTEX-M0 - то выбор big endian становиться активным. А вот CORTEX-M3 (LPC1754) всегда позволяет выбрать тип endian.

насколько помню, CM3 от NXP укладывал как little endian, а когда начал разбираться с STM32F0 - он укладывает как big endian (во всяком случае, вектора выглядели именно так, если смотреть дамп)

Посмотрел в проекте для STM32F10x - там по умолчанию стоит галочка little endian и есть возможность выбора big.

[esaulenka]

А вот CORTEX-M3 (LPC1754) всегда позволяет выбрать тип endian.

Ну уж раз галка есть, то, конечно же, так тому и быть.
Неважно, что в user manual NXP-шники пишут:

34.3.1.5 Data types
The processor:
• supports the following data types:
– 32-bit words
– 16-bit halfwords
– 8-bit bytes
• supports 64-bit data transfer instructions.
• manages all data memory accesses as little-endian. See Section 34.3.2.1.

Посмотрел в проекте для STM32F10x - там по умолчанию стоит галочка little endian и есть возможность выбора big.

Не, ну как тут с галкой-то поспорить?! Документация заведомо в проигрыше...
Reference manual от STM32F030

2.2 Memory organization
2.2.1 Introduction
Program memory, data memory, registers and I/O ports are organized within the same linear 4-Gbyte address space.
The bytes are coded in memory in Little Endian format. The lowest numbered byte in a word is considered the word’s least significant byte and the highest numbered byte the most significant.

[Still Enemy]

Всем спасибо. Все свободны))