Adler assist instructions

A processor is provided with a register file comprising a plurality of vector registers, and an execution core coupled to the register file, where the execution core is configured to execute a set of checksum instructions with a first checksum instruction to specify a first vector operand, a second vector operand, and a result vector operand, where the first vector operand is in a first vector register of the plurality of vector registers, the second vector operand is in a second register of the plurality of vector registers, and the result vector operand is to be written to a third vector register of the plurality of vector registers, and to execute the first checksum instruction, the execution core is configured to accumulate bytes from the first vector operand and the second vector operand into a first portion of the result vector operand and add the accumulated bytes from the first vector operand and the second vector operand to a second portion of the result vector operand to generate the second portion written to the result vector operand.

BACKGROUND

Field

Embodiments described herein are related to processors and, more particularly, to hardware assist instructions to improve compression/decompression performance and power efficiency.

Background Information

Compression is used for a variety of reasons in computing devices. For example, software downloads may be compressed for delivery over a network, and may be decompressed on the target computing device for installation. In some cases, such as portable computing devices (e.g. smart phones, portable digital assistants, tablet computers, etc.), the software may be decompressed, installed, then recompressed for storage on the device. Storing various software in compressed form may save storage space on the device, which may be more limited than the storage in larger computing devices such as laptops, desktops, servers, etc.

Errors, such as channel impairment, hardware failures, and software errors, may occur and must be detected before a computer system falls into a potentially catastrophic state. Checksum algorithms are used to produce a fixed size datum that may be computed from data and is used to verify the integrity of a data and/or a system. Adler-32 is a simple operation that is a form of checksum using scalar operations, and as compared to other checksum algorithms, such as cyclic redundancy check (CRC-32), it trades reliability for speed. Adler-32 is obtained by calculating two 16-bit checksums and concatenating their bits into a 32-bit integer.

SUMMARY

In an embodiment, a processor is provided with a register file comprising a plurality of vector registers, and an execution core coupled to the register file, where the execution core is configured to execute a set of checksum instructions with a first checksum instruction to specify a first vector operand, a second vector operand, and a result vector operand, where the first vector operand is in a first vector register of the plurality of vector registers, the second vector operand is in a second register of the plurality of vector registers, and the result vector operand is to be written to a third vector register of the plurality of vector registers, and to execute the first checksum instruction, the execution core is configured to accumulate bytes from the first vector operand and the second vector operand into a first portion of the result vector operand and add the accumulated bytes from the first vector operand and the second vector operand to a second portion of the result vector operand to generate the second portion written to the result vector operand. In some embodiments, the first vector operand is a source vector of bytes from a data source buffer.

The execution core is further configured to execute a second instruction from the set of checksum instructions, wherein to execute the second checksum instruction, the execution core is further configured to specify a third vector operand, and a second result vector operand, wherein the third vector operand is in a fourth vector register of the plurality of vector registers and the second result vector operand is to be written to a fifth vector register of the plurality of vector registers, wherein the execution core is configured to accumulate bytes from the third vector operand into a first portion of the second result vector operand and add the accumulated bytes in the first portion of the second result vector to the second portion of the second result vector operand to generate the second portion written to the second result vector operand. In some embodiments, concatenating the first portion of the result vector operand and the second portion of the result vector operand generates a checksum result, the checksum result comprises a computation for a fixed size datum. In an embodiment, the data source buffer is compressed data. In some embodiments, the execution core is further configured to execute a third instruction, the execution core is further configured to specify a fourth vector operand, a fifth vector operand, and a third result vector operand, wherein the fourth vector operand is in a sixth vector register of the plurality of vector registers, the fifth vector operand is in a seventh register, and the third result vector operand is to be written to an eighth vector register of the plurality of vector registers, wherein the execution core is configured to multiply a first portion of vector elements of a fourth vector operand by at least one vector element of a fifth vector operand to generate a vector written to the third result vector operand, shift the third result vector operand by a defined value, and multiply the third result vector operand by at least one vector element of the fifth vector operand to generate a subtraction value and subtracting the third result vector operand by the subtraction value. In an embodiment, the defined value is computed to prevent overflow. In an embodiment, the execution core is further configured to execute the first instruction consecutively with a block from a set of consecutive blocks from a data source, wherein each block from the set has a defined number of bytes, and wherein the execution of the first instruction with the block to generate the result vector written to the sixth vector register of the register file, and execute the third instruction in response to completing the consecutive execution of the first instruction with the block.

