Method and system for dynamic address translation

Methods, computer-readable media, and systems for dynamic address translation between a source memory space and a target memory space are provided. In some illustrative embodiments, a method is provided for copying data from a source memory space to a target memory space. The method includes extracting a plurality of source data units, each of size s bits, from the source memory space and translating the plurality of source data units into a plurality of target data units. A target data unit is an addressable unit of the target memory space and each target data unit is of size t bits. The method further includes copying the plurality of target data units into a plurality of contiguous transfer units, each of size b bits, in the target memory space.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of European Patent Application No. 04291918.3, filed Jul. 27, 2004, incorporated by reference herein as if reproduced in full below.

BACKGROUND OF THE INVENTION

Mobile electronic devices such as personal digital assistants (PDAs) and digital cellular telephones are increasingly including applications written in the Java™ programming language. Many of the processors used in these mobile devices have fixed address modes using byte and/or word addressing. However, the Java™ applications executing on such processors may need to access data that does not match the size of a Java object field, or a Java array element. Such data may be stored in memory that is allocated to components comprised in the electronic device, e.g., pixels stored in memory by a display component.

Generally, a Java application uses a Java data structure to provide data to, or receive data from a corresponding data structure in the memory allocated to the component. This corresponding data structure may contain fields that do not match the size of fields in the Java data structure. A translation between the application data structure and the component memory data structure is performed, either in software or by special hardware. Performing the translation from a Java data structure to the data structure in the component memory in software can be computationally intensive. Enhancements to improve the efficiency of performing the translations in Java applications are desirable. Such enhancements may also be desirable in other high level languages such as C and C++.

SUMMARY

Accordingly, there are disclosed herein methods and systems dynamic address translation from a data representation in a source memory space to a data representation in a target memory space. Some embodiments provide a method copying data from a source memory space to a target memory space. The method comprises extracting a plurality of source data units from the source memory space, wherein each source data unit is of size s bits and translating the plurality of source data units into a plurality of target data units, wherein a target data unit is an addressable unit of the target memory space and each target data unit is of size t bits. The method further comprises copying the plurality of target data units into a plurality of contiguous transfer units in the target memory space, wherein each transfer unit is of size b bits.

Some embodiments provide a computer-readable medium that stores a software program that when executed by a processor performs the above-described method. Other embodiments provide a system that comprises a processor, a memory coupled to the processor, and instructions stored in the memory, that when executed by the processor, perform the above-described method.

NOTATION AND NOMENCLATURE

Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, semiconductor companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . ”. Also, the term “couple” or “couples” is intended to mean either an indirect or direct connection. Thus, if a first device couples to a second device, that connection may be through a direct connection, or through an indirect connection via other devices and connections.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more detailed description of the preferred embodiments of the present invention, reference will now be made to the accompanying drawings, wherein:

FIG. 1 shows a diagram of a system in accordance with embodiments of the invention;

FIG. 2 further illustrates the system of FIG. 1;

FIG. 3-8 illustrate the operation of a dynamic memory translation method in accordance with embodiments of the invention; and

FIG. 9 depicts an illustrative embodiment of the system described herein.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, unless otherwise specified. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiments is meant only to be exemplary of those embodiments, and not intended to intimate that the scope of the disclosure, is limited to those embodiments.

The subject matter disclosed herein is directed to a software solution that dynamically translates n-bit addressable data in a logical memory space to an m-bit addressable representation in a physical memory space and vice versa. When data is transferred from the logical memory space to the physical memory representation, the data is translated by a software translation algorithm to an addressable format of the physical memory (i.e., from an n-bit based addressable logical memory to an m-bit based addressable physical memory). When data is transferred from the physical memory representation to the logical memory space the data is translated by a software translation algorithm to an addressable format of the logical memory (i.e., from an m-bit based addressable physical memory to an n-bit based addressable logical memory).

Merely by way of example, some of the embodiments described herein are directed to a Java application that accesses the physical memory allocated to a display device. As one of ordinary skill in the art will appreciate, the principles disclosed herein have applicability apart from the Java language and display devices.

FIG. 1 shows a system 100 in accordance with embodiments of the invention. As shown, the system may comprise at least two processors 102 and 104. Processor 102 may be referred to for purposes of this disclosure as a Java Stack Machine (“JSM”) and processor 104 may be referred to as a Main Processor Unit (“MPU”). System 100 may also comprise memory 106, and a display 114 coupled to both the JSM 102 and MPU 104 via one or more busses 122. At least a portion of the memory 106 may be shared by both processors, and if desired, other portions of the memory 106 may be designated as private to one processor or the other. Other components (not specifically shown) may be included as desired for various applications.

