I don't know how CPUs work so I simulated one in code (djhworld.github.io)

And that's when you start to fall into the deep rabbit hole that is FPGA's and VHDL/Verilog, all in the pursuit of that need for speed.

I don't think you lose three orders of magnitude of performance with a high level language. What a modern C compiler produces with a little help from the programmer should be reasonably close to what you can achieve by hand. Even slow languages like Python are not a thousand times slower than C. Maybe a hundred times.

> classical computer science problem called "Sisyphus dilemma" can be done in a single logic instruction

This sounds interesting and I'd like to read about it, but Google isn't helping.

    /**
  * 
  * @param n (41) the number of people standing in the circle
  * @return the safe position who will survive the execution 
  * ~Integer.highestOneBit(n*2)
  * Multiply n by 2, get the first set bit and take its complement
  * ((n<<1) | 1)
  * Left Shift n and flipping the last bit
  * ~Integer.highestOneBit(n*2) & ((n<<1) | 1) 
  * Bitwise And to copy bits exists in both operands.
  */
 public int getSafePosition(int n) {
  return ~Integer.highestOneBit(n*2) & ((n<<1) | 1);
 }

> Take a look to see how simple is working of a CPU, and by how many MAGNITUDES does the code size grow when any modern "programming paradigm" is involved.

Yeah, but you can't scale that to teams of programmers working on complex business logic.

1. CPUs are not simple by any means, as evidenced by spectre and meltdown

2. Sure, assembly is faster than Java script but good luck getting any abstraction or type safety in ASM. And also you're code is impossible to debug and takes 15 times longer to work on

> Lots of developers did not study CS at all

I do feel the same. A lot of "computer science" degrees are in fact just basic programming ones, and that often goes to masters, and rare cases PhD level degrees.

It is a common critic from industry that "computer science does not teach how to code," and I see too many universities seemingly taking it these days.

It is ironic how once computing science was once a road to unemployability and coding was all rife, but now companies don't want to hire people without degrees to do menial jobs like webdev.

Don't let yourself get too cynical! Development is becoming more accessible, and this is skewing the ratio.

I bet there are far more low level developers now than 30 years ago, however.

>my low level compute knowledge

But does it really make you better than other, very unlucky programmers, who doesn't have the "low level computer knowledge"? Does it make you the REAL programmer?

Because it's not. Because that's THE reason we have higher-level programming languages (and also lower-level ones) in the first place. Is computer just a black box to you? That's completely fine.

>computer scientist with close to no understanding of how a computer actually works

Which is how it's supposed to be.

Don't be such a gatekeeper.

What I find fascinating is that Lisp, commonly perceived as too high level to be practical, is actually at its core (in its original implementations!) an incredibly low level language.

Your emulator project is really neat. I would love to see more documentation on the design and process of it. The notes.md file was pretty spartan. Thanks for sharing. Cheers.

This is awesome, will look forward to following its progress

Just a few days ago I found NandGame, which is a browser game where you build a computer starting with just the Nand gate and using only components you already built for the next one. Pretty cool idea.

Hi author here!

I actually didn't set out on building anything, it all happened organically! I honestly cannot remember why I chose the book, I think I just saw the blurb and figured it was good enough to read.

It was only when I was a couple of chapters in that I figured I could probably whip something up in code :)

+1 for Nand to Tetris.

As someone who came to computing through high level software and a little later than many (I wasn't dismantling appliances at age 5 like you hear in a lot of people's origin stories) this was a really empowering ground-up introduction to hardware architecture.

One of the few Coursera courses [1] I actually finished and found rewarding, challenging and fun throughout.

1. https://www.coursera.org/learn/build-a-computer

There's a very good article [0] that makes rounds here very now and then. It gives a very good explanation of many of those concepts, while remaining understandable for those that haven't taken CPU design courses.

[0] http://www.lighterra.com/papers/modernmicroprocessors/

Edit: It'd be great a 2019 refresh (last update is from 2016) talking about Ryzen and the newer Intel designs.

I took this class at Georgia Tech as an undergrad and I also highly recommend it for the material. We had a chain of CS classes leading up to it (2110 -> 2200 -> 4290) on the undergrad side, but when I took it, this course was actually cross-listed as both an undergrad and graduate CS and ECE class (so CS 4290/6290 and the same sort of thing for the ECE major were all in the same literal lecture hall). Of course, most CS students were only taking this if they were in the System & Architectures thread (or maybe Devices?), but most CS students had to at least take up to CS 2200 (Systems & Networks, which basically took the concepts up to "Build me a working 1 CPU computer", whereas this class took the next steps from "Okay, so how do we do better than 1 instruction per cycle?"). Multi-core processors are really cool!