In an embodiment, a non-transitory machine-readable medium storing instructions executed to cause one or more processors of a data processing system to perform operations, the instructions comprising a first checksum instruction from a set of checksum instructions configured to execute, the first checksum instruction specifying a first vector operand, a second vector operand, and a result vector operand, wherein the first vector operand is in a first vector register of a plurality of vector registers, the second vector operand is in a second register of the plurality of registers, and the result vector operand is to be written to a third vector register of the plurality of vector registers, wherein to execute the first checksum instruction, the execution core is further configured to accumulate bytes from the first vector operand and the second vector operand into a first portion (optional: of vector elements) of the result vector operand and add the accumulated bytes from the first vector operand and the second vector operand to a second portion of the result vector operand to generate the second portion written to the result vector operand.

In yet another embodiment, a processor comprises a register file comprising a plurality of vector registers, and an execution core coupled to the register file, wherein the execution core is configured to execute a first checksum instruction from a set of checksum instructions, the first checksum instruction to specify a first vector operand, a second vector operand, and a result vector operand, wherein the plurality of vector registers includes a first vector register to store the first vector operand, a second vector register to store the second vector operand, and a third vector register to store the result vector operand, wherein to execute the first checksum instruction, the execution core is further configured to accumulate bytes from the first vector register and the second vector register into a first portion of the third vector register associated with the result vector operand and add the accumulated bytes to a second portion of the third vector register, and output a value of the third vector register.

DETAILED DESCRIPTION

Embodiments describe hardware instruction assists for a vectorized checksum algorithm. Hardware instruction assists may use a software wrapper to call the hardware assist instructions. The hardware instruction assists may be viewed as being part of an instruction set architecture level and is not tied to a particular hardware implementation. The hardware instruction assist is used with a software wrapper to encapsulate the vectorized checksum algorithm and can be interrupted by the processor to handle other instructions. The use of hardware instruction assists for the vectorized checksum algorithm may improve performance and expend less energy. In some embodiments, the hardware assist instructions may be used with a compression algorithm in order to check the integrity of the data received.

In particular, each checksum hardware instruction assist provides techniques that allow performance with a single instruction (and in some embodiments, a single cycle) functions of checks on integrity of data. This is an improvement over prior approaches that required more instructions and cycles.

FIG.1is a block diagram for a vectorized checksum algorithm in accordance with an embodiment. As shown, data102may be processed to create a datum118for an integrity check. As shown, data102stored in a buffer may be processed using vectorized operations as opposed to scalar operations.

Generally, vector operations perform a specified operation on a plurality of vector elements in one or more vector operands in parallel and independently for each vector element. For example, a vector add operation may add vector elements in corresponding positions within the vector operands, producing sums as vector elements of a vector result operand. A four element vector would have vector elements VE0, VE1, VE2, and VE3, in the listed order in adjacent vector element positions within the vector. A vector add would add the VE0elements of the source operands to produce the VE0element of the result operand; add the VE1elements of the source operands to produce VE1element of the result operand; etc. While a four element vector is used as an example, other embodiments may employ different numbers of vector elements per vector and/or may support multiple numbers of vector elements per vector. For example, a 128 bit vector register set could support 2 64-bit vector elements, 4 32-bit vector elements, 8 16-bit vector elements, and 16 8-bit vector elements. Various vector instructions may be defined to use the vector registers as vector elements of different sizes. Thus, vector operations/instructions perform well on vector elements that are the same size, and many operations may be performed in parallel to improve performance of vectorizable algorithms.