System 100 also comprises a Java Virtual Machine (“JVM”) 108, compiler 110, Java APIs 120, Java native APIs 124, and Java applications 118. The JVM may comprise a class loader, bytecode verifier, garbage collector, and a bytecode interpreter loop to interpret the bytecodes that are not executed on the JSM processor 102. The Java applications 118 are written in Java language source code and may comprise references to one or more classes of the Java Application Program Interfaces (“APIs”) 120 and the Java native APIs 124. The Java native APIs 124 comprises interfaces to classes and methods implemented in other languages such as C++, C or assembler.

The Java source code is converted or compiled to a series of bytecodes 112, with each individual one of the bytecodes referred to as an “opcode.” Bytecodes 112 are provided to the JVM 108, possibly compiled by compiler 110, and provided to the JSM 102 and/or MPU 104 for execution. In some embodiments, the JSM 102 may execute at least some Java bytecodes directly. When appropriate, however, the JVM 108 may also request the MPU 104 to execute one or more Java bytecodes not executed or executable by the JSM 102. In addition to executing compiled Java bytecodes, the MPU 104 also may execute non-Java instructions.

The MPU 104 may also host an operating system (“O/S”) (not specifically shown) which performs various functions such as system memory management, the system task management that schedules the software aspects of the JVM 108 and most or all other native tasks running on the system, and management of the display 114. Java code may be used to perform any one of a variety of applications such as multimedia, games or web based applications in the system 100, while non-Java code, which may comprise the O/S and other native applications, may still run on the system on the MPU 104.

FIG. 2 shows various components related to the management of the display 114. As shown, the Java application 150 comprises an application data structure 152. The application data structure 152 is presented as an array for purposes of explanation but may be any suitable type of data structure. The application array 152 links to translation software 154 which, in turn, links to display memory 156. Display memory 156 may comprise a portion of memory 106 allocated for use by the display 114. Information to be shown on the display 114 is stored in the display memory 156. A display interface 160 extracts display data from the display memory 156 and provides an appropriate electrical interface to cause the desired information to be shown correctly on the display 114.

As noted above, the Java application 150 comprises an application array 152 usable for managing the display 114. The application array 152 is a Java array and thus comports with the applicable requirements of the Java programming language. For example, the array 152 may be an n-bit addressable data structure. In Java, n is typically 32 bits meaning that array 152 is addressed in units of 32-bit (four byte) increments. The display memory 156, however, may be formatted differently than the Java array 152. For example, while the application array 152 may be an n-bit addressable data structure, the display memory 156 may comprise an m-bit addressable data structure where m is different than n. In some embodiments, for example, m could be 8, but m could also be any number of bits appropriate to the display color definition.

The Java application 150 accesses the display memory 156 through application array 152. The Java application 150 can cause text and/or graphics data (“display data”) to be shown on display 114 by writing such display data to the application array 152. As noted above, the application array 152 is n-bit addressable and the display memory is m-bit addressable, where n may be different (e.g., greater) than m. Thus, the application array is formatted differently than the display memory. With n being different than m, the display data from the application array 152 cannot be copied directly into the display memory 156 without being re-formatted, nor can the data be copied directly from the display memory 156 to the application array 152 without re-formatting. When the data within the application array 152 is written by the application software, the data is automatically reformatted by the translation software 154 into a format compatible with the display memory 156. When the data within the display memory 156 is placed in the application array 152, the data is automatically reformatted by the translation software 154 into a format compatible with the application array 152.

FIG. 3 presents an example further illustrating the functionality of the translation software 154. Logical address space 300 associated with application array 152 may comprise display data from application 150 to be written to a physical address space 302 that is stored in display memory 156. In this example, the size of an addressable data unit in the logical address space 300 (i.e., logical data unit) is 32 bits and the size of an addressable data unit in the physical address space 302 (i.e., physical data unit) is 8 bits.

The translation software 154 maps the high level representation (32-bit-based memory block) in the logical address space 300 on to a low-level representation (8-bit-based memory block) in the physical address space 302 and vice versa. The number of meaningful bits in an addressable data unit in the logical address space 300 may not exceed the size of a physical data unit. For example, if the physical address space 302 is 8-bits wide, then the logical address space 300 associated with the application array 152 stores meaningful data in chunks of eight bits.

In the example of FIG. 3, meaningful data chunks are shown at addresses 0xA003, 0xA007, 0XA00B, and so on, while the remaining portions of the address space (e.g., 0xA000-0xA003, 0xA004-0xA006, and so on) are set to a predetermined value of 0. When writing to the physical address space 302, the translation software 154 copies only the meaningful bits of each addressable data unit in the logical address space 300 to the physical address space 302. The meaningful data chunks at addresses 0xA003, 0xA007, 0xA00B, and so on of the logical address space 300 are copied to addresses 0x0C00, 0x0C01, 0x0C02, and so on by translation software 154. When reading from the physical address space 300, the translation software 154 copies the data in each of the locations at addresses 0x0C00-0x0C04 to the least significant bits of addresses 0XA000, 0xA004, 0xA008, and so on of the logical address space 300. The translation software 154 fills the remainder of each addressable data unit with zeros if the data is unsigned, or with a sign extension value if the data is signed.