I frequently take for granted that most people don't have this foundational knowledge. The basics come up more than you'd think, especially when provisioning the right hardware for the task.

what are the prerequisites? C?

A colleague linked me to a similar course - I'll definitely be checking this out though - thanks

yes, that's notably the only publication by Microsoft Press, I can recommend ;)

An amazing book and one of my favorites, discovered just a few years ago sadly, I would have loved something like that when I was younger.

Anytime someone is starting out their development career and didn't go to school for CS, I recommend this book. It's a fast read and an excellent primer.

I actually read this book in 2012/13, it inspired me to build my gameboy emulator! It's definitely an excellent read.

I can't remember if the book discussed the gate level stuff, maybe that washed over me a bit at the time I'm not sure.

> but I'm kind of surprised that at no point did they attempt to build another

Perhaps because the existing implementation had already served its purpose - an educational exercise to understand CPU design, and not an instruction-level emulator or transcompiler.

Thanks for the feedback, these are some good ideas if I was do do this again.

I'm sorry you didn't think I took the best approach.

> I barely made it work well enough to get an ok grade but I learned that overconfidence can be more dangerous than the lack of.

That is a very important lesson.

> I went a little overboard and created a C backend for the emulator along with an in-browser JS client that was pretty much a full-blown machine language IDE and debugger.

Haha, this made me smile. I can totally relate to that ambitious line of thinking: given a task to solve, you imagined the logical next steps, to build an environment for solving that general class of tasks.

Great lesson about feature creep, but I also think that kind of vision and ambitious problem-solving can be valuable in the long term, if it works the whole community/ecosystem can benefit.

> I went a little overboard and created a C backend for the emulator along with an in-browser JS client that was pretty much a full-blown machine language IDE and debugger.

My original goal for the project was to type a letter on the keyboard and get something rendering on the screen, but I definitely felt the urge to keep implementing new things. Luckily the blog post took a lot of that urge away and focussed it on writing about the project!

This was my favorite part of college too. I think it was near the end of a really good networking class I took maybe my junior year when I distinctly remember chatting on AIM and thinking about how I could visualize approximately how my key presses were going from the hardware through the OS into memory into instructions on the CPU executing the application back out onto my screen and across the network to a server and on to my friend's machine for the reverse trip. It was a powerful moment. Of course as I've gone further through my career I've realized how far off my approximation was because everything is even more complex in the details, but I still think it was a fundamentally valid and valuable moment.

This is one reason I'm ambivalent about the skepticism around computer science / engineering programs as a prerequisite for a career in software development. It bums me out to think of people toiling at this work without experiencing that kind of bottom-up knowledge of computing. But I think this is largely a projection of my own personality on others; that would be a bummer for me, but I think many people don't care about any of that and just want to do valuable work for good pay.

Glad to hear from another survivor of Dr. Patts class. I took him for intro to computing first semester of college with no programming experience and I got wrecked by his class, but most of the content has stuck with me up through my career!

Cool.

I always find that "learn by doing" works best in these sorts of things :)

Oh yes, I've seen other people do similar things with 8-bit CPUs on a bunch of breadboards which is awesome, maybe I'll attempt that another time!

I did suffer a different form of pain with trying to implement all the gates together in a GP programming language - that was probably a bad idea in hindsight!

I started out doing hardware, as you say. Lots of bad soldering (initially). Expensive smoke and shitty chips from Radio Shack that appeared to have had their magic smoke removed prior to being shipped to stores in packaging that definitely was not anti-static. Capacitors that blew up into confetti, diodes that became LEDs for a single, glorious instant. Poking around in the back of old teevee sets and somehow avoiding being electrocuted or thrown against the wall by 30KV waiting patiently in a circuit where the bleed resistor had cracked. Realizing that you're going to need another paper route to afford the buffer chips and board work. Learning that manufacturer data sheets are sometimes full of lies. Redesigning the support circuitry for the CPU to remove just one more chip. Failing a bunch of high school courses because you were writing a BASIC interpreter (in anticipation of working hardware, someday) instead of doing homework.

Oh, I built a working computer, too. That was fun. But when at the end of that project you've got a processor and some RAM and a display sitting there in front of you, well, you realize that you don't really know what to do with the rig. Now what?

Then I realized that I could do far more damage in software (at scale) than with hardware (just one-off workbench class disasters). And so . . .

I remember in my college class that went over logic gates and all that, we had to make some circuits in a simulator program. I think we eventually made cycle-based adders in it. I'm pretty sure you could make a full CPU like that too.