Continuing withFIG.1, corresponding vector elements of104and106with data from102may be accumulated and stored in a checksum variable “Adler”108for the checksum algorithm. The accumulated bytes from Adler108may be added to previously accumulated bytes stored in a checksum variable “Sum2”110and114. Pseudocode for the operations is provided as follows:

A modulo operation is performed on Sum2and Adler variables to prevent overflow errors, and the variables are concatenated120together to form a datum118. The datum118may be used verify the integrity of the data. For example, the datum118may be compared against an expected value for the datum118.

FIG.2is a block diagram of one embodiment of a computer system200. The computer system200includes a processor202, a level two (L2) cache204, a memory208, and a mass-storage device210. As shown, the processor202includes a level one (L1) cache206and an execution core212coupled to the L1 cache206and a register file214. The execution core212may include one or more execution units (e.g.,216and218) such as an integer execution unit, a floating point (FP) execution unit, and a vector execution unit218, as shown. The execution units216and218may be coupled to the register file214, and/or there may be multiple register files214for different operand types, in various embodiments. It is noted that although specific components are shown and described in computer system200, in alternative embodiments different components and numbers of components may be present in computer system200. For example, computer system200may not include some of the memory hierarchy (e.g., L2 cache104, memory108and/or mass-storage device210). Multiple processors similar to the processor202may be included. Multiple execution units of a given type (e.g. integer, floating point, vector, load/store, etc.) may be included and the number of execution units of a given type may differ from the number of execution units of another type. Additionally, although the L2 cache106is shown external to the processor202, it is contemplated that in other embodiments, the L2 cache204may be internal to the processor202. It is further noted that in such embodiments, a level three (L3) cache (not shown) may be used. In addition, the computer system200may include graphics processors, video cards, video-capture devices, user-interface devices, network cards, optical drives, and/or other peripheral devices that are coupled to processor202using a bus, a network, or another suitable communication channel (all not shown for simplicity).

In various embodiments, the processor202may be representative of a general-purpose processor that performs computational operations. For example, the processor202may be a central processing unit (CPU) such as a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), or a field-programmable gate array (FPGA). The processor202may be a standalone component, or may be integrated onto an integrated circuit with other components (e.g. other processors, or other components in a system on a chip (SOC), etc.). The processor202may be a component in a multichip module (MCM) with other components.

More particularly, as illustrated inFIG.2, the processor202may include the execution core212. The execution core212may be configured to execute instructions defined in an instruction set architecture implemented by the processor202. The execution core212may have any microarchitectural features and implementation features, as desired. For example, the execution core212may include superscalar or scalar implementations. The execution core212may include in-order or out-of-order implementations, and speculative or non-speculative implementations. The execution core212may include any combination of the above features. The implementations may include microcode, in some embodiments. The execution core212may include a variety of execution units, each execution unit configured to execute operations of various types (e.g. the integer execution unit, the floating point execution unit, the vector execution unit218, a load/store execution unit (not shown) etc.). The execution core212may include different numbers of pipeline stages and various other performance-enhancing features such as branch prediction. The execution core212may include one or more of instruction decode units, schedulers or reservations stations, reorder buffers, memory management units, I/O interfaces, etc.

The register file214may include a set of registers that may be used to store operands for various instructions. The register file214may include registers of various data types, based on the type of operand the execution core212is configured to store in the registers (e.g. integer, floating point, vector, etc.). The register file214may include architected registers (i.e. those registers that are specified in the instruction set architecture implemented by the processor202). Alternatively or in addition, the register file214may include physical registers (e.g. if register renaming is implemented in the execution core212).

The L1 cache206may be illustrative of any caching structure. For example, the L1 cache206may be implemented as a Harvard architecture (separate instruction cache for instruction fetching and data cache for data read/write by execution units for memory-referencing ops), as a shared instruction and data cache, etc. In some embodiments, load/store execution units may be provided to execute the memory-referencing ops.