In general, embodiments of the translation software 154 translate the data from an n-bit based addressable contiguous source memory space (e.g., logical address space 300) to an m-bit based addressable target memory (e.g., physical address space 302). The size s of an addressable data unit in the source memory space (i.e., a source data unit) is
s=n*u bits where u>0.
u is the number of addressable elements of the source memory space that are included in a source data unit. Note that if u=1, then s=n, which is the size of the smallest data unit that can be addressed in the source memory space. The size t of an addressable data unit in the target memory space (i.e., a target data unit) is
t=m* v where v>0.
v is the number of addressable elements of the target memory space that are included in a target data unit. Note that if v=1, then t=m, which is the size of the smallest data unit that can be addressed in the target memory space. The translation software 154 copies data from the source memory space to the target memory space, taking into account the respective addressing modes. That is, each source data unit of size s=n*u bits is copied into the target memory space as a target data unit of size t=m*v.

In some embodiments, the translation software 154 receives as inputs the address of the source memory space, the address of the target memory space, the size (in bits) of a source data unit, the size (in bits) of a target data unit, and the number of source data units in the source memory space to be copied to the target memory space. For each of the source data units, the translation software 154 builds a target data unit of t bits representing the source data unit of s bits, and then copies the series of t bits into the target memory space. FIGS. 4, 5, and 6 illustrate building target data units when s=t, s>t, and s<t.

As the example in FIG. 4 shows, when s=t, embodiments of the translation software 154 copy all the bits in each source data unit 400 to a target data unit 402. No extra computation is required to form a target data unit. As the example in FIG. 5 shows, when s>t, the translation software 154 copies the least significant t bits 504 of each source data unit 500 to a target data unit 502. In this example, s=8 and t=4. As the example in FIG. 6 shows, when s<t, the translation software 154 copies the s bits of the source data unit 600 into the s least significant bits 604 of the target data unit 602. The translation software 154 also fills the most significant t-s bits 606 of the target data unit 602 with zeroes. In this example, s=8 and t=16.

Stated more formally, the translation software 154 iterates through a set S of source data units that are to be copied to the target memory space
S={s1, s2, s3, . . . , sp},
where each si, iε[1, p], denotes a source data unit of size s bits to build a set T of target data units,
T={t1, t2, t3, . . . , tp},
where each ti denotes a target data unit of size t bits such that ti contains the bits of the corresponding source data unit si. In some embodiments, a build process applied by the translation software 154 to each si of the set S to create each ti of the set T comprises: 1) if s≦t, a target data unit ti is formed by the least significant t bits extracted from the corresponding source data unit si; and 2). if s<t, a target data unit ti is formed by s bits of the corresponding source data unit si and t-s bits of zero value or sign extension, where the s bits from the source data unit si constitute the least significant bits of the target data unit ti, and the t-s zero-value or sign extension bits constitute the most significant bits of the target data unit ti. The t-s bits are zero value if the data is unsigned, and sign extension if the data is signed.

The translation software 154 copies the t bits of each ti to the target memory space in one or more transfer units where each transfer unit is b bits in size. The copy process used by the translation software 154 is configured to handle both cases where b=t and b≠t. The copy process copies the bit values in the set T to fill a set of transfer units B in the target memory,
B={bi, b2, b3, . . . , bq},
where q is the number of transfer units needed to contain the bits comprising set T. The value of q may be determined as follows:
If rem(t*p, b)=0 then q=div(t*p, b) else q=div(t*p, b)+1
where p is the number of target data units ti in the set T, rem(a, b) is the operation that computes the remainder of dividing a by b and div(a, b) is the operation that divides a by b.

FIGS. 7 and 8 show examples of the operation of a copy process used in embodiments of the translation software 154. FIG. 7 shows a simple example where t=4 and b=8. In cases such as this, where b is evenly divisible by t, each target data unit ti may be entirely copied into a portion of a transfer unit bi of the target memory space. In the example of FIG. 7, the copy process copies t1 into the most significant bits of b1, t2 into the least significant bits of b1, t3 into the most significant bits of b2, t4 into the least significant bits of b2, and so on.

