在8位平台或32位平台上将uint8_t的元素转换为32位变量

Question

Lets consider two examples

1: 8 bit MCU/MPU/Platform - Little endian

uint8_t arr[5] = {0x1,0x2,0x3,0x4,0x5};//assume &arr[0] == 0x0
uint32_t *ui32 = (uint32_t*)&arr[1];

What is the value of *ui32 ? 0x2030405 ? Is it necessary uint32_t variable to be placed to an address multiple of 4 at this platform?

1: 32 bit MCU/MPU/Platform - Little endian

Pretty much the same example:

uint8_t arr[] = {0x1,0x2,0x3,0x4,0x5, 0x6, 0x7, 0x8}; //again assume &arr[0] == 0x0
uint32_t *ui32 = (uint32_t*)&arr[1];

What is the value of *ui32 ?

I know that 32bit variables should reside in address multiple of 4.

Where I can find specification on this?

Answer 1

Language Lawyering

Your code contains undefined behavior and is non-portable. For example, on some UNIX workstations I've programmed on, memory accesses must be aligned to the size of the operand, so most but not all of the time, attempting to dereference (uint32_t*)&arr[1] would crash the program with SIGBUS , a hardware error caused by the memory bus. The compiler allows you to shoot yourself in the foot like that. Casting a pointer like you did violates the strict aliasing rules of C, which causes undefined behavior .

You can get around this issue by writing uint32_t x; memcpy( &x, &array[1], sizeof(x) ) uint32_t x; memcpy( &x, &array[1], sizeof(x) ) , which the standard explicitly allows. From this point on, I'll be assuming you're doing the equivalent of this. If you were not using an offset into the array, you could also type=pun with fields of a union in C (although the rules are different in C++).

By the standard, the elements of an array must be stored contiguously, with no padding between them. A memcpy() between some object x and an array of unsigned char[sizeof(x)] is legal, and the result is called its object representation .

Copying arbitrary bits to the object representation of any of the exact-width types in <stdint.h> with memcpy() is unspecified behavior , not undefined behavior . It is a well-formed program, and you will get some valid uint32_t out of it, even though the language standard does not say what that has to be. You aren't giving the compiler permission to do whatever it wants, such as Kill All Humans. This is only because the standard does not permit the exact-width integral types to have any bits other than value bits, and therefore, they cannot have trap representations , invalid bit patterns that cause undefined behavior if copied into a value of that type. (The example in the standard is an implementation that stores a parity bit in every word.)

However, the other side of that guarantee is that the types uint8_t and uint32_t are not guaranteed to exist, and there have been a few architectures in the real world for which conforming versions of them could never exist. (However, unsigned char array[sizeof(uint_least32_t) + 1] is guaranteed to work.)

Tl;dr

A real-world little-endian implementation on which that code runs correctly would probably tell you that *u32 is 0x05040302 . Otherwise, we would call it something other than little-endian. However, some compilers put the onus on the programmer to follow the strict-aliasing rules carefully. They are known to produce optimized code that doesn't do what you expect if you write through either pointer.

Answer 2

1: 8 bit MCU/MPU/Platform - Little endian

 uint8_t arr[5] = {0x1,0x2,0x3,0x4,0x5};//assume &arr[0] == 0x0 uint32_t *ui32 = (uint32_t*)&arr[1]; 

What is the value of *ui32 ?

C explicitly declares the effect of reading the value of *ui32 to be undefined in that case, on account of reading the value of an object (part of arr ) via an lvalue of a different type.

0x2030405 ?

It is by no means guaranteed, yet not so uncommon in practice, that the value obtained by reading *ui32 would be that of interpreting the bit pattern comprising elements 1 - 4 of arr as that of a uint32_t , but what number that represents is unspecified. It is left to implementations to determine how to map physical bytes to logical ones.

However, if by "little-endian" you mean that the C implementation's uint32_t is represented by a four-8-bit-byte sequence in least-significant to most-significant order, and if you suppose that dereferencing the pointer indeed does successfully interpret the pointed-to bit pattern as that of a uint32_t , then the resulting value would be the same as that represented by the integer constant 0x05040302u .

Is it necessary uint32_t variable to be placed to an address multiple of 4 at this platform?

You have not specified a platform, nor even a particularly narrow class of platforms. I would generally expect an 8-bit platform not to require 4-byte alignment for objects of type uint32_t , but C does not specify, and platforms and implementations may vary.

1: 32 bit MCU/MPU/Platform - Little endian

Pretty much the same example:

Exactly the same answer, except that it is more likely -- but by no means certain -- that 4-byte alignment would be required for objects of type uint32_t .

I know that 32bit variables should reside in address multiple of 4.

Not necessarily. Some 32-bit platforms indeed do require it; some do not require it, but offer faster access for aligned objects; and some don't care at all.

Where I can find specification on this?

Such details of your C implementation of interest as are available at all would be found in that implementation's documentation. The underlying system's ABI and / or hardware documentation might serve as a secondary source.

Overall, however, the best recommendation is usually to avoid such questions altogether. Avoiding unspecified, implentation-defined, and especially undefined behaviors would allow you to rely wholly on the C standard to predict the behavior of your program.

Answer 3

8 bit MCU/MPU/Platform - Little endian

The answer will assume the platform, somehow, support longer integers even if the CPU might not, and that they are little-endian.

Note that, if a uC is truly 8-bit and has no notion of longer integers, then it does not make much sense to talk about its (byte) endianness. We could say, for instance, that it is both little-endian and big-endian (or that it is not any of those).

 //assume &arr[0] == 0x0 

This may be hinting that this is coming from some exercise about misaligned accesses.

What is the value of *ui32 ? 0x2030405 ? Is it necessary uint32_t variable to be placed to an address multiple of 4 at this platform?

It depends on the platform and on the options of the compiler (eg if the compiler is assuming strict aliasing, then this is undefined behaviour to begin with).

However, since this is a 8-bit platform (and assuming you tell the compiler to do what you seem to want to do), a fair guess is that uint32_t has to be supported in software and that unaligned accesses are not a problem. Assuming the integer is kept in memory as little-endian (as explained above) by that software implementation, then yes, a good guess would be 0x05040302 .

32 bit MCU/MPU/Platform - Little endian What is the value of *ui32 ?

Again, in this case, it would depend on the platform/compiler. In some of them, there wouldn't be any value even, since the CPU would trap when you try to read such an address (since &arr[0] == 0 , ui32 == 1 which is unaligned to eg 4).

I know that 32bit variables should reside in address multiple of 4.

Typically, but depends on the platform. Also, even if a platform supports unaligned accesses, it may be the case that it is slower than aligned accesses (so you want them aligned anyhow).

Where I can find specification on this?

On top of the C specification, you would need to check your compiler's documentation and your architecture's manuals.