An instruction may be an executable entity defined in an instruction set architecture implemented by the processor202. There are a variety of instruction set architectures in existence (e.g. the x86 architecture original developed by Intel, ARM from ARM Holdings, Power and PowerPC from IBM/Motorola, etc.). Each instruction is defined in the instruction set architecture, including its coding in memory, its operation, and its effect on registers, memory locations, and/or other processor state. A given implementation of the instruction set architecture may execute each instruction directly, although its form may be altered through decoding and other manipulation in the processor hardware. Another implementation may decode at least some instructions into multiple instruction operations for execution by the execution units in the processor202. Some instructions may be micro coded, in some embodiments. Accordingly, the term “instruction operation” may be used herein to refer to an operation that an execution unit in the processor202/execution core212is configured to execute as a single entity. Instructions may have a one to one correspondence with instruction operations, and in some cases an instruction operation may be an instruction (possibly modified in form internal to the processor202/execution core212). Instructions may also have a one to more than one (one to many) correspondence with instruction operations. An instruction operation may be more briefly referred to herein as an “op.”

The mass-storage device210, memory208, L2 cache204, and L1 cache206are storage devices that collectively form a memory hierarchy that stores data and instructions for processor202. More particularly, the mass-storage device210may be a high-capacity, non-volatile memory, such as a disk drive or a large flash memory unit with a long access time, while L1 cache206, L2 cache204, and memory208may be smaller, with shorter access times. These faster semiconductor memories store copies of frequently used data. Memory208may be representative of a memory device in the dynamic random access memory (DRAM) family of memory devices. The size of memory208is typically larger than L1 cache206and L2 cache204, whereas L1 cache206and L2 cache204are typically implemented using smaller devices in the static random access memories (SRAM) family of devices. In some embodiments, L2 cache204, memory208, and mass-storage device210are shared between one or more processors in computer system200.

In some embodiments, the devices in the memory hierarchy (i.e., L1 cache206, etc.) can access (i.e., read and/or write) multiple cache lines per cycle. These embodiments may enable more effective processing of memory accesses that occur based on a vector of pointers or array indices to non-contiguous memory addresses.

It is noted the data structures and program instructions (i.e., code) described below may be stored on a non-transitory computer-readable storage device, which may be any device or storage medium that can store code and/or data for use by a computer system (e.g., computer system200). Generally speaking, a non-transitory computer-readable storage device includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, compact discs (CDs), digital versatile discs or digital video discs (DVDs), or other media capable of storing computer-readable media now known or later developed. As such, mass-storage device210, memory208, L2 cache204, and L1 cache206are all examples of non-transitory computer readable storage media.

As mentioned above, the execution core212may be configured to execute vector instructions (e.g. in the vector execution unit218). The vector instructions may be defined as single instruction-multiple-data (SIMD) instructions in the classical sense, in that they may define the same operation to be performed on multiple data elements in parallel. The data elements operated upon by an instance of an instruction may be referred to as a vector. The data elements forming the vector may be referred to as vector elements. Vector elements themselves may have any data type (e.g. integer, floating point, etc.) and more than one data type may be supported for vector elements.

In one embodiment, the register file214may include vector registers that can hold operand vectors and result vectors. In some embodiments, there may be 32 bit vector registers in the vector register file. However, in alternative embodiments, there may be different numbers of vector registers and/or different numbers of bits per register. Furthermore, embodiments which implement register renaming may include any number of physical registers that may be allocated to architected vector registers. Architected registers may be registers that are specifiable as operands in vector instructions.

More particularly, the vector execution unit218may be configured to execute the checksum assist instructions described herein (or ops decoded from the checksum assist instructions), in addition to various vector operations such as arithmetic operations, logic, operations, shifts, etc.

