Opty:

Firstly, may I say: Thank You. Your post led me to reread Dispain again, too.

I misread one section refering to the location in terms of bytes; I originally though I read it as bits, and my thinking was erroneous as to the position of an instruction possibly being located within bytes that were not located on the boundary of the instruction group. My error.

In consideration of your pointing out my error, I would now agree with your assessment that the 32-bit word has but two boundaries: the beginning and the end.

In the '584 specification, the predetermined location is a function of the opcode, in fact the type of instruction included as the opcode inherently contains the location of the accessed instruction, i.e., one can assume what that predetermined location is based on the opcode, or type of instruction. Additionally, the use of the term "decoding," in my opinion, is a matter of symantics.

An from Despain regarding my opinion on decoding symantics and examples of the predetermined location as an inherent function of the opcode, itself:

148. For conciseness, I will refer to this disputed term "the 'decoding' step." The parties agree that the term "decoding" relates to "interpreting an instruction, in particular the portion thereof that signifies the operation to be performed," which is consistent with how the term is used in the art. "Decoding" an instruction generally refers to interpreting it into internal control signals for the execution section of the microprocessor. See, e.g., '584, 6:3-4. As a rule, all portions of an instruction are decoded. In this case, however, the language of claim 29 states that the instruction is decoded "to locate said predetermined position." As described above, the "predetermined position" is intended to be always the same for instructions of a given type.

Your question regarding whether the decoding is require at all is a good one, as Despain alludes to in this excerpt from his deposition:

150. Plaintiffs' proposed construction of the "decoding" step also emphasizes that the predetermined position is indentified "without reference to operand or address bits in the
instruction being interpreted," which reflects the processor behavior described in the '584 specification. As noted above, an instruction can be thought of as having various discrete parts, including an opcode that identifies the operation the processor is to perform and some number of operand identifiers (which in the general case might be immediate operands, register identifiers, and/or memory addresses, as discussed above with reference to "operand"). See Amd. 11/21/97 at 8, Ex. 16. In response to a given opcode, the processor will always perform the same action, such as adding two operands, loading an operand into a register or onto a parameter stack, branching or jumping to a new point in the program code, and so on, even though the operand data may vary among instances of the same instruction. Thus, a particular opcode determines certain aspects of processor behavior but not all of them. Of interest here is the "predetermined position," which is identified without reference to operand or address bits as Plaintiffs' construction states.
151. This can be seen by reviewing the examples of instructions that claim 29 is intended to cover. See Amd. 2/05/98 at 7-8, Ex. 17. Consider, for instance, the SKIP instruction. When a SKIP instruction is encountered, assuming any condition is satisfied, the 2-bit microinstruction counter (labeled as 180 in Fig. 16 of the '584 patent) is reset to zero as the next instruction group is latched into instruction register 108. '584, 14:20-27. The resetting of the microinstruction counter causes execution of the next group to begin at the beginning boundary of the group, i.e., the "predetermined position" for a SKIP instruction. See Amd. 2/05/98 at 7, Ex. 17. Similarly, for a MICROLOOP instruction, if the loop counter is not zero, the 2-bit microinstruction counter is cleared. '584, 14:54-57. Clearing the counter without loading a new group causes execution to return to the beginning boundary of the accessing group, i.e., the "predetermined position" for a MICROLOOP instruction. See Amd. 2/05/98 at 7, Ex. 17.
152. For a BRANCH instruction, the target is aligned at a 32-bit word boundary. '584, 20:35-36, 21:43-45. The target word is selected based on an operand, but since the target is predetermined to be aligned at the boundary, the microinstruction counter can be reset simply based on the fact that the opcode corresponds to the BRANCH opcode. Thus, the predetermined position, which in this case is the beginning boundary, is identified without reference to any operand.
153. The same principle applies where an operand is accessed. For example, in JUMP or IMMEDIATE instructions, the operand is "right justified in the instruction register. This means that the least significant bit of the operand is always located in the least significant bit of the instruction register." Id. at 16:15-18; Amd. 2/05/98 at 7, Ex. 17. The location of the operand relative to the end boundary can thus be determined based solely on the opcode, which indicates the presence of the operand. Similarly, for a LOAD-SHORT-LITERAL instruction, the operand is always in "Byte 4 of the current 4-byte instruction group." '584, 29:23-25.
154. As these examples show, the "predetermined position" for the accessing instruction is determined from the opcode, without reference to immediate operand or address bits in the instruction being determined. Plaintiffs' definition correctly describes the processor's behavior.

In summary, it is now my opinion that it appears that the '584 Claim 29, in its amended form, may not be rendered narrower or less-strong by introducing the term "first" with regard to the location of the "predetermined position from from a boundary of said instruction groups". I strongly believe that TPL's response - noting the MICROLOOP reference as purely an example - goes directly to the core of maintaining that the "boundary" may be either the beginning OR the end of the 32-bit, 4-word instruction group, as determined by the opcode.

I reiterate that my analysis remains one made from a non-expert perspective, though I believe it maintains a strong common sense evaluation and interpretation. I look forward to comments or corrections.

Thanks again for your prompting me to review my own review.

Cheers,

DG