Compressed instruction format for use in a VLIW processor and processor for processing such instructions

Abstract

Software creates a compressed instruction format for a VLIW processor which allows greater efficiency in use of cache and memory. Instructions are byte aligned and variable length. Branch targets are uncompressed. Format bits specify how many issue slots are used in a following instruction. NOPS are not stored in memory. Individual operations are compressed according to features such as whether they are resultless, guarded, short, zeroary, unary, or binary. Instructions are stored in compressed form in memory and in cache. Instructions are decompressed on the fly after being read out from cache.

Claims

We claim:

1. Computer software, stored in a computer storage medium, for producing compressed code for running on a VLIW processor, the software comprising

code for receiving a compiled and linked object module produced by a compiler and/or linker, which object module is stored in a computer storage medium;

code for compressing the compiled and linked software to produce a second object module, which second object module is stored in a computer storage medium, which second object module includes a stream of instructions for execution on a VLIW processor, the stream of instructions comprising:

a first instruction including a first format field which specifies an instruction compression format; and

a second instruction following the first instruction, the second instruction including a second format field and a compressed operation, the compressed operation being compressed according to the first format field.

2. The computer software of claim 1 wherein the first instruction also includes at least one operation field.

3. The computer software of claim 1 wherein the second format field specifies a compression of an operation in a third instruction.

4. Computer software, stored in a computer storage medium, for producing compressed code for running on a VLIW processor, the software comprising

code for receiving a compiled and linked object module produced by a compiler and/or linker, which object module is stored in a computer storage medium;

code for compressing the compiled and linked software to produce a second object module, which second object module is stored in a computer storage medium, which second object module includes a stream of instructions for execution on a VLIW processor, the stream of instructions comprising:

a stored VLIW instruction, the instruction comprising a plurality of operations for commencing execution in a same machine cycle on distinct functional units of a VLIW processor, each operation having an executable form having a respective executable operation length, each non-null operation of the instruction being in a compressed , compressed according to a compression scheme which assigns a respective compressed operation length to that non-null operation, the compressed instruction length being less than the executable operation length.

Description

BACKGROUND OF THE INVENTION

a. Field of the Invention

The invention relates to VLIW (Very Long Instruction Word) processors and in particular to instruction formats for such processors and apparatus for processing such instruction formats.

b. Background of the Invention

VLIW processors have instruction words including a plurality of issue slots. The processors also include a plurality of functional units. Each functional unit is for executing a set of operations of a given type. Each functional unit is RISC-like in that it can begin an instruction in each machine cycle in a pipe-lined manner. Each issue slot is for holding a respective operation. All of the operations in a same instruction word are to be begun in parallel on the functional unit in a single cycle of the processor. Thus the VLIW implements fine-grained parallelism.

Thus, typically an instruction on a VLIW machine includes a plurality of operations. On conventional machines, each operation might be referred to as a separate instruction. However, in the VLIW machine, each instruction is composed of operations or no-ops (dummy operations).

Like conventional processors, VLIW processors use a memory device, such as a disk drive to store instruction streams for execution on the processor. A VLIW processor can also use caches, like conventional processors, to store pieces of the instruction streams with high bandwidth accessibility to the processor.

The instruction in the VLIW machine is built up by a programmer or compiler out of these operations. Thus the scheduling in the VLIW processor is software-controlled.

The VLIW processor can be compared with other types of parallel processors such as vector processors and superscalar processors as follows. Vector processors have single operations which are performed on multiple data items simultaneously. Superscalar processors implement fine-grained parallelism, like the VLIW processors, but unlike the VLIW processor, the superscalar processor schedules operations in hardware.

Because of the long instruction words, the VLIW processor has aggravated problems with cache use. In particular, large code size causes cache misses, i.e. situations where needed instructions are not in cache. Large code size also requires a higher main memory bandwidth to transfer code from the main memory to the cache.

Large code size can be aggravated by the following factors.

In order to fine tune programs for optimal running, techniques such as grafting, loop unrolling, and procedure inlining are used. These procedures increase code size.

Not all issue slots are used in each instruction. A good optimizing compiler can reduce the number of unused issue slots; however a certain number of no-ops (dummy instructions) will continue to be present in most instruction streams.

In order to optimize use of the functional units, operations on conditional branches are typically begun prior to expiration of the branch delay, i.e. before it is known which branch is going to be taken. To resolve which results are actually to be used, guard bits are included with the instructions.