FIG. 8 shows an example where the ti do not fit evenly in the transfer units of the target memory space. In this example, t=6 and b=8. The copy process first copies the t bits of target data unit t1 into transfer unit b1 of the target memory space. After copying t1, b−t=2 bits in the current transfer unit b1 remain empty. The copy process fills these two bits with bit values from the next target data unit t2. The copy process extracts the two most significant bits from t2 to fill these two empty bits of transfer unit b1. The copy process then places remaining t−(b−t)=4 bits from t2 in the most significant four bits of the next transfer unit b2. The copy process repeats this procedure to copy all of the of target data units ti in the set T to transfer units in B.

Table 1 contains pseudo code illustrating the operation of at least one embodiment of a copy process used in the translation software 154. Note that this pseudo code is intended to illustrate the logic of the copy process and does not contain the details of performing the bit operations to place the bits of a target data unit in a transfer unit of the target memory space. In this pseudo code, the number of bits from the current element ti to be copied is denoted by nbBitsToBeCopied, the number of empty bits in the current transfer unit bj to be filled is denoted by nbEmptyBits, the number of bits of the current element ti that cannot be copied in the current transfer unit bj is denoted by nbBitsCannotBeCopied, the current target data unit ti from T to be copied is denoted by currentDataUnit, and the current transfer unit bj in B to be filled is denoted by currentTransferUnit. Initially, the currentDataUnit is t1, nbBitsToBeCopied is t, currentTransferUnit is b1, and nbEmptyBits=b.

The operation of the pseudo code is explained in the context of the example of FIG. 8. Initially, the currentDataUnit is t1, nbBitsToBeCopied is t=6, currentTransferUnit is b1, and nbEmptyBits is b=8. The pseudo code begins with a determination of whether there is sufficient space in the current transfer unit b1 to hold the number of bits to be copied (line 1). Since nbBitsToBeCopied=6 and nbEmptyBits=8, this determination is true and lines 3-18 are executed. All six bits of t1 are copied to b1 (line 4), nbEmptyBits is set to 2, nbBitsToBeCopied is set to t=6 for the next iteration (line 6) and currentDataUnit is set to t2 (line 12) since all bits of t1 have been copied. A check is made to determine whether b1 is full (line 15). Because nbEmptyBits is currently two, this test fails.

On the next iteration, a check is again made to determine whether there is sufficient space in the current transfer unit b1 to hold the number of bits to be copied (line 1). Since nbBitsToBeCopied=6 and nbEmptyBits=2, this determination is false and lines 22-29 are executed. nbBitsCannotBeCopied is set to nbBitsToBeCopied−nbEmptyBits=4 (line 22). Then, the most significant 2 bits of t2 are copied into the least significant 2 bits of b1 (line 23). nbEmptyBits is set to b for the next iteration since b1 is full and a new transfer unit is filled beginning with the next iteration (line 24) and nbBitsToBeCopied is set to nbBitsCannotBeCopied=4, the number of bits remaining to be copied in t2. Because all of the bits in b1 are full, cuffentTransferUnit is set to b2.

On the subsequent iteration, the check is made to determine whether there is sufficient space in the current transfer unit b2 to hold the number of bits to be copied (line 1). Since nbBitsToBeCopied=4 and nbEmptyBits=8, this determination is true and lines 3-18 are executed. The least significant four bits of t2 are copied to the most significant four bits of b2 (line 4), nbEmptyBits is set to 4 (line 5), and nbBitsToBeCopied is set to t (line 6) and currentDataUnit is set to t3 for the next iteration. This iterative process is repeated until all the bits of the tI are copied to transfer units in the target memory space.

TABLE 1 1 if (nbBitsToBeCopied <= nbEmptyBits) then 2 { 3  nbBitsCannotBeCopied = 0; // because all bits of ti are copied 4  copy in currentTransferUnit nbBitsToBeCopied from  currentDataUnit; 5  nbEmptyBits = nbEmptyBits − nbBitsToBeCopied; 6  nbBitsToBeCopied = t; // because all bits of ti are copied, the 7 // empty bits of the current transfer unit, 8 // if there are any, will be set by 9 // values from the next element ti+1 10 11  //get from T the next element to be copied in the next iteration 12  currentDataUnit = ti+1; 13 14  //update the current transfer unit if needed 15  if (nbEmptyBits = 0) then // if all bits of the current transfer unit  are set 16  { 17   currentTransferUnit = bj+1; // then get the next transfer unit 18  } 19 } 20 else 21 { 22  nbBitsCannotBeCopied = nbBitsToBeCopied − nbEmptyBits; 23  copy in currentTransferUnit nbEmptyBits from currentDataUnit; 24  nbEmptyBits = b;     // because all bits of bj  are full 25  nbBitsToBeCopied = nbBitsCannotBeCopied; 26  // the remaining bits from ti to be copied in the next transfer  unit bj+1 27 28  // all bits of the current transfer unit are set; get the next transfer  unit 29  currentTransferUnit = bj+1; 30 }

Table 2 contains a C language source code embodiment of a method that may be used in embodiments of the translation software 154. One of ordinary skill will appreciate that this code example is presented by way of example only and other implementations are possible and fall within the scope of this disclosure.

The C source code of Table 3 contains an example implementation of a function translate that copies meaningful data bits from a source address space to a target address space. This example implementation uses a byte as a transfer unit, so the size of the transfer unit is 8 bits. The function has five parameters: 1) a pointer to the source address space containing the data to be translated, sourcespace; 2) a pointer to the beginning of the target address space, targetspace; 3) the number of bits in a source data unit, sourceUnitSize; 4) the number of bits in a target data unit, targetUnitSize; and 5) the number of source data units to be copied to the target memory space, nbElem. The function also uses several variables during the translation process. Table 2 contains the definitions of these variables.