FIG.3is a block diagram300for a checksum instruction, for one embodiment. Each checksum may compute checksum variables with a single instruction. At the top ofFIG.3, a mnemonic for a checksum instruction, adler16, is provided with a result destination register (Vd) having one or more sets of vector elements, such as the two sets shown with304and306, and a data source register (Vn)302. The plurality of registers may be vector registers accessed from a register file214. By way of example, the data source register302may be a 16 byte vector, and the result destination registers may use the first and the second 4-byte elements to write the result for computation of variables (as shown with adler304and sum2306) for the checksum algorithm implemented with the checksum instruction.

The execution core212is configured to accumulate bytes from the source vector register302and add it to a first set of vector elements (Vd.s[0]) of the result vector operand304. Then, the execution core212properly scales and accumulates the previous adler result (Vd.s[0] prior to the304operation) and the bytes from the source vector register302to the second set of vector elements (Vd.s[1]), which stores the result vector operand “sum2”306. This instruction updates the adler/sum2pair (Vd.s[0]/Vd.s[1]) in response to an input 16-byte vector in Vn, as follows:
Vd.s[1]+=(16*Vd.s[0]+16*Vn.b[0]+ . . . +1*Vn.b[15]);
Vd.s[0]+=(Vn.b[0]+Vn.b[1]++Vn.b[15]).

FIG.4is a block diagram400for a checksum instruction, for one embodiment. At the top ofFIG.4, a mnemonic for a checksum instruction, adler32, is provided with a result destination register (Vd) having one or more sets of vector elements, such as two sets shown with adler406and sum2408, and data source registers (Vn)402and (Vm)404. The adler32 variables may be computed with a single instruction.

As shown, the execution core212is configured to accumulate bytes from the first vector operand402and the second vector operand404to generate a first set of vector elements of the result vector operand adler406. In some embodiments, the first vector operand is a source vector402of bytes permitted for the instructions to avoid overflow from a data source buffer. Overflow may occur when an arithmetic operation attempts to create a numeric value that is outside of the range that can be supported by the register. The instruction may be executed repeatedly with a set of consecutive blocks of a defined number of bytes from the data source. By way of example, the data buffer may have data to perform the adler32 instruction 173 times with a sequence of bytes in consecutive blocks from an initial data buffer size of 5552 bytes.

Next, the accumulated bytes adler406are added to a second set of vector elements of the result vector operand sum2408to generate the second set of vector elements written to the result vector operand408. Adler406and sum2408may have existing values such that the computed value during execution is added to a previous value of the adler406and sum2408. In an embodiment, the adler32 instructions generate variable computations adler406and sum2408in the first and second four byte elements of the result operand Vd.s[0]406and sum2Vd.s[1]408. This instruction updates the adler/sum2pair (Vd.s[0]/Vd.s[1]) in response to an input 32-byte vector in Vn and Vm.
Vd.s[1]+=(32*Vd.s[0]+32*Vn.b[0]+ . . . +1*Vm.b[15]);
Vd.s[0]+=(Vn.b[0]+.+Vn.b[15]+Vm.b[0]+.+Vm.b[15]);

FIG.5is a block diagram500for a checksum instruction, for one embodiment. At the top ofFIG.5, a mnemonic for a checksum instruction, mod_base, is provided with a result destination register (Vd)506and data source registers (Vn)502and (Vm)504. As shown, the execution core212is configured to perform a modulo operation by a defined number in the data source register Vm[0]504on the data source register502. The defined number for the modulo operation may be the largest prime number that can be computed for the size of a register before there is a potential for an overflow with computations during execution of the instruction in accordance the respective register width or size. By way of example, the modulo operation may be performed with a defined number of 65521 to prevent an overflow of a 32 bit register with holding the result of computations for variables adler and sum2, two 16-bit variables. In this example, 65521 is the largest prime number for 2{circumflex over ( )}16.

In an embodiment, the execution core212multiplies a first set of vector elements of a first vector operand502by at least one vector element of a second vector operand504to generate a vector written to the result vector operand406. Each vector element of a lower or upper half of a set of vector elements502is multiplied by the vector element of a second vector operand504.

