Hacker News Reader

Comment by eadmund | Hacker News Reader

> + HPPA's upwards-growing stack

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.

View on HN

> To be honest, I never really understood why more architectures don't have upwards-growing stacks.

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.

“ 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.”

I would expect you to use negative offsets to access the previous elements.

> 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.

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.

On endianness, I'm not making a claim that one or the other is "better" or "right" -- merely that little-endian architectures are pervasive in the current world, and so picking big-endian for a hypothetical new architecture would be unnecessarily forcing it to deal with "this software is buggy on big-endian" issues forever. Which is fine if there is some really strong reason your new architecture should be big-endian; but if it's mere aesthetic preference then the cost probably outweighs the benefit right now.

Stack grows down because it can then potentially use the same as unused heap (which grows from bottom)

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.

Network does have a natural order. You can make a routing decision faster when you get the most significant units first. If you get the least first, you have to wait for the entire address before you can route to it.

Oh cool - I never knew this was the reason why...

Thanks!

This is mostly irrelevant today though; the hardware is so much faster and memory so much more plentiful that handling is done by reading the full header (and often full packet) then making the routing or forwarding decision. You don't need to squeeze out every single cycle or save every single byte possible. You have so much headroom saving cycles or bytes makes no difference and you can't optimize enough to make significant BOM reductions by choosing cheaper chips while still offering features considered standard. Even if you could you'd be selling into an ultra-ultra-cheap market segment no one cares about (congrats, you made a $2 10Mbps router that can run on a coin cell battery).

Huh - I would have thought for higher speed stuff (say 40G+ ?) performance would still be an issue if you wanted to maintain wire speed - Especially driving multiple interfaces ?

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...

That something doesn't make a big improvement doesn't mean that the improvement does not exist.

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.

>>Network has no natural order

"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...

> Hard disagree, big-endian is right and little-endian is wrong. At least, unless you think this year is 2202

Our numbers originate from people using a right-to-left script...

Do they? They came through people who used a right-to-left script (the Arabs). But they originated in India. Did they use right-to-left?

The oldest source [1] seems to be in Sanskrit, a left-to-right language, so they were big-endian numbers. This still does not rule out an even older origin in a right-to-left language, but as it stands I'm afraid I was just wrong with my 'little endian origin' story. Too bad, I liked it.

[1] https://mathshistory.st-andrews.ac.uk/HistTopics/Bakhshali_m...

> Hard disagree, big-endian is right and little-endian is wrong. At least, unless you think this year is 2202.

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"), ...

Reply on news.ycombinator.com