TABLE 2 Variable Name Definition vUnit The bits from a source data unit to be copied into the target address space. The number of bits in vUnit = the size of a target data unit. transferUnitSize The number of bits in a transfer unit of the target address space CurrentTransferUnit Holds the transfer unit of data currently being constructed isTruncated A flag indicating whether the bits remaining in vUnit will fit in a transfer unit or not. This flag is initially set to false. nbEmptyBits The number of empty bits to be filled in CurrentTransferUnit. Initially set to transferUnitSize nbBitsToBeCopied The number of bits of the data to be copied into CurrentTransferUnit; initially set to targetUnitSize nbBitsCannotBeCopied The number of bits that cannot be copied into CurrentTransferUnit; nbUnits Holds a count of the number of source data units that have been moved from the source address space to the target address space nbOfTransferUnits The number of transfer units to be filled in the target address space index Holds an index of the current source data unit in the source address space ptr A pointer to the transfer unit in the target address space to be filled

The translate function begins by initializing variables and data structures used during the translation process. The number of transfer units to be filled in the target address space, nbOfTransferUnits, is determined using the values of the parameters nbElem and targetUnitSize (lines 20-32). For purposes of this example, the size of a transfer unit in the target address space is assumed to be eight bits (line1). The function also initializes several variables to be used during the compression process (lines 71-87) and initializes a mask table, mask, with a number of entries equal to targetUnitSize (lines 57-68). The entries in this mask table are used to extract the meaningful data bits from a source data unit. The number of entries in the mask table corresponds to the number of bits in a target data unit (i.e., targetUnitSize). For example, if the size of target data unit is four bits, then mask[0]=1, mask[1]=3, mask[2]=7, and mask[3]=15. mask[<number of bits to be extracted>1] is used to extract the <number of bits to be extracted> least significant meaningful data bits from a source data unit. That is, to extract the three least significant bits, mask[3-1] is used.

The translation process begins by determining whether all of the transfer units in the target address space have been filled (line 91). If the target address space is full, the translate function terminates, returning the number of transfer units filled (line1 56). If the target address space is not full, the number of empty bits in the current transfer unit, i.e., nbEmptyBits, is initialized to be the number of bits in a transfer unit of the target address space and a variable to hold the data bits to be written to the next transfer unit location in the target address space, i.e., CurrentTransferUnit, is initialized to 0 (lines 93-97).

A check is then made to determine if there are still some empty bits to be filled in the current transfer unit location of the target address space (line 100). If there are not, CurrentTransferUnit is written to the target address space (line 152), the count of the number of transfer units copied, nbUnits, is incremented (line 153), and processing resumes with the determination of whether all of the transfer units have been filled (line 91). If there are empty bits to be filled, then a check is made to determine whether the current source data unit has been completely copied (line 102). This determination is made by checking the value of a truncation flag, isTruncated. If the current source data unit has been copied, the relevant bits of the next source data unit are extracted from the next source data unit in the source address space and placed in vUnit (line 109). Note that an entry of the mask table corresponding to a mask value that will extract a number of bits equal to targetUnitSize is used. If the size of a source data unit is less than the size of a target data unit, the targetUnitSize-sourceUnitSize most significant bits of vUnit are set to zero. Otherwise, the process continues with the previously extracted relevant bits of the current source data unit.

Next, the number of bits of the source data unit that cannot be copied into the current transfer unit, nbBitsCannotBeCopied, is determined (lines 112-113). If the number of bits that cannot be written is zero (line 115), then the remaining bits of the source data unit will fit into the current transfer unit. The truncation flag is set to indicate that all bits of the source data unit have been copied (line 119) and the count of the number of empty bits left in the current transfer unit, nbEmptyBits, is reduced by the number of bits to be copied into the current transfer unit (line 122). The remaining number of bits of the source data unit are then copied from vUnit to CurrentTransferUnit using the appropriate mask from the mask table (lines 124-126). This copy operation will shift the bits left as needed to place them in the appropriate position of CurrentTransferUnit. The number of bits to be placed in the next iteration, nbBitsToBeCopied, is set to be the number of bits in a target data unit (line 129), and the source address space index is incremented (line 132). Processing then continues with the check to determine if there are empty bits in the current transfer unit (line 100).