Next, the result vector operand506is shifted by a defined shift value. By way of example, the result vector may be shifted right 47 bits. A multiply-subtract operation may be performed on the result vector operand Vd506. By way of example, the result vector operand Vd506may be multiplied by at least one vector element of the second vector operand Vm[0]504to generate a subtraction value (e.g., Vd*Vm[0]) and the subtraction value may be subtracted from the result vector operand506.

FIG.6is a flowchart600illustrating operation to execute the adler32 instruction. The processor202/execution core212may receive a first source vector of bytes from a data buffer from the first vector operand (602). The processor202/execution core212may accumulate bytes from the first vector operand and the second vector operand into a first portion of the result vector operand to generate a first set of vector elements of the result vector operand (604). The processor202/execution core212may add the accumulated bytes to a second set of vector elements of the result vector operand to a second portion of the result vector operand to generate the second set of vector elements written to the result vector operand (606).

FIG.7is a flowchart700illustrating operation to execute the adler16 instruction. The processor202/execution core212may receive a first vector operand of bytes from a data source buffer (702). The processor202/execution core212may accumulate bytes from the first vector operand and the second vector operand (704). Next, the processor202/execution core212add the accumulated bytes in the first set of vector elements to the second set of vector elements of the result vector operand to generate the second set of vector elements written to the result vector operand (706).

FIG.8is a flowchart800illustrating operation to execute the mod_base instruction. The processor202/execution core212may receive a first vector operand of bytes from a data source buffer (802). The processor202/execution core212may multiply a first set of vector elements of a first vector operand by at least one vector element of a second vector operand to generate a vector written to the result vector operand (804). Next, the processor202/execution core212may shift the result vector operand by a defined value (806). The processor202/execution core212may multiply the result vector operand by at least one vector element of the second vector operand to generate a subtraction value (808). The processor202/execution core212may subtract the subtraction value from the result vector operand (808).

FIG.9is a flowchart900illustrating operation to execute instructions for a checksum algorithm. Initially, the processor202/execution core212may receive a block of bytes from a set of consecutive blocks of bytes from a data source102(902). The input data for the checksum may be broken into a set of consecutive blocks for computing the checksum to avoid errors, such as overflow, 2-byte errors, and/or minimize expensive operations. 2-Byte errors are a class of errors that may result in leaving a computation result as unchanged. In some embodiments, the modulo operations may be viewed as an expensive operation in regards to the time it takes for computation. As such, the mod_base modulo operation can be performed at the end of each consecutive block, in this example, as opposed to following every computation of adler and sum2.

By way of example, if the maximum value for variables (e.g., sum2and adler) is 65520, and the input bytes maximum value is 255, then the largest n such that 255*n*(n+1)/2+(n+1) (65520)<2{circumflex over ( )}32 to allow for no overflow during computations with an unsigned 32 bit integer. Continuing with this example, a long sequence of bytes may be broken into consecutive blocks of 5552 bytes and the modulo instruction mod_base may be performed.

After receipt of the block of bytes, the processor202/execution core212may perform an adler16 instruction with a first set of bytes from the block to generate a first and a second set of vector elements in a result vector operand (904). With a block size of 5552 bytes example, the adler16 instruction may be performed once with an input of a 16 byte vector and the remaining data in the block may be processed with the adler32 instruction. As indicated above, the adler16 instruction may have the execution core configured to accumulate bytes from the first vector operand into a first set of vector elements of the second result vector operand and add the accumulated bytes in the first set of vector elements to the second set of vector elements of the second result vector operand to generate the second set of vector elements written to the second result vector operand. In one embodiment, the result vector operand values may be an input to the subsequent adler32 instructions such that the adler and the sum2variables will have input values.

Next, the processor202/execution core212may perform adler32 instructions (e.g., 173 times) consecutively with remaining data from the block and write the result to the first and the second set of vector elements in the result vector operand (906). In some embodiments, the main loop of four instructions may be executed in a one cycle/iteration. With the new instructions, a possible code snipped for updating the adler/sum2pair is as follows:

