Decoding Dilema ############### .. include:: /header.inc .. vim:filetype=rst spell: Chip designers live in a world of compromises. They have a bunch of parts they need to wire together, and a bunch of wires they need to route from point to point They must find a way to accomplish that, and factor in spacing problems, heat problems, electrical noise problems. Sheesh! It is a miracle that they even get this work done. In the modern world, most of those issues are addressed by software developed to find optimal solutions to a problem with way too many variables. When the smoke clears, we have a way to encode every instruction we want, and have packed all of the choices into a compact chunk of bits called an instruction opcode. Our job as decoders is to unravel this seemingly chaotic mess and figure out which instruction we are looking at when we fetch a chunk of that instruction. The Decoding Mess ***************** The chip manufacturer provides a detailed list of all available instructions for the chip. I put all of that data into a single JSON_ data file so I could study the bit patterns they came up with. It was pretty obvious that there were groups of instructions that you could identify by looking at the first four bits of the instruction. Unfortunately, the remaining 12 bits are still a mess, but you soon discover that there are only a few different ways they smashed together needed data into these bits. But how can we find usable patterns in the encoding that we can use to decode things? Enter Python ============ Python has tons of useful libraries, either packaged with the language, or easily downloaded into your system as you find a use for them. JSON_ processing os a simple task for standard Python (one of the reasons I built that JSON data file in the first place!) All we need to do it get Python to read the JSON_ data file, and sort things so we can look for patterns. Just a quick review of the encoding data shows us that examining all of the encodings in nibble format will be helpful. When I entered the encoding data for each instruction, I created a string with 4-bit groups of codes separated by spaces. This makes it simple for Python to break up the encodings. Then I constructed a complex dictionary, keyed by each 4-bit pattern. Python can sort the keys in a dictionary easily, so in the end, what I came up with was a list of 4-bit codes, four levels deep, each sorted and able to show which instructions share a particular bit pattern. Without getting too deep into the process, here is the python code I came up with: .. literalinclude:: code/decoder.py :linenos: :caption: decoder.py Running this produces a listing showing all of the patterns and how each instruction defined for our little chip are sorted out. .. note:: I placed a copy of the JSON_ data file, and the reference document used to generate the data in the ``files`` folder now in the CPUfactory3 repository. I am not going to show the entire output listing here, but we will look at a piece of that output: .. code-block:: text 1111 00kk kkkk k000 BRLO k k001 BREQ k k010 BRMI k k011 BRVS k k100 BRLT k k101 BRHS k k110 BRTS k k111 BRIE k ksss BRBS s, k 01kk kkkk k000 BRSH k k001 BRNE k k010 BRPL k k011 BRVC k k100 BRGE k k101 BRHC k k110 BRTC k k111 BRID k ksss BRBC s, k All of these instructions share a common pattern. The bits labeled "k" need to be collected into a single constant. There are 6 bits total in the encoding, and the legal values are :math:`0 <= k <= 63`. If you look closely, you discover that the three low bits in the third nibble are counting their way through a set of individual instructions. .. note:: The last instruction in each group is just another way of writing the same instructions shown above. We really do not need those instructions, so we will ignore them in our decoder. We can use nested C++ switch statements to decode this. All we need to do is unpack some bits into useful integers, then set up our switch statement: Let's try this out and see what we can build. Bit Twiddling ============= The ``C`` language was invented at a time when lots of programmers worked in assembly language. There were all kinds of instructions that could examine individual bits in a packed pile of bits. When ``C`` came along, they made sure that bit twiddling was still possible. The logical operators can be used to help out: * ``&`` logical AND on a set of bits * ``|`` logical OR on a set of bits * ``^`` logical XOR on a set of bits. Each of these operators uses a pattern of zeros and ones to do the magic. The ``&`` operator can be used to "mask off" certain bits. Just create a ``mask`` with ones where you want to keep the bits, and zeros where you want to remove bits, then use the expression ``num & mask`` to strip off the unneeded bits, making them all zero. The ``|`` operator can be used to set certain bits, but we will not be using that here. The ``^`` operator can be used to "toggle" bits, again something we do not need at the moment. Finally, we can use the shift operators (``>>`` and ``<<``) to slide bits left or right. Any bits that "fall off" of either end are just deleted. As we slide bits, zeros are added to the appropriate end. This is quite handy when you have the right bits in a group in a packed set of bits, and just want to slide them into position so they become a normal integer number. We will use these operators to unpack the needed data items to identify a particular instruction. Ready, Let's give this a try! Here is a random instruction (well, it will be one of those shown in that list above: .. literalinclude:: code/unpacker/ex01/main.cpp :lines: 5 Unpacking the instruction ========================= All of our example instructions are 16-bit encodings, but we need the four nibbles to work with. We can use the masking and shifting tricks to isolate those nibbles: .. literalinclude:: code/unpacker/ex01/main.cpp :linenos: :lines: 16-26 I am using the ``bitset`` class simply to display the data item in binary, to make sure I get the nibbles split out correctly. The heart of the action involves masking and shifting to get the bits needed in the right spot. The common mask is just ``0x000f``, this has our bits at the far right of a 16-bit number. I then use the right-shift operator to slide each nibble into position, where I use the mask to make sure that ony the right-most four bits remain in each nibble. The data item produced is still 16-bits big, but the left-most 12-bits are definitely all zeros after this operation! .. note:: You should be working to visualize what is happening in these operations. We are not thinking of this pile of bits as a number any more. They are just a set of bits sitting in a list, and we are manipulating them to get the bit pattern we want. Let's see this in action: .. program-output:: g++ -o demo main.cpp :cwd: code/unpacker/ex01 .. program-output:: ./demo :cwd: code/unpacker/ex01 That was pretty simple. Not quite as easy as doing things like this in Python, but C++ can do it once you learn the tricks! Now, we can set up our first level switch statement: .. literalinclude:: code/unpacker/ex02/main.cpp :linenos: :lines: 29-36 I left out most of the ``case`` lines, but for the general decoder, we do need them. We are using the first nibble from the instruction to break up our logic into more manageable segments. If you run the Python program on the JSON_ data file, you discover that many instruction groups will be pretty easy to decode. Others, not so easy (UGH!) We will not run this example, since we are just getting started. From the Python output above, we see that there are two bits in ``n2`` that select the group of instructions we need. Extracting that is another example of sliding the bits into place: .. literalinclude:: code/unpacker/ex03/main.cpp :linenos: :lines: 29-30 We also need to break out the three bits that select the right instruction from the group we just identified. Here is the (slightly complex) code needed to get the "k" value, and that second selector number: .. literalinclude:: code/unpacker/ex03/main.cpp :linenos: :lines: 32-34 Make sure you see how shifting and masking managed to put together the "k" value. .. note:: 42 is such a nice number, look at the bit pattern needed to set that number up! We have everything in place to decode our instruction now. Here is the nested switch statement that will do the job: .. literalinclude:: code/unpacker/ex03/main.cpp :linenos: :lines: 36-87 Although that is tedious to set up it should make sense. Here is the output: .. program-output:: g++ -o demo main.cpp :cwd: code/unpacker/ex03 .. program-output:: ./demo :cwd: code/unpacker/ex03 At each level in decoding this instruction, we identify a selector pattern that several instructions share. Each time we discover that several instructions share a particular encoding, we use another nested switch statement to identify the particular selector pattern we need, and home in on the exact instruction. Our decoder unit will probably be the biggest part of the simulator, which is why I am limiting the instructions we need to worry about. In my experiments, I am working on the full instruction set. It is not exactly hard work, but it takes time to set up. Those selectors we decoded in this experiment show how to get at the bits you need to define the operation of the machine. For these instructions, all we really need is that constant ``k`` value. We will send that on to the execute stage for processing, perhaps with additional data from the ``sel2`` value to identify exactly what these instructions need to do. More on that later. Hmmm, maybe I need to train my Python tool to write the C++ code. Such tricks have been used before!