How we pack so much stuff into "The Elements of Computing Systems" book/course
I am intrigued to see this thread about the book/course that I developed together with Noam Nisan, and would like to answer the question posed in the post title, as long as the related question -- what is given up in the process. Actually, I just finished writing a paper addressing this very question, but the paper is under review so I will just quote an exceprt from it. Sorry about the length ... -- Shimon

Constructing a general-purpose computer from first principles is a humongous undertaking; accomplishing this task in one semester requires some concessions. With that in mind, our approach is based on four simplifying principles: no exceptions, no efficiency, no special features, no design uncertainty.

No exceptions: throughout the projects, it is deliberately and explicitly assumed that all inputs are error-free. For example, when writing the assembler or the compiler, we assume that the source files that the translators have to process contain only valid Hack and Jack code, respectively; there is no need to write error checking and messaging code. In a similar fashion, when we develop the Add16 chip or the ALU, we explicitly ignore overflow; there is no need to design special logic and circuitry to handle this exception.

We believe that ignoring exceptions – if done openly and explicitly – is perfectly acceptable. The act of analyzing and documenting missing or wanting features in one's implementation is an important exercise, educating for honesty and accuracy.

No efficiency: Some of our hardware and software designs are inefficient. For example, consider how we build a RAM chip. First, we build an 8-register RAM. Next, we assemble eight such chips with some addressing logic to build a 64-register RAM. Next, we assemble eight such chips to build a 512-register RAM. Three similar steps later we end up with the 16K memory chip required for the Hack computer. The resulting RAM design is elegant, but far from optimized. In the context of this course though, this is acceptable: striving for beauty and elegance is no less important than striving for efficiency, and in many cases both pursuits lead to the same end.

How manifest is the inherent inefficiency of the Hack/Jack platform? When we set out to design this platform several years ago, we defined our efficiency lower bound as follows: we wish to design a computer that will be sufficiently fast to execute interactive graphics and animation programs without visible delays. This goal has been achieved: hundreds of computer games like Tetris and Space Invaders were already developed in the Jack language by students and self-learners. Following compilation, these programs run smoothly on the Hack platform (for example, see http://tinyurl.com/4yxmoyv).

No special features: It would be nice to have a fancy ALU that supports floating point arithmetic; it would be nice if the high level language featured more data types; it would be nice if the compiler had error diagnostics; it would be nice if the virtual machine were optimized; it would be nice is the operating system supported a file system; it would be nice to write a Scheme interpreter over the Hack platform; and wouldn’t it be nice if two Hack machines could communicate over the Internet? The list of "nice to haves" goes on and on. Every one of these suggestions provides an excellent pretext for a fruitful and lively class discussion and advanced projects.

No design uncertainty: In this course, all the software designs are given. The students are not asked to design anything – they "merely" have to implement the supplied HDL stub files and APIs. We believe that except for software design courses, students should not be asked to design systems. Our experience shows that college students, as well as entry-level programmers, are not sufficiently mature to engage in design; letting them loose on a non-trivial design task can cause more damage than benefit. License to design a system should be given only after one has reviewed, understood, and implemented, many examples of good designs. Thus, discussing and implementing good designs – either by creating or borrowing them – should be a central part of our teaching mission.

Taken together, the limited treatment of exceptions, efficiency, and special features serves an important educational purpose: it focuses the students' minds on the big picture. One of the major goals in this course is to expose great ideas and gems in applied computer science, as they unfold in hands-on implementations. This level of engagement requires focus and concentration that cannot be achieved without setting explicit limits on scope and resolution.

Relevant URL: www.idc.ac.il/tecs