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.
Latest Texas Instruments Incorporated Patents:
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 INVENTIONMobile 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++.
SUMMARYAccordingly, 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 NOMENCLATURECertain 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 DRAWINGSFor a more detailed description of the preferred embodiments of the present invention, reference will now be made to the accompanying drawings, wherein:
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.
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.
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.
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
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.
As the example in
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.
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
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 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.
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).
The system 100 may be implemented as a mobile device 915 such as that shown in
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.
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
International Classification: G11C 7/10 (20060101);