2
\$\begingroup\$

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).

Steps 4, 5 and 6 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.

\$\endgroup\$
13
  • 1
    \$\begingroup\$ Your "question" is really more of a soliloquy and there are so many different thoughts that arrive in mind that I'd almost have to respond with a soliloquy of my own. But there isn't really a single way things get done, these days. (Or ever, really.) Imaginative people come up with a variety of ways to get things done. But perhaps a simplified answer might be that in many cases there's no harm in performing an ALU operation and then throwing away the result if the result is irrelevant to the current instruction. I think you may want a tour of all the ways things are done. May not here, though. \$\endgroup\$
    – jonk
    Jan 31 at 2:15
  • \$\begingroup\$ You can have a ton of fun with WebRISC-V - RISC-V PIPELINED DATAPATH SIMULATION ONLINE, though!! Highly recommended. Load up a simple program and step through it, clock by clock, and see how it works. This is but one example of a modern processor (Berkeley ISA design applied to a specific implementation of it.) It even includes different behaviors whether you want execution in the branch delay slot, or not. \$\endgroup\$
    – jonk
    Jan 31 at 2:19
  • \$\begingroup\$ @jonk Thanks for your comments. Even if a tour was allowed in this case, I think it would be too much. All I wanted to know is whether that was usual in von Neumann architectures, so I can evaluate if I have a reasonable grasp of their basic operation on a simplified architecture. That said, one or two examples of oft-used alternative approaches would be fine just to give an idea of it (although that could be considered a small tour as well). \$\endgroup\$
    – Piovezan
    Jan 31 at 8:31
  • \$\begingroup\$ I don't know anything about your book. I have designed and built CPUs that work. I can refer you to good books on concrete, specific designs and the process to follow in completing a design and implementation of it. I can refer you to a good, but simple to follow overview that covers the essentials without bogging down too much. But it is more than I'd like to write here. Would more books help? \$\endgroup\$
    – jonk
    Jan 31 at 9:55
  • \$\begingroup\$ A simple to follow overview would be a nice suggestion, along with possibly others, thank you. I just want to have an understanding from an application software developer's standpoint. Regarding to this qustion's answer, I take it that you have already answered it in your first comment, so I can expect the "Perform addition on the ALU by default" design not being the norm on von Neumann architectures and to find different approaches to it. \$\endgroup\$
    – Piovezan
    Jan 31 at 10:36

1 Answer 1

3
\$\begingroup\$

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.

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.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Very nice summary of a very complex topic. But, you mentioned the RISC-V, and said "this relatively new entry is literally going to take over the world". Haven't we been hearing this same refrain about RISCs going as far back as 1982(?) when David Patterson first described the RISC1? \$\endgroup\$
    – SteveSh
    Jan 31 at 20:03
  • \$\begingroup\$ @SteveSh It's just my own opinion. But I sincerely believe that it has the right mix and some unique qualities I've not seen before. I think it will reach and exceed the necessary critical mass. Intel and Apple are actively hiring RISC-V grads as if they cannot get enough and toolsets to support development are growing daily. I've been watching the evolution on a daily basis (I spend time every single day on it for the last year or so.) I've finally reached a tentative conclusion about the future. If I were younger, this is where I'd be banking my future. I am buying stock where I can. \$\endgroup\$
    – jonk
    Jan 31 at 20:16
  • \$\begingroup\$ I really appreciate the effort put on that answer and the perspective provided by the related discussion. It dives a good deal into computer architecture design to a point I may not be able to prioritize right now (or that may, I believe, be better suited to a systems developer), but which can be kept as an useful reference for future readings. Thank you very much for the effort put to answering all those questions. \$\endgroup\$
    – Piovezan
    Feb 2 at 17:02
  • \$\begingroup\$ As a side note, regarding the book Bebop Bytes Back: An Unconventional Guide to Computers, I spotted the similarly-titled book from the same author: Bebop to the Boolean Boogie: An Unconventional Guide to Electronics. Sounds like it's a prequel/complementary material, although its latest edition has been more recently published than the former. \$\endgroup\$
    – Piovezan
    Feb 2 at 18:02
  • \$\begingroup\$ @Piovezan Bebop Bytes Back stands alone and so far as I'm aware doesn't depend upon it. You don't need to get both (my opinion.) \$\endgroup\$
    – jonk
    Feb 2 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.