Larger register files, preferably used on newer processor types, require longer addresses, which have to be included with operations.

A scheme for compression of VLIW instructions has been proposed in U.S. Pat. Nos. 5,179,680 and 5,057,837. This compression scheme eliminates unused operations in an instruction word using a mask word, but there is more room to compress the instruction.

SUMMARY OF THE INVENTION

It is an object of the invention to compress VLIW instructions.

This object is met by compression software. The compression software includes code means for receiving a compiled and linked object module and code means for compressing the object module. The compressing code produces a second object module for storing. The second object module includes a stored instruction. The instruction comprises a plurality of operations. Each operation is compressed according to a compression scheme which assigns a compressed operation length to that operation. The compressed operation length is chosen from a plurality of finite lengths. The finite lengths include at least two non-zero lengths. Which of the finite lengths is chosen is dependent upon at least one feature of the operation.

Branch targets are uncompressed. For each instruction, other than a branch target, compression format information is stored in a previous instruction.

Further information about technical background to this application

The following prior applications are incorporated herein by reference:

U.S. application Ser. No. 998,080, filed Dec. 29, 1992 (PHA 21,777), which shows a VLIW processor architecture for implementing fine-grained parallelism;

U.S. application Ser. No. 142,648 filed Oct. 25, 1993 (PHA 1205) now Pat. No. 5450556, which shows use of guard bits; and

U.S. application Ser. No. 366,958 filed Dec. 30, 1994 (PHA 21,932) which shows a register file for use with VLIW architecture.

Bibliography of program compression techniques:

J. Wang et al, "The Feasibility of Using Compression to Increase Memory System Performance", Proc. 2nd Int. Workshop on Modeling Analysis, and Simulation of Computer and Telecommunications Systems, p. 107-113 (Durham, N.C., USA 1994);

H. Schroder et al., "Program compression on the instruction systolic array", Parallel Computing, vol. 17, n 2-3, June 1991, p.207-219;

A. Wolfe et al., "Executing Compressed Programs on an Embedded RISC Architecture", J. Computer and Software Engineering, vol. 2, no. 3, pp 315-27, (1994);

M. Kozuch et al., "Compression of Embedded Systems Programs", Proc. 1994 IEEE Int. Conf. on Computer Design: VLSI in Computers and Processors (Oct. 10-12, 1994, Cambridge, Mass., USA) pp.270-7.

Typically the approach adopted in these documents has been to attempt to compress a program as a whole or blocks of program code. Moreover, typically some table of instruction locations or locations of blocks of instructions is necessitated by these approaches.

BRIEF DESCRIPTION OF THE DRAWING

The invention will now be described by way of non-limitative example with reference to the following figures:

FIG. 1a shows a processor for using the compressed instruction format of the invention.

FIG. 1b shows more detail of the CPU of the processor of FIG. 1a.

FIGS. 2a-2e show possible positions of instructions in cache.

FIG. 3 illustrates a part of the compression scheme in accordance with the invention.

FIGS. 4a-4f illustrate examples of compressed instructions in accordance with the invention.

FIGS. 5a-5b give a table of compressed instructions formats according to the invention.

FIG. 6a is a schematic showing the functioning of instruction cache 103 on input.

FIG. 6b is a schematic showing the functioning of a portion of the instruction cache 103 on output.

FIG. 7 is a schematic showing the functioning of instruction cache 104 on output.

FIG. 8 illustrates compilation and linking of code according to the invention.

FIG. 9 is a flow chart of compression and shuffling modules.

FIG. 10 expands box 902 of FIG. 9.

FIG. 11 expands box 1005 of FIG. 10.

FIG. 12 illustrates the decompression process.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1a shows the general structure of a processor according to the invention. A microprocessor according to the invention includes a CPU 102, an instruction cache 103, and a data cache 105. The CPU is connected to the caches by high bandwidth buses. The microprocessor also contains a memory 104 where an instruction stream is stored.

The cache 103 is structured to have 512 bit double words. The individual bytes in the words are addressable, but the bits are not. Bytes are 8 bits long. Preferably the double words are accessible as a single word in a single clock cycle.

The instruction stream is stored as instructions in a compressed format in accordance with the invention. The compressed format is used both in the memory 104 and in the cache 103.