If the number of bits that cannot be copied is not zero (line 134), then there are not enough empty bits in the current transfer unit to hold the data bits remaining the source data unit. The truncation flag is set to indicate that all bits of the source data unit have not been copied (line 138), and the count of the number of empty bits left in the current transfer unit, nbEmptyBits, is set to zero since the current transfer unit will be full after the copy operation (line 141). The number of bits of the source data unit that will fit into the current transfer unit are then copied from vUnit to CurrentTransferUnit using the appropriate mask from the mask table (lines 144-145). This copy operation will shift the bits right as needed to place them in the appropriate position of CurrentTransferUnit. The number of bits to be placed in the next iteration, nbBitsToBeCopied, is set to be the number of bits that cannot be copied (line 149), and processing continues with the check to determine if there are empty bits in the current transfer unit (line 100).

TABLE 3 1 int transferUnitSize = 8; /* # bits in a byte */ 2 3 /* 4  * fills the target space from data coming from the source space 5  * @param sourceSpace: pointer to the source memory space 6  * @param targetSpace : pointer to the target memory space 7  * @param sourceUnitSize: # of bits of in a source data unit 8  * @param targetUnitSize: # of bits in a target data unit 9  * @param nbElem: # of elements in the source space to be copied 10  * @return # of generated transfer units in the target space 11  */ 12 int translate ( unsigned short* sourceSpace, 13      char** targetSpace, 14      int sourceUnitSize, 15      int targetUnitSize, 16      int nbElem) 17 { 18  /* useful data deduced from parameters */ 19 20  /* # of bits to be copied in the target space */ 21  int nbOfBits = nbElem * targetUnitSize; 22 23  /* 24  Compute the # of transfer units to be filled in the target space by dividing the # 25  of bits in the target space by the size of one transfer unit. If the remainder of 26  divide operation is 0, the # of transfer units is the result of the divide. 27  Otherwise, the # transfer units is the result of the divide operation plus one. 28  */ 29  div_t res = div(nbOfBits,transferUnitSize); 30 31  /* # of transfer units generated in the target space */ 32  int nbOfTransferUnits = (res.rem == 0) ? res.quot : res.quot + 1; 33 34  char * ptr; 35 36  unsigned short vUnit; 37  int index; 38 39  int isTruncated; 40  int nbEmptyBits; 41  int nbBitsToBeCopied; 42  int nbBitsCannotBeCopied; 43  int nbUnits; 44 45  int i, j, vMask, v; 46 47  char CurrentTransferUnit; 48 49  /***************************************************************** 50  The mask table is used to extract the least significant K bits from the 51   source data unit. For example, if targetUnitSize = 4, then 52   mask[0] = 1, mask[1] = 3, mask[2] = 7, and mask[3] = 15. Mask[3−1] 53   Is used to extract the least significant 3 bits. 54  */ 55 56  /* int of the mask table */ 57  int * mask = (int *) malloc(sizeof(int) * targetUnitSize); 58  for (i = 1; i <= targetUnitSize; i++) 59   { 60   vMask= 0; 61   v = 1; 62   for (j = 0; j < i; j++) 63    { 64     vMask = vMask + v; 65     v = v * 2; 66    } 67   mask[i−1] = vMask; 68   } 69 70  /* Index in the source space.*/ 71  index = 0; 72 73  /* 74   Fill the target space with nbOfTransferUnits transfer units. Initialize 75   a truncation flag. A vUnit from the source address space is truncated 76   if all bits do not fit in the current transfer unit of the target space. 77  */ 78  isTruncated = 0; /*false*/ 79 80  /* # bits to be copied */ 81  nbBitsToBeCopied = targetUnitSize; 82 83  /* Pointer in the target space */ 84  ptr = *targetSpace; 85 86  /* Current number of transfer units filled in the target space */ 87  nbUnits = 0; 88 89  /* Construct transfer units of the target space */ 90 91  while (nbUnits < nbOfTransferUnits) 92   { 93   /* # bits of the current transfer unit to be updated */ 94   nbEmptyBits = transferUnitSize; 95 96   /* Holds the target transfer unit being constructed */ 97   CurrentTransferUnit = (char) 0; 98 99   /* There are some empty bits to be filled in the current transfer unit */ 100   while ((nbEmptyBits > 0) && (index < nbElem)) 101   { 102    if (! isTruncated) 103    { 104     /* 105     The current source data unit copied to the target space is not 106     truncated. Get the next one from the source data space and 107     extract targetUnitSize bits 108    */ 109     vUnit = sourceSpace[index] & mask[targetUnitSize − 1]; 110    } 111 112    nbBitsCannotBeCopied = (nbEmptyBits >= nbBitsToBeCopied) ? 113     0 : nbBitsToBeCopied − nbEmptyBits; 114 115    if (nbBitsCannotBeCopied == 0) 116    { 117     /* There are enough empty bits in the current transfer unit, so 118      the source data unit will not be truncated */ 119     isTruncated = 0; 120 121     /* Update the number of empty bits in the current transfer unit */ 122     nbEmptyBits = nbEmptyBits − nbBitsToBeCopied; 123 124    /* fill the transfer unit, extracting the bits and shifting left */ 125     CurrentTransferUnit = (char) ((vUnit & mask[nbBitsToBeCopied 126        − 1]) << nbEmptyBits) | CurrentTransferUnit; 127 128    /* # of bits to be placed for the next data unit */ 129     nbBitsToBeCopied = targetUnitSize; 130 131    /* increment index to next data unit in the source space. */ 132     index++; 133    } 134    else 135    { 136    /* There are not enough empty bits in the current transfer unit; the 137      current data will be truncated (if it is not yet) */ 138     isTruncated = 1; 139 140     /* and there will be no empty bits in the current transfer unit */ 141     nbEmptyBits = 0; 142 143     /* Copy data into the current transfer unit*/ 144     CurrentTransferUnit = (char) (((vUnit & mask[nbBitsToBeCopied 145        − 1]) >> nbBitsCannotBeCopied)) | CurrentTransferUnit; 146 147     /* The # of bits to be placed in the next iteration = # of bits 148      that cannot be placed */ 149     nbBitsToBeCopied = nbBitsCannotBeCopied; 150    } 151   } 152   *ptr = CurrentTransferUnit; /* put constructed transfer unit in target space */ 153   nbUnits++; /* increment the number of transfer units copied */ 154   ptr++; /* move to the next transfer unit */ 155   } 156  return nbOfTransferUnits; 157 }

