DETAILED ACTION
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 .
Claims 1-24 are pending in this office action and presented for examination. Claims 3, 5-8, 11-12, 14-17, 20, and 23 are newly amended by a preliminary amendment dated June 23, 2025.
In claim 5, line 1, “claim 1” appears to be newly added without appropriate underlining.
Specification
The disclosure is objected to because of the following informalities. Appropriate correction is required.
In paragraph [0033], second-to-last line, “instructions set” may have been intended to be “instruction set”.
In paragraph [0050], line 15, “the conflict comparison unit 320, can” should be “the conflict comparison unit 320 can”.
In paragraph [0054], line 5, “column 420” may have been intended to be “column 410”.
In paragraph [0055], line 7, “CRs instructions” may have been intended to be “CR instructions”.
In paragraph [0056], lines 7-8, “non-CRs instructions” may have been intended to be “non-CR instructions”.
In paragraph [0057], line 1, “non-CRs instructions” may have been intended to be “non-CR instructions”.
In paragraph [0058], line 1, “non-CRs instructions” may have been intended to be “non-CR instructions”.
Drawings
The drawings are objected to because:
Drawings shall be executed in durable, black, sufficiently dense and dark, uniformly thick and well-defined, lines and strokes without colorings. However, FIG. 4A, FIG. 4B, and FIG. 6 do not appear to meet this requirement.
The height of the numbers and letters shall not be less than 0.32 cm. However, FIG. 1, FIG. 2, FIG. 3, FIG. 4A, FIG. 4B, FIG. 5A, FIG. 5B, FIG. 6, and FIG. 7 do not meet this requirement.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 2, 10, and 13 are objected to because of the following informalities. Appropriate correction is required.
In claim 2, lines 2-3, “the instruction processing pipeline is configured to” may have been intended to be “the instruction processing pipeline is further configured to”. (For example, see claim 4, lines 2-3.)
In claim 10, line 2, “the first instruction” should be “the first CR instruction” for clarity, in view of the previously recited “the first instruction being a first CR instruction” in claim 9, line 12.
In claim 10, lines 2-3, “the instruction processing pipeline is configured to” may have been intended to be “the instruction processing pipeline is further configured to”. (For example, see claim 13, lines 2-3.)
In claim 13, line 2, “the second instruction” should be “the second CR instruction” for clarity, in view of the previously recited “the second instruction is a second CR instruction” in claim 12, lines 1-2.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a pipeline flush control unit … the pipeline flush control unit being configured to: …” in claim 1 (with further functionality recited in dependent claim 3) and claim 9 (with further functionality recited in claim 12), and “a pipeline flush control unit … the pipeline flush control unit … being configured to: …” in claim 24.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. The claim limitations above are being interpreted to cover pipeline flush control unit 300 of FIG. 3, including its constituent elements (i.e., conflict accumulator 310, conflict comparison unit 320, and conflict designations 330, which includes the table(s) having instructions classifications and conflict criteria as disclosed in paragraph [0053]).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation “the first instruction being configured to write to a first control register of the plurality of control registers” in lines 10-12. However, it is indefinite as to how an instruction (i.e., bits) can be configured to itself write to a control register.
Claims 2-8 are rejected for failing to alleviate the rejection of claim 1 above.
Claim 3 recites the limitation “the second instruction is configured to write to a second control register of the plurality of control registers” in lines 1-3. However, it is indefinite as to how an instruction (i.e., bits) can be configured to itself write to a control register.
Claim 4 is rejected for failing to alleviate the rejection of claim 3 above.
Claim 5 recites the limitation “the indication of the second instruction” in line 3. However, there is insufficient antecedent basis for this limitation in the claims.
Claim 6 recites the limitation “The processor of claim 1, wherein the processor is configured to clear the accumulator in response to initiating flushing of the instruction processing pipeline” in lines 1-3. However, there is no indication about how the recited function (clearing) is performed, as the recited function does not follow from the structure recited in the claim. As such, it is unclear whether the function requires some other structure or is simply a result of operating the processor in a certain manner. Specifying a particular structure that performs the recited function, provided such an amendment is supported by the original disclosure, would inform one of ordinary skill in the art of the metes and bounds of the functional limitation.
Claim 6 recites the limitation “the accumulator” in line 2. However, there is insufficient antecedent basis for this limitation in the claims.
Claim 8 recites the limitation “the instruction processing pipeline includes a RISC-V instruction processing pipeline” in lines 2-3. However, the metes and bounds of this limitation are indefinite. For example, it is indefinite as to how an instruction processing pipeline can include both a RISC-V instruction processing pipeline as well as another distinct element, which is a scenario encompassed by the claim language in view of the open-ended language “includes”. For example, it is indefinite as to the criteria by which an instruction processing pipeline is a “RISC-V” instruction processing pipeline in particular.
Claim 9 recites the limitation “CR instructions” in line 6. However, the metes and bounds of this limitation are indefinite. For example, paragraph [0005] appears to provide an explicit definition for “CR instructions”: “For purposes of this disclosure, instructions that affect operation of a pipeline are generally referred to as control register instructions, or CR instructions”. However, given that every instruction except for a no-operation instruction affects the operation of a pipeline in some manner, it is unclear as to whether a CR instruction is consequently any instruction besides a no-operation instruction. For example, it is unclear as to whether an add instruction that causes the pipeline to perform an add, and therefore affects the operation of a pipeline, is consequently a CR instruction. For example, it is unclear as to whether a CR instruction necessarily has to, or does not necessarily have to, entail some form of functionality associated with a control register. For example, it is unclear as to whether an instruction (such as an add instruction) that updates a flag (such as a carry flag) in a control and status register (i.e., a CSR) would consequently be considered a CR instruction. Note that this limitation is also recited in claim 9, line 12; and claim 12, line 2. Note that the similar limitation “CR instruction” is recited in claim 9, line 12; claim 9, line 16; claim 9, line 17; claim 12, line 2; claim 12, line 4; claim 12, line 8; claim 12, lines 8-9; claim 12, line 10; claim 12, line 11; claim 13, line 2; and claim 15, line 3 (two instances).
Claim 9 recites the limitation “non-CR instructions” in lines 6-7. However, the metes and bounds of this limitation are indefinite. For example, paragraph [0005] appears to provide an explicit definition for “non-CR instructions”: “Further for purposes of this disclosure, instructions that do not modify CRs or change behavior of a pipeline are generally referred to as non-CR instructions”. However, given that every instruction except for a no-operation instruction changes behavior of a pipeline in some manner (e.g., causes the pipeline to perform an operation), it is unclear as to whether a non-CR instruction is consequently a no-operation instruction. For example, to any extent that a particular instruction may both “affect operation of a pipeline” (see the explicit definition for “CR instructions”) and “not … change behavior of a pipeline” (see the explicit definition for “non-CR instructions”) in view of nuanced differences between “affect” and “change”, and “operation” and “behavior”, it is unclear as to whether such an instruction would be considered a CR instruction, a non-CR instruction, both, or none. For example, to any extent that a particular instruction may both “affect operation of a pipeline” (see the explicit definition for “CR instructions”) and “not modify CRs” (see the explicit definition for “non-CR instructions”), it is unclear as to whether such an instruction would be considered a CR instruction, a non-CR instruction, both, or none. For example, it is unclear as to whether an instruction being a non-CR instruction is dependent on the instruction not modifying a CR (singular) or CRs (plural). For example, it is unclear as to whether the “do not” language in the aforementioned explicit definition merely limits “modify CRs”, or further limits “change behavior of a pipeline” as well. For example, it is unclear as to whether an instruction that does not modify CRs, but does change behavior of a pipeline, is a non-CR instruction. For example, it is unclear as to whether an instruction that does modify CRs, but does not change behavior of a pipeline, is a non-CR instruction. For example, it is unclear as to whether an instruction (such as an add instruction) that updates a flag (such as a carry flag) in a control and status register (i.e., a CSR) would consequently not be considered a non-CR instruction. Note that this limitation is also recited in claim 11, line 2. Note that the similar limitation “non-CR instruction” is recited in claim 11, line 2; and claim 14, line 2.
Claims 10-17 are rejected for failing to alleviate the rejections of claim 9 above.
Claim 15 recites the limitation “the indication of the second CR instruction” in line 3. However, there is insufficient antecedent basis for this limitation in the claims.
Claim 15 recites the limitation “the second CR instruction” in line 3. However, there is insufficient antecedent basis for this limitation in the claims.
Claim 16 recites the limitation “The processor of claim 9, wherein the processor is configured to clear the accumulator in response to initiating flushing of the instruction processing pipeline” in lines 1-3. However, there is no indication about how the recited function (clearing) is performed, as the recited function does not follow from the structure recited in the claim. As such, it is unclear whether the function requires some other structure or is simply a result of operating the processor in a certain manner. Specifying a particular structure that performs the recited function, provided such an amendment is supported by the original disclosure, would inform one of ordinary skill in the art of the metes and bounds of the functional limitation.
Claim 16 recites the limitation “the accumulator” in line 2. However, there is insufficient antecedent basis for this limitation in the claims.
Claim 17 recites the limitation “the instruction processing pipeline includes a RISC-V instruction processing pipeline” in line 2. However, the metes and bounds of this limitation are indefinite. For example, it is indefinite as to how an instruction processing pipeline can include both a RISC-V instruction processing pipeline as well as another distinct element, which is a scenario encompassed by the claim language in view of the open-ended language “includes”. For example, it is indefinite as to the criteria by which an instruction processing pipeline is a “RISC-V” instruction processing pipeline in particular.
Claim 18 recites the limitation “determining, by the processor in response to completing the execution of the first instruction, that flushing of the instruction processing pipeline can be delayed” in lines 5-6. However, the metes and bounds of this limitation are indefinite. For example, it is indefinite as to whether the aforementioned limitation is intended to convey a determination that flushing of the instruction processing pipeline is to be delayed, or whether the aforementioned limitation is intended to implicitly convey that there is separate determination which determines whether the flushing of the instruction processing pipeline is actually delayed. Examiner recommends using more definite language than “can”.
Claims 19-23 are rejected for failing to alleviate the rejection of claim 18 above.
Claim 19 recites the limitation “control register (CR) instruction” in line 2. However, the metes and bounds of this limitation are indefinite. For example, paragraph [0005] appears to provide an explicit definition for “CR instructions”: “For purposes of this disclosure, instructions that affect operation of a pipeline are generally referred to as control register instructions, or CR instructions”. However, given that every instruction except for a no-operation instruction affects the operation of a pipeline in some manner, it is unclear as to whether a CR instruction is consequently any instruction besides a no-operation instruction. For example, it is unclear as to whether an add instruction that causes the pipeline to perform an add, and therefore affects the operation of a pipeline, is consequently a CR instruction. For example, it is unclear as to whether a CR instruction necessarily has to, or does not necessarily have to, entail some form of functionality associated with a control register. For example, it is unclear as to whether an instruction (such as an add instruction) that updates a flag (such as a carry flag) in a control and status register (i.e., a CSR) would consequently be considered a CR instruction.
Claim 19 recites the limitation “non-CR instruction” in line 3. However, the metes and bounds of this limitation are indefinite. For example, paragraph [0005] appears to provide an explicit definition for “non-CR instructions”: “Further for purposes of this disclosure, instructions that do not modify CRs or change behavior of a pipeline are generally referred to as non-CR instructions”. However, given that every instruction except for a no-operation instruction changes behavior of a pipeline in some manner (e.g., causes the pipeline to perform an operation), it is unclear as to whether a non-CR instruction is consequently a no-operation instruction. For example, to any extent that a particular instruction may both “affect operation of a pipeline” (see the explicit definition for “CR instructions”) and “not … change behavior of a pipeline” (see the explicit definition for “non-CR instructions”) in view of nuanced differences between “affect” and “change”, and “operation” and “behavior”, it is unclear as to whether such an instruction would be considered a CR instruction, a non-CR instruction, both, or none. For example, to any extent that a particular instruction may both “affect operation of a pipeline” (see the explicit definition for “CR instructions”) and “not modify CRs” (see the explicit definition for “non-CR instructions”), it is unclear as to whether such an instruction would be considered a CR instruction, a non-CR instruction, both, or none. For example, it is unclear as to whether an instruction being a non-CR instruction is dependent on the instruction not modifying a CR (singular) or CRs (plural). For example, it is unclear as to whether the “do not” language in the aforementioned explicit definition merely limits “modify CRs”, or further limits “change behavior of a pipeline” as well. For example, it is unclear as to whether an instruction that does not modify CRs, but does change behavior of a pipeline, is a non-CR instruction. For example, it is unclear as to whether an instruction that does modify CRs, but does not change behavior of a pipeline, is a non-CR instruction. For example, it is unclear as to whether an instruction (such as an add instruction) that updates a flag (such as a carry flag) in a control and status register (i.e., a CSR) would consequently not be considered a non-CR instruction.
Claim 21 recites the limitation “control register (CR) instruction” in line 2. However, the metes and bounds of this limitation are indefinite. For example, paragraph [0005] appears to provide an explicit definition for “CR instructions”: “For purposes of this disclosure, instructions that affect operation of a pipeline are generally referred to as control register instructions, or CR instructions”. However, given that every instruction except for a no-operation instruction affects the operation of a pipeline in some manner, it is unclear as to whether a CR instruction is consequently any instruction besides a no-operation instruction. For example, it is unclear as to whether an add instruction that causes the pipeline to perform an add, and therefore affects the operation of a pipeline, is consequently a CR instruction. For example, it is unclear as to whether a CR instruction necessarily has to, or does not necessarily have to, entail some form of functionality associated with a control register. For example, it is unclear as to whether an instruction (such as an add instruction) that updates a flag (such as a carry flag) in a control and status register (i.e., a CSR) would consequently be considered a CR instruction. Note that the similar limitation “CR instruction” is recited in claim 21, line 3; claim 21, line 5; claim 21, line 10; claim 21, line 11; claim 21, line 12; claim 21, line 13; claim 23, line 2; and claim 23, lines 2-3.
Claims 22-23 are rejected for failing to alleviate the rejection of claim 21 above.
Claim 22 recites the limitation “non-CR instruction” in lines 1-2. However, the metes and bounds of this limitation are indefinite. For example, paragraph [0005] appears to provide an explicit definition for “non-CR instructions”: “Further for purposes of this disclosure, instructions that do not modify CRs or change behavior of a pipeline are generally referred to as non-CR instructions”. However, given that every instruction except for a no-operation instruction changes behavior of a pipeline in some manner (e.g., causes the pipeline to perform an operation), it is unclear as to whether a non-CR instruction is consequently a no-operation instruction. For example, to any extent that a particular instruction may both “affect operation of a pipeline” (see the explicit definition for “CR instructions”) and “not … change behavior of a pipeline” (see the explicit definition for “non-CR instructions”) in view of nuanced differences between “affect” and “change”, and “operation” and “behavior”, it is unclear as to whether such an instruction would be considered a CR instruction, a non-CR instruction, both, or none. For example, to any extent that a particular instruction may both “affect operation of a pipeline” (see the explicit definition for “CR instructions”) and “not modify CRs” (see the explicit definition for “non-CR instructions”), it is unclear as to whether such an instruction would be considered a CR instruction, a non-CR instruction, both, or none. For example, it is unclear as to whether an instruction being a non-CR instruction is dependent on the instruction not modifying a CR (singular) or CRs (plural). For example, it is unclear as to whether the “do not” language in the aforementioned explicit definition merely limits “modify CRs”, or further limits “change behavior of a pipeline” as well. For example, it is unclear as to whether an instruction that does not modify CRs, but does change behavior of a pipeline, is a non-CR instruction. For example, it is unclear as to whether an instruction that does modify CRs, but does not change behavior of a pipeline, is a non-CR instruction. For example, it is unclear as to whether an instruction (such as an add instruction) that updates a flag (such as a carry flag) in a control and status register (i.e., a CSR) would consequently not be considered a non-CR instruction.
Claim 24 recites the limitation “the first instruction being configured to write to a first control register of the plurality of control registers” in lines 11-13. However, it is indefinite as to how an instruction (i.e., bits) can be configured to itself write to a control register.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 18-23 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Burger et al. (Burger) (US 6006325).
Consider claim 18, Burger discloses a method of processing (col. 1, line 29, processor) machine-readable instructions (col. 1, line 30, instruction stream), the method comprising: completing, in an instruction processing pipeline of a processor (col. 3, line 36, microprocessor machine pipeline), execution of a first instruction of the machine-readable instructions (col. 3, lines 49-51, at pipeline stage 270 the instruction is executed by an execution unit to determine a final result; col. 3, line 55, instruction that writes to a control register); determining, by the processor in response to completing the execution of the first instruction, that flushing of the instruction processing pipeline can be delayed (col. 6, lines 22-30, FIG. 4 illustrates an example of an instruction fetch serialization fence instruction in use. The first instruction is a write to a control register that turns on virtual memory (write VM__On into Control Register 1). Next, any number of instructions that do not reference memory may exist. But before any instruction that references the memory, the SRLZ.i serialization fence instruction is issued to ensure the effect of virtual memory translation will be visible for subsequent instructions; col. 6, lines 50-53, implementing the instruction fetch serialization fence instruction would be to flush the processor's pipeline only if the control register write affects the instruction stream fetching; col. 6, lines 60-63, The SRLZ.i instruction would then flush the machine pipeline only if the instructions fetched after the SRLZ.i instruction were fetched incorrectly since the control register effects were not observable yet; col. 5, lines 11-27, FIG. 3 illustrates an example use of the data memory reference serialization fence instruction. In FIG. 3, a write instruction writes a new status value to a performance monitor control register (PMCR). This change of the write instruction writes a new status value to a PCMR and will affect any subsequent data memory reference operations such as reads from memory or writes to memory. Therefore, before any data memory reference instruction the SRLZ.d serialization fence instruction should be executed. Note, however, that any number of instructions that are not affected by the write to the performance monitor control register may exist between the write to the performance monitor control register and the SRLZ.d serialization fence instruction. The SRLZ.d serialization fence instruction will ensure that the write to the performance monitor control register will be observed before the following instruction. As illustrated in the FIG. 3, the subsequent memory read instruction will observe the effects of the write to the performance monitor control register; col. 5, lines 50-56, however, the best method of implementing the data memory reference serialization fence instruction would be to stall the instruction issue phase if and only if any control register write latency period has not yet expired. Note that if the control register latency period has expired then the serialization fence instruction performs no operation (No-op); note that col. 4, lines 15-23, lists as alternatives stalling and flushing); recording an indication of the first instruction (col. 3, line 55, instruction that writes to a control register); examining the instruction processing pipeline to identify a second instruction of the machine-readable instructions in the instruction processing pipeline prior to completing execution of the second instruction (col. 6, line 27, instruction that references the memory; col. 5, line 18, data memory reference instruction; col. 4, line 3, dependent instruction); determining, based on a set of predetermined criteria, whether the second instruction conflicts with the first instruction (col. 6, lines 22-30, FIG. 4 illustrates an example of an instruction fetch serialization fence instruction in use. The first instruction is a write to a control register that turns on virtual memory (write VM__On into Control Register 1). Next, any number of instructions that do not reference memory may exist. But before any instruction that references the memory, the SRLZ.i serialization fence instruction is issued to ensure the effect of virtual memory translation will be visible for subsequent instructions; col. 6, lines 50-53, implementing the instruction fetch serialization fence instruction would be to flush the processor's pipeline only if the control register write affects the instruction stream fetching; col. 6, lines 60-63, The SRLZ.i instruction would then flush the machine pipeline only if the instructions fetched after the SRLZ.i instruction were fetched incorrectly since the control register effects were not observable yet); col. 5, lines 11-27, FIG. 3 illustrates an example use of the data memory reference serialization fence instruction. In FIG. 3, a write instruction writes a new status value to a performance monitor control register (PMCR). This change of the write instruction writes a new status value to a PCMR and will affect any subsequent data memory reference operations such as reads from memory or writes to memory. Therefore, before any data memory reference instruction the SRLZ.d serialization fence instruction should be executed. Note, however, that any number of instructions that are not affected by the write to the performance monitor control register may exist between the write to the performance monitor control register and the SRLZ.d serialization fence instruction. The SRLZ.d serialization fence instruction will ensure that the write to the performance monitor control register will be observed before the following instruction. As illustrated in the FIG. 3, the subsequent memory read instruction will observe the effects of the write to the performance monitor control register; col. 5, lines 50-56, however, the best method of implementing the data memory reference serialization fence instruction would be to stall the instruction issue phase if and only if any control register write latency period has not yet expired. Note that if the control register latency period has expired then the serialization fence instruction performs no operation (No-op); note that col. 4, lines 15-23, lists as alternatives stalling and flushing); and if the second instruction is determined to conflict with the first instruction, initiating flushing of the instruction processing pipeline (col. 6, lines 22-30, FIG. 4 illustrates an example of an instruction fetch serialization fence instruction in use. The first instruction is a write to a control register that turns on virtual memory (write VM__On into Control Register 1). Next, any number of instructions that do not reference memory may exist. But before any instruction that references the memory, the SRLZ.i serialization fence instruction is issued to ensure the effect of virtual memory translation will be visible for subsequent instructions; col. 6, lines 50-53, implementing the instruction fetch serialization fence instruction would be to flush the processor's pipeline only if the control register write affects the instruction stream fetching; col. 6, lines 60-63, The SRLZ.i instruction would then flush the machine pipeline only if the instructions fetched after the SRLZ.i instruction were fetched incorrectly since the control register effects were not observable yet); col. 5, lines 11-27, FIG. 3 illustrates an example use of the data memory reference serialization fence instruction. In FIG. 3, a write instruction writes a new status value to a performance monitor control register (PMCR). This change of the write instruction writes a new status value to a PCMR and will affect any subsequent data memory reference operations such as reads from memory or writes to memory. Therefore, before any data memory reference instruction the SRLZ.d serialization fence instruction should be executed. Note, however, that any number of instructions that are not affected by the write to the performance monitor control register may exist between the write to the performance monitor control register and the SRLZ.d serialization fence instruction. The SRLZ.d serialization fence instruction will ensure that the write to the performance monitor control register will be observed before the following instruction. As illustrated in the FIG. 3, the subsequent memory read instruction will observe the effects of the write to the performance monitor control register; col. 5, lines 50-56, however, the best method of implementing the data memory reference serialization fence instruction would be to stall the instruction issue phase if and only if any control register write latency period has not yet expired. Note that if the control register latency period has expired then the serialization fence instruction performs no operation (No-op); note that col. 4, lines 15-23, lists as alternatives stalling and flushing).
Consider claim 19, Burger discloses the method of claim 18 (see above), wherein: the first instruction is a control register (CR) instruction (col. 3, lines 49-51, at pipeline stage 270 the instruction is executed by an execution unit to determine a final result; col. 3, line 55, instruction that writes to a control register); and the second instruction is a non-CR instruction (col. 6, line 27, instruction that references the memory; col. 5, line 18, data memory reference instruction; col. 4, line 3, dependent instruction).
Consider claim 20, Burger discloses the method of claim 18 (see above), wherein, if the second instruction is determined not to conflict with the first instruction, the method further comprises completing execution of the second instruction (col. 6, lines 22-30, FIG. 4 illustrates an example of an instruction fetch serialization fence instruction in use. The first instruction is a write to a control register that turns on virtual memory (write VM__On into Control Register 1). Next, any number of instructions that do not reference memory may exist. But before any instruction that references the memory, the SRLZ.i serialization fence instruction is issued to ensure the effect of virtual memory translation will be visible for subsequent instructions; col. 6, lines 50-53, implementing the instruction fetch serialization fence instruction would be to flush the processor's pipeline only if the control register write affects the instruction stream fetching; col. 6, lines 60-63, The SRLZ.i instruction would then flush the machine pipeline only if the instructions fetched after the SRLZ.i instruction were fetched incorrectly since the control register effects were not observable yet); col. 5, lines 11-27, FIG. 3 illustrates an example use of the data memory reference serialization fence instruction. In FIG. 3, a write instruction writes a new status value to a performance monitor control register (PMCR). This change of the write instruction writes a new status value to a PCMR and will affect any subsequent data memory reference operations such as reads from memory or writes to memory. Therefore, before any data memory reference instruction the SRLZ.d serialization fence instruction should be executed. Note, however, that any number of instructions that are not affected by the write to the performance monitor control register may exist between the write to the performance monitor control register and the SRLZ.d serialization fence instruction. The SRLZ.d serialization fence instruction will ensure that the write to the performance monitor control register will be observed before the following instruction. As illustrated in the FIG. 3, the subsequent memory read instruction will observe the effects of the write to the performance monitor control register; col. 5, lines 50-56, however, the best method of implementing the data memory reference serialization fence instruction would be to stall the instruction issue phase if and only if any control register write latency period has not yet expired. Note that if the control register latency period has expired then the serialization fence instruction performs no operation (No-op); note that col. 4, lines 15-23, lists as alternatives stalling and flushing).
Consider claim 21, Burger discloses the method of claim 18 (see above), wherein: the first instruction is a first control register (CR) instruction (col. 3, lines 49-51, at pipeline stage 270 the instruction is executed by an execution unit to determine a final result; col. 3, line 55, instruction that writes to a control register); and the second instruction is a second CR instruction (col. 3, lines 49-51, at pipeline stage 270 the instruction is executed by an execution unit to determine a final result; col. 3, line 55, instruction that writes to a control register), the method further comprising: recording an indication of the second CR instruction (col. 3, line 55, instruction that writes to a control register); identifying a third instruction of the machine-readable instructions in the instruction processing pipeline prior to completing execution of the third instruction (col. 6, line 27, instruction that references the memory; col. 5, line 18, data memory reference instruction; col. 4, line 3, dependent instruction); determining, based on the set of predetermined criteria, whether the third instruction conflicts with the first CR instruction or conflicts with the second CR instruction (col. 6, lines 22-30, FIG. 4 illustrates an example of an instruction fetch serialization fence instruction in use. The first instruction is a write to a control register that turns on virtual memory (write VM__On into Control Register 1). Next, any number of instructions that do not reference memory may exist. But before any instruction that references the memory, the SRLZ.i serialization fence instruction is issued to ensure the effect of virtual memory translation will be visible for subsequent instructions; col. 6, lines 50-53, implementing the instruction fetch serialization fence instruction would be to flush the processor's pipeline only if the control register write affects the instruction stream fetching; col. 6, lines 60-63, The SRLZ.i instruction would then flush the machine pipeline only if the instructions fetched after the SRLZ.i instruction were fetched incorrectly since the control register effects were not observable yet); col. 5, lines 11-27, FIG. 3 illustrates an example use of the data memory reference serialization fence instruction. In FIG. 3, a write instruction writes a new status value to a performance monitor control register (PMCR). This change of the write instruction writes a new status value to a PCMR and will affect any subsequent data memory reference operations such as reads from memory or writes to memory. Therefore, before any data memory reference instruction the SRLZ.d serialization fence instruction should be executed. Note, however, that any number of instructions that are not affected by the write to the performance monitor control register may exist between the write to the performance monitor control register and the SRLZ.d serialization fence instruction. The SRLZ.d serialization fence instruction will ensure that the write to the performance monitor control register will be observed before the following instruction. As illustrated in the FIG. 3, the subsequent memory read instruction will observe the effects of the write to the performance monitor control register; col. 5, lines 50-56, however, the best method of implementing the data memory reference serialization fence instruction would be to stall the instruction issue phase if and only if any control register write latency period has not yet expired. Note that if the control register latency period has expired then the serialization fence instruction performs no operation (No-op); note that col. 4, lines 15-23, lists as alternatives stalling and flushing); and if the third instruction is determined to conflict with the first CR instruction or the second CR instruction, initiating flushing of the instruction processing pipeline (col. 6, lines 22-30, FIG. 4 illustrates an example of an instruction fetch serialization fence instruction in use. The first instruction is a write to a control register that turns on virtual memory (write VM__On into Control Register 1). Next, any number of instructions that do not reference memory may exist. But before any instruction that references the memory, the SRLZ.i serialization fence instruction is issued to ensure the effect of virtual memory translation will be visible for subsequent instructions; col. 6, lines 50-53, implementing the instruction fetch serialization fence instruction would be to flush the processor's pipeline only if the control register write affects the instruction stream fetching; col. 6, lines 60-63, The SRLZ.i instruction would then flush the machine pipeline only if the instructions fetched after the SRLZ.i instruction were fetched incorrectly since the control register effects were not observable yet); col. 5, lines 11-27, FIG. 3 illustrates an example use of the data memory reference serialization fence instruction. In FIG. 3, a write instruction writes a new status value to a performance monitor control register (PMCR). This change of the write instruction writes a new status value to a PCMR and will affect any subsequent data memory reference operations such as reads from memory or writes to memory. Therefore, before any data memory reference instruction the SRLZ.d serialization fence instruction should be executed. Note, however, that any number of instructions that are not affected by the write to the performance monitor control register may exist between the write to the performance monitor control register and the SRLZ.d serialization fence instruction. The SRLZ.d serialization fence instruction will ensure that the write to the performance monitor control register will be observed before the following instruction. As illustrated in the FIG. 3, the subsequent memory read instruction will observe the effects of the write to the performance monitor control register; col. 5, lines 50-56, however, the best method of implementing the data memory reference serialization fence instruction would be to stall the instruction issue phase if and only if any control register write latency period has not yet expired. Note that if the control register latency period has expired then the serialization fence instruction performs no operation (No-op); note that col. 4, lines 15-23, lists as alternatives stalling and flushing).
Consider claim 22, Burger discloses the method of claim 21 (see above), wherein the third instruction is a non-CR instruction (col. 6, line 27, instruction that references the memory; col. 5, line 18, data memory reference instruction; col. 4, line 3, dependent instruction).
Consider claim 23, Burger discloses the method of claim 21 (see above), wherein, if the third instruction is determined not to conflict with the first CR instruction or the second CR instruction, the method further comprises completing execution of the third instruction (col. 6, lines 22-30, FIG. 4 illustrates an example of an instruction fetch serialization fence instruction in use. The first instruction is a write to a control register that turns on virtual memory (write VM__On into Control Register 1). Next, any number of instructions that do not reference memory may exist. But before any instruction that references the memory, the SRLZ.i serialization fence instruction is issued to ensure the effect of virtual memory translation will be visible for subsequent instructions; col. 6, lines 50-53, implementing the instruction fetch serialization fence instruction would be to flush the processor's pipeline only if the control register write affects the instruction stream fetching; col. 6, lines 60-63, The SRLZ.i instruction would then flush the machine pipeline only if the instructions fetched after the SRLZ.i instruction were fetched incorrectly since the control register effects were not observable yet); col. 5, lines 11-27, FIG. 3 illustrates an example use of the data memory reference serialization fence instruction. In FIG. 3, a write instruction writes a new status value to a performance monitor control register (PMCR). This change of the write instruction writes a new status value to a PCMR and will affect any subsequent data memory reference operations such as reads from memory or writes to memory. Therefore, before any data memory reference instruction the SRLZ.d serialization fence instruction should be executed. Note, however, that any number of instructions that are not affected by the write to the performance monitor control register may exist between the write to the performance monitor control register and the SRLZ.d serialization fence instruction. The SRLZ.d serialization fence instruction will ensure that the write to the performance monitor control register will be observed before the following instruction. As illustrated in the FIG. 3, the subsequent memory read instruction will observe the effects of the write to the performance monitor control register; col. 5, lines 50-56, however, the best method of implementing the data memory reference serialization fence instruction would be to stall the instruction issue phase if and only if any control register write latency period has not yet expired. Note that if the control register latency period has expired then the serialization fence instruction performs no operation (No-op); note that col. 4, lines 15-23, lists as alternatives stalling and flushing).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Schuttenberg et al. (US 20210303303 A1) discloses “an instruction following a state transition instruction (a further instruction) is issued regardless of whether its requirement in respect of a security state aligns with the current security state of the operating system, and a check of whether the security requirements of the instruction are met is carried out at completion (e.g. before or during completion) of the instruction by the completion circuitry. This avoids the need for the processing circuitry to assume that the requirements of any instructions part way through execution do not match the updated security state of the operating system, so that a flush does not need to be triggered in response to every change in security state. This allows the performance of the system to be improved by reducing the likelihood of a pipeline flush, thus avoiding the performance impact associated with a flush” (see paragraph [0026]), which is relevant to the claimed flushing and conflict detection.
Hardage (US 9058179 B2) discloses “serialisation of the status register access instructions can be achieved with less impact upon the system performance by dispatching such instructions to a special register access pipeline and then controlling how other instructions in the system are committed and retired in order to ensure that serialisation is achieved” (see col. 2, lines 14-19), which is relevant to the claimed instruction processing pipeline and instructions configured to write control registers.
Golla et al. (US 7509484 B1) discloses suppressing a pipeline flush if a pipeline has no follow-on instructions (see col. 3, lines 18-20), which is relevant to the claimed conflict determination and initiating flushing.
Johnson et al. (US 5787266) discloses “performing special register writes without serialization. The apparatus detects certain special register write instructions when the instructions are dispatched, and stores an indication of the write in a special register dependency block. Instructions subsequent to the special register write instruction are examined for both explicit and implicit dependencies upon the special register write. If a dependency is detected with respect to a particular instruction, the instruction is dispatched to a reservation station along with an indication of the dependency. Instructions subsequent to the special register write instruction which are not dependent upon the special register are dispatched without an indication of special register dependency. Instructions without dependencies may speculatively execute prior to instructions with dependencies, or even prior to the special register write instruction. Advantageously, instructions which were previously stalled due to serialization may execute speculatively. Instruction throughput may be improved, improving the overall performance of the microprocessor” (see col. 3, lines 17-36), which is relevant to the claimed control registers and determining whether the second instruction conflicts with the first instruction.
Brandt et al. (US 20160259644 A1) discloses “post-serialization of operations for the new mode may still be performed so that fetch, decode, and execute operations are delayed as needed until the correct operational mode configuration is loaded” (see paragraph [0111]), which is relevant to the claimed control register and conflict determination.
Gschwind et al. (US 20180373496 A1) discloses pipeline flushes in the context of a read and set floating point status and control instruction (see paragraph [0086]), which is relevant to the claimed control registers and flushing.
Abhishek Raja et al. (US 20210064377 A1) discloses “the data processing apparatus 100 makes it possible to speculatively execute instructions after the status updating instruction on the assumption that the status storage circuitry 170 will not be updated. If this turns out to be incorrect, then a rewind occurs flushing those instructions that executed based on incorrect information” (see paragraph [0033]), which is relevant to the claimed control registers and flushing.
Tremblay et al. (US 6862664 B2) discloses speculative execution, committing if no interfering data access is encountered, and discarding changes if an interfering data access is encountered (see col. 2, lines 15-29), which is relevant to the claimed conflict determination and initiating flushing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEITH E VICARY whose telephone number is (571)270-1314. The examiner can normally be reached Monday to Friday, 9:00 AM to 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
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.
/KEITH E VICARY/Primary Examiner, Art Unit 2183
Prosecution Insights