FIG. 1b shows more detail of the VLIW processor according to the invention. The processor includes a multiport register file 150, a number of functional units 151, 152, 153, . . . , and an instruction issue register 152. The multiport register file stores results from and operands for the functional units. The instruction issue register includes a plurality of issue slots for containing operations to be commenced in a single clock cycle, in parallel, on the functional units 151, 152, 153, . . . . A decompression unit 155, explained more fully below, converts the compressed instructions from the instruction cache 103 into a form usable by the IIR 154.

COMPRESSED INSTRUCTION FORMAT

1. General Characteristics

The preferred embodiment of the claimed instruction format is optimized for use in a VLIW machine having an instruction word which contains 5 issue slots. The format has the following characteristics

unaligned, variable length instructions;

variable number of operations per instruction;

3 possible sizes of operations: 26, 34 or 42 bits (also called a 26/34/42 format).

the 32 most frequently used operations are encoded more compactly than the other operations;

operations can be guarded or unguarded;

operations are one of zeroary, unary, or binary, i.e. they have 0, 1 or 2 operands;

operations can be resultless;

operations can contain immediate parameters having 7 or 32 bits

branch targets are not compressed; and

format bits for an instruction are located in the prior instruction.

2. Instruction Alignment

Except for branch targets, instructions are stored aligned on byte boundaries in cache and main memory. Instructions are unaligned with respect to word or block boundaries in either cache or main memory. Unaligned instruction cache access is therefore needed.

In order to retrieve unaligned instructions, processor retrieves one word per clock cycle from the cache.

As will be seen from the compression format described below, branch targets need to be uncompressed and must fall within a single word of the cache, so that they can be retrieved in a single clock cycle. Branch targets are aligned by the compiler or programmer according to the following rule:

if a word boundary falls within the branch target or exactly at the end of the branch target, padding is added to make the branch target start at the next word boundary Because the preferred cache retrieves double words in a single clock cycle, the rule above can be modified to substitute double word boundaries for word boundaries.

The normal unaligned instructions are retrieved so that succeeding instructions are assembled from the tail portion of the current word and an initial portion of the succeeding word. Similarly, all subsequent instructions may be assembled from 2 cache words, retrieving an additional word in each clock cycle.

This means that whenever code segments are relocated (for instance in the linker or in the loader) alignment must be maintained. This can be achieved by relocating base addresses of the code segments to multiples of the cache block size.

FIGS. 2a-e show unaligned instruction storage in cache in accordance with the invention.

FIG. 2a shows two cache words with three instructions i1, i2, and i3 in accordance with the invention. The instructions are unaligned with respect to word boundaries. Instructions i1 and i2 can be branch targets, because they fall entirely within a cache word. Instruction i3 crosses a word boundary and therefore must not be a branch target. For the purposes of these examples, however, it will be assumed that i1 and only i1 is a branch target.

FIG. 2b shows an impermissible situation. Branch target i1 crosses a word boundary. Accordingly, the compiler or programmer must shift the instruction i1 to a word boundary and fill the open area with padding bytes, as shown in FIG. 2c.

FIG. 2d shows another impermissible situation. Branch target instruction i1 ends precisely at a word boundary. In this situation, again i1 must be moved over to a word boundary and the open area filled with padding as shown in FIG. 2e.

Branch targets must be instructions, rather than operations within instructions. The instruction compression techniques described below generally eliminate no-ops (dummy instructions). However, because the branch target instructions are uncompressed, they must contain no-ops to fill the issue slots which are not to be used by the processor.

3. Bit and Byte order

Throughout this application bit and byte order are little endian. Bits and bytes are listed with the least significant bits first, as below:

Bit number 0 . . . 8 . . . 16 . . .

Byte number 0 1 2

address 0 1 2

Instruction format

The compressed instruction can have up to seven types of fields. These are listed below. The format bits are the only mandatory field.

The instructions are composed of byte aligned sections. The first two bytes contain the format bits and the first group of 2-bit operation parts. All of the other fields are integral multiples of a byte, except for the second 2-bit operation parts which contain padding bits.

The operations, as explained above can have 26, 34, or 42 bits. 26-bit operations are broken up into a 2-bit part to be stored with the format bits and a 24-bit part. 34-bit operations are broken up into a 2 bit part, a 24-bit part, and a one byte extension. 42-bit operations are broken up into a 2 bit part, a 24 bit part, and a two byte extension.

A. Format bits

These are described in section 5 below. With a 5 issue slot machine, 10 format bits are needed. Thus, one byte plus two bits are used.

