Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
  • G06F9/30181—Instruction operation extension or modification
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
  • G06F9/30003—Arrangements for executing specific machine instructions
  • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
  • G06F9/30181—Instruction operation extension or modification
  • G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag

Definitions

• This disclosure relates generally to data processing systems, and more specifically, to use of a debug instruction in a data processing system.
• Debug instructions are commonly used during software development to allow debug operations to take place. Once the software has been developed and checked with debug instructions, these debug instructions are removed so as not to cause undesired exceptions in the software application. However, removal of these debug instructions can change the execution characteristics of the system and may be especially problematic in real-time applications.
• FIG. 1 is a block diagram of a data processing system, in accordance with one or more embodiments of the present invention.
• FIG. 2 is a block diagram of a processor in accordance with one or more embodiments of the present invention.
• FIG. 3 is a flow chart that illustrates address-qualified conditional debug operation of one or more embodiments of the present invention.
• FIG. 4 illustrates operation of one or more embodiments of the present invention using memory paging system attributes to facilitate conditional debug operation based on address.
• FIG. 5 illustrates operation of one or more embodiments of the present invention using a segment or region marking technique to facilitate conditional debug operation based on address.
• FIG. 6 illustrates operation of one or more embodiments of the present invention in which a composition of memory paging system and segment or region marking techniques is employed to facilitate conditional debug operation based on address.
• Debug instructions are supported in various processor implementations to facilitate conditional entry into a debug halted mode or to facilitate generation of a software debug exception (e.g., a debug interrupt).
• a software debug exception e.g., a debug interrupt
• a developer is able to initiate debug operations under software control and based on a current state of the execution environment.
• those debug instructions that remain in production code can trigger undesired exceptions and debug behaviors unless removed or suppressed.
• removal of the debug instructions tends to change execution characteristics of the system. That is, the code image itself changes since branch targets, page boundaries, and other instruction relationships may change upon removal of the debug instructions. These changes may be particularly problematic in real-time code.
• a processor implementation that supports selection of an execution mode for debug instruction instances based on respective addresses thereof in addressable memory can provide an attractive mechanism for executing debug instructions in a way that allows some instances of the instructions to operate with debug semantics while suppressing other instances by executing them with no-operation (NOP) semantics.
• selection of operative execution semantics may be based on attributes of a memory page in which a particular debug instruction instance resides.
• portions of an address space may be delimited (e.g., using values stored in bounding registers) and addresses of particular debug instruction instances compared against the delimited portions to select appropriate execution semantics.
• both types of evaluations may be used in selecting appropriate execution semantics for a particular debug instruction instance.
• a processor that implements a debug notify halt (dnh) instruction is adapted to provide selective execution semantics for instances of the dnh instruction based on memory address or region in which the instance resides.
• a memory management unit annotates instruction instances (e.g., as they are fetched from memory) in accord with memory page, segment or region match (or mismatch) criteria and execution semantics are selected based on the annotation.
• decode logic is employed to supply signals or opcodes for a NOP-type instruction implemented by the processor in place of those signals or opcodes ordinarily supplied for execution of a debug instruction for which NOP semantics are not selected.
• NOP-type instruction implemented by the processor
• decode logic is employed to supply signals or opcodes for a NOP-type instruction implemented by the processor in place of those signals or opcodes ordinarily supplied for execution of a debug instruction for which NOP semantics are not selected.
• FIG. 1 illustrates a data processing system 10 consistent with some embodiments of the invention.
• data processing system 10 may be implemented on a single integrated circuit or on a plurality of integrated circuits.
• data processing system 10 may be implemented as a system-on-chip.
• data processing system 10 includes processor(s) 12, external debug circuitry 14, I/O module 16, and memory 18.
• processor(s) 12 includes processor(s) 12, external debug circuitry 14, I/O module 16, and memory 18.
• Components of data processing system 10 are interconnected and interoperate using any suitable techniques. For simplicity, we illustrate interconnection amongst major functional blocks via bus 20, although persons of ordinary skill in the art will recognize that any of a variety of interconnection techniques and topologies may be employed without departing from the present invention.
• processor(s) 12 typically include fetch buffers or other facilities for storing instructions to be executed by the processor(s), decoder and sequencing logic, one or more execution units, and register storage, together with suitable data, instruction and control paths.
• units of program code e.g., instructions
• data reside in memory 18, in one or more levels of cache(s) and/or in processor stores (such as a fetch buffer, registers, etc.)
• processor stores such as a fetch buffer, registers, etc.
• any of a variety of memory hierarchies may be employed, including designs that separate or commingle instructions and data in memory or cache.
• Memory 18 may be located on the same integrated circuit as a processor, may be located on a different integrated circuit than processor(s) 12 or may span multiple integrated circuits.
• memory 18 may include storage of any suitable type, such as, for example, read only memory (ROM), random access memory (RAM), non-volatile memory (e.g., Flash), etc.
• External debug circuitry 14 may be contained on the same integrated circuit as a processor, or may be implemented as a separate system independent of any integrated circuits or system-on-chip containing processor(s) 12.
• FIG. 2 is a block diagram of a processor instance corresponding to processor(s) 12 of data processing system 10 (see FIG. 1), now referred to as processor 12.
• Processor 12 includes an instruction decoder 22, execution units 24, instruction fetch unit 26, control circuitry 28, general purpose registers 30, load/store unit 32, bus interface unit (BIU) 34 and internal debug circuitry 40.
• Processor 12 communicates with other components of a data processing system via bus 20 coupled to BIU 34.
• other components include memory (potentially including cache(s)) and I/O components, as previously illustrated with reference to FIG. 1.
• memory management unit (MMU) 36 coordinates address translations (e.g., in accord with an implemented segmentation or paged memory model) and provides a convenient place to implement some of the conditional debug controls described herein. Accordingly, in the description that follows, we illustrate some designs that include an MMU facility. Nonetheless, based on the description herein, persons of ordinary skill in the art will recognize that other components along the instruction path from memory to execution units 24 (e.g., instruction fetch unit 26 and instruction decoder 22) may host analogous conditional debug controls or portions of the particular controls described, particularly in embodiments that may omit an MMU.
• Optional cache 37 which may be provided (e.g., on-chip) together with processor 12 in some embodiments.
• Optional cache 37 is illustrated as an integrated data/instruction cache, although persons of ordinary skill in the art will recognize that separate data and instruction portions may be provided, if desired, and some embodiments may co-locate only a data-portion or only an instruction-portion together with processor 12.
• Internal debug circuitry 40 monitors activity within processor 12 and, in response to detecting one or more predetermined conditions based on stored debug configuration information present within debug registers 42 or elsewhere within processor 12, may generate one or more data breakpoint events, instruction breakpoint events, instruction execution events such as a branch or trap taken event, an instruction completion event or the like.
• Internal debug circuitry 40 may be coupled to external debugging units, such as an IEEE ISTO-5001 compliant NexusTM debugging unit via debug port shown in FIG. 2.
• External debugging units may include all or a portion of external debug circuitry 14 shown in FIG. 1.
• NexusTM is a trademark of Freescale Semiconductor, Inc., Austin, Texas.
• Debug port may be a serial interface, such as JTAG, or may be implemented as a parallel port, a combination of serial and parallel ports, or as an Ethernet port.
• processor 12 may interface internal debug circuitry to other debug circuitry on-chip using an appropriate interconnect or signaling mechanism.
• internal debug circuitry 40 includes debug registers 42 and debug control circuitry 44.
• Debug registers 42 typically include bits grouped in fields for controlling various debug related events, including instruction breakpoints, data breakpoints, watchpoints, and other messaging associated with debugging.
• these debugging resources may be shared between processor 12 and external debug circuitry 14, and, in any case, may be employed to establish predicate states (such as memory page attributes, marked segments or regions, and/or combinations of address-identifiers) that selectively enable (or disable) based on addresses, the conditional debug controls described herein.
• debug registers 42 provide storage for one or more address comparison values, address ranges, and data match values that may be useful for implementing instruction and/or data access breakpoint and watchpoint events, and other debug control criteria. These address and data values, along with various control criteria, are used to determine when processor 12 accesses one or more predetermined instruction addresses or data addresses for the purpose of generating a breakpoint or watchpoint event, which can cause processor 12 to begin exception processing for a debug exception when internal debug mode is active, or cause processor 12 to enter a debug halted mode in which it responds to commands provided by external debug circuitry 14 through the debug port of internal debug unit 40 when external debug mode is active.
• debug registers 42 may include debug control registers suitable for storage of debug configuration information, instruction address compare registers and data address compare registers, as well as debug status registers, debug counters and data value compare registers.
• debug registers 42 may be a visible part of the user's software programming model.
• Debug counters may be configured to count-down when one or more count-enabled events occur. When a count value reaches zero, a debug count event may be signaled and a debug interrupt may be generated, if enabled.
• Data value compare registers may store data values for data comparison purposes, such as in the implementation of conditional breakpoints.
• register resources are managed by software, and no external debug circuitry usage is required.
• Software may configure the registers through data movement using move to and from special purpose register instructions which are software instructions to initialize the individual debug registers for performing software-based debugging activities.
• Enabled debug events trigger software debug interrupts.
• a software interrupt handler may then perform various desired activity which is determined by the software programmer of data processing system 10.
• external debug circuitry 14 may be assigned ownership of shared debug registers of debug registers 42, and when a configured debug event occurs, processor 12 may enter a halted state and wait for a command to be provided by external debug circuitry 14. Software no longer has control of the shared debug resources when external debug mode is enabled.
• debug registers 42 include external debug control registers located within debug registers 42 or elsewhere within processor 12, which may not be part of the user's software programming model. That is, software executing on processor 12 may not have visibility of external debug control registers.
• External debug circuitry 14 may access the shared debug resources and any dedicated external debug resources directly via the debug port (as shown in FIG.
• debug registers 42 and external debug control registers may be mapped as JTAG data registers with register selection encodings contained within one or more fields for the various JTAG instructions, which provide for read and write accesses to the registers by the debugger through JTAG IR and DR operations.
• conditional debug-type instruction for which operation of a given instance thereof may be qualified (using techniques described herein) based on the address at which the instance appears in memory addressable by a processor.
• the examples are the debug notify halt (dnh) instruction and breakpoint instruction codings implemented by processor cores such as e700/e500 and e200 Core families of cores available from Freescale Semiconductor for cost-sensitive, embedded real-time applications such as in the MPC5000 family of automotive microcontrollers (MCUs).
• the dnh instruction provides a bridge between execution of instructions on the core in a non-halted mode and subsequent operations of an external debug facility.
• the dnh instruction allows software to transition the core from a running state to a halted state (if enabled by an external debugger), and to notify the external debugger with both a message and bits coded in the instruction itself.
• the dnh instruction is a conditional debug instruction in that its runtime effect is determined by the state of certain indications that may be set in debug control registers (see e.g., FIG. 2, debug registers 42).
• a DNH_NOP indication is set by either the external debug facility or by software and a DNH_EN indication is cleared, dnh instruction instances are executed as nops. If a DNH_WPT indication is set, a watchpoint is signaled external to the CPU.
• Coarse grain control mechanisms allow the dnh instruction to be treated as a nop, when desirable, instead of halting the processor in a debug state or taking an illegal instruction exception.
• This control allows dnh instructions to remain embedded in the code image of the application after code development, yet remain innocuous by simply acting as nop operations. In this manner, the code image itself need not change, and predictable execution is provided, since branch targets, page boundaries, and other instruction relationships remain unchanged.
• coarse grain control of all (or even of an entire group of) instances of a dnh-type instruction may not provide adequate granularity to allow a dnh instruction instance in stable code to be treated as a nop, while simultaneously allowing another dnh instruction instance to operate as a halt or watchpoint.
• a breakpoint (bkpt) instruction can be employed in some embodiments of the present invention as a debug instruction for which address qualification is provided.
• a breakpoint instruction may not be explicitly defined by the instruction set architecture (ISA), but may be implemented as an illegal instruction opcode, which upon execution, generates an exception or fault that may be dispatched for handling by a debug facility.
• a bkpt instruction opcode (or some similar instruction coding) may be defined and provided.
• a breakpoint instruction as if it were a defined instruction set coding (e.g., a bkpt instruction).
• coarse grain control mechanisms allow the bkpt instruction to be treated as a nop, when desirable, instead of halting the processor in a debug state.
• This control allows bkpt instructions to remain embedded in the code image of the application after code development, yet remain innocuous by simply acting as nop operations.
• predictable execution may be provided since branch targets, page boundaries, and other instruction relationships remain unchanged.
• coarse grain control of all (or a group of) instances of a bkpt instruction may not provide adequate granularity to allow a bkpt instruction instance in stable code to be treated as a nop, while simultaneously allowing another bkpt instruction instance to operate as a breakpoint.
• FIG. 3 is a flow chart that illustrates setup and operation of an address-qualified conditional debug technique in accordance with one or more embodiments of the present invention.
• a setup 301 sequence is illustrated for address- qualified conditional debug.
• individual code blocks are considered (311 ) for disabling (or enabling) of debug-type instruction instances such as dnh, dnh2, bkpt, etc. appearing therein.
• code blocks can be of any suitable granularity and may correspond to functions, procedures, modules, sub-sequences of instructions, etc.
• setup sequence 301 stores corresponding page frame identifiers, segment identifiers, region identifiers (e.g., as base address/mask pairs) and/or any other address- based qualifiers for varying operation or behavior of individual debug instruction instances.
• each instruction (or group of instructions) is fetched (321), typically from memory or cache in preparation for decode and eventual execution of the instruction (or instructions) in accord with program sequencing.
• the particular memory address at which the particular instance is found in memory is checked (322) against address-based qualifiers in store 310. If a page, segment or range of memory addresses indicated in store 310 matches (323) the particular memory address of the debug-type instruction instance, then debug execution semantics are suppressed (324) for that instruction instance.
• a nop instruction opcode is substituted for the matching instruction instance by an instruction fetch or decode unit (see e.g., FIG. 2, instruction fetch unit 26, instruction decoder 22) although other suppression mechanisms may be employed, if desired.
• the corresponding instruction (with debug execution semantics are suppressed) is executed (325).
• FIG. 4 illustrates operation of one or more embodiments of the present invention in which memory paging system attributes are used to facilitate conditional debug operation based on the memory address of a particular debug instruction instance.
• address-based qualifiers are represented in a store based on indications supplied from debug hardware and/or software. More specifically, in the illustration of FIG. 4, debug- related page frame attributes are supplied (405) and encoded in one or more paged memory management stores (e.g., page tables, translation lookaside buffer (TLB) entries, etc.) illustrated collectively as page translations 410.
• paged memory management stores e.g., page tables, translation lookaside buffer (TLB) entries, etc.
• Persons of ordinary skill in the art will appreciate any of a variety of suitable implementations for MMU 450 and, more generally, for a paged memory management system. For clarity, and without limitation on the range of suitable implementations, we illustrate only those aspects of a simplified paging system pertinent to an illustration of our techniques.
• MMU 450 provides translations of virtual addresses (e.g., instruction fetch address 427) to physical addresses in addressable storage (e.g., physical address 499 corresponding to location 471 in memory and/or cache 420).
• addressable storage e.g., physical address 499 corresponding to location 471 in memory and/or cache 420.
• addressable storage is viewed at page frame level of granularity, such that a page frame corresponding to virtual address 498 is mapped using page translations 410 to a corresponding page (e.g., physical page 458) in physical address space.
• page attributes 411 are coded in association with mappings 412.
• write- through (W), caching-inhibited (I), memory-coherency-required (M), guarded (G) and endianness (E) attributes may be specified as constituent indications within page attributes 411 that are associated with individual translations.
• W write- through
• I caching-inhibited
• M memory-coherency-required
• G guarded
• E endianness
• D debug-disable
• page attributes 411 may be provided (in some implementations) using an attribute specifically defined in the paging system implementation or (in other implementations) using an otherwise unallocated user-definable page attribute.
• the particular debug-disable (D) indication 413 retrieved from page translations 410 in connection with fetch of a particular debug-type instruction instance stored at addressed location 471 is used to determine execution semantics for the fetched instruction instance.
• virtual-to-physical page translations 418 and 419 correspond to respective physical pages 458 and 459 in physical address space. Accordingly, based on corresponding debug-disable (D) indications set (405) in page translations 410, debug-type instruction instances fetched from physical addresses within pages 458 and 459 are executed with nop semantics.
• debug-disable (D) indication 413 indicates that a corresponding debug-type instruction should be executed with nop semantics.
• other coding senses may be employed.
• nop semantics may be provided in any of a variety of ways.
• MMU 450 may annotate (452) the fetched debug-type instruction instance (or the cache line or other fetch unit in which the debug-type instruction instance appears) to mark it for later substitution (or overloading) at a convenient point along an instruction path.
• the opcode of a debug-type instruction instance so annotated may be replaced (or overloaded) with a nop instruction opcode in fetch unit 426 (e.g., at 453) or in instruction decoder 422 (e.g., at 454).
• MMU 450 could itself substitute or overload the nop instruction opcode, although this presumes a level of instruction set knowledge generally not provided in a memory management unit.
• FIG. 5 illustrates operation of one or more embodiments of the present invention in which a segment or region marking technique is used to facilitate conditional debug operation based on the memory address of a particular debug instruction instance.
• address-based qualifiers are represented in storage based on indications supplied (505) from debug hardware and/or software. More specifically, in the illustration of FIG. 5, address base/mask pairs (511 ... 512) are used to mark corresponding segments or regions (561 , 562) of addressable storage represented in memory and/or cache 518. Instruction fetch address 527 is compared against address base/mask pairs using a collection of comparators (516 ... 517) and based on a match, an indication 513 is supplied that results in annotation (552) and/or substitution/overloading (at a convenient point along an instruction path) of the corresponding debug-type instruction instance(s).
• debug-type execution semantics of the instruction instance retrieved from location 571 in addressable memory are suppressed based on correspondence of the instruction fetch address 527 with one or more of the address base/mask pairs (511 ... 512).
• address base/mask pair indicates that a corresponding debug-type instruction is to be executed with nop semantics, although other coding senses may be employed.
• convenient points along the instruction path include a fetch unit or instruction decoder.
• FIG. 6 illustrates operation of one or more embodiments of the present invention in which a composition of memory paging system and marking techniques are employed to facilitate conditional debug operation based on address.
• address-based qualifiers are represented in storage based on indications supplied (605) from debug hardware and/or software.
• page frame attributes are encoded in one or more paged memory management stores (e.g., page tables, translation lookaside buffer (TLB) entries, etc.) illustrated collectively as page translations 610.
• page translations 610 e.g., page tables, translation lookaside buffer (TLB) entries, etc.
• entry 618 thereof (which corresponds to instruction fetch address 627) provides the translation that identifies page 658 as the page in addressable memory in which location 671 (and the fetched debug instruction) resides.
• address base/mask pairs (e.g., address base/mask pair 611 ) are used to mark corresponding region 661 within page 658 and to further delimit the portion of addressable storage for which debug-type execution semantics are to be suppressed.
• FIG. 6 illustrates an AND composition (see logic 699) of (i) results of a comparison (616) between instruction fetch address 627 and contents of address base/mask pair 611 and (ii) the debug-disable (D) indication 613 retrieved from page translations 610 in connection with the corresponding fetch of a particular debug instruction instance stored at addressed location 671.
• the illustrated configuration provides a mechanism for narrowing the set of memory locations for which debug execution semantics are to be suppressed to a subset of those appearing in pages having debug- disable (D) indications.
• compositions of page and region indicators are possible and envisioned.
• a NOT-AND composition can be used to exclude addressable locations that match address base/mask pair 611 from those that otherwise fall within the coverage of a page for which a debug-disable (D) indication has been coded.
• an OR composition can be used to include addressable locations that either match address base/mask pair 611 or fall within the coverage of a page for which a debug-disable (D) indication has been coded.
• annotation e.g., 652
• substitution/overloading at a convenient point along an instruction path
• debug-type execution semantics of the instruction instance retrieved from location 671 in addressable memory are suppressed based on correspondence of the instruction fetch address 627 with both (i) an entry (618) of translations 610 in which a set debug-disable (D) indication 613 appears and (ii) contents of address base/mask pair (611 ).
• the debug-disable (D) indication and address base/mask pair cover debug-type instruction instances that are to be executed with nop semantics, although other coding senses may be employed.
• convenient points along the instruction path for substitution/overloading with a nop opcode include a fetch unit or instruction decoder.
• Process identifiers PID or address space identifiers (ASID) are often employed in processor implementations and can be used to provide each execution process with its own unique virtual address space. Accordingly, in some embodiments of the present invention, all or a portion of such a PID or ASID field value may be used in a comparison that establishes a set of addresses for which debug-type or nop execution semantics is desired. For example, such a use of PID or ASID field values may include (or exclude) those addresses that fall within a virtual address space associated with a particular process or thread in (or from) a set for which particular execution semantics are specified.
• virtualization techniques may be employed. Virtualization often establishes logical partitions which operate independent of each other in distinct address spaces. For example, some multithreaded processor implementations, each virtual processor may be assigned to a logical partition. Similarly, in a multi-processor system, each physical processor may be assigned to a logical partition. In general, logical partition assignments may be made by assigning partition ID (LPID) values. A partition ID value forms an extension of the virtual address and can be used to match against the logical partition value for each TLB entry during address translation. Accordingly, in some embodiment of the present invention, all or a portion of a LPID field value may be included as an input to range comparison logic to allow for further specification of one or more virtual address spaces or partitions.
• LPID partition ID
• address space comparisons may be employed separately or in combination with lookup or comparisons illustrated or described with reference to FIGS. 3-6.
• similar functionality could be provided by marking appropriate page attributes on those pages that correspond to an address space; however, marking/unmarking the pages can be time consuming or inconvenient. Therefore, in some embodiments, the preceding alternatives may be attractive.
• a class of debug instructions allow for grouping of debug instructions into independent groups, where each group has independent control over the action or actions to be taken upon execution, thereby providing additional debug flexibility. These groups may be independently controlled, and the resulting actions may be dynamically modified by either a hardware or software debugger. Techniques of the present invention may also be employed to provide address-qualification for group-delimited debug instructions.
• Embodiments of the present invention may be implemented using any of a variety of different information processing systems. Accordingly, while FIGS. 1 and 2, together with their accompanying description relate to exemplary data processing system and processor architectures, these exemplary architectures are merely illustrative. Of course, architectural descriptions herein have been simplified for purposes of discussion and those skilled in the art will recognize that illustrated boundaries between logic blocks or components are merely illustrative and that alternative embodiments may merge logic blocks or circuit elements and/or impose an alternate decomposition of functionality upon various logic blocks or circuit elements.
• Articles, system and apparati that implement the present invention are, for the most part, composed of electronic components, circuits and/or code (e.g., software, firmware and/or microcode) known to those skilled in the art and functionally described herein. Accordingly, component, circuit and code details are explained at a level of detail necessary for clarity, for concreteness and to facilitate an understanding and appreciation of the underlying concepts of the present invention. In some cases, a generalized description of features, structures, components or implementation techniques known in the art is used so as to avoid obfuscation or distraction from the teachings of the present invention.
• code e.g., software, firmware and/or microcode
• program and/or “program code” are used herein to describe a sequence or set of instructions designed for execution on a computer system. As such, such terms may include or encompass subroutines, functions, procedures, object methods, implementations of software methods, interfaces or objects, executable applications, applets, servlets, source, object or intermediate code, shared and/or dynamically loaded/linked libraries and/or other sequences or groups of instructions designed for execution on a computer system.
• All or some of the program code described herein, as well as any software implemented functionality of information processing systems described herein, may be accessed or received by elements of an information processing system, for example, from computer readable media or via other systems.
• computer readable media may be permanently, removably or remotely coupled to an information processing system.
• Computer readable media may include, for example and without limitation, any number of the following: magnetic storage media including disk and tape storage media; optical storage media such as compact disk media (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media; nonvolatile memory storage media including semiconductor-based memory units such as FLASH memory, EEPROM, EPROM, ROM; ferromagnetic digital memories; MRAM; volatile storage media including registers, buffers or caches, main memory, RAM, etc.; and media incident to data transmission including transmissions via computer networks, point-to-point telecommunication equipment, and carrier waves or signals, just to name a few.
• magnetic storage media including disk and tape storage media
• optical storage media such as compact disk media (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media
• nonvolatile memory storage media including semiconductor-based memory units such as FLASH memory, EEPROM, EPROM, ROM
• ferromagnetic digital memories such as FLASH memory, EEPROM, EPROM,

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Debugging And Monitoring (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (1)

Family

ID=41064277

Family Applications (1)

Country Status (5)

Families Citing this family (25)

Citations (3)

Family Cites Families (16)

• 2008
  • 2008-03-17 US US12/049,984 patent/US8261047B2/en active Active
• 2009
  • 2009-02-02 WO PCT/US2009/032793 patent/WO2009117178A1/en not_active Ceased
  • 2009-02-02 JP JP2011500821A patent/JP5335887B2/ja not_active Expired - Fee Related
  • 2009-02-02 CN CN200980106158.4A patent/CN101946232B/zh active Active
  • 2009-02-13 TW TW098104740A patent/TWI464576B/zh not_active IP Right Cessation

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events