4 ms·

What architectures would it not be 04 on?

by clarebear123 2y ago

withinboredom 2y ago
(older) ARM (aka, big-endian) it will be 01
- clarebear123 2y ago
  I just ran it on my M2 mac and got 04. Don't compilers typically take endianness into account for things like this anyway?
  - odo1242 2y ago
    No, compilers don’t take endianness into account. (especially not C) You need to use a bit mask in order to make this code endian-independent rather than a pointer alias. Like (uint8_t)(int & 0xFF), or something like that.
  - Panzer04 2y ago
    Why would it do that? You're asking for a raw memory address value.
- Syonyk 2y ago
  You'll have to be a lot more specific than "ARM" - Most newer ARM systems are little endian in practical operation, and ARM has been "flexible endian" (you can switch between big and little endian - SCTLR has the relevant bits to control the accesses on most recent ARM ISAs) for some long while now.
- musicale 2y ago
  IIRC several currently used architectures (e.g. ARM, Power, z/Architecture, RISC-V) can all run in big-endian mode. And in the embedded space I think PowerPC and MIPS are still around.
Syonyk 2y ago
Anything big endian. unsigned int x = 0x01020304; unsigned char *c = (unsigned char*)&x; Assume x is stored at 0x100. On a little endian architecture (x86, most modern ARM systems, etc), it will be stored in memory as [04][03][02][01], from bytes 0x100 to 0x103. If you assign char c to the address of x (0x100), it will read one byte, which is 0x4. However, on a big endian system, that same value would be stored in memory as [01][02][03][04] - so, reading a byte at 0x100 would return 0x1. Older ARM systems were big endian, and there are others that run that way, though it's rarer than it used to be. One of the perks of little endian is that if you want to read a smaller version of a value, you can read from the same address. To read that value as an 8, 16, or 32 bit value, I read at the same address. On a big endian system, I'd have to do more address math to do the same thing. It mostly doesn't matter, but it is nice to be able to have a "read of 8 bits at the address of the variable" do the sane thing and return the low order 8 bits, not the high order bits.
- clarebear123 2y ago
  Do you know if compilers are smart enough to return 04 even on big-endian architectures nowadays? For some reason I'm under the impression that (at least clang and gcc) are able to change this from "first byte in x" to "least significant byte in x" but don't actually know why I think that. Maybe embedded compilers typically don't?
  - Syonyk 2y ago
    No, and it would be wrong for it to do so, because you've given it a very explicit set of instructions about what to do: "Give me the value of the byte of memory at the start of x." To do what you're asking, you'd do something like this: unsigned char c = (unsigned char)x; That will give you the low order byte of x. But to do that, on a big endian system, when you've told it to get you the byte at the base address of x, is simply wrong behavior. At least in C. I can't speak to higher level languages since I don't work in them.
  - deleted 2y ago
    [deleted]
  - 2y ago

What architectures would it not be 04 on?

withinboredom 2y ago

(older) ARM (aka, big-endian) it will be 01

clarebear123 2y ago
I just ran it on my M2 mac and got 04. Don't compilers typically take endianness into account for things like this anyway?
- odo1242 2y ago
  No, compilers don’t take endianness into account. (especially not C) You need to use a bit mask in order to make this code endian-independent rather than a pointer alias. Like (uint8_t)(int & 0xFF), or something like that.
- Panzer04 2y ago
  Why would it do that? You're asking for a raw memory address value.
Syonyk 2y ago
You'll have to be a lot more specific than "ARM" - Most newer ARM systems are little endian in practical operation, and ARM has been "flexible endian" (you can switch between big and little endian - SCTLR has the relevant bits to control the accesses on most recent ARM ISAs) for some long while now.
musicale 2y ago
IIRC several currently used architectures (e.g. ARM, Power, z/Architecture, RISC-V) can all run in big-endian mode. And in the embedded space I think PowerPC and MIPS are still around.

Syonyk 2y ago

Anything big endian. unsigned int x = 0x01020304; unsigned char *c = (unsigned char*)&x; Assume x is stored at 0x100. On a little endian architecture (x86, most modern ARM systems, etc), it will be stored in memory as [04][03][02][01], from bytes 0x100 to 0x103. If you assign char c to the address of x (0x100), it will read one byte, which is 0x4. However, on a big endian system, that same value would be stored in memory as [01][02][03][04] - so, reading a byte at 0x100 would return 0x1. Older ARM systems were big endian, and there are others that run that way, though it's rarer than it used to be. One of the perks of little endian is that if you want to read a smaller version of a value, you can read from the same address. To read that value as an 8, 16, or 32 bit value, I read at the same address. On a big endian system, I'd have to do more address math to do the same thing. It mostly doesn't matter, but it is nice to be able to have a "read of 8 bits at the address of the variable" do the sane thing and return the low order 8 bits, not the high order bits.

clarebear123 2y ago
Do you know if compilers are smart enough to return 04 even on big-endian architectures nowadays? For some reason I'm under the impression that (at least clang and gcc) are able to change this from "first byte in x" to "least significant byte in x" but don't actually know why I think that. Maybe embedded compilers typically don't?
- Syonyk 2y ago
  No, and it would be wrong for it to do so, because you've given it a very explicit set of instructions about what to do: "Give me the value of the byte of memory at the start of x." To do what you're asking, you'd do something like this: unsigned char c = (unsigned char)x; That will give you the low order byte of x. But to do that, on a big endian system, when you've told it to get you the byte at the base address of x, is simply wrong behavior. At least in C. I can't speak to higher level languages since I don't work in them.
- deleted 2y ago
  [deleted]
- 2y ago