The system 100 may be implemented as a mobile device 915 such as that shown in FIG. 9. As shown, the mobile device 915 comprises an integrated keypad 912 and display 914. The JSM processor 102 and MPU processor 104 and other components may be comprised in electronics package 910 connected to the keypad 912, display 914, and radio frequency (“RF”) circuitry 916. The RF circuitry 916 may be connected to an antenna 918.

While the various embodiments of the invention have been shown and described, modifications thereof can be made by one skilled in the art without departing from the spirit and teachings of the invention. The embodiments described herein are illustrative only, and are not intended to be limiting. Many variations and modifications of the invention disclosed herein are possible and are within the scope of the invention. Accordingly, the scope of protection is not limited by the description set out above. Each and every claim is incorporated into the specification as an embodiment of the present invention.

Claims

1. A method for copying data from a source memory space to a target memory space, the method comprising:

extracting a plurality of source data units from the source memory space, wherein each source data unit is of size s bits;
translating the plurality of source data units into a plurality of target data units, wherein a target data unit is an addressable unit of the target memory space and each target data unit is of size t bits; and
copying the plurality of target data units into a plurality of contiguous transfer units in the target memory space, wherein each transfer unit is of size b bits.

2. The method of claim 1, wherein translating the plurality of source data units further comprises copying the s bits of each source data unit of the plurality of source data units to a target data unit of the plurality of target data units if s=t.

3. The method of claim 1, wherein translating the plurality of source data units further comprises copying a least significant t bits of each source data unit to a target data unit of the plurality of target data units if s>t.

4. The method of claim 1, wherein translating the plurality of source data units further comprises:

if s<t, copying the s bits of each source data unit to an s least significant bits of a target data unit of the plurality of target data units, and setting a t-s most significant bits of the target data unit to zero if the s bits are unsigned or to a sign extension value if the s bits are signed.

5. The method of claim 1, wherein copying the plurality of target data units further comprises:

copying n bits of the t bits of a first target data unit to an n most significant bits of a first transfer unit of the plurality of transfer units, wherein the transfer unit has x empty bits before the copying; and
if n<x, copying x-n bits of a second target data unit to an x-n least significant bits of the first transfer unit and copying t-(x-n) bits of the second target data unit to a t-(x-n) most significant bits of a second transfer unit contiguous to the first transfer unit.

6. The method of claim 1, wherein copying the plurality of target data units further comprises:

if a number of bits n to be copied in a target data unit is less than or equal to a number of empty bits x in a transfer unit, copying n bits of the target data unit to an n most significant bits of the x empty bits of the transfer unit; and
if the number of bits n is greater than the number of empty bits x, copying an x most significant bits of the n bits of the target data unit to the x empty bits of the transfer unit.

