What if you knew how computers work? (2015)
xorpd.net
xorpd.net
I took this class when I was already A dozen years into my software development career. It’s certainly not necessary to write software, but I’m really glad I know the underpinnings of computing.
Stepping through the fetch-execute cycle one cycle at a time, watching your CPU do its little thing, and then realizing that that is exactly what actual CPUs do, they're just doing it billions of times per second, that was amazingly eye-opening.
The rest took a bit longer than 5 years (maybe 7), and of course the learning didn't stop there. But I do remember thinking in the early 1990s "OK, I understand the entire stack at this point, what comes next?" My understanding had reached a level I was satisfied with - it would not have compared with someone who spent their entire working life focused on that level, but it was far, far beyond any normal computer user's understanding.
In the 2 decades and more since then, not a whole lot has changed that has invalidated the understanding I think I gained at the beginning. Microcode was a bit of a shock. The biggest shock has been watching a whole new generation of programmers who barely grasp the lower 80-90% of the system. Maybe that's good, but it doesn't feel obviously right.
Next to that it might be convenient to have something like asmdebugger.com next to it.
Another book that also really helped working with this was "Code: the Hidden Language of Computer Hard and Software" by Charles Petzold. This explains how computers work from light bulb/transistor level, all the way to the top to the OS, the monitor and the keyboard.
You can really take this two ways: one part being about von Neuman architectures, the other side culminating in Lisp. They’re fairly separate but both interesting views on computing. Of course, the opposite viewpoints also do exist, as Harvard architectures and your favorite “blub” language is still used today…
While they haven't given me any expertise on how to actually use these technologies to solve intricate problems (only experience and true depth can do that), they have given me a near-complete picture of what ordinary computers do today. Nothing is magic. Everything is a logical operation.
I only regret I hadn't read these back when I was a teenager.
PS. Next thing I would like to learn is the general design of modern CPUs and branch prediction.
The most valuable thing(s) I got from it are clear explanations of Transactions, Isolation Levels, and examples of errors that occur due to asynchronous operations.
I tend to think that if more people understood how to program at this level, the weight of software and websites would be a lot less. I can't log in to my bank website without download 1 MB of crap. It's super easy to program using by importing * but if you can write in assembly you can really optimize. It's just not worth the effort these days. So the improvement of Moore's law (RIP) ends up going to programmers' salaries instead of to performance improvements. Kind of an interesting way to think about it.
At least, in theory.
It's not about knowing assembly or not. It's resources, time, cost, money, ROI.
I had to build a one-time export yesterday. Am I gonna spend a lot of time optimizing the speed of it? Or am I going to make it work and get the export to the client faster?
It would've wasted my time and the clients money if I optimized the queries. Sure, the export itself took longer. But overall, the task was done quicker.
If the client wanted this export to run on their server frequently, I would've spend the time making sure the export itself runs faster.
For exmaple, in your example of a one-time export it might also make sense to write code that does not meet all requirements and explicitly can not handle certain edge cases, if it's more effective to fix these cases manually than try to automate that.
Yes, once measurements were introduced after the Velvet Revolution, water consumption by households fell to half almost overnight.
> when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand
I’ve done assembler work, I’m perfectly competent at it. I would never try to build a website in anything low level like that. It’s optimizing for completely the wrong set of problems. The world has lots of network bandwidth, cpu cycles and volatile memory. You won’t find many situations where having a better performing website is worth sacrificing the savings in human labor you get from high level abstractions.
That was in 1978 and the computer was an Apple II.
If you E&M questions are just node solving, linear algebra and difeq is all you need for E&M to solve "most" work. You do a lot of specialized versions of that in QM and as mentioned above the people doing the actual semiconductor design are so highly specialized that they are often not transferable to other problem domains and require fundamentally different approaches. Not sure any non-PHD study will really help one advance the field in a meaningful way. Study of QM i would say sufficiently enriches all physics verticals that if you are capable, it's worthy of individual pursuit, but also makes total sense to study as part of a curriculum taking place after intro E&M.
Quantum Tunneling in everyday life: https://www.discovermagazine.com/the-sciences/how-quantum-me...
Caltech had an elective course for freshman about how semiconductors worked up through flip-flops and registers. I took it. It involved QM and yes, tunnelling. So it's doable for mortals.
I read Charles Perzhold's Code, worked through parts of SICP, developed a bit of high level code software, have a very good knowledge of chemistry, lithographic processes (and QM, half forgotten by now). And yet it is not enough to get a good understanding of the modern computer - EE, compilers, OS de, networks, ... wiring the while thing together, et cetera.
I see the point in historical approaches, but it is quite time consuming. At the end, you will most likely attack problems at one to three levels in the "stack".
What would you consider to be an above average conceptual tool and skill set for the modern hacker?
There's this quote which I think applies here: if you want to bake an apple pie from scratch, you first need to invent the universe.
Digital circuits use a fairly simple model, and that's not difficult to pick up.
Analog circuits can use a number of more complex models, and they're more of a challenge, depending on what you're trying to do.
Actually designing transistors - defining dopant levels, topology, and process steps - is a very specialised skill that very few people have.
And modern PC motherboards are marvels of electromagnetic engineering as well as electronic engineering. You have GHz signals running reliably on circuit boards with multiple layers. Getting those to work is another very specialised skill.
So it would quite something to find someone who had a professional-level understanding of all the levels: from silicon chemistry and quantum physics at one extreme, to electromagnetic design, to all the different levels of electronic design, to binary machine language and processor architectures, to OS design and application software, to all the various data structures and encodings that make all of the above useful.
Every time at this phase I'd suffer the existential horror the first time put an oscilloscope to the circuit -- the clock wasn't square! Signals would ring, and other signals which hadn't transitioned would sometimes bounce a bit. Setup and hold times could be pretty well estimated, but it was still an estimate. Then there were phantoms that might appear on the scope or real issues that would not show up on the scope because the probe lead was enough to make what was measured not the same as what was actually going on.
Your work sounds really interesing to me.
I am wondering about the reasons for these issues that you mentioned. Could you please mention them here ? It might serve as a nice pointer to do better hardware design debugging I believe(I have close to zero experience in this. Hence the interest).
Also, are there any formal systems that verify your TTL-level designs ?
Thank you.
A truly squarewave clock, or any rising/falling edge that happens in zero time would have infinite bandwidth, and no real circuit can have infinite bandwidth because of capacitance, inductance, and resistance. Even though the power rails of a TTL chip are 0V and 5V, when a fast transition happens, the signal can experience reflections because the impedance of the driver and the copper trace are different, and because the end of the copper trace isn't terminated with impedance which matches the trace. As a result, the edge takes finite time to transition from 0V to 5V, but the signal can actually exceed 5V because of a reflection. Likewise, falling signals can go below 0V.
Also, the signal at one end of a wire will not be the same as the signal at the other end of the wire. It isn't even just a simple time delayed version. Eventually they'll come to equilibrium if the signal is stable long enough.
You can read about transmission lines here: https://en.wikipedia.org/wiki/Transmission_line
OK, another defect. Imagine a TTL part with 8 buffers in it, say a 74ACT244. Say all the outputs are low, and at some moment seven of those inputs switch from low to high. The corresponding outputs must drive enough current to switch their loads from low to high as well. Each of those outputs draw current to charge their load from 0V to 5V, and all of the current flows through a single power pin and a single ground pin. Because of of non-zero resistance and inductance, the voltage seen by the transistors on the chip is shifted slightly from the voltage seen on the PCB. That can cause the output which isn't changing to sink/source current (depending on the direction of the change) causing its output to bounce a bit. Imagine having four people on a trampoline, with one standing still and three jumping at the same time. That "standing still" person will still bounce up and down because of the others causing their common ground reference to shift.
Another defect. A chip's spec sheet lists a bunch of requirements for proper operation and guarantees of the chip's behavior if the requirements are met. Say a flip flip says it has a 5ns setup time, that is, the data in to the flop must be held stable for 5ns before the rising edge of the clock arrives. If this requirement isn't met, the chip's behavior is unspecified (it might capture it, it might not, it might capture it but it might take an arbitrarily long time to appear on the output, or the output could even oscillate). During the design phase one adds up the worst case propagation times for all paths from point A to point B and makes sure there is at least 5ns to spare to guarantee the requirements. But in real life, a clock trace runs all over the board and has many loads, each presenting some amount of capacitance. Kind of like relativity, different chips will see the rising edge at different times. Looking at a given chip, the clock edge and data inputs are each transitioning from high to low or low to high over the course of a nanosecond (and often more). At what point on that slope is the signal really a "0" or a "1"? Sometimes those signals are clean transitions because of reflections, it might go from 0.7V before the clock edge, to -0.5V after the clock edge, to 2.2V (neither logical 0 nor 1), stay like that for a few ns, then move to 4.2V for a few ns, then 4.0V for a few ns, then 4.6V.
The most maddening is the fact you can't always trust what the oscilloscope tells you. The oscilloscope has finite bandwidth; 100MHz scopes were common in the 80s and early 90s when I was using them. The 200MHz scopes were a lot more expensive. You might think, hey my clock is only 25 MHz, 100 MHz is plenty ... but a fast signal edge contains harmonics that are a multiple of that 25 MHz base frequency, so the scope tends to act as a lowpass filter. The scope probe is typically more than a meter long, and there is a clip on the probe that must be attached to your circuit ground. That is a 2m loop of wire, and in the best case it would take a signal a few ns to travel the length of that wire, and any stray EM fields can induce signals on that probe that aren't in the circuit (though obviously the probe designers take pains to minimize such effects). When debugging and a signal looked unexpectedly weird, a common tactic to avoid sinking too much time chasing phantoms was to change the probe, change the channel, or simply waggle the lead wire around to test the sensitivity of the displayed waveform on stray capacitance and such.
Testbenches always had a few cans of refrigerant on hand. If you suspected a chip might be flaky, probe its output then spray it and see if the output is affected by the chip temperature.
The list goes on...
On RF designs it was not uncommon to find seemingly needless small valued components at certain probe points. The idea was these modeled the reactive load of a probe. When you needed to probe it you'd remove the components and attach your probe and the circuit see approximately the same load so you could have more faith that what you were seeing more closely matched what was happening when you weren't looking.
I have seen such small valued components, looked their values up and thought, "this is insane".
(I wish I could say I thought, "I must be dumb, someone must be much smarter than I am", but if I hadn't embodied a certain kind of hubris I would not work in software.)
Also, Honestly, I thought reflections would be negligible when we are dealing with mA and 0-5V ranges. But your reply makes me think that there is more to it
Finally, thank you for your reply. I gonna come back to this answer in the future when I have a lab setup that is more than a solder and some screwdrivers :)
I admit I struggled with QM.
1) In dynamic languages, it's not possible to detect whether a function is used or not in the general case. For example, consider string accesses on objects. If the compiler is not sophisticated enough to resolve the set of possible strings at compile time (or such analysis would unacceptably increase compile times), then you can't shake out unused methods on that object. [1]
2) For languages like C and C++, the compiler cannot tree shake because it only knows about a single file at a time (translation unit, to be precise). You would have to rely on link-time optimizations to effectively tree shake, but LTO is not well-supported by all toolchains.
Tree shaking also has a cost that I mentioned earlier -- it increases compile times. Both LTO and tree shaking in dynamic languages increase compile times superlinearly [citation needed] wrt. the size of your application. As other commenters have mentioned, it's better to avoid including unnecessary libraries in the first place.
There are no cost free abstractions, and that applies to tree shaking as well. https://www.youtube.com/watch?v=rHIkrotSwcc
[1] For the pedants: yes, I know resolving the possible set of values (stricter than "all possible values for that type") for a variable is undecidable in the general case.
You're right that people are already splitting apps into bundles, but that is usually done at the page level.
[1] You could probably avoid having to take a mutex after the first call to the function with self patching code, but that sounds incredibly ugly and could have other implications (self-modifying code could be detected as a virus; could be used as a gadget to exploit some other vulnerability).
The same can be done for a binary and it’s own code, but I wonder if it’s used as a signal in antivirus protections if done too often.
The closure js compiler is also pretty good if you prefer writing js.
If we only start using better languages in our applications we could improve performance quite a bit.
So from crap import * is pragmatic and practical. Short term at least.
That you know of.
But we can't standardize because technology is improving so quickly. Any standard would be quickly obsolete.
If we ever standardize on one CPU, one screen size, one GPU, etc etc. Then we can make big gains by hyperfocusing on this.
This statement doesn't really make sense. If programmers spent the time to optimize everything instead of gluing a bunch of inefficient libraries together, software would cost even more than it does now. So that's even higher salaries because there is even more business competition for the same pool of available programmer hours in the workforce (and that doesn't even take into account the fact that you would wipe out 90% of the programming workforce if writing assembly is required).
Moore's law means that you can afford inefficient code, so it's taking money from programmers and keeping it in the businesses that would have originally had to pay for a hand-tuned piece of code.
But sure, if you want to talk performance - the fastest CPU this year, the Threadripper 3990X, is over 100x faster than the fastest CPU of 2005, the Athlon 64 FX-57. That's about 7-8 doublings, or pretty much spot on.
If you don't think so try and calculate a_{i+1} = rand_int() a_i mod 232 on a machine from today and one from 2005. Then do the same with a machine from 2005 and 1990.
One can write assembly while knowing only a fraction of that stuff, but the compiler will probably outperform that kind of assembly, so there is little point aside from the fun of it.
If businesses demanded that everything be of optimal performance, developer salaries would most likely increase because that would increase demand for developer labour in the market without increasing its supply. And I know that many developers would be more than happy to do this (performance optimisation being one of these classic 'nerd sniping' tasks that really appeals to many programmers) but are simply not granted the time to.
And there is a reason that hardly anyone's boss is telling them to eek out every bit and clock cycle: they can't afford it, or at least don't want to pay to do that. So the "benefit" of doing this actually lands squarely on the business, if you want anywhere to look for wasted resources.
https://www.penguinrandomhouse.com/books/645954/how-computer...
The book is still in writing stage thus not sure about the quality though but by looking at the table of contents it's looking very promising.
https://usborne.com/browse-books/features/computer-and-codin...
Scroll down to the bottom of the page for links to the pdfs.
The ROI isn’t great, the time you spend learning this is time you could have spent going deeper into your chosen craft and becoming even more masterful.
By the time you do learn a dangerous level of assembly and reverse engineering knowledge, you’ll still have to fight for entry level gigs to get in the industry unless you’re really good at finding niche and high paying work... meanwhile people still want to pay you six figures+ for your decade or more of experience writing everyday software at scale.
Alas, where as it once seemed like anything was possible, as I get older I come to realize the best use of my time is to further perfect the things I already know how to do well, so that one day I can truly become a sagacious master, or at the very least not fall behind my peers and become “outdated”.
Learning opportunities like this are inspiring, but ultimately just a passing curiosity. I hope someone young finds it well.
And yet. To a junior dev who asked me for advice on this stuff today, I’d just say read Code: The Hidden Language of Computer Hardware and Software, and if you like that then work through Nand to Tetris, and then go back to whatever you need for you day job.
He’s really a great teacher.
I’m a CE and need to know exactly this stuff.
What I don’t need to know, and don’t at all, is how web APIs really work, what a kubernetes is, there is something called Elixir I think and it may or may not be related to some Etherium not-money, and have you heard about elastic searches? Because I haven’t.
But I do need to know extremely tight programming for tiny microcontrollers, how many cycles per instruction this or that will take, when pipelines get flushed, device drivers, and datasheets and silicon erratas.
If you deal in higher level stuff, you likely use more ram for a text field than I may have on my entire chip.
The only reason I don't use less RAM for a text field is because it doesn't fucking matter, RAM is cheap and when you're building web applications your user is probably not going to run out of it, it's not even a thought. RAM sitting around doing nothing is a waste of money, might as well put it to use.
I think that's true of most things—you don't need to (and likely cannot) know everything in real depth, but having some knowledge tells you where to look, what to look for, etc.
Most of your CPU time is spent waiting on memory. Compilers are hard-pressed to make you choose efficient data-structures. You just need to know the implementation details to get a responsive user experience.
I thought a lot of these details could be boring or hard to grasp, but it was the opposite—to me, things like how logic gates worked, how we remember values between computer cycles were all very fascinating, especially compared to the kind of work I've done for a long time.
I've learned a bit more about operating systems and databases since then, and I think knowing a bit of computer architecture helped me understand several topics in much better depth. So even if knowing these things doesn't have a very direct ROI in terms of getting a job, I think it's worth spending the time to learn at least the basics.
Don't miss his amazing x64 poetry book, at https://www.xorpd.net/pages/xchg_rax/snip_00.html
Websites wouldn’t be 4MB on the front page...
Some of you would be ashamed of the choices you make in typed languages...
Others would be horrified to find out what happens in the back end of not typed languages...
You would constantly find it amazing that single CPU core systems aren’t ever actually doing more than one thing at a time and the concurrency of moving the mouse on the screen and ANYTHING else the system is doing is just an illusion...
You wouldn’t shit on C language... at least less.
... IDK, I’m sure there are a ton more I’m not thinking about. I’ll leave it up to someone else to articulate better... something something FaceTime is usually a massive waste of technology.
These are bad musings from an embedded programmer who is dealing with a 2020 released chip and it’s 4KB of ram.
Anyone who still thinks C is the way computers work is in for a surprise when they realize all modern x86 machines are just emulating x86 in microcode for backward compatibility reasons.
…they read the standard and are introduced to the C abstract machine, where pointers aren’t integers anymore.
This is very different from how e.g. ARM architectures work.
Any examples?
My app developers came back with a message ID field that uses a UUID. A 256bit store, 16 of my possible 20 bytes.
The whole packet as they designed it was only 6x larger than could possibly fit.
They used int... not having any idea what a int64_t was or that because the value could only ever be 0-20 that a uint8_t was most appropriate. Oh but the language they’re using doesn’t have 8bit ints I guess so then it was a discussion of “what is but shifting” and who even uses this weird operator >> and << !?
I have a hundred examples of the above. Embedded is a different world, I consider that “how computers work” territory.
Nope. If anything, while programming for microcontrollers I learned C is too remote from hardware and leaves too much implementation-defined. Struct padding? Implementation-defined. Bit field implementation? So implementation-defined you'll have to roll your own with shifts and masks. Accessing anything mapped to memory address? The pointers as defined in C standard aren't what you think, but fortunately the implementation often is. Even standard variable sizes are only 21 years old, which means that there is still legacy code that either doesn't use them or wraps them in layers of typedefs to work with toolchains or libraries that don't. And good luck if you have 24-bit registers.
Of course it's frustratingly low level at the same time. I don't know what could be a good choice, and C is what everyone already uses anyway.
You must be much more advanced than I am. Because in 20 years I’ve never had an issue with structure padding because I just assume it pads to n basetypes and pad them manually to 4byte intervals in 32bit.
As to portability, man, you must be moving from ARM to mips to x86 to 8051 to OLD stuff, I’ve never had an issues here either, I just don’t make assumptions of but order if it might matter. Jh mean, code gets tested right? LE to BE or padding or whatever isn’t going to slip by me typically.
The problem with shifts and masks is they don’t typically “automatically” take advantage of the BMF cpu operations like structures definitely will.
IDK, like I said, you must be more advanced than I am. I’ve had none of this issues. Ignorance must be bliss! :)
Websites are 4MB because they want a certain experience and a certain functionality, and developers assemble various common components and libraries to achieve this with the least amount of custom development.
A developer knowing assembler will not change the priorities of web site owners.
That being said...I don't really do code at all :) Most of what I do is on the hardware side of things.
Edit: Emac...not emacs
I had to stop and sit and think several times while reading that book, but it was a real thrill when I started to understand it, feeling that small flash of near-omniscience...
For me, it was the Z80, because there happened to be a book at Radio Shack, published by Howard Sams, that was extremely well written. But since this is about x86 assembly, the old 8086 isn't all that bad in terms of grasping how the different kinds of instructions actually play out in the registers, memory and i/o busses, and so forth. And it's not so bad to learn about the features of modern processors in light of how they compare to early chips. For instance in the 8086, a pointer is not an abstract concept, but a real physical thing!
Despite modern microcontrollers being much more sophisticated than the Z80, that foundation has helped me learn and understand things like how to read the documentation for special function registers and advanced peripheral chips.
Probably the pinnacle of CISC human oriented asm.
For real world processors, I would say that the 68000 is probably the best introduction to assembly level programming. For a real-world CPU. Lots of registers, usually a flat and easily understood memory map, a clean instruction set, and instructions that have direct parallels to many of the basic operations you would find in higher level languages, e.g. multiply, divide, addition and subtraction of 32-bit numbers, easily understood loops, various conditionals and so forth. Certain early ARM variants would run a close second of "try this out, it's easy to understand." Though even then, I'd hesitate to introduce someone to ARM programming unless they had a real interest in learning assembly programming.
6502 is simple, I agree with that, but moving beyond the most basic of operations takes careful thought.
So for an introductory assembly language on a real world processor, I would have someone start with 68K. Once they grasp that, which, if they are a reasonably competent programmer, facile in their language of choice, they should be able to crank out 68K assembly that does useful work in a couple of days. It is possible to then consider the 6502 or Z80 or 6809 as options for a less capable, but certainly more difficult next step in assembly language.
I would strongly disagree that 6502 is designed for human readability or that it is the pinnacle of assembly language programming options. For real world processors, I would be hard pressed to rank it in the top 10 of "processor of choice to solve this task because of capability." Perhaps up to about 1982 it could be considered reasonably competent. But "pinnacle" is not a word I would ever use to describe that CPU no matter how fond my memories are of learning to program it or shipping my first video games on it. The 6502 CPU has a number of shortcomings that were clearly evident in the late 1970s when it was at peak popularity. The one thing it did have going for it was that it was cheap and that it was easy to get going on a board with some supporting chips.
Features of the 6502 ISA like register width being half of pointer width with no way to link a pair of registers together to a full address, relying on you to have to bounce back and forth through memory to construct a full pointer really obfuscated a lot of the concepts I wanted to teach. Yes, "zero page is the real registers", bla bla, but those extra hoops don't do any favors to someone who's just learning computer architecture.
68k looks clean, but I've never had to use it in my career so I shy away from it for probably that reason only.
The MSP430 is also a good learning processor, clean instruction set, not too much to take in at once, though there is mental overhead when you need to start being concerned with stack processing and also with some jump instruction limits.
Going to be real, I never liked the split A and D integer register files of the 68k. It always seemed like it would obfuscate one of the base ideas I want students to keep over thier lives. That it's all memory, whether it's 'data', or pointers, or instructions, it's all just bits in memory. Having to load into one part of the processor to use it as an offset seemed antithetical to that goal.
> The MSP430 is also a good learning processor, clean instruction set, not too much to take in at once, though there is mental overhead when you need to start being concerned with stack processing
It's got clean push and pop instructions, and R1(SP) an otherwise be accessed just like a normal register in the file. What are you thinking about there?
> and also with some jump instruction limits.
Yeah, I just stuck RAM and ROM within the limit on the emulated system they use so that doesn't come up.
Regarding the stack processing, I mispoke; I was recalling a different CPU, whereby, given an address in the R(0), it is possible to execute an instruction at a different memory address than the one the PC is currently pointing at, effectively giving you a second PC, which was frequently used to execute a function without jumping to the function. The easiest way to describe that concept is a mix-in.
And lol, yeah, the execute indirect processors are super goofy and I wouldn't subject students to that right off the bat.