Can one not store a value in EAX and read AL and observe endianness? I honestly don’t know and haven’t done such coding for 2 decades.
Endianness, and why I don't like htons(3) and friends
11–15 of 15 posts
Re: Endianness, and why I don't like htons(3) and friends
#12Way back, {hton,ntoh}{s,l,ll} didn't originally use C99 types because they predated stdint. Instead, macros and platform specific-isms were used to choose the right types. As more primitive functions, swap_endian_u{16,32,64,128} are useful to build {hton,ntoh}{s,l,ll}. IEN-137 is wrong and presented it as a false case of bikeshedding. Standardizing network order on little rather than big endian would save energy. The…
depending on the device and instruction set the swap is entirely free, e.g. where it's just a choice of a different load instructions (or the cool arches where you just make an unaligned read, the lsb triggers swapping).
If energy is your concern making arches more energy efficient for swapping is the sensible thing as there are already many protocols and file formats in network order. There is fundamentally no reason for it to have a energy cost at all.
And if you're really concerned about energy, the energy needed to communicate and store bits usually vastly dominates the energy needed to compute on them. On that basis protocols should be using varrious tightly packed / variable length encodings instead.
Re: Endianness, and why I don't like htons(3) and friends
#13I don’t see what makes htons special here. The C standard library is full of functions that return an int that isn’t an integer. For example, printf returns “a nonnegative integer or an error code”, creat returns a file descriptor, mknod returns a Boolean (coded as 0=true, -1=false) and sets errno , but all have return type int . Strong typing historically wasn’t a goal at all in C. K&R C and its predecessors liked e…
This is why the old Borland Turbo C always had you define bool at the beginning. It was also cool with void main(void) but that’s another story.
Everyone can be cool with void main(void) nowadays in C.
https://en.cppreference.com/w/c/language/main_function:
“Every C program coded to run in a hosted execution environment contains the definition (not the prototype) of a function named main, which is the designated start of the program.
int main (void) { body } (1)
int main (int argc, char *argv[]) { body } (2)
/* another implementation-defined signature */ (since C99.) (3)(C++ is a bit more strict. There, main must return an int)
Re: Endianness, and why I don't like htons(3) and friends
#14Can one not store a value in EAX and read AL and observe endianness? I honestly don’t know and haven’t done such coding for 2 decades.
Why though? If you have an eax register, you're in a little endian environment.
Re: Endianness, and why I don't like htons(3) and friends
#15The author is definitely wrong about one thing (probably several, but who's counting):
"There is actually a relatively easy fix: if we insist on reading numbers with the most significant digit on the right (which we do), and the computer insists on storing less significant components first (which it does), these two desires can be reconciled by printing the hex dump from right to left"
If your hex dump was all 32 bit words, it would kinda work, but the addresses would be "swizzled" (03 02 01 00 07 06 05 04, etc. guh!)
But what about hexdump("hello world!") which would become
lleh ow o !dlr