A downward-growing stack is more intuitive. To access items on a downward-growing stack, you use positive offsets; for instance, sp+0x10 could be the second stack-passed argument to a function. For an upward-growing stack, you have to use negative offsets.
> Hard disagree, big-endian is right and little-endian is wrong.
Little-endian is more natural. With little-endian numbers, the byte b at offset n has value b*256**n; with big-endian numbers, the byte b at offset n has value b*256**(l-n-1).
> And remember that network byte order is big-endian.
That's mostly by historical accident; the architectures originally used to implement the network protocols we use nowadays were big-endian. It makes sense in some situations to have on-wire numbers be big-endian, especially network addresses, since it allows the hardware to decide before the whole number arrives; that is less relevant nowadays because not only networks are much faster, but also it's more common to read the whole header to a buffer before making these decisions.
Why would one use negative offsets with the stack pointer instead of positive offsets with the base pointer?
Using the stack pointer, I can never dynamically push something onto the stack without changing the offsets.
I would expect you to use negative offsets to access the previous elements.
But then again, HPPA makes it more obvious that stack should be limited size because the above only works for single-threaded processes
Worse things about HPPA is delayed jumps... no wonder they were the ones that partnered with Intel on Itanium.
Network has no natural order (do you start with the last bit?)... for new stuff I'd do the little-endian any way if I cared to bother.
Thanks!
If I wanted to show where ordering truly does not matter, I would rather look at encoding schemes. Some versions of Ethernet use https://en.wikipedia.org/wiki/64b/66b_encoding , meaning that the smallest unit that can be read at once is 8 bytes. That removes the ordering from IPv4 addresses, but IPv6 can still get handled earlier by taking ordering into account.
I agree home/consumer stuff is just basicly coasting on 3-4 generation tech though. I ran cat-6 cable around the house hoping to get 10G sometime in my lifetime for less then the cost of a kidney...
"When the bytes which make up such multi-byte numbers are ordered from most significant byte to least significant byte, that is called "network byte order" or "big endian." (1)
Seems pretty straightforward MSB to LSB? which is what I learned way back in 'C' times...Did something change ?
1) https://datatracker.ietf.org/doc/html/draft-newman-network-b...
Our numbers originate from people using a right-to-left script...
[1] https://mathshistory.st-andrews.ac.uk/HistTopics/Bakhshali_m...
If you think a bit about it, it would have been much more natural to write number in the opposite order compared to what we have now, since we read and manipulate numbers from least-significant digit to most-significant digit and read text left-to-right.
When you read a number like 346624596, you need to parse it twice to know its value, but also to know its magnitude or do anything significant with it. In the opposite order, everything becomes simpler: adding two numbers, knowing the magnitude or ignoring the least-significant digits ("its about 350 millions"), ...
To be honest, I never really understood why more architectures don't have upwards-growing stacks. Visually, one adds things to the top of a stack, after all, so it makes sense to increment the stack pointer. I suppose it's a relic of the old days when folks just set the start of the stack to some remote part of memory and hoped it never grew down into the code or the heap?
> + these days, being big-endian is spending weirdness budget
Hard disagree, big-endian is right and little-endian is wrong. At least, unless you think this year is 2202. I don't know how Intel got this so badly incorrect.
And remember that network byte order is big-endian. Any protocol which emits little-endian bytes on the wire is broken by design.