Seriously? A 1 bit "full adder" is too complicated to build with discrete gates? If you are going to show people how to build a discrete 4 bit ALU then you really need to own it and at least build it with simple gates, if not transistors if you want to seriously own the discrete bit. As you can see in this reference (https://en.wikibooks.org/wiki/Microprocessor_Design/Add_and_...) a single bit full adder is 2 xor, 2 and, and an or gate. For for a four bit addr, that is 8 XOR (2 chips), 8 AND (2 chips), and 4 OR (1 chip), so 5 chips instead of one MSI 4 bit adder.
Building the full adder might even make it less ICs overall. Lots of tricks are lost here, for example the subtraction logic can be used to implement a NOT function if you add to zero. Rather than having an extra XOR chip you can implement XOR by using the adder but cutting the cout->cin path.
The 74x181 4-bit ALU IC implements all of this (plus quite a lot more) in 56 gates once you drop the carry-lookahead logic. That'd be about the same number of ICs as used in this project, but logic only.
I like projects like this. I started reading Code a while back, and thought it would be fun to make a computer out of relays, light bulbs, tinker toys, or whatnot. Then I started reading The Elements of Computing Systems, and thought about building something in a FPGA. One of these days.
I had The Elements of Computing Systems in my lap, opened to the chapter on creating an ALU as i came across this post :) Still have to build all the logic chips before I can implement the ALU though. This stuff is super fun.
Actually, you don't need to implement the other chips to create your ALU. You just have to implement the chips in the chapter. Each chapter is designed to be self-sustaining, so if you wanted to jump ahead to make the ALU you could, then later implement the underlying components.
Usable CPU's do not need caches, branch prediction and pipelining, and IO can be memory mapped.
There are other bits you need to make a usable CPU (for instance: registers, instruction decoder, instruction pointer and a stack pointer and some more glue), but the ones you mention are totally optional.
For software people who find this interesting and would like a great introduction, consider taking the course "Computation Structures" from MITx on EdX.
Part I cpvers basic logic gates, at both a high level (how you use them) and a lower level (how you build them on a chip), their characteristics (propagation delay, contamination delay, and things like that), combinatorial logic, sequential logic, state machines, pipelining, and probably more that I don't remember. The labs are done via a browser-based simulator, and by the end of the course you will have designed and implemented a 32-bit ALU with add, subtract, logical and arithmetic shifts in both directions by up to 31 bits, all the boolean operators, and the usual comparison operators.
Part II builds on that, taking you through designing and implementing a full 32-bit processor. Caching is discussed in the lectures, but not used in the processor.
Part III (which I did not have time to take), I believe, adds caching and pipelining to the processor, and covers parallel processing and device handling, and also operating system stuff.
For a while I wanted to actually build the processor from Part II using discrete 7400 series logic, but the chip count came in too high for me. My gate counts were: 295 AND2, 8 AND3, 3 NOR2, r OR2, 96 OR3, 20 OR4, 226 XOR2, 6 NOT, 563 MUX2, 161 MUX4. (That's not counting whatever I'd need for the control ROM and the 32 x 32-bit register file).
At 4 MUX2s per chip, and 4 AND2s per chip, that's 215 chips. Another 81 for the MUX4s and 57 for the XOR2s brings it up to 353. Without even tossing in the rest, I'm way over my limit.
I could cut this down quite a bit by taking out the shift unit (which uses 353 MUX2s), making the shift instructions generate an illegal instruction trap, and have the trap handler emulate the shift instructions. That would save 88 chips. (Well, not quite 88 chips...I think I'd have to add a "logical right shift by 1" instruction to make it so this approach would not be too slow, but a dedicated "logical right shift by 1" unit is a lot simpler than a "shift logical or arithmetic in any direction by any amount" unit).
The cool thing though, is that I, a software guy, could could actually make those hardware changes now. A lot of things about computers now make a lot more sense to me. I highly recommend it to those curious about what goes on at a lower level than we software guys normally deal with (even if we are writing software that interfaces with devices).
Also highly, highly recommend buying the book; this is one of those cases (unlike, for me, linear algebra) where you can soak up a pretty good fraction of the whole topic just by plowing through the text, and this particular text is pretty great.
