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 .
Drawings
The lengthy set of drawings has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the drawings.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description: 344.
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) 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. 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.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The following title is suggested: “RESTRICTING VECTOR LENGTH IN A PROCESSOR USING CONTROL VALUES”.
The disclosure is objected to because of the following informalities:
[0038]: In line 7, the phrase “the control value may either a first value…” is grammatically incorrect. Examiner recommends that the phrase should read as “the control value may either be a first value…”
[0038]: In line 8, the phrase “an optionally additional values” is grammatically incorrect. Examiner advises Applicant to fix the phrase.
[0086]: Third-to-last line, delete the additional “a” before “processor state save region”.
[00100]: In line 6, insert “computing” after “(throughput)”.to improve clarity.
[00110]: The phrase “a register maps” is grammatically incorrect and should be corrected to “a register map”.
[00145]: In line 3, the phrase “a SSE register” is grammatically incorrect and should instead read as “an SSE register”.
[00166]: In line 4, the phrase “a opmask” is grammatically incorrect and should instead read as “an opmask”.
[00189+]: The example embodiments suffer the same issues as the claim objections/rejections and should be fixed when appropriate.
Appropriate correction is required.
Claim Objections/Recommendations
Claims 5, 11-12, 16, and 18-20 are objected to because of the following informalities:
Claim 5, lines 1-2: Remove hyphens between “512-bits” and “256-bits” as the use of the hyphens is improper.
Claim 11, lines 1-2: Remove hyphens between “512-bits” and “256-bits” as the use of the hyphens is improper.
Claim 12, lines 1-2: Remove hyphens between “512-bits”, 256-bits”, and “128-bits” as the use of the hyphens is improper.
Claim 16, line 6: Remove hyphen between “256-bits” as the use of a hyphen is improper.
Claim 18, line 11-13: Remove hyphens between “256-bits” as the use of the hyphens is improper.
Claim 19, last line: Insert “the” before “second” to improve clarity.
Claim 20, lines 1-2: Remove hyphens between “512-bits” and “256-bits” as the use of the hyphens is improper.
Appropriate correction is required.
Examiner makes the following recommendations:
Claim 8, line 2: Change the line for it to read “front-end circuitry, configured to” to improve the flow of the claim.
Claim 16, lines 11-12: Change the line for it to read “front-end circuitry, configured to” to improve the flow of the claim.
Claim 19, line 5: Change the line for it to read “front-end circuitry, configured to” to improve the flow of the claim.
Claim Interpretation
The following is a quotation of MPEP 2111.04(II):
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.
The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. The system claim interpretation differs from a method claim interpretation because the claimed structure must be present in the system regardless of whether the condition is met and the function is actually performed.
Regarding claim 1, the claim recites “when a control value is a first value” and “when the control value is a second value” in lines 4, 8-9, and 11-12. The Applicant’s specification in paragraphs [0067, 00203] suggests that the control value may be a third value, different from the first or second value. Under BRI, none of the limitations are required and the claim would simply recite “a method performed by a processor” when the control value is the third value. Therefore, the limitations, recited above, are contingent. In the case that the claim becomes allowable, over the prior art, Applicant is advised to insert “positively occurring” actions within the method claim so that the conditional of the contingent limitations may be satisfied and recites the same invention as the independent processor and system claims. Note: This does not indicate the claim is allowable and should not be interpreted in that regard.
Regarding claim 2, the claim recites a limitation which is conditional on the contingent limitations “when a control value is a second value” being true.
Regarding claim 6-7, the claims recite “when the control value is the first value” and “when the control value is the second value”. Under BRI, none of the limitations are required and the claim would simply recite “decoding a processor state save instruction” and “performing operations corresponding to the processor state save instruction” when the control value is the third value. Therefore, the limitations, recited above, are contingent.
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.
Claim 18 is 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 18 recites the limitation "the 512-bit vectors" in line 7. There is insufficient antecedent basis for this limitation in the claim. It’s unclear if the limitation is referring to “512-bit vectors of a 512-bit vector width” in claim 16, line 15, “512-bit vectors” in claim 16, line 23, or “512-bit vectors” in claim 16, line 25. For the sake of examination, Examiner will interpret this limitation to be referring to “512-bit vectors of a 512-bit vector width” in claim 16, line 15.
Claim 18 recites the limitation "the 256-bit vectors" in line 10. There is insufficient antecedent basis for this limitation in the claim. It’s unclear if the limitation is referring to “256-bit vectors of a 256-bit vector width” in claim 16, line 16 or “256-bit vectors” in claim 16, line 21. For the sake of examination, Examiner will interpret this limitation to be referring to “512-bit vectors of a 512-bit vector width” in claim 16, line 16.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5-9, and 11-15 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sahita et al. (US 11029957 B1).
Wikipedia “Advanced Vector Extensions” is cited as extrinsic evidence to indicate that the opcodes of AVX and AVX-512 indicate wider vector widths or narrow vector widths.
Wikipedia “list of x86 instructions” is cited as extrinsic evidence to indicate that the even narrower vector width instructions uses a particular opcode format.
Intel “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” is cited as extrinsic evidence to explain the functionality of XCR0, the XSAVE area, XSAVE, and XRSTOR, and to further indicate that exceptions are thrown when an illegal instruction is detected.
Regarding claim 1, Sahita teaches a method performed by a processor (Fig. 1: Processor core 109(1-N) as the processor), the method comprising:
executing first instances of vector instructions having respective opcode values regardless of whether they specify wider vectors of a wider vector width or narrower vectors of a narrower vector width, when a control value is a first value (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can execute AVX instructions and AVX-512, when allowed by the control register 112 (i.e., XCR0). AVX/AVX-512 instructions indicate wide vectors or narrow vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Page 1, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512). The bits set in XCR0 as the control value and bits 1-2 and 5-7 set to “1” in the XCR0 register as the first value. AVX and AVX-512 instructions as the first instances of vector instructions), the wider vector width being wider than the narrower vector width (Col. 11 lines 9-45: AVX-512 instructions indicate wider vector widths (512-bit vector widths) being wider than AVX instructions indicating a narrower vector width (256-bit vector widths) (see Wikipedia “Advanced Vector Extensions”, Pages 1 and 4-5))
executing second instances of vector instructions having the respective opcode values when they specify narrower vectors of the narrower vector width, but do not specify wider vectors of the wider vector width, when the control value is a second value different than the first value (Fig. 1 and Col. 11 lines 9-45: Bits 1-2 are set to “1” and bits 5-7 are set to “0” as the second value. When the bits are set in the specific configuration, AVX instructions, which specify narrower vectors of the narrower vector width but does not specify wider vectors of the wider vector length, may be executed by the execution circuit 154 within one of processor cores 108(1-N). AVX instructions as the second instances of vector instructions); and
preventing execution of third instances of vector instructions having the respective opcode values when they specify wider vectors of the wider vector width, when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “0”, AVX-512 instructions, which specify wider vectors of the wider vector width, cannot be executed (i.e., prevented from executing). AVX-512 instructions as the third instances of vector instructions).
Alternatively, regarding claim 1, Sahita teaches a method performed by a processor (Fig. 1: Processor core 109(1-N) as the processor) when the control value is a third value (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value). See “Claim Interpretation” section.
Claim 2 is rejected for the same reason as the alternate rejection of claim 1, because, as discussed in the “Claim Interpretation” section, the limitation of claim 2 is contingent and not required.
Regarding claim 2, Sahita teaches the method of claim 1, wherein said preventing comprises causing exceptions for the third instances of the vector instructions (Fig. 1 and Col. 11 lines 9-45: When XCR0[7:5]: is set to “0”, the execution of instructions would cause an invalid-opcode exception (#UD) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Page 13-2, fourth-to-last paragraph)).
Regarding claim 3, Sahita teaches the method of claim 1, further comprising accessing the control value from an on-die storage location that is on a die on which the processor is disposed (Figs. 1 and 29, Col. 11, lines 9-45, Col 51, lines 25-27: The processing cores 108(1-N) (core 2502A-N in Fig. 29) may be implemented on a system on a chip (i.e., a die). The control value, located in a control register 112 (i.e., a storage location) in the processing cores, would be considered an on-die storage location that is on a die on which the processor is disposed. Therefore, the processing system would be accessing the control value from an on-die storage location).
Regarding claim 5, Sahita teaches the method of claim 1, wherein the wider vector width is at least 512-bits, and wherein the narrower vector width is no more than 256-bits (AVX uses 256-bit wide registers and AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is at least 512-bits and the narrower vector width is no more than 256-bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 6, Sahita teaches the method of claim 1, further comprising:
decoding a processor state save instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)); and
performing operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XSAVE instruction), including:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 set to “1” in the XCR0 register), saving processor state of a set of wider vector registers of the wider vector width to a processor state save area in system memory (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the ZMM0-31 registers (i.e., processor state of a set of wider vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164) located within memory 102 (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). XSAVE area as the processor state save area and memory 102 as the system memory); and
when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), saving processor state of a set of narrower vector registers of the narrower vector width to the processor state save area,
without saving the processor state of the set of wider vector registers to the processor state save area (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the YMM0-15 registers (i.e., processor state of a set of narrower vector registers) are to be stored into an XSAVE memory location (i.e., XSAVE area 164), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)).
Alternatively, regarding claim 6, Sahita teaches the method of claim 1, further comprising:
decoding a processor state save instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)); and
performing operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XSAVE instruction) when the control value is a third value (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value). See “Claim Interpretation” section.
Regarding claim 7, Sahita teaches the method of claim 1, further comprising:
decoding a processor state restore instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XRSTOR instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)); and
performing operations corresponding to the processor state restore instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XRSTOR instruction), including:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 are set to “1” in the XCR0 register), loading processor state from a processor state save area in system memory into a set of wider vector registers of the wider vector width (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the data stored in the XSAVE memory location (i.e., XSAVE area 164) located within memory 102 are loaded into the ZMM0-31 registers (i.e., loading processor state into a set of wider vector registers) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15). XSAVE area as the processor state save area and memory 102 as the system memory. The ZMM0-31 registers as the set of wider vector registers); and
when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), loading processor state from the processor state save area into a set of narrower vector registers of the narrower vector width,
without loading processor state from the processor state save area into the set of wider vector registers (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the data for the YMM0-15 registers are loaded from the XSAVE memory location (i.e., XSAVE area 164 loads processor state into a set of narrower vector registers), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). The YMM0-15 registers as the set of narrower vector registers).
Alternatively, regarding claim 7, Sahita teaches the method of claim 1, further comprising:
decoding a processor state restore instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XRSTOR instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)); and
performing operations corresponding to the processor state restore instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes and performs operations corresponding to the XRSTOR instruction) when the control value is a third value (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value). See “Claim Interpretation” section.
Regarding claim 8, Sahita teaches a processor (Fig. 1: Processor core 109(1-N) as the processor) comprising:
front-end circuitry (Fig. 1: Units within IP gen stage 111, fetch stage 130, decode stage 140, and execution stage 150 as the front-end circuitry) to:
decode vector instructions having respective opcode values into corresponding first decoded instructions regardless of whether they specify wider vectors of a wider vector width or narrower vectors of a narrower vector width, when a control value is a first value (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can decode AVX instructions and AVX-512 through decode stage 140, when allowed by the control register 112 (i.e., XCR0). AVX/AVX-512 instructions indicate wide vectors or narrow vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Page 1, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512). The bits set in XCR0 as the control value and bits 1-2 and 5-7 set to “1” in the XCR0 register as the first value. Decoded AVX and AVX-512 instructions as the first decoded instructions), the wider vector width being wider than the narrower vector width (Col. 11 lines 9-45: AVX-512 instructions indicate wider vector widths (512-bit vector widths) being wider than AVX instructions indicating a narrower vector width (256-bit vector widths) (see Wikipedia “Advanced Vector Extensions”, Pages 1 and 4-5));
decode the vector instructions having the respective opcode values into corresponding second decoded instructions when they specify narrower vectors of the narrower vector width, but do not specify wider vectors of the wider vector width, when the control value is a second value different than the first value (Fig. 1 and Col. 11 lines 9-45: Bits 1-2 set to “1” and bits 5-7 are set to “0” as the second value. When the bits are set in the specific configuration, AVX instructions, which specify narrower vectors of the narrower vector width but does not specify wider vectors of the wider vector length, may be decoded in the decode stage 140 within one of processor cores 108(1-N). Decoded AVX instructions as the second decoded instructions); and
cause exceptions for the vector instructions having the respective opcode values when they specify wider vectors of the wider vector width, when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “0”, AVX-512 instructions, which specify wider vectors of the wider vector width, cannot be executed as the execution of AVX-512 instructions would cause an invalid-opcode exception (#UD) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Page 13-2, fourth-to-last paragraph)); and
execution circuitry coupled with the front-end circuitry (Fig. 1: Execution circuit 154, located within the execution stage 150), the execution circuitry to execute the first and second decoded instructions (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as first and second decoded instructions).
Regarding claim 9, Sahita teaches the processor of claim 8, further comprising:
a die on which the processor is disposed (Figs. 1 and 29, Col. 11, lines 9-45, Col 51, lines 25-27: The processing cores 108(1-N) may be implemented on a system on a chip (i.e., a die)); and
an on-die storage location of the die, the on-die storage location to store the control value (Figs. 1 and 29, Col. 11, lines 9-45, Col 51, lines 25-27: The control value, located in a control register 112 (i.e., a storage location) in the processing cores 108(1-N) (core 2502A-N in Fig. 29), would be considered an on-die storage location that is on a die on which the processor is disposed. Therefore, the processor cores would be accessing the control value from an on-die storage location).
Regarding claim 11, Sahita teaches the processor of claim 8, wherein the wider vector width is at least 512-bits (AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is at least 512-bits (see Wikipedia “Advanced Vector Extensions”, Page 1)), and
wherein the narrower vector width is no more than 256-bits (AVX uses 256-bit wide registers. Therefore, the narrower vector width is no more than 256-bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 12, Sahita teaches the processor of claim 11, wherein the wider vector width is 512-bits, and wherein the narrower vector width is either 256-bits or 128-bits (AVX uses 256-bit wide registers and AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is 512-bits and the narrower vector width is 256-bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 13, Sahita teaches the processor of claim 8, wherein the front-end circuitry is to decode a processor state save instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)), and further comprising:
execution circuitry to perform operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as executing the XSAVE instruction), including to:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 are set to “1” in the XCR0 register), save processor state of a set of wider vector registers of the wider vector width to a processor state save area in system memory (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the ZMM0-31 registers (i.e., processor state of a set of wider vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164) located within memory 102 (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). XSAVE area as the processor state save area and memory 102 as the system memory); and
when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), save processor state of a set of narrower vector registers of the narrower vector width to the processor state save area, without saving the processor state of the set of wider vector registers to the processor state save area (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), the YMM0-15 registers (i.e., processor state of a set of narrower vector registers) are to be stored into an XSAVE memory location (i.e., XSAVE area 164), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)).
Regarding claim 14, Sahita teaches the processor of claim 8, wherein the front-end circuitry is to decode a processor state restore instruction (Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XRSTOR instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)), and further comprising:
execution circuitry to perform operations corresponding to the processor state restore instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as executing the XRSTOR instruction), including to:
when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 set to “1” in the XCR0 register), load processor state from a processor state save area in system memory into a set of wider vector registers of the wider vector width (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the data stored in the XSAVE memory location (i.e., XSAVE area 164) located within memory 102 are loaded into the ZMM0-31 registers (i.e., loading processor state into a set of wider vector registers) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15). XSAVE area as the processor state save area and memory 102 as the system memory. The ZMM0-31 registers as the set of wider vector registers); and
when the control value is the second value (Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), load processor state from the processor state save area into a set of narrower vector registers of the narrower vector width, but not load processor state from the processor state save area into the set of wider vector registers (Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the data for the YMM0-15 registers are loaded from the XSAVE memory location (i.e., XSAVE area 164 loads processor state into a set of narrower vector registers), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). The YMM0-15 registers as the set of narrower vector registers).
Regarding claim 15, Sahita teaches the processor of claim 8, wherein the front-end circuitry is to:
decode the vector instructions having the respective opcode values into corresponding decoded instructions regardless of whether they specify wider vectors of the wider vector width, narrower vectors of the narrower vector width, or even narrower vectors of an even narrower vector width, when the control value is the first value (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can decode SSE instructions, AVX instructions, and AVX-512 through decode stage 140, when allowed by the control register 112 (i.e., XCR0). SSE, AVX, AVX-512 instructions indicate wide vectors or narrow vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Page 1, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512. See Wikipedia “list of x86 instructions”, starting at page 25, SSE instructions have the “0F” byte and does not come with a prefix). Decoded AVX and AVX-512 instructions as the first decoded instructions), the even narrower vector width being narrower than the narrower vector width (Col. 11 lines 9-45: SSE instructions indicate even narrower vector widths (128-bit vector widths) being narrower than AVX instructions indicating a narrower vector width (256-bit vector widths) (see Wikipedia “list of x86 instructions”, Pages 25 and 45-46)); and
decode the vector instructions having the respective opcode values into corresponding decoded instructions when they specify even narrower vectors of the even narrower vector width, but do not specify wider vectors of the wider vector width or narrower vectors the narrower vector width, when the control value is a third value different than the first and second values (Fig. 1 and Col. 11 lines 9-45: Bit 1 of XCR0 set to “1” and bits 2 and 5-7 of XCR0 are set to “0” as the third value. When the bits are set in the specific configuration, SSE instructions, which specify even narrower vectors of the even narrower vector width but does not specify wider vectors of the wider vector length or narrower vectors the narrower vector width, may be decoded in the decode stage 140 within one of processor cores 108(1-N). Decoded SSE instructions as the decoded instructions).
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 4 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Shanbhogue et al. (US 20180067866 A1) and Serebrin et al. (WO 2009094163 A2).
Regarding claim 4, Sahita teaches the method of claim 1.
Sahita does not teach to access the control value from a field of an architecturally-defined virtualization control structure in system memory.
Note that the XCR0 register is a control register (see Col. 11 lines 9-45).
Shanbhogue teaches to store control register data in fields of a VMCS ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
Sahita, in view of Shanbhogue, still does not teach to access the control value from a field of an architecturally-defined virtualization control structure.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Regarding claim 10, Sahita teaches the processor of claim 8.
Sahita does not teach that the processor is to access the control value from an architecturally-defined field of a virtualization control structure in system memory.
Note that the XCR0 register is a control register (see Col. 11 lines 9-45).
Shanbhogue teaches to store control register data in fields of a VMCS ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
Sahita, in view of Shanbhogue, still does not teach to access the control value from a field of an architecturally-defined virtualization control structure.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Barragy et al. (US 20060075218 A1).
Wikipedia “Advanced Vector Extensions” is cited as extrinsic evidence to indicate that the opcodes of AVX and AVX-512 indicate wider vector widths or narrow vector widths.
Intel “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” is cited as extrinsic evidence to explain the functionality of XCR0, the XSAVE area, XSAVE, and XRSTOR, and to further indicate that exceptions are thrown when an illegal instruction is detected.
Regarding claim 16, Sahita teaches a processor (Fig. 1: Processor core 109(1-N) as the processor) comprising:
an extended control register XCR0 (Fig. 1 and Col. 11 lines 9-45: Control register may be the XCR0 register) including:
a bit position XCR0[5] to store a first bit, the first bit to either be set to enable, or cleared to disable, use of a set of eight 64-bit mask registers k0-k7 (Col. 11 lines 9-45: When bit 5 of XCR0 is set, the opmask registers k0-k7 may be used, otherwise it’s disabled if bit 5 is not set. Bit 5 as the first bit);
a bit position XCR0[6] to store a second bit, the second bit to either be set to enable, or cleared to disable, use of a most significant 256-bits of a first set of sixteen 512-bit vector registers ZMM0-ZMM15 (Col. 11 lines 9-45: When bit 6 of XCR0 is set, the registers ZMM0-ZMM15 may be used, otherwise they’re disabled if bit 6 is not set. Bit 6 as the second bit); and
a bit position XCR0[7] to store a third bit, the third bit to either be set to enable, or cleared to disable, use of a second set of sixteen 512-bit vector registers ZMM16- ZMM31 (Col. 11 lines 9-45: When bit 7 of XCR0 is set, the registers ZMM16-ZMM31 may be used, otherwise they’re disabled if bit 7 is not set. Bit 7 as the third bit); and
front-end circuitry coupled with the extended control register XCR0 (Fig. 1: Units within IP gen stage 111, fetch stage 130, decode stage 140, and execution stage 150 as the front-end circuitry. The control register is coupled with the units), the front-end circuitry to:
when the first, second, and third bits are set (Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “1”), , decode vector instructions having respective opcode values into corresponding first decoded instructions regardless of whether they specify 512-bit vectors of a 512-bit vector width, 256-bit vectors of a 256-bit vector width, or 128-bit vectors of a 128-bit vector width (Fig. 1 and Col. 11 lines 9-45: Processor cores 109(1-N) can decode AVX instructions and AVX-512 through decode stage 140, when bit 2 and bits 5-7 are set to “1” in the XCR0 register. AVX-512 instructions indicate 512-bit wide vectors and AVX instructions indicate 256-bit wide vectors in their opcodes (see Wikipedia “Advanced Vector Extensions”, Pages 1 and 4-5, VEX prefix to an opcode for AVX vs EVEX prefix to an opcode for AVX-512). Decoded AVX and AVX-512 instructions as the first decoded instructions); and
when the first, second, and third bits are set (Fig. 1 and Col. 11 lines 9-45: When bits 5-7 are set to “1”), :
decode the vector instructions having the respective opcode values into corresponding second decoded instructions when they specify 256-bit vectors of the 256-bit vector width or 128-bit vectors of the 128-bit vector width ; and
execution circuitry, coupled with the front-end circuitry (Fig. 1: Execution circuit 154, located within the execution stage 150), the execution circuitry to execute the first and second decoded instructions (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as first and second decoded instructions).
Sahita does not teach that when the first, second, and third bits are set, and when a control value is a first value, decode vector instructions having respective opcode values into corresponding first decoded instructions regardless of whether they specify 512-bit vectors of a 512-bit vector width, 256-bit vectors of a 256-bit vector width, or 128-bit vectors of a 128-bit vector width; and
when the first, second, and third bits are set, and when the control value is a second value different than the first value:
decode the vector instructions having the respective opcode values into corresponding second decoded instructions when they specify 256-bit vectors of the 256-bit vector width or 128-bit vectors of the 128-bit vector width but not 512-bit vectors of the 512-bit vector width; and
cause exceptions for the vector instructions having the respective opcode values when they specify wider vectors of the wider vector width, when the control value is the second value.
Note that in Sahita, the XCR0 register is a control register that configures the features of a processor (see Col. 11 lines 9-45), which acts as a configuration register. Additionally, note that when an XCR0 bit 5-7 are “read” as 0, the execution of AVX-512 instructions would cause an invalid-opcode exception (#UD) (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Page 13-2, fourth-to-last paragraph)
Barragy teaches a disable override register (Figs. 2-3 and [0025-0029]: The disable override register (DOR) 90 may override disable a processor feature which may be indicated by a processor configuration register (PCR) 70), in which the value stored in the register would act as a control value and override values read from a configuration register.
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita with the teachings of Barragy to have used a disable override register (DOR) alongside the XCR0 register such that bit values of the XCR0 register can be read as “0” without modifying the XCR0 register, allowing the execution of AVX instructions and AVX-512 instructions when the control value of the DOR does not override the XCR0 values and only allowing the execution of AVX instructions when the DOR overrides bits 5-7 of the XCR0 register to be read as “0”, causing an exception when an attempt is made to execute AVX-512 instructions. One of ordinary skill would recognize that certain processor features may be inappropriate during a given program phase. Therefore, by disabling certain processor features, program performance may improve (see [0016, 0019]).
Claims 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Barragy et al. (US 20060075218 A1), Shanbhogue et al. (US 20180067866 A1), and Serebrin et al. (WO 2009094163 A2).
Regarding claim 17, Sahita, in view of Barragy, teaches the processor of claim 16.
Sahita, in view of Barragy does not teach that the processor is to access the control value from an architecturally-defined field of a virtualization control structure in system memory.
Note that in Sahita, the XCR0 register is a control register (see Sahita, Col. 11 lines 9-45). Furthermore, the disable override register in the current embodiment controls the XCR0 register, therefore considered a control register.
Shanbhogue teaches to store control register data in fields of a VMCS ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Barragy, with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
Sahita, in view of Barragy and Shanbhogue, still does not teach to access the control value from a field of an architecturally-defined virtualization control structure.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Barragy and Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Claims 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Sahita et al. (US 11029957 B1) in view of Shanbhogue et al. (US 20180067866 A1), Serebrin et al. (WO 2009094163 A2), and Rozas et al. (US 20190196982 A1).
Wikipedia “Advanced Vector Extensions” is cited as extrinsic evidence to indicate that the opcodes of AVX and AVX-512 indicate wider vector widths or narrow vector widths.
Intel “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” is cited as extrinsic evidence to explain the functionality of XCR0, the XSAVE area and the XSAVE instruction, and to further indicate that exceptions are thrown when an illegal instruction is detected.
Regarding claim 19, the claim is mostly rejected for the same reasons as claim 8.
Sahita also teaches a system (Fig. 1: Computer system) comprising:
a memory ; and
a processor coupled with the memory (Fig. 1: The processor cores 108(1-N) is coupled to memory 102 through system bus 107. Processor cores as the processor).
Sahita does not teach a dynamic random access memory (DRAM) to store a virtual machine control structure (VMCS), the VMCS having a field to store a control value and a processor coupled with the DRAM.
Note that the memory may store details relating to virtual machines (see Col. 8, lines 7-36). Furthermore, note that the XCR0 register is a control register (see Sahita, Col. 11 lines 9-45).
Shanbhogue teaches to store control register data in fields of a VMCS, stored in a memory ([0029]: Data such as control registers may be loaded into guest state fields in a VMCS (virtual machine control structure), which is located in system hardware memory 120. The VMCS as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Barragy, with the teachings of Shanbhogue to have stored control register data in the fields of a VMCS. One of ordinary skill would recognize that when using a virtual machine and accessing the processor core in a guest VM, the control register data may differ from the host OS and should be stored such that the settings and state of the guest VM may be easily maintained when switching between the host OS and guest VM, avoiding the issue of having the settings be set again for the guest VM.
However, the combination raises the issue of how the control register data is to be accessed from the VMCS.
Serebrin teaches to access the control value from a field of an architecturally-defined virtualization control structure ([0036, 0061-0062]: VMLOAD instruction may load state data for a control register from the VMCB (virtual machine control block). The VMCB as the architecturally-defined virtualization control structure).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue, with the teachings of Serebrin to have accessed the control register data from a field of the VMCS. One of ordinary skill would recognize that to access data stored in a memory structure, it will need to be loaded from memory using a command/instruction, in which the VMLOAD achieves that function.
Sahita, in view of Shanbhogue and Serebrin, still does not teach that the memory to store the VMCS is a DRAM.
Rozas teaches the system memory being DRAM and stores the VMCS (Fig. 1A and [0041]: System memory 160 may be DRAM).
It would have been obvious to one of ordinary skill in the art before the effective filing date to have combined the teachings of Sahita, in view of Shanbhogue and Serebrin, with the teachings of Rozas to have made the memory to store the VMCS be DRAM. DRAM provides higher storage densities and lower costs compared to other memories such as SDRAM, which may be preferred by one of ordinary skill.
Regarding claim 20, Sahita, in view of Shanbhogue, Serebrin, and Rozas, teaches the system of claim 19, wherein the wider vector width is at least 512-bits (AVX-512 uses 512-bit wide registers. Therefore, the wider vector width is at least 512-bits (see Wikipedia “Advanced Vector Extensions”, Page 1)), and wherein the narrower vector width is no more than 256-bits (AVX uses 256-bit wide registers. Therefore, the narrower vector width is no more than 256-bits (see Wikipedia “Advanced Vector Extensions”, Page 1)).
Regarding claim 21, Sahita, in view of Shanbhogue, Serebrin, and Rozas, teaches the system of claim 19, wherein the front-end circuitry is to decode a processor state save instruction (Sahita, Fig. 1 and Col. 11 lines 9-45: Enabling the XSAVE area indicates that the processor can decode and execute instructions involving the XSAVE area such as the XSAVE instruction (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1, 13-14, and 13-15)), and further comprising:
execution circuitry to perform operations corresponding to the processor state save instruction (Fig. 1 and Col. 6, lines 64-67: Execution circuit 154 executes decoded instructions, which would include instances such as executing the XSAVE instruction), including to:
when the control value is the first value (Sahita, Fig. 1 and Col. 11 lines 9-45: When bits 1-2 and 5-7 are set to “1” in the XCR0 register), save processor state of a set of wider vector registers of the wider vector width to a processor state save area in system memory (Sahita, Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[7:5] are set to “1” (corresponding to XCR0[7:5]), the ZMM0-31 registers (i.e., processor state of a set of wider vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164) located within memory 102 (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14). XSAVE area as the processor state save area and memory 102 as the system memory); and
when the control value is the second value (Sahita, Fig. 1 and Col. 11 lines 9-45: When bits 1-2 are set to “1” and bits 5-7 are set to “0” in the XCR0 register), save processor state of a set of narrower vector registers of the narrower vector width to the processor state save area, without saving the processor state of the set of wider vector registers to the processor state save area (Sahita, Fig. 1 and Col. 11 lines 9-45: The bits of the XCR0 register are used to create a requested-feature bitmap (indicated as RFBM) which corresponds to the XCR0 register. When bits RFBM[2:1] are set to “1” and bits RFBM[7:5] are set to “0” (corresponding to XCR0[2:1] and XCR0[7:5]), only the YMM0-15 registers (i.e., processor state of a set of narrower vector registers) are stored into an XSAVE memory location (i.e., XSAVE area 164), not the ZMM0-31 registers (see “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture” Pages 13-1 and 13-14)).
Allowable Subject Matter
Claim 18 is objected to as being dependent upon a rejected base claim, but would be allowable, over the prior art, if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Claim 18 recites, among other things, that when the control value is the second value, save processor state of thirty-two 256-bit vector registers YMM0-YMM31 that are to store the 256-bit vectors to the processor state save area, without saving the processor state of the most significant 256- bits of the first set of sixteen 512-bit vector registers ZMM0-ZMM15, or a most significant 256-bits of the second set of sixteen 512-bit vector registers ZMM16- ZMM31, to the processor state save area.
The closest prior art, Sahita et al. (US 11029957 B1) in view of Barragy et al. (US 20060075218 A1), fails to explicitly teach to save processor state of thirty-two 256-bit vector registers YMM0-YMM31 that are to store the 256-bit vectors to the processor state save area. The combination only describes saving the processor state of 15 256-bit vector register YMM0-YMM15 as the disabling of bit 7 of XCR0 disables ZMM16-31, which includes YMM16-31, and therefore, the combination does not allow saving the processor state of thirty-two 256-bit registers.
In the art, it’s more common to define a register vector width and have instructions process vectors using the defined register vector width rather than having an opcode of an instruction to both define the register vector width and the operation to be performed using the defined register vector width (e.g., see Tran et al. in pertinent art section. Figs. 4A-4B and [0047]) and when saving the processor state, the state, which mainly includes the state of the registers, is typically stored in its entirety (e.g., see Penton et al. in pertinent art section, Figs. 1-2 and Col. 9, lines 59 to Col. 10, line 40). The prior art has not been found to teach to have an instruction to indicate the register vector width and to pick and choose which registers get saved based on whether a certain instruction vector width can be executed on the processor. Based on the configuration including “when the control value is the second value, save processor state of thirty-two 256-bit vector registers YMM0-YMM31 that are to store the 256-bit vectors to the processor state save area, without saving the processor state of the most significant 256- bits of the first set of sixteen 512-bit vector registers ZMM0-ZMM15, or a most significant 256-bits of the second set of sixteen 512-bit vector registers ZMM16- ZMM31, to the processor state save area”, the combination of features is considered to be allowable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20240020119 A1: Tran et al. teaches to modify vector length.
US 8661232 B2: Penton et al. teaches to store and restore register state in memory.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EMILIO ALCANTARA-RAMOS whose telephone number is (571)272-4211. The examiner can normally be reached Mon-Fri 8:30-5:00 PST.
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.
/E.A./Examiner, Art Unit 2183
/JYOTI MEHTA/ Supervisory Patent Examiner, Art Unit 2183