Virtual Memory with 256 Bytes of RAM
blog.robertelder.org
blog.robertelder.org
I had fun creating this, and might make similar visualizations in the future. If you have feedback or requests, I would welcome it. I give you permission to disregard HN's policy on 'gratuitous negativity' as much as I have the authority to.
Thank you for writing it, I'm actually doing a little refresher of my computer architecture coursework now and comparing what I remember to article.
Virtual Memory Explanation - https://www.cs.purdue.edu/homes/clifton/cs250/
Virtual Memory Exercise - http://webcache.googleusercontent.com/search?q=cache:VFdxPaP...
But if you want feedback, my only comment after playing with it for 15 minutes is that I wish the animation could be controlled. Or at least paused. The "run animation" doesn't seem to do anything for me.
Otherwise, I really like the idea and the visualization. I like the 256 byte idea too.
As one of those 'silent upvoters' and just speaking for myself, think of it as 'speechless'. I wrote a pretty basic kernel which used memory mapping but without virtual memory. Explaining those concepts to someone else is pretty hard and your live animation would have simplified quite a few discussions I've had on the subject if I had had access to it the better part of 2 decades ago. So thank you very much for this work, consider applying similar techniques to visualizing what happens to a running program as it allocates memory and frees it again for various parts of the programs life-span.
One nit though: the low-contrast font color makes it unnecessarily hard to read.
I think it would be nice to have a complete memory lookup written down step by step in text form. e.g.
we're trying to look up the address 0xAA in virtual memory,
the current page table pointer is 0xBB,
therefore we're reading directory entry from the address 0xCC
the directory address contains (...)
etc.And what I mean by 'just beyond my comprehension' is that it's far enough ahead (and also in the direction I'm headed), that I'll be reading it several times before it all really sinks in.
In short, I love it. I think this is really fantastic and I wish more folks took the time you did to really walk through more intricate concepts like this. Really, really appreciate the time you put in. Thank you.
It would be better to use bytes, since x86 instructions can be as small as one byte (e.g. the C3 in 0x55C35D08 and 0x55C3C9D2 is the return instruction, the last byte of the function, and the 55 is the start of the next one), but this is basically how a JIT works. If the access permissions are set right (or nonexistent, as the case may be), you can generate code into a buffer and execute it directly.
You could explore this further by modifying the 08 in 0x55C35D08 to any signed byte value (80 to 7F --- -128 to 127), resulting in a "JIT'd" function that adds that amount to its argument. The actual instruction is the 3 bytes 83 C0 08, which is "add eax, 8". Definitely not portable, but if you're "pseudo-JITting" pieces of code in your application, you are likely worrying about other more important things than portability.
(If you work with things like this enough, you start memorising the most common opcodes and can mentally disassemble hex dumps...)
Since you asked for specific feedback, I'll suggest trying to find a way to trick us HNers into learning more of what your simulation actually does, instead of just looking at the pretty lights. Maybe showing text first and requiring a click to show the simulation? Or maybe start with a very simple visualization and a small amount of text to get us hooked, then have a wizard-like step-by-step interface that introduces more complexity with each step.
Also, maybe flashing red is a bit too distracting :).
Very cool work.