B. 2-bit operation parts, first group

While most of each operation is stored in the 24-bit part explained below, i.e. 3 bytes, with the preferred instruction set 24 bits was not adequate. The shortest operations required 26 bits. Accordingly, it was found that the six bits left over in the bytes for the format bit field could advantageously be used to store extra bits from the operations, two bits for each of three operations. If the six bits designated for the 2-bit parts are not needed, they can be filled with padding bits.

C. 24-bit operation parts, first group

There will be as many 24 bit operation parts as there were 2 bit operation parts in the two bit operation parts, first group. In other words, up to three 3 byte operation parts can be stored here.

D. 2 bit operation parts, second group

In machines with more than 3 issue slots a second group of 2-bit and 24-bit operation parts is necessary. The second group of 2-bit parts consists of a byte with 4 sets of 2-bit parts. If any issue slot is unused, its bit positions are filled with padding bits. Padding bits sit on the left side of the byte. In a five issue slot machine, with all slots used, this section would contain 4 padding bits followed by two groups of 2-bit parts. The five issue slots are spread out over the two groups: 3 issue slots in the first group and 2 issue slots in the second group.

E. 24-bit operation parts, second group

The group of 2-bit parts is followed by a corresponding group of 24 bit operation parts. In a five issue slot machine with all slots used, there would be two 24-bit parts in this group.

F. further groups of 2-bit and 24-bit parts

In a very wide machine, i.e. more than 6 issue slots, further groups of 2-bit and 24-bit operazion parts are necessary.

G. Operation extension

At the end of the instruction here is a byte-aligned group of optional 8 or 16 bit operation extensions, each of them byte aligned. The extensions are used to extend the size of the operations from the basic 26 bit to 34 or 42 bit, if needed.

The formal specification for the instruction format is:

<instruction> ::=

<instruction start>

<instruction middle>

<instruction end>

<instruction extension>

<instruction start> ::=

<Format:2*N>{<padding:1>}V2{<2-bit operation part:2>}V1{<24-bit operation part:24>}V1

<instruction middle> ::={{<2-biz operation part:2>}4 {24-bit operation part:24>}4}V3

<instruction end> ::={<padding:1>}V5{<2-bit operation part:2>}V4 {24-bit operation part:24>}V4

<instruction extension> ::={<operationextension:0/8/16>}S <padding>::="0"

Wherein the variables used above are defined as follows:

N=the number of issue slots of the machine, N>1

S=the number of issue slots used in this instruction (0.ltoreq.S.ltoreq.N)

C1=4-(N mod 4)

If (S.ltoreq.C1) then V1=S and V2=2*(C1-V1)

If (S>C1) then V1=C1 and V2=0

V3=(S-V1) div 4

V4=(S-V1) mod 4

If (V4>0) then V5=2*(4-V4) else V5=0

Explanation of notation

::=means "is defined as"

<field name:number>

means the field indicated before the colon has the number of bits indicateu after the colon.

{<field name>}number

means the field indicated in the angle brackets and braces is repeated the number of times indicated after the braces

"0" means the bit "0".

"div" means integer divide

"mod" means modulo

:0/8/16

means that the field is 0, 8, or 16 bits long

Examples of compressed instructions are shown in FIGS. 4 a-f.

FIG. 4a shows an instruction with no operations. The instruction contains two bytes, including 10 bits for the format field and 6 bits which contain only padding. The former is present in all the instructions. The latter normally correspond to the 2-bit operation parts. The X's at the top of the bit field indicate that the fields contain padding. In the later figures, an O is used to indicate that the fields are used.

FIG. 4b shows an instruction with one 26-bit operation. The operation includes one 24 bit part at bytes 3-5 and one 2 bit part in byte 2. The 2 bits which are used are marked with an O at the top.

FIG. 4c shows an instruction with two 26-bit operations. The first 26-bit operation has its 24-bit part in byeeb 3-5 and its extra two bits in the last of the 2-bit part fields. The second 26-bit operation has its 24-bit part in bytes 6-8 and its extra two bits in the second to last of the 2-bit part fields.

FIG. 4d shows an instruction with three 26-bit operations. The 24-bit parts are located in bytes 3-11 and the 2-bit parts are located in byte 2 in reversed order from the 24-bit parts.