7. A computer-readable medium storing a software program that, when executed by a processor, performs a method for copying a source memory space to a target memory space, the method comprising:

extracting a plurality of source data units from the source memory space, wherein each source data unit is of size s bits;
translating the plurality of source data units into a plurality of target data units, wherein a target data unit is an addressable unit of the target memory space and each target data unit is of size t bits; and
copying the plurality of target data units into a plurality of contiguous transfer units in the target memory space, wherein each transfer unit is of size b bits.

8. The computer-readable medium of claim 7, wherein translating the plurality of source data units further comprises copying the s bits of each source data unit of the plurality of source data units to a target data unit of the plurality of target data units if s=t.

9. The computer-readable medium of claim 7, wherein translating the plurality of source data units further comprises copying a least significant t bits of each source data unit to a target data unit of the plurality of target data units if s>t.

10. The computer-readable medium of claim 7, wherein translating the plurality of source data units further comprises:

if s<t, copying the s bits of each source data unit to an s least significant bits of a target data unit of the plurality of target data units, and setting a t-s most significant bits of the target data unit to zero if the s bits are unsigned or to a sign extension value if the s bits are signed.

11. The computer-readable medium of claim 7, wherein copying the plurality of target data units further comprises:

copying n bits of the t bits of a first target data unit to an n most significant bits of a first transfer unit of the plurality of transfer units, wherein the transfer unit has x empty bits before the copying; and
if n<x, copying x-n bits of a second target data unit to an x-n least significant bits of the first transfer unit and copying t-(x-n) bits of the second target data unit to a t-(x-n) most significant bits of a second transfer unit contiguous to the first transfer unit.

12. The computer-readable medium of claim 7, wherein copying the plurality of target data units further comprises:

if a number of bits n to be copied in a target data unit is less than or equal to a number of empty bits x in a transfer unit, copying n bits of the target data unit to an n most significant bits of the x empty bits of the transfer unit; and
if the number of bits n is greater than the number of empty bits x, copying an x most significant bits of the n bits of the target data unit to the x empty bits of the transfer unit.

13. A system, comprising:

a processor;
a memory coupled to the processor; and
instructions stored in the memory that, when executed by the processor, perform a method for copying a source memory space to a target memory space, the method comprising:
extracting a plurality of source data units from the source memory space, wherein each source data unit is of size s bits;
translating the plurality of source data units into a plurality of target data units, wherein a target data unit is an addressable unit of the target memory space and each target data unit is of size t bits; and
copying the plurality of target data units into a plurality of contiguous transfer units in the target memory space, wherein each transfer unit is of size b bits.

14. The system of claim 13, wherein translating the plurality of source data units further comprises copying the s bits of each source data unit of the plurality of source data units to a target data unit of the plurality of target data units if s=t.

15. The system of claim 13, wherein translating the plurality of source data units further comprises copying a least significant t bits of each source data unit to a target data unit of the plurality of target data units if s>t.

16. The system of claim 13, wherein translating the plurality of source data units further comprises:

if s<t, copying the s bits of each source data unit to an s least significant bits of a target data unit of the plurality of target data units, and setting a t-s most significant bits of the target data unit to zero if the s bits are unsigned or to a sign extension value if the s bits are signed.

17. The system of claim 13, wherein copying the plurality of target data units further comprises:

copying n bits of the t bits of a first target data unit to an n most significant bits of a first transfer unit of the plurality of transfer units, wherein the transfer unit has x empty bits before the copying; and
if n<x, copying x-n bits of a second target data unit to an x-n least significant bits of the first transfer unit and copying t-(x-n) bits of the second target data unit to a t-(x-n) most significant bits of a second transfer unit contiguous to the first transfer unit.

18. The system of claim 13, wherein copying the plurality of target data units further comprises:

if a number of bits n to be copied in a target data unit is less than or equal to a number of empty bits x in a transfer unit, copying n bits of the target data unit to an n most significant bits of the x empty bits of the transfer unit; and
if the number of bits n is greater than the number of empty bits x, copying an x most significant bits of the n bits of the target data unit to the x empty bits of the transfer unit.

19. The system of claim 13, wherein the system comprises a mobile device.

Patent History
Publication number: 20060023517
Type: Application
Filed: Jul 21, 2005
Publication Date: Feb 2, 2006
Applicant: Texas Instruments Incorporated (Dallas, TX)
Inventors: Gilbert Cabillic (Brece), Salam Majoul (Rennes)
Application Number: 11/186,062
Classifications
Current U.S. Class: 365/189.050
International Classification: G11C 7/10 (20060101);