The processor202/execution core212performs a mod_base modulo operation on the first and the second set of vector elements in the result vector operand (908) to perform the mod_base operation on adler and sum for the block. The processor202/execution core212may execute a first modulo instruction on the first set of vector elements to generate the first set of vector elements written to the result vector operand and a second modulo instruction on the second set of vector elements to generate the second set of vector elements written to the result vector operand.

The processor202/execution core212may concatenate the first and the second set of vector elements in the result vector operand to form a datum for the block (908). The processor202/execution core212may execute a concatenate instruction on the first set of vector elements and the second set of vector elements to generate a checksum result. The checksum result may be a computation for a fixed size datum used to verify the integrity of the block. If there are more blocks to process (910), then process continues with receiving more blocks (902).

Alternatively, if there are no further blocks to process (910), a datum is generated by adding each of the block datums for the set of consecutive blocks and the result is written to a checksum result register (912). Next, the generated datum in the checksum result register may be compared to a received datum (914) to verify the integrity of the data that processed with the checksum algorithm.

FIG.10is a block diagram1000of one embodiment of a vector execution unit216shown inFIG.2, including circuitry configured to execute various assist instructions. The circuitry shown inFIG.10may include circuitry that is shared with other types of vector operations and/or circuitry that is dedicated to the assist instructions, or any combination thereof. The vector execution unit1002is coupled to inputs for the op to be executed, as well as the source operands V1and V2. The result operation may be specified as part of the op and may be forwarded with the result to the register file214.

A control circuit1004may receive the op and may control the other circuitry in the vector execution unit218accordingly. Thus, the control circuit1004may be coupled to the other circuitry shown inFIG.10, although the connections are not expressly illustrated inFIG.10to avoid complicating the drawing. An adder circuit1006may be provided, which may be coupled to the second source operand V2. The adder circuit1006may be configured to add various elements of the vector V1and the V2. For example, V1may be an adler variable for the adler16 instruction that is computed with (Vn.b[0]+Vn.b[1]++Vn.b[15]) in the result vector Vd.s[0], where Vn=V1. In another example, an adler variable of the adler32 instruction is computed with (Vn.b[0]+.+Vn.b[15]+Vm.b[0]+.+Vm.b[15]) in the result vector Vd.s[0], where Vn=V1and Vm=V2.

Similarly, the adder circuit1008may be configured to add various elements of the vector V1, V2, and the generated adler variable Vd.s[0]. For example, the sum2variable for the adler16 instruction is computed with (16*Vd.s[0]+16*Vn.b[0]+ . . . +1*Vn.b[15]) in the result vector Vd.s[1], where Vn=V1. In another example, the sum2variable for the adler32 is computed with (32*Vd.s[0]+32*Vn.b[0]+ . . . +1*Vm.b[15]) in the result vector Vd.s[1], where Vn=V1and Vm=V2.

The mod_base modulo operations may be performed on the adler and the sum2results in the result vectors Vd.s[0] and Vd.s[1] with the multiply circuit1010, shift circuit1012, and multiply subtract circuit1014.

Optionally, compute circuit1016may be provided to compute the datum with a concat instructions/ops. The compute circuit1016may be coupled to the multiply subtract circuit1014and may receive the modulo of the adler and sum2variables to compute the datum. In other embodiments, the output to the register file may be the adler and sum2variable values.

The output select circuit1018shown inFIG.10may be coupled to the compute circuit and may be configured to select among the outputs based on the op being performed to provide an output to the register file1020.

Turning next toFIG.11, a block diagram of one embodiment of a system1100is shown. In the illustrated embodiment, the system1100includes at least one instance of a system on a chip (SOC)1106coupled to one or more peripherals1104and an external memory1102. A power supply (PMU)1108is provided which supplies the supply voltages to the SOC1106as well as one or more supply voltages to the memory1102and/or the peripherals1104. In some embodiments, more than one instance of the SOC1106may be included (and more than one memory1102may be included as well). The memory1102may include the memories208illustrated inFIG.2, in an embodiment.

