CPU Memory Visualization is Crowded

[zachriggle]

Currently, the CPU Memory visualization shows the address of EACH BYTE next to that byte's value. Additionally, the addresses are not aligned to an e.g. 8- or 16-byte boundary.

This makes it very busy visually, and hard to read versus other formats.

Consider instead the format shown by xxd (leading address zeroes stripped)

$ head -c 64 /dev/zero | xxd -c 16 -g 1 -o 0x210  | sed 's|00000||'
210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

You might even want to add column headers for readability by new users, e.g.:

     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +a +b +c +d +e +f
210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

(with obvious style hints to show that the row / column headers are separate from data)

[bordplate]

I agree that the visualization is crowded, maybe the addresses shouldn't be as prevalent or repeated that often, however for beginners I don't like the format xxd uses.

The addresses are not supposed to align to 8- or 16-byte boundaries, it starts at the highest address of stack and grows with the stack pointer as the stack grows. If you've got 0x256 bytes of memory, the stack starts at address 0x255.

For those experienced with reading hex data, this looks like a toy, and it is definitely not the best way to visualize it. For this it's more important to me that the user understands exactly what byte is in a given address in the stack, that the user sees and understands each byte as a block in memory. Of the two formats, I strongly believe this is the better one for beginners, but is has lots of room for improvement.

I would love to hear your thoughts about how to improve this format. Down the line, it's probably a good idea to implement the format you suggest as an alternative for more complex demonstrations than my initial use of this project.

[zachriggle]

Thanks for the feedback! I've added some thoughts below, per your request.

For those experienced with reading hex data ... better one for beginners

Someone unfamiliar with base-16 will not derive much use from any layout of hex-dumped data. I

Anyone who has ever read hex-dumped data has likely seen it aligned to some boundary.

Your first blog post must necessarily assume a reader that Intel assembly, I expect they're comfortable with standard grids that start at 0 (or 0x???0), instead of starting at e.g. 0x24e.

The addresses are not supposed to align to 8- or 16-byte boundaries, it starts at the highest address of stack and grows with the stack pointer as the stack grows

Stack addresses are only unaligned by chance. It is entirely possible to fixup the (displayed) addresses to be aligned -- I'd actually recommend this.

Being aligned will likely aid comprehension and learning, since most people are familiar with grids, whether base-10 or base-16, and having the leftmost column start at zero.

For this it's more important to me that the user understands exactly what byte is in a given address in the stack

I think this could be done very informatively with a mouseover and row/column headers.

[bordplate]

I really do appreciate all your insights and feedback on this, I just don't happen to agree.

There is a reason I visualized it as I did initially and I stand by that decision.

However, there's definitely a place for the format you suggest, I'm very grateful for your feedback and it will be invaluable when I get to that.