Had to do the same assignment. I highly recommend doing it. Was the most painful thing I ever did in college, but it taught me so much about how processors work, and how to code in C.

Had almost the same assignement. We were teams of two, and we had to demonstrate that it works by implementing something very simple assembly instructions, we had to design them too. I was in charge of the pipelining and clocking and my colleague took the ALU and the I/O. Testing was job for both, AFAIK. I remember chasing a propagation bug, had to add some delays on some lines to get proper sync.

Realy really fun for a semester and a well deserved note at the end of it.

I had to do something similar although the task was to implement a subset of MIPS instructions and simulated pipelining and out-of-order execution.

Same thing for one of our computer engineering courses at UIUC. Great course, and while it took a long time to do it, it was a great experience (other than the fact that we had to do it in Mentor Graphics, which would randomly crash and eat your project). We had assembly programs we had to test against, and it was always really interesting debugging your register stalls. I think mine was a 5-stage processor, MIPS style, so we had to worry about all the pipelining. There were also a standard parts library so everyone was trying to compete against each other to get the best instructions per cycle.

I had a very similar experience, including a very late night trying to fix a weird integration problem along with my project team. We had spent hours trying to find the issue, but nobody was thinking effectively and we were making stupid decisions. Everyone wanted to keep going, but I insisted that we were not thinking clearly and that sleep would help us better solve the problem. I even promised I would come back first thing in the morning to start debugging again on my own. The team begrudgingly agreed and we walked away for the night.

I slept, came back in the morning, and had the problem fixed in like 15 minutes. I learned so much about CPU design from that class, but I also learned how important sleep is to thinking clearly.

Hello!

Really enjoyed your story.

While I wasn't up against any deadlines I did have a few of those so-simple-it's-painful fixes when I was doing this project haha

Has to do that. Implemented a 68000.

It was a stupid project. I learned nothing from the project that I had not already learned along the way with simpler toy instructional examples. And yeah, the double all-nighter and having one team member give up 12-hours before the due date was one of the worst experiences in my life.

I know that feel. I was tasked with wiring up the even / odd bytes for my team's Microcomputer. After countless hours of wire trimming and breadboarding, I was so afraid to boot up the board. Popped the brick in the wall, got a solid power light, and was presented with my terminal.

Huge sigh of relief, I might have just passed out then and there if I didn't have to continue.

Situations like this show why it's very important to have a complete understanding of the system when debugging --- the more complete your knowledge, the less likely it will be forgotten in panic/frustration and lead you to assume things about the system such as the correctness of certain parts.

I've been a TA for a course that did something very similar, and whenever a student came to me with a noticeably vague understanding (usually expressed as "it doesn't work, I've spent days on this and I don't know why"), I would observe him/her debugging it for a few minutes and showing it to me, and almost always I'd spot the problem right away; but instead of pointing it out, I would ask the student to print several copies of the circuit onto paper, then tell him/her to annotate all the signals with their expected values for the few cycles leading up to, including, and after the problematic one.

At this point a lot of them would look at me like I was insane, and reply with some variant of "I can't do it" or "we were never taught how to do that" and want to reach for the computer, whereupon I would stop them and show how. Once they figured it out, they would usually reach a point and say "I think this was my problem" --- wanting to go back to the computer again, and again I'd intervene to tell him/her to finish the whole annotation first (because they'd often have more bugs to be discovered.) Once finished, however, I'd let them use the computer again and compare, and then they would always have no problem finding and fixing the original bug, and perhaps several more after that.

I believe this is closely related to another phenomenon I've observed, which I call "debugger tunnel-vision", where a human using a tool and trying to debug a system essentially starts to blindly trust parts of it as being correct, because his/her own understanding of the functioning is itself unclear. My insistence on not using the computer and going back to pencil and paper (and brain) is, albeit probably quite "old-school" to some here, I believe an extremely important technique in being able to understand and debug effectively. It's worked not only for low-level hardware courses, but more high-level ones too --- where I tell students struggling with their code to "mentally execute" each step and compare the resultant expected values with those obtained. One of my favourite sayings is: How can you expect to be able to tell a computer what to do, if you yourself don't know how to do it?

Was it in a Bachelors course or a Masters course?

I had to do something similar for my computer architecture class using the program Logisim (http://www.cburch.com/logisim/)

I watched the Computerphile episode about this on Youtube when I was in the midst of the project, apparently it's at a Computer History museum in Cambridge now, I really should find the time to go!

I think the machine would need to be much _much_ faster, with the stack pointer register + a few extra instructions to even attempt a project like that hahahahaha