FIG. 4e shows an instruction with four operations. The second operation has a 2 byte extension. The fourth operation has a one byte extension. The 24-bit parts of the operations are stored in bytes 3-11 and 13-15. The 2-bit parts of the first three operations are located in byte 2. The 2-bit part of the fourth operation is located in byte 12. An extension for operation 2 is located in bytes 16-17. An extension for operation 4 is located in byte 18.

FIG. 4f shows an instruction with 5 operations each of which has a one byte extension. The extensions all appear at the end of the instruction.

While extensions only appear after the second group of 2-bit parts in the examples, they could equally well appear at the end of an instruction with 3 or less operations. In such a case the second group of 2-bit parts would not be needed.

There is no fixed relationship between the position of operations in the instruction and the issue slot in which they are issued. This makes it possible to make an instruction shorter when not all issue slots are used. Operation positions are filled from left to right. The Format section of the instruction indicates to which issue slot a particular operation belongs. For instance, if any instruction contains only one operation, then it is located in the first operation position and it can be issued to any issue slot, not just slot number 1. The decompression hardware takes care of routing operation to their proper issue slots.

No padding bytes are allowed between instructions that form one sequential block of code. Padding blocks are allowed between distinct blocks of code.

5. Format Bits

The instruction compression technique of the invention is characterized by the use of a format field which specifies which issue slots are to be used by the compressed instruction. To achieve retrieval efficiency, format bits are stored in the instruction preceding the instruction to which the format bits relate. This allows pipelining of instruction retrieval. The decompression unit is alerted to how many issue slots to expect in the instruction to follow prior to retrieval of that instruction. The storage of format bits preceding the operations to which they relate is illustrated in FIG. 3. Instruction 1, which is an uncompressed branch target, containe a format field which indicates the issue slots used by the operations specified in instruction 2. Instructions 2 through 4 are compressed. Each contains a format field which specifies issue slots to be used by the operations of the subsequent instruction.

