Hi! I'm Lexi, I wrote this article/mini-book.<p>There's a classic question of "what happens when you load a website?", but I've always been more interested in "what happens when you run a program?". About 3 months ago, I was really annoyed at myself for not knowing how to answer that question so I decided to teach myself.<p>I taught myself everything else I know in programming, so this should be easy, right? NOPE! Apparently everything online about how operating systems and CPUs work is <i>terrible</i>. There are, like, no resources. Everything sucks. So while I was teaching myself I realized, hey, I should make a really good resource myself. So I started taking notes on what I was learning, and ended up with a 60-page Google Doc. And then I started writing.<p>And while I was writing, it turned out that most of the stuff in that giant doc was wrong. And I had to do more research. And I iterated and iterated and iterated and the internet resources continued to be terrible so I needed to make the article better. Then I realized it needed diagrams and drawings, but I didn't know how to do art, so I just pulled out Figma and started experimenting. I had a Wacom tablet lying around that I won at some hackathon, so I used that to draw some things.<p>Now, about 3 months later, I have something I'm really proud of! I'm happy to finally share the final version of Putting the "You" in CPU, terrible illustrations and all. I built this as part of Hack Club (<a href="https://hackclub.com" rel="nofollow noreferrer">https://hackclub.com</a>), which is a community of other high schoolers who love computers.<p>It was cool seeing some (accidental) reception on HN a couple weeks ago while this was still a WIP, I really appreciated the feedback I got. I took some time to substantially clean it up and I'm finally happy to share with the world myself.<p>The website is a static HTML/CSS project, I wrote everything from scratch (I'm especially proud of the navigation components).<p>I hope you enjoy, and I hope that this becomes a resource that anyone can use to learn!
Very nicely written, and congrats on doing such a deep dive on this kind of topic.<p>These days 17 year olds can get away with "programming" by gluing things they don't understand, but I think they'll eventually hit a ceiling. So what you're doing is super valuable, not for yourself, but for everyone else who will learn from your materials.<p>Well done :)<p>EDIT: now go write an emulator if you haven't already, it's a ton of fun :)
Congrats on completing this guide.<p>> There aren't many comprehensive systems resources if you aren't going to college, so I had to sift through tons of different sources of varying quality and sometimes conflicting information.<p>The absolutely best resource you will find is Charles Petzold's <i>Code: The Hidden Language of Computer Hardware and Software</i>. The 2nd edition was just released.<p><a href="https://codehiddenlanguage.com/" rel="nofollow noreferrer">https://codehiddenlanguage.com/</a>
This is on my reading list. This little bit sold me on it in the past:<p>> <i>The bottom of every page is padded so readers can maintain a consistent eyeline.</i><p>Such a <i>tiny</i> and, in hindsight, obvious detail. It's surprisingly pleasant. When I noticed that, I knew I had a passion project in front of me.
I'm almost 40 years old, and I've never accomplished something like this. I was just about to cope about my impostor syndrome. Well, I guess I need to cope more!<p>Great job :p
Damn. If you're producing this type of content at 17, I can't even imagine the amazing things you'll be able to do it you choose to pursue the field professionally. Absolutely amazing!!
OP, you should take a look at Casey Muratori's course at computerenhance.com<p>The first part of the course's homework creates a simulator of the 1978 intel 8086 (which modern x86_64 assembly still closely resembles). You will learn a lot of things about computers that are really difficult to find elsewhere.
As a fellow (very nearly) 17 year old, good job! :^) Just 20 minutes ago I was trying to figure out how to extract the first byte of a 16 bit integer and finding out about Endianness, and you're writing a whole book about CPUs! I'll make sure to read this once I've finished Crafting Interpreters, although it may take a while since progress with that has certainly slowed down (as it does with many of my other projects lol).
That‘s a very nice writeup, I like the style. The mix of text to illustrations/memes was really pleasent. I have my reservations about the RISC/CISC nomenclature but I guess that‘s „each to their own“ >.><p>As someone who has spent some time figuring out how parts of the kernels work I can sympathize with the pain it probably was (but well worth it given the article imo).<p>For NT, I think that Windows Internals covers a lot about the stuff one wants to know and Microsoft‘s documentation is also not bad (certainly better than Linux‘s kernel docs imo); it‘s a really good starting point.<p>For more info about Windows I can recommend gamehacking forums/resources. There‘s a lot of filtering needed but they are a pretty good source of info for niche things sometimes.<p>As a last note, I noticed that the font of some code blocks are pretty large when viewed on my smartphone making them hard to read (e.g. Ch. 6/main.c)<p>P.S.:
> If you are a teenager and you like computers and you are not already in the Hack Club Slack, you should join right now<p>Way too remind me that I‘m getting old lol
As someone who has worked a bunch with debugging Linux itself, debugging qemu, and vulnerabilities in kernel and userspace, I really struggle to appreciate stuff like this because my initial reaction is “well, duh, of course that’s how it works” but looking back at myself getting into those fields I really applaud you and thank you for creating this great content
You are a very skilled technical writer. One way to discern this is asking at a given point, "What question just likely popped into their mind after what they have read?" (you don't have to be right, just close) ... and importantly, "Do they need a little break from the main outline?" Your brief tangents in light blue are a perfect answer to both questions. Your terminal examples show what things really look like, or how they appear to people who work with the code every day. Your narrative glue shows impeccable grammar and flow. Don't try to change your style one bit, let it change itself over time.<p>Never went to college or high school. When I was 17 in 1981 and had been already been deep diving into several different types of computer systems over 3 years, I would have died to read what you have written, just the way it is written. It would have answered so many questions directly, fortunately I sometimes had other peoples' code to look at (and Vector Graphic actually included commented Z80 assembler for their entire BIOS in the manual, many pages!) but when you are short on examples to look at, that's when the real disillusionment sets in. I love today's world, one is only a few keywords away from great examples. The challenge is to present them in a way that someone reading puts it all together and becomes excited about understanding.<p>Great work!
This is so cool! And I'm dismayed that you have been subjected to the typical Hacker News cynicism.<p>By looking through some of your other project and interests, I can see that you likely have a healthy sense of your own capabilities and certainly don't need my validation or approbation. But I'm going to give it anyway.<p>Piffle on anyone who knocks you on tone! It is not trivial to make this level of technical information available in such an approachable fashion. When we first start our careers, detailed technical knowledge and the ability to solve low-level problems are super important. But the way you "crawl up the value chain" in software engineering is to become a "force multiplier" - someone who can make other people more productive. And the ability to communicate well (both <i>what</i> to communicate and <i>how</i> to communicate it) becomes a more and more important skill. This work clearly demonstrates your communication skills.<p>I hope you make software engineering your career choice. The field could use more people like you.
Going down the Rabbit Hole is fun for any subject you learn a lot. For electronics I went down the hole power, current and voltage, EMF, magnetism, ferromagnetic metals, domains (as in magnetic area no networking i.e. electron alignment), virtual electrons, physics, quantum mechanics...<p>Similar for computers you see the high level stuff but then you can go right down to the wire level where bits are voltages +5/-5/0V and clock timing.<p>Although being too curious can be bad thing. You have to know when to stop or where to start. I think we've all heard stories of people troubleshooting who are very intelligent. They're tearing into a problem down to the hardware level or going over code line by line when all they needed to do was reboot.
[dupe]<p>The other link for this is cpu.land -- stick to your 'official' urls! -- shared and discussed a few weeks ago<p><a href="https://news.ycombinator.com/item?id=36823605">https://news.ycombinator.com/item?id=36823605</a>
The guide is stuck in some false then versus now thinking.<p>A preemptible kernel isn't "modern". Cooperative multitasking isn't "old".<p>These are just choices in the design space that can be relevant at any time.<p>Fully preempted real-time operating systems existed many decades ago.<p>Meanwhile, today, there seems to be a renewed interest today in coroutines and fibers and such, and they are showing up in programming languages. Those mechanisms are forms of cooperative multitasking.<p>If you need an embedded system to do a few simple things, why would you threaten its stability with preemptive, interrupt-driven task switching?
> The envp argument contains another null-terminated list of environment variables used as context for the application. They’re… conventionally KEY=VALUE pairs. Conventionally.<p>TIL! It seems a lot of (newer) programming languages make this assumption.<p>> …I love computers.<p>Me too, kid. Me too.
Hey. Nice work! I really enjoyed reading this. This is the kind of sensible, from-the-beginning writeup that I wish I'd had way back in the day when I first got started. It's a nice synthesis of a large amount of complicated information, and builds a good mental model for someone who isn't looking for a PhD-level understanding. I remember not truly understanding how, when I would load a program on my Commodore 64, "yeah but how does it actually know to run? All I did was read some data from disk and then it just, like, went." This would have provided exactly that kind of understanding.<p>Anyway, good on you. Your article was a real pick-me-up, it makes me happy to see this out there, from young folks. I enjoyed the hell out of it, and I hope you enjoyed creating it.
This is great work :) thanks for sharing it with us. Unexpected Linkin Park bit at the end was nice, but now I'm wondering if Linkin Park is now considered 'oldies'
This is a really cool project, kind of touches a point about the history of computers as we know them now, a wealth of information can be found on classic books such as “The art of computer programming” by Knuth, this is more related to how things work now which has changed a lot over the years but the basics are still there.
Great effort, but really still needs a bunch of work. In some places the sentences just don't make sense. I think in terms of CPU, a good starting point is the Von Neumann architecture which most computers are designed around.<p>The current description of CPUs mix things up with OS concepts. You may want to look into things like memory management units ( MMU ) that builds on the basic Von Neumann architecture to provide "virtual memory" such that an OS can use it to provide process isolation that OS's can use. Also the more capable CPUs have what are often called "modes" (protected mode in x86, ARM have a similar thing) to isolate running programs from each other and be able to create rings for things like kernels and device drivers.
This site doesn't explain how CPUs run programs. It only explained the instructions that CPUs will run and some abstractions on top of that, but not how CPUs typically run those instructions.
Great job! I'm an expert but you were right: I learned some things from Chapter 3.<p>A couple of very minor points:<p>"The first mass-produced CPU was the Intel 4004, designed in the late 60s by an Italian physicist and engineer named Federico Faggin."<p>The first <i>microprocessor</i> (CPU on a single chip) was Faggin's Intel 4004, but mass-produced CPUs existed before that. Earlier CPUs
were built from multiple chips, and before that multiple individual transistors, and before that multiple vacuum tubes, and before that multiple relays (although it's fair to say that relay computers were never mass-produced).<p>"The CPU stores an instruction pointer which points to the location in RAM where it’s going to fetch the next instruction."<p>This is also called the Program Counter or PC outside the Intel universe. This is confusing as "PC" also stands for "Personal Computer"
but people who learned computing in the days before Intel became popular still call it the PC register.
What's your advice on how to teach programming to my kid? Curious to hear what another young person thinks. Kid is 11, has all the basics, knows how to type, knows how to open a terminal.<p>What things did you think were important to learn, what kinds of things motivated you most? What did you do when you got stuck?
Hi! Great job! I really enjoyed reading this mini-book and I'm recommending my friends in college to read it. It mentions a lot of topics that we studied during an "Operating Systems" course.<p>We don't have HackClub here where I live, thus I never heard of it, but what they do sounds awesome and inspires me to promote it or even start it here (especially since there's no HackClub in Ukraine).<p>Thank you for sharing this experience, it was one of the best reads I had in a while!
Fantastic work by the author. The best part:<p>> I talked to GPT-3.5 and GPT-4 a decent amount while writing this article. While they lied to me a lot and most of the information was useless, they were sometimes very helpful for working through problems. LLM assistance can be net positive if you’re aware of their limitations and are extremely skeptical of everything they say. That said, they’re terrible at writing. Don’t let them write for you.<p>Good. Thank you for disclosing this.<p>Great to know that even teenagers like the author know the limits of LLMs and know where and when to use them and haven't fallen into the hype and mania in blindly trusting them, unlike the millions of so-called new wave of <i>'AI startups'</i> out there.<p>Once again, fantastic work and keep it up.
I was about halfway through chapter 3 and thought to myself, "I haven't listened to In the End by Linkin Park in a while, let's spin that up". my reaction when I scrolled down ten seconds later...XD
The best resource I've found so far that helped me understand how computers / CPUs work, is Ben Eater's work. Both his 6502 computer, and 8-bit CPU series are amazing.<p>Looking forward to reading your guide. Thanks for sharing!
"... run programs ...." can be considered at a number of (abstract) levels, until the lowermost level is reached , which is machine language. ( Actually, the preceding statement is not correct , since there is often, [ but not all ways] CPU micro code , below Machine language. Machine language is assembly language translated into ones and zeros , that is loaded into the CPU. CPU microcode is a language used to control the internal CPU logic to execute the machine language.
Wow this is amazing. The writing is actually really good too, I love how personable it is, in contrast with a dry boring textbook.<p>Love it, and wish I had this drive at your age.
This is awesome with such good presentation. Well done!<p>I would also recommend the linux programming interface book for those looking for a very in depth introduction to this topic.
What a lovely guide and the best part is that it is a genuine guide.<p>Many articles posted on the internet are meant for one thing, guide a user to buy a certain service or product. But after reading the whole guide I only had the feeling of someone wanting to share knowledge.<p>The hackclub also seems to be a very interesting organisation and I hope more and more teenagers will join you guys and contribute to society as you have contributed by making this guide.
This is fantastic. Great job! I like the easier to comprehend language than what you typically find when reading information about this stuff (wikipedia is one of the worst...).<p>You'd probably like Nand2Tetris. To be frank, I never finished it (it's so long!), but building a CPU from scratch was insightful (at the time - I don't remember much now, sadly).
I love this! Maybe dive a little deeper? Like, what happens from power on to login prompt. Like, power good > get instruction from predetermined address > execute (BIOS code) > init hardware > change to protected mode > load OS, etc.<p>Different cpus are different, of course, but they all go through a similar start up sequence. Again, nicely done.
"After executing an instruction, the pointer moves forward to immediately after the instruction in RAM so that it now points to the next instruction.'<p>What is a pointer? How does it "move" inside the computer? This is low level stuff, but still probably somewhat mysterious to the layman.<p>Never mind the obscurity of the word "syntax".
Very nice guide! I love your writing style, and your research skills are clearly top-notch. Great stuff!<p>You might enjoy reading some articles by Julia Evans (<a href="https://jvns.ca/" rel="nofollow noreferrer">https://jvns.ca/</a>), who has a similar informal, conversational, exploratory style.<p>Stay curious!
Amazing article. I have not seen such a comprehensive guide yet. Although when I have seen the title I was expecting it would be focused more on CPU inner workings: superscalar pipelines, frontend, backend, instruction fusing, memory banks, instruction cache, branch prediction, instruction reordering etc.
I thought it’d be lower level as it’s still very abstract and more of an operating systems guide than a guide on how CPUs physically run programs. Like how a string of current representing 1s and 0s allows the CPU to do certain things, etc.<p>But well organized none the less!
Kid, first of all great job! Second of all I am jealous you understand this as such a young age. I was pounding 40 ounces of Old English in the hood at 17, but should have doing something like this. Granted, the internet was just a baby when I was 17.
wow 17! excellent work. You're going places for sure if you keep this up. I would guess even most working Devs don't have any real concept of how things work at the CPU level let alone during high school.
:x86:<p>Apart from the drawing boards at Intel when the 80286 was designed, can anyone find any evidence or have first-hand experience that rings 1 and 2 were ever used in any specific commercial purpose? (I haven't heard or seen of it.) 286 protected mode was generally a flop (outside of OS/2), while 386 protected mode was significantly better. The LDTR (-> LDT) and hardware task switching (reloading TR) aren't typically used. GDTR (-> GDT), TR (->TSS) and IDTR (->IDT) setup are essential.<p>The TSS includes where to find the 6-7 stacks, and for a permissions mask for port I/O.<p>Double fault handler (in the IDT -> INT 8) is typically what leads to a colorful screen of death. When the double fault handler fails (or the IDT or was overwritten), a triple fault happens and the CPU halts or the virtual machine does it own impression of a colorful screen of death without (usually) actually killing the host machine.<p>An invalid opcode handler permits handling CPU-unknown opcodes in the OS such as using emulation or other hardware.<p>Note that generally most PCs prior to UEFI/EFI booted in real mode with 1 core running, so writing a parallel and concurrent OS typically involves setting up protected mode structures, switching to protected mode, and then talking to the APIC for every other core.<p>Resources:<p><a href="https://sandpile.org" rel="nofollow noreferrer">https://sandpile.org</a><p><a href="http://ref.x86asm.net/geek64.html" rel="nofollow noreferrer">http://ref.x86asm.net/geek64.html</a><p><a href="https://cdrdv2.intel.com/v1/dl/getContent/671200" rel="nofollow noreferrer">https://cdrdv2.intel.com/v1/dl/getContent/671200</a><p><a href="https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html" rel="nofollow noreferrer">https://www.intel.com/content/www/us/en/docs/intrinsics-guid...</a><p><a href="https://www.amd.com/en/support/tech-docs/amd64-architecture-programmers-manual-volumes-1-5" rel="nofollow noreferrer">https://www.amd.com/en/support/tech-docs/amd64-architecture-...</a><p>SVGA/VGA/EGA<p><a href="https://wiki.osdev.org/Expanded_Main_Page" rel="nofollow noreferrer">https://wiki.osdev.org/Expanded_Main_Page</a><p><a href="http://www.osdever.net/FreeVGA/home.htm" rel="nofollow noreferrer">http://www.osdever.net/FreeVGA/home.htm</a><p><a href="https://archive.org/details/gpbb20/" rel="nofollow noreferrer">https://archive.org/details/gpbb20/</a><p><a href="https://archive.org/details/programmersguidetotheegavgaandsupervgacardsbyrichardf.ferraro19943rdedition/" rel="nofollow noreferrer">https://archive.org/details/programmersguidetotheegavgaandsu...</a><p>System management<p><a href="https://wiki.osdev.org/Symmetric_Multiprocessing" rel="nofollow noreferrer">https://wiki.osdev.org/Symmetric_Multiprocessing</a><p><a href="https://pdos.csail.mit.edu/6.828/2018/readings/i386/s09_08.htm" rel="nofollow noreferrer">https://pdos.csail.mit.edu/6.828/2018/readings/i386/s09_08.h...</a> <- CPU fault handlers<p><a href="https://ctyme.com/rbrown.htm" rel="nofollow noreferrer">https://ctyme.com/rbrown.htm</a><p><a href="https://wiki.osdev.org/UEFI" rel="nofollow noreferrer">https://wiki.osdev.org/UEFI</a><p>USB<p><a href="https://beyondlogic.org/usbnutshell/usb1.shtml" rel="nofollow noreferrer">https://beyondlogic.org/usbnutshell/usb1.shtml</a><p>Emulators<p><a href="https://www.qemu.org" rel="nofollow noreferrer">https://www.qemu.org</a> (qemu-system-x86_64 or qemu-system-i386 for very retro)<p>You'll usually want to create an ELF32x64 binary kernel image that's a bit of real mode, ia32 and then switches to 64-bit registers mostly (ia32e [amd64/x86_64]).
Meta point: I'm curious of people's thoughts when OPs in general post "I'm N years old..." or "I'm a blind programmer who..." before posting something unrelated to their life situation. Personally I think this falls into the "girls do not exist on the internet" rule of thumb. No reason to state that you're a girl (or 12 years old or whatever) other than to prime people to look upon your writing with lower standards. I think it is fine to mention your situation in passing or as a footnote if it is interesting, but unsure it really adds anything to lead with it (personally I think it detracts).<p>That's just my opinion. Anyone else have thoughts?<p>FWIW this seems pretty well written from just skimming the intro and a bit of chapter 3.<p>Edit: sorry I did not mean for this to be the top comment and push OP down so far. The writing here is really good and folks should definitely click through and at least give it a skim if they're interested. I was just curious what people's thoughts were on this topic.
The only thing is I hate titles like this—the title is bragging a bit too much.<p>Maybe a title more like:<p>“How I’m helping my high school peers learn about CPUs”.<p>That way it implies you’re young, smart, and care about others—all of which I imagine are true :)