The peripherals1104may include any desired circuitry, depending on the type of system1100. For example, in one embodiment, the system1100may be a mobile device (e.g., personal digital assistant (PDA), smart phone, etc.) and the peripherals1104may include devices for various types of wireless communication, such as Wi-Fi, Bluetooth, cellular, global positioning system, etc. The peripherals1104may also include additional storage, including RAM storage, solid state storage, or disk storage. The peripherals1104may include user interface devices such as a display screen, including touch display screens or multitouch display screens, keyboard or other input devices, microphones, speakers, etc. In other embodiments, the system1100may be any type of computing system (e.g., desktop personal computer, laptop, workstation, net top etc.).

The external memory1102may include any type of memory. For example, the external memory1102may be SRAM, dynamic RAM (DRAM) such as synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM, RAMBUS DRAM, low power versions of the DDR DRAM (e.g., LPDDR, mDDR, etc.), etc. The external memory1102may include one or more memory modules to which the memory devices are mounted, such as single inline memory modules (SIMMs), dual inline memory modules (DIMMs), etc. Alternatively, the external memory1102may include one or more memory devices that are mounted on the SOC1106in a chip-on-chip or package-on-package implementation.

As illustrated, system1100is shown to have application in a wide range of areas. For example, system1100may be utilized as part of the chips, circuitry, components, etc., of a desktop computer1110, laptop computer1120, tablet computer1130, cellular or mobile phone1140, or television1150(or set-top box coupled to a television). Also illustrated is a smartwatch and health monitoring device1160. In some embodiments, smartwatch may include a variety of general-purpose computing related functions. For example, smartwatch may provide access to email, cellphone service, a user calendar, and so on. In various embodiments, a health monitoring device may be a dedicated medical device or otherwise include dedicated health related functionality. For example, a health monitoring device may monitor a user's vital signs, track proximity of a user to other users for the purpose of epidemiological social distancing, contact tracing, provide communication to an emergency service in the event of a health crisis, and so on. In various embodiments, the above-mentioned smartwatch may or may not include some or any health monitoring related functions. Other wearable devices are contemplated as well, such as devices worn around the neck, devices that are implantable in the human body, glasses designed to provide an augmented and/or virtual reality experience, and so on.

System1100may further be used as part of a cloud-based service(s)1170. For example, the previously mentioned devices, and/or other devices, may access computing resources in the cloud (i.e., remotely located hardware and/or software resources). Still further, system1100may be utilized in one or more devices of a home other than those previously mentioned. For example, appliances within the home may monitor and detect conditions that warrant attention. For example, various devices within the home (e.g., a refrigerator, a cooling system, etc.) may monitor the status of the device and provide an alert to the homeowner (or, for example, a repair facility) should a particular event be detected. Alternatively, a thermostat may monitor the temperature in the home and may automate adjustments to a heating/cooling system based on a history of responses to various conditions by the homeowner. Also, the application of system1100to various modes of transportation. For example, system1100may be used in the control and/or entertainment systems of aircraft, trains, buses, cars for hire, private automobiles, waterborne vessels from private boats to cruise liners, scooters (for rent or owned), and so on. In various cases, system1100may be used to provide automated guidance (e.g., self-driving vehicles), general systems control, and otherwise. These any many other embodiments are possible and are contemplated. It is noted that the devices and applications illustrated are illustrative only and are not intended to be limiting. Other devices are possible and are contemplated.

The word “may” is used herein in a permissive sense (i.e., having the potential to, being able to) and not in a mandatory sense (i.e., must). The terms “comprising” and “including,” and forms thereof, are open-ended and mean “including, but not limited to.”

In utilizing the various aspects of the embodiments, it would become apparent to one skilled in the art that combinations or variations of the above embodiments are possible for forming a fan out system in package including multiple redistribution layers. Although the embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the specific features or acts described. The specific features and acts disclosed are instead to be understood as embodiments of the claims useful for illustration.