The format bits are encoded as follows. There are 2*N format bits for an N-issue slot machine. In the case of the preferred embodiment, there are five issue slots. Accordingly, there are 10 format bits. Herein the format bits will be referred to in matrix notation as Format›j! where j is the bit number. The format bits are organized in N groups of 2 bits. Bits Format›2i! and Format›2i+1! give format information about issue slot i, where 0.ltoreq.i.ltoreq.N. The meaning of the format bits is explained in the following table:

                  TABLE I
    ______________________________________
    Format ›2i!
             Format ›2i + 1!
    lsb      msb          meaning
    ______________________________________
    0        0            Issue slot i is used and an
                          operation for it is available in
                          the instruction. The operation
                          size is 26 bits. The size of the
                          extension is 0 bytes
    1        0            Issue slot i is used and an
                          operation for it is available in
                          the instruction. The operation
                          size is 34 bits. The size of the
                          extension is 1 byte.
    0        1            Issue slot i is used and an
                          operation for it is available in
                          the instruction. The operation
                          size is 42 bits. The size of the
                          extension is 2 bytes.
    1        1            Issue slot i is unused and no
                          operation for it is included in the
                          instruction.
    ______________________________________

                  TABLE II
    ______________________________________
    OPERATION TYPE       SIZE
    ______________________________________
    <binary-unguarded-short>
                         26
    <unary-param7-unguarded-short>
                         26
    <binary-unguarded-param7-
                         26
    resultless-short>
    <unary-short>        26
    <binary-short>       34
    <unary-param7-short> 34
    <binary-param7-resultless-
                         34
    short>
    <binary-unguarded>   34
    <binary-resultless>  34
    <unary-param7-unguarded>
                         34
    <unary>              34
    <binary-param7-resultless>
                         42
    <binary>             42
    <unary-param7>       42
    <zeroary-param32>    42
    <zeroary-param32-resultless>
                         42
    ______________________________________

                  TABLE II'
    ______________________________________
    FORMAT              ALIASED TO
    ______________________________________
    zeroary             unary
    unary.sub.-- resultless
                        unary
    binary.sub.-- resultless.sub.-- short
                        binary.sub.-- resultless
    zeroary.sub.-- param32.sub.-- short
                        zeroary.sub.-- param32
    zeroary.sub.-- param32.sub.-- resultless.sub.-- short
                        zeroary.sub.-- param32.sub.-- resultless
    zeroary.sub.-- short
                        unary
    unary.sub.-- resultless.sub.-- short
                        unary
    binary.sub.-- resultless.sub.-- unguarded
                        binary.sub.-- resultless
    unary.sub.-- unguarded
                        unary
    binary.sub.-- param7.sub.-- resultless.sub.-- unguarded
                        binary.sub.-- param7.sub.-- resultless
    unary.sub.-- unguarded
                        unary
    binary.sub.-- param7.sub.-- resultless.sub.-- unguarded
                        binary.sub.-- param7.sub.-- resultless
    zeroary.sub.-- unguarded
                        unary
    unary.sub.-- resultless.sub.-- unguarded.sub.-- short
                        binary.sub.-- unguarded.sub.-- short
    unary.sub.-- unguarded.sub.-- short
                        unary.sub.-- short
    zeroary.sub.-- param32.sub.-- unguarded.sub.-- short
                        zeroary.sub.-- param32
    zeroary.sub.-- parame32.sub.-- resultless.sub.-- un-
                        zeroary.sub.-- param32.sub.-- resultless
    guarded.sub.-- short
    zeroary.sub.-- unguarded.sub.-- short
                        unary
    unary.sub.-- resultless.sub.-- unguarded.sub.-- short
                        unary
    unary.sub.-- long   binary
    binary.sub.-- long  binary
    binary.sub.-- resultless.sub.-- long
                        binary
    unary.sub.-- param7.sub.-- long
                        unary.sub.-- param7
    binary.sub.-- param7.sub.-- resultless.sub.-- long
                        binary.sub.-- param7.sub.-- resultless
    zeroary.sub.-- param32.sub.-- long
                        zeroary.sub.-- param32
    zeroary.sub.-- param32.sub.-- resultless.sub.-- long
                        zeroary.sub.-- param32.sub.-- resultless
    zeroary.sub.-- long binary
    unary.sub.-- resultless.sub.-- long
                        binary
    ______________________________________

                  TABLE III
    ______________________________________
    FIELD        SIZE   MEANING
    ______________________________________
    src1         7      register file
                        address of first
                        operand
    src2         7      register file
                        address of second
                        operand
    guard        7      register file
                        address of guard
    dst          7      register file
                        address of result
    param        7/32   7 bit parameter or
                        32 bit immediate
                        value
    op code      5/8    5 bit short op code
                        or 8 bit long op
                        code
    ______________________________________

                  TABLE IV
    ______________________________________
    Name of module identification of function performed
    ______________________________________
    scheme.sub.-- table
                   readable version of table of FIGS. 5a
                   and 5b
    comp.sub.-- shuffle.c
                   256-bit shuffle, see box 1010
    comp.sub.-- scheme.c
                   boxes 1103-1104
    comp.sub.-- bitstring.c
                   boxes 1005 & 1009
    comp.sub.-- main.c
                   controls main flow of FIGS. 9 and 10
    comp.sub.-- src.c,
                   miscellaneous support routines for
    comp.sub.-- reference.c,
                   performing other functions listed in
    comp.sub.-- misc.c,
                   FIG. 11
    comp.sub.-- btarget.c
    ______________________________________

                  TABLE V
    ______________________________________
    # of pins name of group
    in group  of pins     description of group of pins
    ______________________________________
    512       data512     512 bit input data word from
                          memory, i.e. either from the
                          instruction cache or the main
                          memory
    32        PC          input program counter
    44        operation4  output contents of issue slot 4
    44        operation3  output contents of issue slot 3
    44        operation2  output contents of issue slot 2
    44        operation1  output contents of issue slot 1
    44        operation0  output contents of issue slot 0
    10        format.sub.-- out
                          output duplicate of format bits
                          in operations
    32        first.sub.-- word
                          output first 32 bits pointed to
                          by program counter
    1         format.sub.-- ctr10
                          is it a branch target or not?
    1, each   reissue1    input global pipeline control
              stall.sub.-- in
                          signals
              freeze
              reset
              clk
    ______________________________________

• Inventors
  Hampapuram, Hari; Lee, Yen C; Jacobs, Eino; Ang, Michael;
• Assignee
  Philips Electronics North America Corporation (New York, NY)
• Published
  Mar-2-1999
• Current US Classes:
  712/24
  717/149
• Application #
  086696
• International Classes
  G06F 007/00
• Field of Search
  395/800.24 395/705 395/706
• Examiner
  Coleman; Eric
• Agent
  Barschall; Anne E.
• US Patent References:
  4437149
  5057837
  5179680
  5632024