Abstract:
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.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]     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  
       [0002]     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.  
         [0003]     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  
       [0004]     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.  
         [0005]     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  
       [0006]     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  
       [0007]     For a more detailed description of the preferred embodiments of the present invention, reference will now be made to the accompanying drawings, wherein:  
         [0008]      FIG. 1  shows a diagram of a system in accordance with embodiments of the invention;  
         [0009]      FIG. 2  further illustrates the system of  FIG. 1 ;  
         [0010]      FIG. 3-8  illustrate the operation of a dynamic memory translation method in accordance with embodiments of the invention; and  
         [0011]      FIG. 9  depicts an illustrative embodiment of the system described herein. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0012]     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.  
         [0013]     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).  
         [0014]     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.  
         [0015]      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.  
         [0016]     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.  
         [0017]     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.  
         [0018]     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 .  
         [0019]      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 .  
         [0020]     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.  
         [0021]     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 .  
         [0022]      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.  
         [0023]     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.  
         [0024]     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.  
         [0025]     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&gt; 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&gt; 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. 
 
         [0026]     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&gt;t, and s&lt;t.  
         [0027]     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&gt;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&lt;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.  
         [0028]     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={s 1 , s 2 , s 3 , . . . , s p }, 
 
 where each s i , iε[1, p], denotes a source data unit of size s bits to build a set T of target data units, 
 
T={t 1 , t 2 , t 3 , . . . , t p }, 
 
 where each t i  denotes a target data unit of size t bits such that t i  contains the bits of the corresponding source data unit s i . In some embodiments, a build process applied by the translation software  154  to each s i  of the set S to create each t i  of the set T comprises: 1) if s≦t, a target data unit t i  is formed by the least significant t bits extracted from the corresponding source data unit s i ; and  2 ). if s&lt;t, a target data unit t i  is formed by s bits of the corresponding source data unit s i  and t-s bits of zero value or sign extension, where the s bits from the source data unit s i  constitute the least significant bits of the target data unit t i , and the t-s zero-value or sign extension bits constitute the most significant bits of the target data unit t i . The t-s bits are zero value if the data is unsigned, and sign extension if the data is signed. 
 
         [0029]     The translation software  154  copies the t bits of each t i  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={b i , b 2 , b 3 , . . . , b q }, 
 
 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 t i  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. 
 
         [0030]      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 t i  may be entirely copied into a portion of a transfer unit b i  of the target memory space. In the example of  FIG. 7 , the copy process copies t 1  into the most significant bits of b 1 , t 2  into the least significant bits of b 1 , t 3  into the most significant bits of b 2 , t 4  into the least significant bits of b 2 , and so on.  
         [0031]      FIG. 8  shows an example where the t i  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 t 1  into transfer unit b 1  of the target memory space. After copying t 1 , b−t=2 bits in the current transfer unit b 1  remain empty. The copy process fills these two bits with bit values from the next target data unit t 2 . The copy process extracts the two most significant bits from t 2  to fill these two empty bits of transfer unit b 1 . The copy process then places remaining t−(b−t)=4 bits from t 2  in the most significant four bits of the next transfer unit b 2 . The copy process repeats this procedure to copy all of the of target data units t i  in the set T to transfer units in B.  
         [0032]     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 t i  to be copied is denoted by nbBitsToBeCopied, the number of empty bits in the current transfer unit b j  to be filled is denoted by nbEmptyBits, the number of bits of the current element t i  that cannot be copied in the current transfer unit b j  is denoted by nbBitsCannotBeCopied, the current target data unit t i  from T to be copied is denoted by currentDataUnit, and the current transfer unit b j  in B to be filled is denoted by currentTransferUnit. Initially, the currentDataUnit is t 1 , nbBitsToBeCopied is t, currentTransferUnit is b 1 , and nbEmptyBits=b.  
         [0033]     The operation of the pseudo code is explained in the context of the example of  FIG. 8 . Initially, the currentDataUnit is t 1 , nbBitsToBeCopied is t=6, currentTransferUnit is b 1 , and nbEmptyBits is b=8. The pseudo code begins with a determination of whether there is sufficient space in the current transfer unit b 1  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 t 1  are copied to b 1  (line  4 ), nbEmptyBits is set to 2, nbBitsToBeCopied is set to t=6 for the next iteration (line  6 ) and currentDataUnit is set to t 2  (line  12 ) since all bits of t 1  have been copied. A check is made to determine whether b 1  is full (line  15 ). Because nbEmptyBits is currently two, this test fails.  
         [0034]     On the next iteration, a check is again made to determine whether there is sufficient space in the current transfer unit b 1  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 t 2  are copied into the least significant 2 bits of b 1  (line  23 ). nbEmptyBits is set to b for the next iteration since b 1  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 t 2 . Because all of the bits in b 1  are full, cuffentTransferUnit is set to b 2 .  
         [0035]     On the subsequent iteration, the check is made to determine whether there is sufficient space in the current transfer unit b 2  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 t 2  are copied to the most significant four bits of b 2  (line  4 ), nbEmptyBits is set to  4  (line  5 ), and nbBitsToBeCopied is set to t (line  6 ) and currentDataUnit is set to t 3  for the next iteration. This iterative process is repeated until all the bits of the t I  are copied to transfer units in the target memory space.  
                                           TABLE 1                           1   if (nbBitsToBeCopied &lt;= nbEmptyBits) then       2   {       3    nbBitsCannotBeCopied = 0; // because all bits of t i  are copied       4    copy in currentTransferUnit nbBitsToBeCopied from            currentDataUnit;       5    nbEmptyBits = nbEmptyBits − nbBitsToBeCopied;            6    nbBitsToBeCopied = t;   // because all bits of t i  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 t i+1              10           11    //get from T the next element to be copied in the next iteration       12    currentDataUnit = t i+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 = b j+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 b j              are full       25    nbBitsToBeCopied = nbBitsCannotBeCopied;       26    // the remaining bits from t i  to be copied in the next transfer            unit b j+1         27       28    // all bits of the current transfer unit are set; get the next transfer            unit       29    currentTransferUnit = b j+1 ;       30   }                  
 
         [0036]     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.  
         [0037]     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                      
 
         [0038]     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 (line 1 ). 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[&lt;number of bits to be extracted&gt; 1 ] is used to extract the &lt;number of bits to be extracted&gt; least significant meaningful data bits from a source data unit. That is, to extract the three least significant bits, mask[ 3 - 1 ] is used.  
         [0039]     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 (line 1   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 ).  
         [0040]     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.  
         [0041]     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 ).  
         [0042]     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 &lt;= targetUnitSize; i++)       59     {       60     vMask= 0;       61     v = 1;       62     for (j = 0; j &lt; 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 &lt; 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 &gt; 0) &amp;&amp; (index &lt; 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] &amp; mask[targetUnitSize − 1];       110      }       111       112      nbBitsCannotBeCopied = (nbEmptyBits &gt;= 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 &amp; mask[nbBitsToBeCopied       126          − 1]) &lt;&lt; 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 &amp; mask[nbBitsToBeCopied       145          − 1]) &gt;&gt; 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   }                  
 
         [0043]     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 .  
         [0044]     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.