Others have already done what strikes me as a reasonable job of answering your first question, so I'm going to concentrate on your second question. Here's a rough idea of one way to structure a CPU.
This is assuming a CPU on the general order of an x86, where many operations specify a source and a destination register, where the source field really specifies both a source and a destination. That is, you take the specified source and destination registers as inputs, modify them as specified in the instruction, and deposit the result in the specified destination.
So in this picture, I haven't tried to show the instruction decoder, just the three primary fields: the source, destination, and op-code fields. The source and destination fields each choose a register to read from, and feed into all the functional units. The op-code field then chooses which of those results to keep. The destination field is also fed to a demultiplexer to choose which register to write the result to.
For a CPU that has separate fields for source 1, source 2, and destination, the destination field would connect to the demultiplexer, and the source 1 and source 2 fields would connect to the first two multiplexers.
Side note: the technique of feeding the operands to all the execution units and using a multiplexer to choose which of those to keep is used primarily in relatively small CPUs, at least in my experience. For a couple of examples, this is used in both the 6502 and (at least some versions of) the Xilinx Picoblaze.
For "larger" CPUs, you could use a demux connected to the op-code field, feeding an enable line for each execution unit. In this case, you could use pull-downs on the outputs, and wire-or the results.
Of course, a modern high-end CPU has a considerably more complex structure. In particular, with multiple instructions executing concurrently, your results will normally be written to a large bank of rename registers, with a separate demux for each execution unit1, so in one cycle you might do an addition that deposits its result in one register and also a multiplication that deposits its result in a different register.
Oh, and of course, this is only showing a subset of the real instructions. In a real CPU, you'd typically have a fair number more. Likewise you might easily have more than 8 registers. This doesn't really affect the structure though, just the widths of the mux/demuxers.
1. Well, since those wide muxes and demuxes can be fairly expensive, you typically don't actually have a separate demux for each execution unit. Rather, you might have, say, half a dozen or so groups of execution units, each with a demux to choose its destination, allowing up to six instructions to execute in parallel.