DETAILED ACTION
Claims 1-3, 5-6, 8-10, 12-13, 15-16, 18-19, 21-23, and 26-29 have been presented and examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 9 is objected to because of the following informalities:
Remove the underline between “a” and “MOVZ”. It appears that applicant is not intending to insert a space because a space previously existed (and because the claim is “Previously Presented”).
Claim 10 is objected to because of the following informalities:
In line 2, remove the underline. This appears to be left over from the previous amendment to add the comma.
Appropriate correction is required.
Claim Interpretation
Referring to claims 1 and 8, the term “constant-type instruction” does not have customary meaning to those of ordinary skill in the art. Thus, per MPEP 2111.01(V), the examiner is to check the specification for a provided meaning for the term. Paragraph [0005] does provide a meaning, stating “In embodiments according to the invention, a constant-type of instruction has zero input operands, one destination operand, and no effect on the condition code register, does not read from memory, does not write to memory, and does not require as input a result from another instruction.” As such, a constant-type instruction is interpreted according to this provided meaning. With respect to claim 15, although “constant-type instructions” is claimed, applicant also defines these instructions in the claim as those that do not read/write a memory, do not require as input a result from a second instruction, and bypass and are not executed by any of the plurality of execution units. As such, for claim 15 only, the examiner is not relying on the meaning set forth in paragraph [0005], but on the meaning set forth in the claim itself. Related interpretations/clarifications are as follows:
The “input operands” of paragraph [0005], and claims 3 and 10, are inputs that are results of other instructions (paragraph [0002]). Therefore, a constant-type instruction cannot include, as an input, a register, in a register file, that is written by a previous instruction. Of particular note, the ORR instruction in paragraph [0027] includes an xzr register input. However, the xzr register does not appear to be a writable register (from page C1-123 of the attached ARM reference, writes to xzr are discarded). Thus, it is the examiner’s understanding that the originally-disclosed ORR instruction (in original paragraph [0027]) is a constant-type instruction, because xzr is not an input that is a result of another instruction.
The “memory” of paragraph [0005], and claims 3 and 15, is interpreted to not include any register of a register file. This interpretation is necessary because claims 3 and 15 set forth that the instructions do not write to the memory. From original paragraph [0027], most instructions write to register Xd. Thus, if the claimed memory includes a register, claims 3 and 15 would encompass instructions that don’t write to a register, which is inaccurate. The examiner notes this limitation is explicit in claims 8 and 10 because the memory that isn’t written to, nor read from, is that which is coupled to the processor. From FIG.1, this means the memory can’t be a register because the registers are within the processor, not coupled to the processor.
Referring to claims 2, 9, and 16, the claimed instructions are limited to performing the functionality set forth in paragraph [0029] of the specification. This interpretation is consistent with the lower left module in the flowchart shown in MPEP 2111.01.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-6, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Eickemeyer et al. (US 6,336,160) in view of the examiner’s taking of Official Notice and Hiraoka et al. (US 5,418,917).
Referring to claim 1, Eickemeyer has taught a computer-implemented method, comprising:
receiving a first instruction by a processing pipeline, of a computer processor (see FIG.4, step 403, and column 4, lines 34-51. The first instruction is the instruction that would exist to load a most significant unused sector of a register with a constant value. An instruction is generally processed from fetch to writeback as shown in the pipeline of FIG.4), the processing pipeline having a plurality of execution units (from FIG.3, at least some of execution units 321-327);
Eickemeyer has not taught identifying the first instruction as a constant-type instruction of a plurality of constant-type instructions. However, Official Notice is taken that a load upper immediate (lui) (or load high (lhi)) instruction was well known in the art prior to applicant’s invention. Such an instruction loads a most significant half of a register with a value and is of the form lui Rd, #imm, where an immediate value (imm) is loaded into the upper half of register Rd. One of ordinary skill in the art would have recognized that this known instruction is a simple way to carry out the constant loading in Eickemeyer and would do so with minimal software (one instruction). The lui instruction has zero input operands written by a previous instruction, one destination operation (Rd), does not read from memory (the immediate value is encoded in the instruction itself), does not write to memory (only register Rd is written), and does not require as input a result from another instruction (the only input in #imm, which is not a result of a previous instruction). While Eickemeyer has not taught that the constant-type instruction has no effect on a condition code register, Hiraoka has taught, in column 7, lines 6-44, that loads do not change a condition code (positive, negative, overflow, etc.), but other instructions (e.g. adds) do. This simplifies execution of lui since it does not have to cause a change to the condition register. As a result, in order to simply load a constant, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer to include the lui instruction that does not affect the condition register. As multiple constants are loaded (Eickemeyer, column 4, lines 38-42), multiple lui instructions (a plurality of constant-type instructions) would exist. As such, Eickemeyer, as modified, would identify the first instruction as a constant-type instruction of a plurality of constant-type instructions since lui, as modified, meets all requirements for a constant-type instruction set forth by applicant in paragraph [0005] of the specification.
Alternatively, Official Notice is taken that a MOVZ instruction was well known in the art prior to applicant’s invention (a supporting reference (ARM) has been provided on July 8, 2021). MOVZ, which is a constant-type instruction for similar reasoning that the lui instruction is a constant-type instruction, loads an immediate value into a portion of a register indicated by a shift amount. For instance, for a 32-bit register, a shift value of 16 would cause the immediate value to be moved into the upper half of the register. For similar reasoning as above, it would have been alternatively obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer to include the MOVZ instruction that does not affect the condition register and for identifying the first instruction as a constant-type instruction of a plurality of constant-type instructions, the plurality either being multiple MOVZ instructions to load the multiple constants in Eickemeyer, or MOVZ and lui. When the instruction is lui, the plurality may also include MOVZ and lui.
Eickemeyer, as modified, has further taught assigning a register file to the first instruction (to load/move a constant value into a constant register, the constant register, and, thus, the register file including the constant register must be assigned to the instruction performing the load/move);
Eickemeyer, as modified, has further taught sending the first instruction to a constant circuit of the processing pipeline, the first instruction bypassing the execution units of the processing pipeline (a constant-type instruction would be sent to a constant circuit, which may include logic to fetch the instruction, decode logic, and processing logic to carry out the loading of the constant. While Eickemeyer does not disclose which unit processes the constant-type instruction, at most one of units 321-327 (FIG.3), if any at all, would process the constant-type instruction. The remaining would be bypassed. Those that are bypassed form the claimed plurality of execution units. As an example, if the lui/MOVZ is sent to unit 325 for processing, then only units 321, 323, and 327 make up the claimed plurality of execution units. Even if 325 is an execution unit, it is not interpreted as part of the claimed plurality of execution units. If the lui/MOVZ is instead sent to unit 321 for processing, then only units 323, 325, and 327 make up the claimed plurality of execution units. Even if 321 is an execution unit, it is not interpreted as part of the claimed plurality of execution units. In either example above, the plurality of execution units would be bypassed for lui/MOVZ processing);
Eickemeyer has further taught determining, by the computer processor at the constant circuit, a value of a constant associated with the first instruction using an opcode of the first instruction and a program counter value associated with the first instruction (the fetch logic that is part of the constant circuit uses a program counter, as is known in the art, to supply the memory address of the constant-type instruction to memory, and the memory responds by sending the instruction at the supplied address to the constant circuit. Ultimately, logic that is part of the “constant circuit” will recognize the opcode as one that performs a load of the constant to the constant register, and, consequently, performs the load. Without the program counter, no instruction would be fetched, and without an opcode specifying a load/move of a constant register, a constant to be loaded/moved is not determined. Thus, the determining the constant requires both the program counter and the opcode); and
Eickemeyer has further taught writing the value of the constant associated with the first instruction to the register file (again, see column 4, lines 34-51. The constant is loaded/moved/written into an upper half of a constant register);
Referring to claim 2, Eickemeyer, as modified, has taught the computer-implemented method of Claim 1, wherein the first instruction is a reduced instruction set computer (RISC) instruction selected from a group consisting of: an ADR instruction; an ADRP instruction; a BL instruction; an ORR instruction; a MOVZ instruction (see the rejection of claim 1, where MOVZ is present); and a MOVN instruction.
Claim 3 is mostly rejected for similar reasoning given in the rejection of claim 1. Furthermore, Eickemeyer has taught a memory coupled to the computer processor (see FIG.2 and note that at least RAM and ROM (both memories) are coupled to the CPU, neither of which would be accessed by a lui/MOVZ instruction).
Referring to claim 5, Eickemeyer, as modified, has taught the computer-implemented method of Claim 1, but has not taught detecting a value of a bit, and wherein the value of the bit indicates whether the first instruction is a type of instruction that has a constant value associated therewith. However, each instruction has a unique opcode and each opcode has multiple bits. The examiner asserts that any operation may be assigned to any opcode. For instance, perhaps lui/MOVZ is assigned opcode 01010, and ADD is assigned 01011. The mappings may be entirely arbitrary (and they vary in the art across processor ISAs), but any constant-type instruction could be adjacent to a non-constant type instruction. In the example situation above, the rightmost bit indicates whether the instruction is constant-type or not. That is, given four leftmost opcode bits of 0101, the rightmost bit indicates either constant-type (when ‘0’) or non-constant-type (when ‘1’). It would have been obvious to one of ordinary skill in the art to select any opcode mappings for constant- and non-constant-type instructions, and, consequently, detect a value of a bit, and wherein the value of the bit indicates whether the instruction is a type of instruction that has a constant value associated therewith.
Referring to claim 6, Eickemeyer, as modified, has taught the computer-implemented method of Claim 1, further comprising determining whether the register file is available prior to said assigning (again, from column 4, lines 34-51, the register will include a constant sector “if all the register bits are not in use by the instructions”. As such, constants registers are only available for assigning if they are available, i.e., if the processor is not using all bits in the registers for other purposes).
Referring to claim 26, Eickemeyer, as modified, has taught the computer-implemented method of Claim 1, wherein the constant circuit is configured to determine a respective value of a constant associated with each constant-type instruction of the plurality of constant-type instructions using a respective opcode associated with said each constant-type instruction and a respective program counter value associated with said each constant-type instruction (for similar reasoning as given in claim 1, note that this would occur for each constant-type instruction that is identified with a unique program counter value and that loads a respective constant based on its opcode. For example, from column 4, lines 38-42, a constant circuit determines to load a constant of “16” when the program counter value points to a constant-type instruction that has a load-constant type opcode that indicates to load a value of “16” to a register. The constant circuit would determine to load a constant of “4” when the program counter value points to a constant-type instruction that has a load-constant type opcode that indicates to load a value of “4” to a register. And so on).
Claims 8-10, 12-13, 21, and 28-29 are rejected under 35 U.S.C. 103 as being unpatentable over Eickemeyer in view of the examiner’s taking of Official Notice, Hiraoka, and Hughes (“PIPE Design Proposal”).
Referring to claim 8, most of the claimed operations are rejected for similar reasoning set forth in the rejection of claim 1. Eickemeyer has further taught a system (FIGs.1, 2, and 3 all show systems), comprising:
a processor (FIG.3, CPU 201) comprising a processing pipeline (FIG.4 shows a pipeline from fetch to writeback), the processing pipeline comprising a plurality of execution units (FIG.3, at least two of 321, 323, 325, and 327, which are units that carry out the execution stage of the pipeline (step 423)) and a constant circuit (the constant circuit would be the logic that receives lui/MOVZ instructions from memory as a result of a fetch and processes the instructions), the processor further comprising a plurality of register files (see column 4, lines 34-51 and FIG.3, which shows register files 305 and 307, which make up register file 301, and register files 309 and 311, which make up register file 303. Thus, there are anywhere from two to six register files depending on interpretation) and a cache (see FIG.3, cache 315); and
a memory coupled to the processor (see FIG.2 and note that at least RAM and ROM (both memories) are coupled to the CPU);
Eickemeyer has not taught that cache 315 is an instruction cache. Eickemeyer is silent on the type of information stored in this cache. However, Official Notice is taken that instruction cache and its advantages were well known in the art before applicant’s invention. Such a cache provides for relatively fast access (e.g. compared to main memory) of recently-used instructions that are likely to be used again in the future. As such, in order to improve speed of instruction fetching, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer such that cache 315 is an instruction cache.
Eickemeyer has also not taught the first instruction bypassing any execution unit, in the system, that includes an arithmetic logic unit. While Eickemeyer makes no mention of an arithmetic logic unit (ALU), which is a known component in the art, Eickemeyer also does not exclude the first instruction from being processed in an ALU. Official Notice is taken that an ALU was well known in the art before applicant’s invention (e.g. see attached Wikipedia article titles “Arithmetic logic unit”). An ALU is a component that performs, among other things, fundamental mathematical and logical operations such as addition, subtraction, AND, OR, XOR, etc. As a result, to realize this functionality with a common component in Eickemeyer, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer such that at least one of arithmetic units 321-327 in FIG.3 includes an ALU. Furthermore, Hughes has taught that an instruction (similar to lui/MOVZ) that loads an immediate value into a register (referred to as “LOADI”) does not go to an ALU but “has the immediate value routed directly to the given register” (see p.1, 4th paragraph. Also, note from p.1, 5th paragraph, that LOADI is not listed as an ALU instruction, meaning an ALU is not used to execute LOADI. Instead, an ALU is bypassed because the immediate of LOADI is sent directly to the register). This is beneficial because simply routing a value to the destination means processing through an ALU could be avoided, which could save time, and, further, allow an additional instruction to use the vacant ALU at the same time LOADI is processed. This improves parallelism and throughput, thereby allowing instructions to finish sooner. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer such that the first instruction bypasses any execution unit, in the system, that includes an arithmetic logic unit.
Claims 9-10 and 12-13, are rejected for similar reasons as claims 2, 1, and 5-6, respectively.
Referring to claim 21, Eickemeyer, as modified, has taught the system of Claim 8, wherein the plurality of register files comprises: a first plurality of constant registers, wherein each constant register of the first plurality of constant registers is dedicated to holding a value of a constant (see FIG.3, sector 305, column 1, line 51, to column 2, line 2, and column 4, lines 34-51. Under a first interpretation, this first plurality 305 is dedicated to holding constant values when 32-bit programs are running (and thus are not writing values greater than 32 bits to the registers). Alternatively, under a second interpretation, any subset/portion of 305 may be the first plurality); and a second plurality of registers other than the first plurality of constant registers (under the first interpretation, see FIG.3, sector 307. Under the second interpretation, another subset/portion of sector 305 may be the second plurality).
Claim 28 is rejected for similar reasoning as claim 26.
Referring to claim 29, Eickemeyer, as modified, has taught the computer-implemented method of Claim 1, but has not taught the first instruction bypassing any execution unit of the processing pipeline that includes an arithmetic logic unit (ALU). However, for similar reasoning set forth in the rejection of claim 8, such would have been obvious.
Claims 15-16, 18-19, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Eickemeyer in view of the examiner’s taking of Official Notice and Hughes.
Referring to claim 15, most of the claimed operations are rejected for similar reasoning set forth in the rejection of claim 1 (note that Hiraoka is not required to reject this claim based on how claim 15 is being interpreted (see “Claim Interpretation” section above)). Eickemeyer has also not taught the first instruction bypassing any execution unit, in the processing pipeline, that includes an arithmetic logic unit (ALU). While Eickemeyer makes no mention of an arithmetic logic unit (ALU), which is a known component in the art, Eickemeyer also does not exclude the first instruction from being processed in an ALU. Official Notice is taken that an ALU was well known in the art before applicant’s invention. An ALU is a component that performs, among other things, fundamental mathematical and logical operations such as addition, subtraction, AND, OR, XOR, etc. As a result, to realize this functionality with a common component in Eickemeyer, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer such that at least one of arithmetic units 321-327 in FIG.3 includes an ALU. Furthermore, Hughes has taught that an instruction (similar to lui/MOVZ) that loads an immediate value into a register (referred to as “LOADI”) does not go to an ALU but “has the immediate value routed directly to the given register” (see p.1, 4th paragraph. Also, note from p.1, 5th paragraph, that LOADI is not listed as an ALU instruction, meaning an ALU is not used to execute LOADI. Instead, an ALU is bypassed because the immediate of LOADI is sent directly to the register). This is beneficial because simply routing a value to the destination means processing through an ALU could be avoided, which could save time, and, further, allow an additional instruction to use the vacant ALU at the same time LOADI is processed. This improves parallelism and throughput, thereby allowing instructions to finish sooner. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer such that the first instruction bypasses any execution unit, in the processing pipeline, that includes an arithmetic logic unit (ALU).
Claims 16 and 18-19 are rejected for similar reasons as claims 2 and 5-6, respectively.
Claim 28 is rejected for similar reasoning as claim 26.
Claims 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over Eickemeyer in view of the examiner’s taking of Official Notice, Hiraoka, Hughes, and Shebanow et al. (US 5,675,759).
Referring to claim 22, Eickemeyer, as modified, has taught the system of Claim 21, but has not taught wherein said assigning comprises assigning a destination address to the first instruction, and wherein the operations further comprise: prior to said assigning the destination address to the first instruction, determining whether the first plurality of constant registers includes a constant register that is available; wherein when the first plurality of constant registers includes an available constant register, the destination address assigned to the first instruction is a destination address for the available constant register, and otherwise the destination address assigned to the first instruction is a destination address for a register of the second plurality of registers. However, Shebanow has taught one way to implement register renaming, which Eickemeyer performs. Shebanow keeps a list of free registers to be assigned for writing data. The list initially holds physical register identifiers in order (e.g. a list from PR0 to PR9 (see FIG.3a, list 34, where the head points to the next free register, and the head has already been incremented from the PR0 starting position through PR4 (which were assigned in order in unit 30). The claimed first and second pluralities may be arbitrarily defined portions. For instance, the first plurality could correspond to physical registers PR0 through PR4, and the second plurality could correspond to physical registers PR5 through PR9. In such a situation, when the head pointer points to PR5, it is determined that there is no more available registers in the first plurality (PR0 through PR4). As such, a register from the second plurality (PR5) is assigned as a destination address. Had the head pointer been pointing to PR4 (e.g. one instruction earlier), then it would have been determined that there is an available register in the first plurality and it would be appropriately assigned as the destination address (as shown in FIG.3a, unit 30, where it is assigned as the destination address corresponding to logical register 4 (LR4). This is one way simple way to implement register renaming using a circular queue and head/tail pointers to track which registers are free. In addition, per the abstract, Shebanow’s system allows for accommodation of backup/backstep procedures to recover from exception/mis-speculation. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Eickemeyer such that said assigning comprises assigning a destination address to the first instruction, and wherein the operations further comprise: prior to said assigning the destination address to the first instruction, determining whether the first plurality of constant registers includes a constant register that is available; wherein when the first plurality of constant registers includes an available constant register, the destination address assigned to the first instruction is a destination address for the available constant register, and otherwise the destination address assigned to the first instruction is a destination address for a register of the second plurality of registers.
Referring to claim 23, Eickemeyer, as modified, has taught the system of Claim 22, wherein said determining whether the first plurality of constant registers includes a constant register that is available comprises accessing a first list that identifies which registers of the first plurality of constant registers are available (as explained in the rejection of claim 22, the freelist could be seen as multiple lists, where the head pointer is used to access a given list. From the initial state, entries in the freelist storing PR0 through PR4 would be a first list. The head pointer is initially at PR0, which means the head pointer is accessing the first list to see what is available); and wherein the operations further comprise accessing a second list that identifies which registers of the second plurality of registers are available (starting in the state of FIG.3a, the first list is no longer accessed because PR0 through PR4 have been cycled through. The head pointer is now at the second list starting with PR5 and ending with PR9, each of which are indicated as available).
Response to Arguments
On page 10 of applicant’s response (hereafter “the response”), applicant argues that the claims and specification state that once it is determined that the first instruction is a constant-type instruction, the first instruction is sent to a constant circuit.
While this appears to be more of a summary of the invention as opposed to an argument, the examiner notes that the claims don’t require that the sending occur in response to the determining. And, claim 15 does not even require the determining.
On page 10 of the response, applicant argues that Eickemeyer sends an instruction to an arithmetic unit (321-327) and, thus, does not teach not sending the instruction to any execution unit that includes an ALU.
First, the examiner notes the breadth of claim 1, which does not require not sending to ALUs. Claims 8 and 15 do require not sending to any ALU. The different grounds of rejection above reflect the differences in breadth. Further, units 321-327 are listed as arithmetic units, not ALUs. An arithmetic unit is not necessarily an ALU, which is a well-known processor component that carries out arithmetic and logical operations (see Wikipedia, “Arithmetic logic unit” included herewith). However, the examiner asserts that it is obvious for at least one of 321-327 to include an ALU. In such a case, Hughes has been brought in to show that an instruction that simply loads an immediate value does not need to go to an ALU, but instead can cause the immediate to be routed directly to the register. This is because the ALU performs math (addition, subtraction, etc.) and bitwise operations (e.g. AND, OR, XOR, etc.), and simply loading an immediate into a register requires neither math nor bitwise operations. Thus, the prior art in combination would not send a constant-type instruction to any ALU.
Conclusion
The following art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wikipedia has taught the basics of an ALU.
Al Sheikh (US 2020/0356372) has taught early instruction execution for simple operations such as load-immediate.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David J. Huisman whose telephone number is 571-272-4168. The examiner can normally be reached on Monday-Friday, 9:00 am-5:30 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta, can be reached at 571-270-3995. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/David J. Huisman/Primary Examiner, Art Unit 2183