Is it usual design that the addition operation in the arithmetic-logic unit is performed by default as other instructions are executed?

Question

The book But How Do It Know? presents an 8-bit computer architecture in which arithmetic-logic instructions (that is, instructions which are executed by the ALU) have 1 as the most significant bit, and are defined by the next three bits, while the others have 0 as the most significant bit.

In particular, the addition instruction has binary op code 1000, and the architecture seems to take advantage of this default 000 (which is the same as not sending any value in the three bits of the instruction selection "mini-bus") in order to perform sums of given A and B byte inputs in the arithmetic-logic unit during other non-logic instructions. In other words, if no other ALU operation is selected, then by default the values ​​of inputs A and B will be added while executing other, non-ALU, instructions.

For example:

1. Given three consecutive bytes of memory, namely: a non-ALU instruction called DATA that moves a byte in memory to a general purpose register, the byte to be moved, and finally the byte of the next instruction, which would otherwise be in the second position (since instructions usually occupy one byte);

2. and also given a six-step stepper (seven, but the last one immediately returns to the first);

...we have the following, according to the book:

After the first three steps of the instruction cycle, which fetch the DATA instruction of opcode 0010, the fourth step moves the second byte to the register, and, although there is no evidence in the image below, it takes the opportunity to add input A from the instruction address register (IAR) to input B which has the "Bus 1" bit enabled (and which makes it a fixed byte evaluating to 1). This results, in the accumulator register (ACC), in the value of the position which follows the instruction stored in IAR, which falls in the third consecutive byte (since the IAR already came from step three with an incremented position in relation to the position of the DATA instruction).

My question is whether this implicit behavior of adding inputs A and B, even as other non-ALU instructions are executed, is a common design in computer architecture (say, for the purpose of optimizing the steps of the instruction cycle).

It raises two other questions that I wanted to confirm: first, in the case that behavior is the default, then what is done with input B when you want to avoid it, that is, when you don't want to perform the sum and instead store only the value of input A in the accumulator register?

I imagine that in order to achieve this, input B needs to receive a 0-valued byte (so that the sum A + 0 = A effectively occurs, which is the same as if it didn't occur at all). But its value always comes from the bus or the TMP register which precedes the input B (and which only has the "Set" bit and not the "Enable") and I don't see any possible way to set this value to zero, except by setting the TMP register to zero in the instruction before the current one. Is that what is usually done?

Hence as a last question, it was not clear where this "Set" bit of the TMP comes from (I think it should come from the control section whenever necessary, but I didn't see that bit being set in the book, so I'm not sure about that). Although, by confirming the previous doubt, it is already implied that this last assumption is correct.

In fact, all those questions can be summed up into a single one, which is to confirm whether these mutually related assumptions of mine are correct.

I still have another question which is where the 0-valued byte set in TMP comes from, but that would require further details about the architecture which I prefer not to include here.

Answer 1

From the above discussion, I'd like to expose you to a variety of ideas so that you can more readily see the scope of the reality of CPU designs and perhaps gather up the difficulty in trying to say what's normal.

• I'd like to start with a computer based upon a single type of relay: Harry Porter's Relay Computer, main web page at Portland State University and a 60-minute video discussing the overall architecture and the instruction set. This is well worth the time. (You can also get schematics.)
• A book that provides an overview of the main sections of a simple 8-bit CPU written, I believe, for software developer types: Bebop Bytes Back: An Unconventional Guide to Computers by Clive Maxfield & Alvin Brown. This is a very easy to read and understand book. The first half of it is targeted squarely at understanding the key elements of a CPU design. You can stop after reading just the first half. But by the time you get through that much, you will have gathered up the key bits and how they relate to each other. It's a good segue for those who otherwise have few clues to start with.
• The book called Microprocessor Design Using Verilog HDL by Monte Dalrymple. This is a well-crafted and extremely detailed book on performing a re-design of the Z80 MCU. This book goes start-to-finish on how one begins with a specification and takes it all the way to completion. There isn't a single book that does this nearly so well. It's something you won't read in a single setting, though. You will use it as a continuing study. It includes all the details of designing a full bus cycle, as well. I cannot recommend another book like it. It's unique. And worth having. You won't see this kind of book written often and if you find another one, I'd like to know about it!
• Neemann's Digital Logic Simulator (github link) is actually much, much more than a digital logic simulator and well worth having. I won't list them here, but you should read through the features listed at the site. As part of an installation (easy to do), you get both a Harvard and a von Neumann implementation of a processor. You can also go to this github site to pick up a TTL version of another CPU. And I'm sure there are many more such, as well.
• I've already mentioned the web simulator: WebRISC-V - RISC-V PIPELINED DATAPATH SIMULATION ONLINE. At this site, you are exposed to a pipelined incarnation of RISC-V. This relatively new entry is literally going to take over the world, so it is well-worth some study. Keep in mind that the number of pipeline stages are not limited to what you see here. This is just one way of many. Some may have fewer stages, some many more stages. But the ISA is well-standardized across the board. And there is increasing amount of information available. You can search out github for many other incarnations (though not so easily visualized because they usually do not include a web simulator) to study. But here are a few: PulseRain Reindeer - RISCV RV32I[M] Soft CPU, VexRiscv: A FPGA friendly 32 bit RISC-V CPU implementation, PicoRV32 - A Size-Optimized RISC-V CPU, SCR1: high-quality open-source RISC-V MCU core in Verilog, RiftCore: 9-stage, single-issue, out-of-order 64-bits RISC-V Core, which supports RV64IMC and 3-level Cache System, Rift2Core: Based on Chisel3, Rift2Core: 9-stage, dual-issue, out-of-order 64-bits RISC-V Core, which supports RV64GFD and 3-level Cache System, RV12 RISC-V 32/64-bit CPU Core, SERV - The SErial RISC-V CPU, videos worth watching about SERV. and there are many many more.

The x86 family today is quite sophisticated. There is a 7-clock front-side bus cycle that includes: Request phase, Error phase, Cache Hit phase, and 4 successive Data phases. These can be over-lapped, so that after a Request is issued by one CPU, which is now waiting on the Error phase, another CPU can issue a Request. And so on. That's just the part that deals with feeding the CPU. When the chipset responds with data to a Request, the results are stored in a short (was 32-byte, but I think it has been lengthened to 64-byte... possibly more) strip of memory where the instructions are decoded. Two decades ago, this was one "complex instruction" decoder that worked in parallel with three "simple instruction" decoders that operated in a single clock to move instructions into RISC instructions in the ROB (re-order buffer) for out-of-order execution. There are registration stations involved for the functional units (floating point, integer, bus, etc), which are allocated to the RISC instructions needing to execute. Eventually, these are processed and released by a "retire unit" that removes them "in-order" so as to simulate expected in-order behavior. (I've avoided so many other sections, such as branch prediction. But suffice it that the architecture is relatively complex.)

Intel provides many references (for example, you can examine this one to get some idea about the bus phases mentioned earlier.) But outside companies also provide a wide spate of training materials, too. Mindshare, Inc. used to be one such company, which not only offered many books on the topic but also training courses (which of course I was enrolled into when working at Intel on the BX chipset design/testing.)

But I very much recommend that you avoid the Intel and AMD processors until after you have gained more familiarity with the various kinds of functional units. Focus first on either 8-bit or 16-bit simple CPUs without segmented memory to virtual memory to physical memory translation units and paging support. Start simple, work upwards from there as your interests allow.