Page 1 of 1
#PB_Compiler constants for Endianness
Posted: Sat Jun 22, 2024 6:56 pm
by benubi
#PB_Compiler_IsBigEndian
#PB_Compiler_IsLittleEndian
Would be great additions for portability/interoperability. I just found out ARM64 and others from the family use little endian per default, but can also switch. I thought mistakenly it would always be big endian.
Re: #PB_Compiler constants for Endianness
Posted: Mon Jun 24, 2024 10:59 am
by r-i-v-e-r
Big endian AArch64 is rare: iOS, Android, Windows, macOS, and most Linux distros run in LE mode on AArch64 hardware. AFAIK, BE is primarily useful for maximising performance of networking code (albeit this is serious min-maxing), but is otherwise mostly a hassle.
Given there's no big endian PureBasic Arm compiler build, we'd need one of those before such constants become useful, and it'd be extremely niche.
Re: #PB_Compiler constants for Endianness
Posted: Mon Jul 08, 2024 12:21 pm
by benubi
Then I was mistaken. I thought that some Mac versions (motorolla and PowerPC) might use Big Endian, and I believed at first the raspberry ARM would be BE. If I understand that correctly there is no big endian PB compiler around, yet?
I've seen "mixed endianness" in some articles, this was concerning GUID's in partition tables (the new types). I wondered what that meant but I suppose that a GUID is or should be a 16 bytes octet stream with "no endianness" per se (that's how I would handle it).
I believe the iso format that CD-ROM/DVD's use is also dual endianness, with addresses+offsets written in both endian versions but I digress.
Thank you for the answer!
Re: #PB_Compiler constants for Endianness
Posted: Mon Jul 08, 2024 2:31 pm
by NicTheQuick
Yes, there is a difference between endianess in memory during runtime and in written data in files or block devices like the partition tables you mentioned.