Hacker News Reader

Comment by TrianguloY | Hacker News Reader

It's easier to understand if your diagram show the starting memory positions (address 0x00000000) at the top, and final positions (address 0xFFFFFFFF) at the bottom. This way the top of the stack is, precisely, at the top.

It doesn't seem to be an standard and there are almost the same number of diagrams with memory from 0 to F than from F to 0. Some of them are more useful in specific contexts, but most are simply drawn the way the author is used to.

Personally I prefer increasing numbers go down, like lines in a file, numbers on a numbered list, timestamp on a log, etc. Having the highest memory value 0xFF on the top seems...odd.

View on HN

> Having the highest memory value 0xFF on the top seems...odd

Dunno ... the highest being on top feels very normal ... . Isn't that more or less the definition of "highest" and "top"?

We have conflicting conventions in all kinds situations:

Numbers increase towards the top in a class Cartesian coordinate system, in the numbering of floors in buildings, on calculator keypads, ...

Numbers increase towards the bottom in coordinate systems in many computer graphics contexts, in numbered lists, on telephone keypads, ...

Sometimes these conventions meet and clash and there is no one right way to handle that.

From a footnote of TFA:

> You may try to fix the confusion by viewing memory with its low addresses at the top and high addresses at the bottom. While this would indeed make stack movement more natural, it would also mean that increasing some memory address would take it down in the graphical representation, which is probably even more counter-intuitive.

Ultimately, my approach is to avoid directional terms such as 'top' and 'bottom' or 'high' and 'low' in the first place; they only cause confusion. Prefer 'greater' or 'smaller' addresses.

(Similarly 'left' and 'right' when applied to bits, which gets especially confusing if endianness is involved; prefer 'more significant' and 'less significant'.)

I never understood why people ever put memory upside down on diagrams.

In fact, I think the only time I see diagrams with F at the top and 0 at the bottom is in explanations of the stack, or in explanations of how "the stack is so weird it grows the wrong way!".

When describing, e.g., a memory map for a custom ASIC, you would always put the low addresses first and the high addresses later. That's just how numbers work. The "stack grows the wrong way" issue seems to be an invented problem.

If you're writing a diagram for little endian, you end up with the bytes going right to left, if you have multibyte values, so you may as well read bottom to top, right to left.

Little-endian is fundamentally confusing, because the bits within the bytes still go the "other" way. Best to just keep the diagram oriented to bits-within-bytes order, and make it clear that bytes-within-words are being plopped into memory backwards.

Just like, back when graphics bitplanes were a thing, it was much less confusing if the diagram just showed (virtual) memory interleaved, the way you'd actually have to deal with it as a programmer, rather than showing the "clean" physical-memory diagrams for what ends up on the "even" and "odd" chips.

The bits within the bytes have no order because they are not addressable on most hardware. You can imagine them going whichever way you like, even in a different dimension. On an architecture without bit pointers, a byte is a number from 0 to 255, not a sequence of bits.

(x86 does indeed have the bt family of instructions that sort of address bits. I would argue that the existence of memory-operand bit accessors like this that accept larger-than-bits-per-word offsets is bizarre, but the instructions are not backwards. On a big endian system, these instructions would have different behavior depending on word size, which would be odd.)

Bits within bytes have a defined order when you do things like pushing the CPU flags register to memory, reading it back into a numerical register, and then bit-shifting/rotating through it. That's something you can do on basically any architecture that supports preemptive scheduling; there's usually either a PUSHF or PUSHALL there to assist.

But, even without the ability to address the memory at the bit level, bits-within-bytes ordering still matters on any architecture where bits are striped between memory channels, RAID-0 wise. (Just like those graphics bitplanes!) The processor being LSB-first vs. MSB-first on how it interprets the data bus, determines which sockets you put the LoROM and HiROM firmware chips into your Apple II :)

I think it makes a difference when you've got bit packed fields. For example a 32-bit word with a 16-bit field a 4-bit field and a 12-bit field.

If you want that 12-bit value to work nice, it's probably going to be all the bits of byte 0 and the lower half of byte 1. (Or the upper half of byte 0 and all of byte 1). That looks best if you write bits and bytes right to left from zero. That 12-bit value uses bits 0-11 and you can mask it from your 32-bit read with 0xfff. The 4-bit value you can mask with 0xf00 and then shift (or shift first, whatever)

I have had to work with data that uses little-endian for bit order as well (although we call it "least significant nit first", and reserve the word "endian" to describe byte order).

We actually dealt with this by adding support to a general purpose open source parsing tool we maintain [0]; where we had to add a feature to the standard specifically to accommodate this [1].

Even though least-significant-bit-first makes sense with littleEndian actually working with it is a giant pain, because approximately no tooling actually thinks that way.

[0] https://daffodil.apache.org/

[1] https://daffodil.apache.org/docs/dfdl/#_Toc62570139

Personally, the association of "top", "highest", "up", and "increase" is strongest, and similarly "bottom", "lowest", "down", and "decrease"; so from that perspective it's "top" and "bottom" when applied to the stack which is the inconsistent one.

I think it's better to just stop drawing memory diagrams vertically, and show it horizontally instead. At least most people seem to agree that left is lower and right is higher.

That way also makes reading/writing a buffer go from top to bottom, similar to reading/writing normally.

Exactly. After all we write programs by starting at the top of the screen and working our way down, and happily of course program execution increments in the same direction. So small addresses at the top and big addresses at the bottom is the most natural way of presenting any memory map.

We call things "base of memory" and "top of memory" though, with the latter one being at the highest address of memory.

I've heard both go in both directions. Hell, I've said both depending on the diagram I'm pointing at when I say it. It's not that universal

but then the heap would grow down in such a diagram...

btw my understanding is that the heap came first in the logical development of C and other systems programming. so it made sense to have .text and other program data at the lowest virtual memory addresses and then have the heap grow towards higher memory addresses.

then when the stack became a thing it had to grow down...

The stack might have actually come before the heap in history, and actually proceeds any systems programming language that was a higher level than assembly. They were seen in the Z4, and Turing wrote about them in 40s.

Reply on news.ycombinator.com