TWI439931B - Object code generation for increased delta performance - Google Patents

Description

Generation of the purpose code for increasing the triangular differential performance

The present invention relates to the generation of an updated destination code for a computer program, the updated destination code being adapted to generate an updated memory image to be loaded into a memory having stored therein and a computer program The current memory image corresponding to the current version.

Many data electronic devices (such as embedded devices) are controlled by software stored in flash memory. A flash memory system is a type of memory that is frequently used in electronic devices because it allows multiple rewrites. However, the write job is limited to writing the entire memory page each time (so-called flash sector). A typical page size for a current flash memory is 64 kbytes.

Rewriting or "reflashing" when updating software stored in one of the flash devices of an electronic device, for example, adding new features to the software and/or correcting errors in the current version of the software Some or all of the memory segments of the flash memory. In general, it should preferably minimize the number of flash pages rewritten during a software update to minimize the time and energy consumption required to assemble the software update.

In particular, an application (OTA) update of an application terminal in which the update time is of great interest. In such applications, it is known that only modifications to the current image, rather than the entire updated image, are assigned to the mobile terminal. These modifications are often referred to as delta-files. Typically, in such systems, an update agent running on the mobile terminal applies the received modifications to the current image, thereby converting the current image to an updated version. Therefore, it is generally preferred to reduce the size of the triangular differential file to reduce the amount of data that must be transmitted via the communication channel for OTA updates.

In addition, it is generally preferable to reduce the storage capacity and the amount of computing resources required to perform software updates in the mobile terminal.

A further common problem with one of such update systems is that the terminal may not work during the update process. Therefore, it is preferable to reduce the time required to reflash the memory and thus reduce the downtime of the system.

However, due to the limitations of the flash memory mentioned above, even a small update of the software source code can cause most of the flash pages to be updated, because even if only a single byte is changed, it is necessary to completely rewrite the entire page.

US Published Application No. 2003/0142556 discloses a method of flash memory staging in which volatile information or volatile software components are stored near the end of each flash memory address space of a flash memory device, The need to change or adjust the flash zone is as slight as possible.

However, the prior art methods described above require information about changing the expected likelihood of each information component.

European Patent No. 0472812 relates to a differential update system comprising a compiler, a modified linker and a comparator, the update system generating a difference comprising a difference between an updated machine code and a previous version of the machine code Program file. The modified linker receives the compiled version of the current version and the clip information generated by the modified link for the previous version, and arranges the fragments in the memory according to their size compared to the previous version.

One of the objects of the present invention is to facilitate an improved triangular differential update procedure.

The present invention solves the above and other problems by a method of generating an updated destination code of a computer program, the updated destination code being suitable for input to a linker component for generating a payload to be stored in a storage medium. After updating the memory image, the storage medium has stored a current memory image corresponding to the current version of the computer program, the method comprising: - receiving at least one updated input code pattern from which the updated destination code is to be generated Grouping - processing at least the updated input code module to generate at least one updated destination code module adapted to be linked by an linker component to produce the updated memory image; - performing at least one optimization process To reduce the difference between the updated destination code module and a corresponding one of the current destination code modules, the current target code module of the group corresponds to the current version of the computer program, wherein the updated destination code is The optimization process is performed before the module is fed to a linker assembly.

In particular, the present invention is based on the recognition that when the compiler - or a compiler after the compiler - optimizes the generated object code before the linker phase to reduce the result of updating the corresponding source code The amount of change in the code will greatly contribute to the generation of a subsequent valid triangular differential file.

Since the source layer is not relied on by substantially reverse-engineering the compiler and linker process at a later stage (eg, in the linker stage) or in a compiled and linked binary image To modify the possibility, the above method first ensures that the resulting image is produced with as little variation as possible, thereby facilitating more efficient generation of triangular differential files that produce fewer triangular differential files and that only need to rewrite fewer memory segments.

In particular, in some embodiments, the optimizing step includes generating the destination code module such that the size of the destination code module does not exceed a corresponding size of the corresponding current destination code module. In some embodiments, an updated destination code module can even be generated to have the same size as the corresponding current destination code module. One advantage is that the subsequent destination code module in the memory space does not need to be shifted/moved by modifying the destination code module.

A further advantage is that even a simple triangular differential file generation tool can generate a high-performance triangular differential file, thereby avoiding the need for sophisticated or expensive triangular differential file generation tools.

In some embodiments, the at least one updated input code module is at least one updated source code module, and the method further comprises compiling the updated source code module. Alternatively, the updated input code module is at least one preliminary destination code module generated by the compiler from at least one corresponding updated source code module. Therefore, the method can be constructed as an integrated compiler process that receives the source code and produces the best destination code, thereby allowing or even optimizing the compilation process to reduce differences in the compiled code, thereby facilitating the subsequent triangular differential file generation performance. Further improvement. Alternatively, the method can be constructed as a post-compiler processing step, wherein the post-processing step receives the object code from the compiler and produces a best destination code that is fed to the linker, thereby allowing the use of a standard compilation tool and thus The method is integrated into an existing code generation tool chain.

When the method further includes receiving control data from the linker (eg, a request from a linker, for example, indicating a size limit condition for the updated destination code module size), the method can be integrated into one for generating In the special tool chain of the triangular differential file, the downstream tool sends the feedback information to the upstream tool to provide an overall optimization of the triangular differential file generation.

In another preferred embodiment, the method includes: - generating a set of preliminary destination code modules; - transferring the set of preliminary destination code modules to a linker; - from the linker and a subsequent triangle At least one of the differential file generators receives the feedback data; and - generates an updated destination code module in response to the feedback data.

Therefore, in this embodiment, the generation of the object code is performed two or more times, wherein the feedback information received from the downstream processing step of the first pass is used in the second pass, thereby further improving the generated target code pair. The suitability of an effective triangular differential file. For example, the linker can generate feedback to the compiler stage, causing the compiler to recompile at least a portion of the source code. This has the advantage that the linker can control one of the generated group code modules, thereby increasing the degree of freedom of the linker to rearrange the destination code module.

When the method further includes receiving processing information regarding a previous processing step for generating a current destination code module from the corresponding current input code module, it causes a destination code having a minimum change compared to the current version. For example, the processing information may include at least one current arrangement information about a current arrangement of different target module portions in the current destination code module and compilation information about a previous compiler step, such as at least one source-to-machine code mapping. And information about which compilation optimization steps were applied during the previous compilation step. Alternatively or additionally, the method includes receiving the current set of destination code modules to allow the process to compare the updated destination module with the current destination code module. The term "source-to-machine code mapping" is the relationship between the source code structure and the corresponding destination code entity. A function (constant, class definition, etc.) can correspond to one or several fragments. Depending on the implementation, a single destination code entity may also correspond to several functions (constants, class definitions, etc.). The complexity of this mapping depends on the actual implementation. A very simple mapping (eg, mapping one source file to a single fragment) may not even require explicit storage, while complex mapping (eg, where two functions combine to produce a common fragment) may have to be stored to correctly match the assembled image and the Update the clip of the image.

In some embodiments, the method further includes storing the updated processing information regarding the processing steps for generating the updated destination code module in a code repository such that the processing information is available for subsequent compilation behavior.

Thus, in some embodiments, meta information is stored between different compilation behaviors and made accessible by the compiler. This meta-information contains information on how to convert source code components into the target module portion so that the compiler can make similar or even consistent transitions in subsequent translations. In some embodiments, the compiler may even reuse the previously created object code.

In some embodiments, the updated destination code module includes a plurality of destination module portions. For example, each of the target module portions may include at least one of a function and a variable. In general, in the present description, the term "destination module portion" means a relocatable entity of a foreign code module, in particular a minimum relocatable entity of a destination code module, and in particular Refers to an entity that can be relocated independently of other entities. In general, the destination module portion may correspond to a structural entity of a stylized language, such as functions, programs, class definitions, constant definitions, variable definitions, and the like.

When the optimization step includes determining the order of the target module portions in the updated destination code module, the process ensures the relative order of the destination module portions in the generated updated destination code and the destination module portion. The difference in order in the current version is as small as possible.

In some embodiments, the optimizing step includes placing at least one of the target module portions not included in a current destination code module corresponding to a first updated destination code module in a different one. The second updated destination code module of the first destination code module is configured to reduce a difference between the first updated destination code module and the corresponding current destination code module. This avoids an increase in the size of a destination code module due to the introduction of additional module portions in the update.

Generally, a code generation system includes: a compiler that compiles a source code and generates a set of object code modules; and a linker that generates executable code in the form of a loadable memory image. The compiler and linker can, for example, be constructed as a separate executable software program, as a functional module for an integrated software development software application, or the like.

Specifically, in a triangular differential file update scheme, the memory images are successively fed into a triangular differential file generator that generates a triangular differential file representing the current code version and updated. The difference between the code versions. Therefore, the generated triangular differential file contains the difference between the current memory image and the updated memory image, that is, a device required to generate an updated version from the current version stored in the device and in the triangular differential file. Information. This will reduce the size of the files that need to be loaded into the device, further reducing the time required to perform a software update.

Source code usually consists of a series of statements written in a human-readable computer stylized language. In modern stylized languages, the source code that makes up a software program is usually produced in the form of one or more text files (so-called source code modules). A compiler is typically a computer program or a functional component of a computer program that translates source code written in a particular stylized language into computer readable machine code. Generally, when the source code includes a plurality of source code modules, the compiler separately compiles each source code module and generates a corresponding destination code module, that is, a destination code module corresponding to each source code module.

The term "destination code" means a computer readable program code, usually expressed in a binary machine language, which is normally output as an established translation process (commonly referred to as compilation), wherein the output is in principle prepared by a computer. carried out. However, the destination code may also include symbol references relating to other locations in the destination code. In particular, when the destination code includes a plurality of destination code modules, references to functions or variables included in other destination code modules are stored as symbol references. Therefore, a destination code module can typically be relocated in memory space and contain unresolved references. In particular, a relocatable destination code module typically includes symbol reference and relocation information, and the latter indicates how the linker resolves the references. One of the interesting attributes of the relocatable destination code module is that the start address and the address of the reference symbol are not determined. Therefore, relocation is the process of replacing the reference to the symbol with the actual address.

A linker is typically a functional component of a computer program or a computer program that resolves the dependencies between the code modules (and in particular any symbol references) that form a group of software development projects. In addition, the task of the linker usually includes arranging each target code module in the memory, and also assigning the relative address to a different destination code module in a corresponding address space. The destination code modules are typically represented in a hardware and/or platform-specific low-level file format as their respective destination files. Accordingly, in some embodiments, the method further includes feeding the updated destination code modules to an linker component for linking the updated destination code modules to generate a suitable one for subsequent The updated memory image processed by the triangular differential file generator.

Here, the term "arrangement of codes in memory" includes respective start addresses or base addresses of different destination code modules, that is, their respective relative addresses in the address space occupied by the code.

One of the advantages of the method described herein is that it facilitates a further optimization step of the linker stage, thereby providing an optimized input for a subsequent triangular differential file generation module and thereby facilitating the most of the triangular differential file Jiahua is produced. The optimization process performed by the linker can include determining the placement of the target code modules in the memory.

Further preferred embodiments are disclosed in the dependent application.

It should be noted that the method features set forth above and below may be implemented in software and may be executed on a data processing system or other processing component by executing program code components such as computer executable instructions. Here and in the following, the term "processing member" includes any circuit and/or device suitable for performing the functions described above. In particular, the term "processing component" includes general purpose or special programmable microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), programmable logic arrays (PLAs), field programmable Gate array (FPGA), dedicated electronic circuitry, etc., or a combination thereof.

For example, the code component can load a memory, such as a random access memory (RAM), from a storage medium or via a computer network from another computer. Alternatively, the above features may be implemented by a hardwired circuit rather than a soft body or in combination with a soft body.

The present invention can be embodied in a variety of ways, including the methods described above and one of the following data processing systems, and other product components, each of which produces one or more of the benefits and advantages described in connection with the methods first mentioned. Each of the preferred embodiments has one or more preferred embodiments, which correspond to the preferred embodiments set forth in connection with the first mentioned method.

In particular, the present invention relates to a data processing system for generating an updated destination code for a computer program, the updated destination code being suitable for input as an linker component for generating a memory to be loaded The memory image is updated, wherein the current memory image corresponding to the current version of the computer program is stored in the memory, and the data processing system is suitably programmed to perform the methods described above and below. step.

The invention further relates to a computer program product comprising a code component adapted to cause the data processing system to perform the above and below when the code component is subsequently executed on a data processing system method. The computer program product can be implemented as a computer readable medium having stored thereon.

In the present description, the term "electronic device" includes any device that includes a memory (such as a flash memory) for storing code. Examples of such devices include portable radio communication devices and other handheld or portable devices. The term "portable radio communication device" includes all devices such as a mobile phone, a pager, a communicator (i.e., an electronic organizer), a smart phone, a personal digital assistant (PDA), a handheld computer, or the like.

1 is a block diagram showing an embodiment of a system for updating software in an electronic device, such as a mobile terminal. The system includes a mobile terminal 101 (e.g., a mobile telephone or similar device), a software update system 102, and a communication interface 103.

The software update system 102 can include a server computer capable of accessing a communication network. In some embodiments, the functionality of the server computer can be distributed among a plurality of computers, such as a computer connected via a computer network (eg, a regional network, a wide area network, an internet, or the like). . The software update system 102 includes a interface circuit 104 that allows the software update system to communicate data via the communication interface 103. For example, the interface circuit can include a serial port, a parallel port, a short-range wireless communication interface (eg, an infrared port), a Bluetooth transceiver, or the like. A further embodiment of the interface circuit includes a network card, a DSL modem, a gateway computer or the like.

The software update system further includes a processing unit 105, such as a server computer CPU, suitably programmed to control and execute the update process, wherein the update process includes generating updated code as described herein. The processing unit further includes a version repository/repository 106 having stored therein at least one basic version/current version of the software to be updated and an updated version of the memory image and further information thereof. In some embodiments, the version database may further include additional information, such as for different types of mobile terminals, for different customer groups, for example, a plurality of basic versions and/or updated versions and/or the like.

Communication interface 103 can be used in any suitable wired or wireless communication interface for transferring data between software update system 102 and mobile terminal 101. For example, if it is a mobile phone suitable for communication via a cellular communication network (for example, a GSM network, a UMTS network, a GPRS network or the like), it can communicate via the cellular communication. The network implements communication between the software update system and the mobile terminal regarding a software update, thereby avoiding the need for additional communication interfaces in the mobile terminal.

Thus, to update the software on the mobile terminal 101, the mobile terminal can receive, for example, an update command including an image of the memory segment to be rewritten, from the update system.

In a differential update system using a triangular differential file, an update command is generated to enable the mobile terminal to generate an updated software version from additional information contained in existing versions and update instructions stored in the mobile terminal. The triangular differential file can be applied on-site, that is, the mobile terminal makes changes on the existing image, so that almost no additional storage is required. In addition, the above method reduces the load time since only the triangular differential file needs to be loaded and since the triangular differential file is usually much smaller than the newer version.

Thus, a possible solution in which the code generation process described herein can be applied is set forth above. However, it should be understood that the code generation process described herein can also be applied to other update scenarios. For example, updates may be provided to the target device via other media (eg, other communication channels, via a computer readable medium, etc.).

Embodiments of the code generation process are explained in more detail below.

Figure 2 is a block diagram showing an embodiment of an electronic device (e.g., a mobile terminal). The mobile terminal 101 includes a communication block 210, a processing unit 211, and a memory unit 212.

Communication block 210 includes circuitry and/or devices that permit radio based data communication via a cellular communication network. Accordingly, in the present description, communication block 210 includes receiving circuitry and transmission circuitry for receiving and transmitting data signals. The communication block may further comprise circuitry for suitably processing (e.g., modulating, encoding, amplifying, etc.) signals by suitable techniques well known in the art of radio communication technology.

The mobile terminal further includes a processing unit 211, such as a suitably programmed microprocessor. The processing unit is adapted to determine a version of the software stored in the mobile terminal, calculate a checksum of the stored software, and generate an updated version of the software upon receiving the corresponding update instruction.

The software and/or other materials have been stored in the memory unit 212 in a predetermined version. For example, the memory 212 can include a firmware of the mobile terminal that, when loaded into the processing unit 211 and executed by the processing unit 211, implements the basic functions of the mobile terminal. The firmware may further include an operating system that allows execution of the application software. Accordingly, the memory 212 can be further stored with application software that provides additional functionality. The memory 212 is addressed using a suitable address space to allow the processing unit to access selected portions of the memory. In some embodiments, memory 212 can be logically or physically divided into a plurality of memory segments. For example, memory 212 can include flash memory that allows data to be written into segments of a predetermined size.

In the present description, it is assumed that the memory 212 is divided into a certain number of segments of a predetermined size, labeled P1, P2, P3, ..., PN, respectively. However, it should be understood that any other memory addressing scheme may alternatively be used. Of course, it should be further understood that if, for example, the entire image of the flash memory of a mobile phone is to be updated, the update process described herein can be applied to the entire memory 212, or if one or more softwares are to be updated. The application only applies the update process described herein to a predetermined portion of the memory.

In the following, different examples of a software update process will be explained with reference to Figures 3-11. In the drawings, the same reference numerals are used to refer to the same or corresponding components, features, and the like.

Figure 3 shows a block diagram of one embodiment of a software update process. Initially, a compiler 303 receives one or more source modules 302 from a source repository 301 (eg, a source repository, a version management system) or directly from a source editing tool. The compiler 303 generates a set of destination code modules 305 that are fed to a linker 306. The linker 306 combines the destination code modules 305 into an absolute archive 307 ready for execution. One of the tasks performed by the link module 306 is to resolve the cross-references between the individually compiled target code modules and assign the final address to create a single executable 307. Thus, the output 307 from the linker is directly loadable into, for example, a file in the flash memory of a device that is to execute the program. The linker output 307 will also be referred to as a memory image.

The linker output 307 is fed into a triangular differential file generation module 308, also referred to as a triangular differential file generator. The triangular differential file generator 308 receives the binary (updated) image 307 and a corresponding current memory image as input and generates a triangular differential file 309 as an update packet or as an update packet. A portion of it is sent to a device whose memory is updated from the current memory image to the updated memory image. The current memory image can, for example, be stored in a repository of image files, such as a suitable database. In some embodiments, the memory image is retrieved from a repository 310, and the repository 310 can be part of the same repository as the source repository 301. In some embodiments, the triangular differential generator 308 can receive additional input, such as additional link information, from the repository 310, for example, in the form of a so-called mapping archive.

The generation of the triangular differential file can be schematically illustrated by the following operations: file _{n e w} -file _{b a s e} → △file

Correspondingly, the actual generation of the new version can then be performed by the mobile terminal according to the following operations: file _{b a s e} +Δfile → file _{n e w}

It should be understood that the above operation of generating a triangular differential file (marked as "-" in the above mark) and generating a new version on the mobile terminal (marked as "+" in the above mark) may include more or less complicated operations. . Examples of suitable triangular differential archival techniques include US 6,546,552 and "Compressing Differences of Executable Code" by Brenda Baker, Udi Manber and Robert Muth, in ACM SIGPLAN Workshop on Compiler Support for System Software (WCSSS '99), 1999. The method described in ).

In the embodiment of FIG. 3, compiler 303 further receives source file change information 304 from the source repository. In some embodiments, the change information 304 includes information about which source components, such as which functions, during the current update (ie, from the source code corresponding to the currently installed software to the updated source code compiled by the compiler 303). , methods, classes, and/or information that has been modified. This information allows the compiler to generate updated destination code module 305 with as little difference as possible.

4 shows a block diagram of another embodiment of a software update process similar to the process described in connection with FIG. The process of Figure 4 differs from the process of Figure 3 in that the compiler 303 of the Figure 4 embodiment receives information about a previously compiled information 413, particularly with respect to generating a compilation of the currently installed memory image. Accordingly, in accordance with this embodiment, compiler 303 stores information about each compilation in repository 310, thereby making the information available for subsequent compilation. It should be understood that, as an option, the compiled information can be stored in a different repository. The compiled information 412 and 413 may contain information regarding source-to-machine code mapping, destination code placement, compiler optimization information, and/or the like. Therefore, the compiler can apply the same optimization steps to the same part of the source code, thereby reducing the difference in the generated object code. In particular, if the compiler receives both information about previous compilations and a change log about source code changes, the compiler can ensure that the source code is compiled in the same way as the previous compilation (eg, with the same optimized settings). They have not changed, resulting in minimal changes in the destination code.

In some embodiments, the results of the previous compilation may even be stored, for example, in repository 310, allowing for the direct reuse of previously compiled components.

Figure 5 shows a block diagram of yet another embodiment of a software update process similar to the process described in connection with Figure 3. The process of FIG. 5 differs from the process of FIG. 3 in that the compiler 303 of the embodiment of FIG. 5 receives feedback information 514 from the linker 306, such as requests/restrictions on the size of different destination code modules. Thus, the feedback signal causes the compiler to compile one or more source files, resulting in a destination code module/file that is more suitable for generating the best memory arrangement by link 306. For example, if the linker determines that the space available for modifying the target code module has increased (eg, because the target code module subsequently positioned in the memory space with reference to the modified target code module in the current build will not Reappearing in the updated build), the linker can send a feedback signal 514 to the compiler to inform the compiler that the upper limit of the size of the modified destination code module has increased. This in turn allows the compiler to avoid splitting of the modified destination code module. In some embodiments, the process of FIG. 5 can be implemented as a two-pass process in which the linker generates a feedback signal based on the result of the first pass (ie, a first compilation and link). The feedback signal 514 causes the compiler to recompile one or more source files, resulting in a modified destination file that is more suitable for the optimal memory arrangement produced by the linker. In some embodiments, the feedback signal 514 may even include information about which of the target module portions (eg, which functions) are included in each of the destination code modules.

Figure 6 shows a block diagram of yet another embodiment of a software update process similar to the process described in connection with Figure 3. The process of FIG. 6 differs from the process of FIG. 3 in that the compiler 303 of the embodiment of FIG. 6 receives information about the previous compilation 413 as described in connection with FIG. 4, and the compiler 303 of the embodiment of FIG. 6 is as described in connection with FIG. The feedback information 514 is received from the linker 306. Moreover, in this embodiment, the linker 306 receives the change information 615 directly from the source repository, such as information about previous linker options or the like.

In addition, the linker 306 of FIG. 6 receives the information 616 about the previous memory image/construction stored in the repository 310. Accordingly, as indicated by data flow arrow 617, linker 306 stores information about the current chaining process of the updated software in a repository for future use. The information stored and retrieved in the repository may include the generated image file itself, layout information about the arrangement of the destination code module in the image file, source-machine code mapping, and the like.

It should be understood that different types of information received by the compiler in the above embodiments may be combined in different ways, i.e., in some embodiments, the compiler may receive some or all of the information.

Figure 7 schematically illustrates the memory arrangement of a flash memory before and after software update, wherein the arrangement is optimized by introducing an overflow block.

Figure 7a illustrates the structure of a portion of an address space of a flash memory. The address space 701 is divided into a number of pages, labeled P1, P2, P3, P4, P5, P6, P7, and P8, respectively. The pages have a predetermined size S; in a typical conventional flash memory, the page size is 64 kilobits (kbytes); however, other sizes may be used.

Figure 7b illustrates an example of a memory arrangement of a code version V1 (which is generally represented by reference numeral 702) stored in address space 701. The code version in this example includes five destination code modules labeled A, B, C, D, and E. The destination code modules have different sizes and are sequentially arranged in the address space 701.

Figure 7c illustrates an updated version of the code V2, which is generally designated 703. In this embodiment, it is assumed that the only change between versions V1 and V2 is to replace module A with module A', which assumes that module A' is larger than the previous module A, such as the additional memory space required for A'. 705 is explained. It is assumed that the remaining modules B, C, D, and E do not change, that is, coincide with the corresponding portion of the version V1. However, as illustrated by reference numeral 706 in Fig. 7c, when the updated version V2 is sequentially arranged, it is necessary to rewrite the entire contents of the memory pages P1 to P7. Pages P1, P2, and P3 need to be rewritten because the content of module A has changed to module A', and the remaining pages need to be changed between versions V1 and V2 due to the positions of modules B, C, D, and E. Was rewritten.

Figure 7d illustrates an optimal memory arrangement based on an updated program version V2 of an optimized compilation step, generally designated 704. In this embodiment, the compiler has generated the updated module based on strict size constraints (i.e., by using previously compiled information about the current version V1), thereby causing the compiler to generate the updated destination code module A'. ₁ and make the B-E of the version V2 not larger than the corresponding destination code module A-E of the current version V1. Accordingly, the compiler has generated two destination code modules A' ₁ and A' _{2 in} place of the single destination code module A' such that A' ₁ has the same size as the original module A of version V1. Additional portions of object code modules A 'comprises from ₂ to A' corresponding to an additional object code modules of the source, and A 'can not be placed in limited size of the object code modules A' _1. Therefore, the subsequent linker can separately place the module parts A' ₁ and A' ₂ to reduce the difference between the memory image generated in V2 and the current version V1. In the example of FIG. 7d, the link has an "overflow" object code modules A _'2 is attached to the image memory. Therefore, when the memory is updated with the best updated version V2 to replace the previous version V1, that is, by reflashing the relevant page of the flash memory, as illustrated by reference numeral 708, only the rewriting is required. Pages P1, P2, and P7. The remaining pages (ie, pages P3, P4, P5, P6, and P8) do not need to be rewritten.

It should be understood that in some cases, the compiler can "overflow" object code A _'2 is placed in the other object code modules within a. For example, if one of the other destination code modules is also updated and the size is reduced as a result of the update, the additional destination code A' ₂ may be placed in another updated destination code module instead of Violation of its size restrictions.

In addition, if the compiler generates the destination code module A' ₁ similar to the original destination code module A of the version V1 based on the information about the change of the source code between the versions V1 and V2 and/or the information about the compilation of the version V1, The difference in the generated image can be further reduced. For example, as in the case of the example of FIG. 7, if the destination code module A spans more than one memory segment (pages P1 and P2 in FIG. 7), the compiler may be able to pair the destination code module A'. the variation is limited to _a defined portion of the object code modules, so that the memory segments P1 and P2 will not all be updated from A to A Effect 'of _1. In addition, to reduce the A and A 'of the difference between ₁ further reduce the need to change other reference A' of the reference object code module ₁ in _which (also goes to other causes variations in the object code module) of danger.

In the following, an example of splitting of an updated destination code module will be explained with reference to FIG.

Figure 8 is a schematic illustration of the generation of a code module that facilitates the linker to make an optimal memory arrangement.

Figure 8a illustrates the compilation of a current version V1 of a source module "A.c" (which is generally designated 801) compiled by a compiler 303 into a destination code module "A.o" (generally designated 802). In this embodiment, it is assumed that the source code module 801 defines three functions f1(), f2(), and f3(). Correspondingly, the destination code module 802 includes corresponding three destination module portions, each of which includes an object code for performing a corresponding function in the functions f1(), f2(), and f3(). The function f1() further depends on the functions f2() and f3(). The placement of the different purpose module portions within the destination code module is determined by the compiler 303 during compilation.

Figure 8b illustrates compilation of the updated version V2 of the source module "A.c" (labeled 803) by the compiler 303. In this example, assume that the updated source code module differs from the original version V1 in that the source code now defines the functions f1(), f3(), g1(), and g2(). In addition, the function f1() now depends on the functions f3(), g1(), and g2(). Thus, the definition of function f2() has been removed compared to version V1, the definition of function f1() has been changed, and two new functions g1() and g2() have been added.

The compiler 303 receives the updated version V2 of the source code 803 and the object code 802 generated during the previous compilation of the version V1. Alternatively or additionally, the compiler 303 may receive placement information regarding the placement of the destination module portion in the previous version V1, rather than receiving the entire destination archive 802.

Based on the previous destination code module 802, the compiler 303 determines the maximum size of the updated destination code module and the target placement of the destination code module portion. Accordingly, in this particular example, the compiler can generate an updated destination code module "A' ₁ .o" (804) that is no larger than the previous destination code module "Ao". In addition, the compiler can locate the functions f1() and f3() already present in the previous version of the destination code in the same location, ie the same relative address as in the destination code module in the previous version. In this example, it is assumed that the destination code module portion corresponding to the function g2() is not larger than the previous function f2(). Therefore, the compiler can place the new function g2() at the same position as the previous function f2(). Finally, the compiler places the function g1() in a separate "overflow" destination code module "A' ₂ .o" (labeled 805).

Thus, the above example illustrates that compiler 303 can generate a destination code module that is no larger than the previous version. In some embodiments, the compiler may even be configured to generate an updated destination file to maintain its overall size, for example, by suitable loading. Therefore, module replacement in the subsequent link process is avoided.

In addition, this example shows how the compiler can place the unaltered and modified module portion in the same location as in the previous version, regardless of its location in the new source archive.

Figure 9 shows a flow chart of an embodiment of a destination code generation process.

Figure 9a shows a flow chart of one embodiment of a destination code generation process. The process begins in step 901 where an updated version of a source module/file to be compiled is received, for example, from source repository 301. In a subsequent step 902, the process identifies a number of module portions, such as functions, class definitions, etc., in the source code module, and is based, for example, on change information 304 received from the source repository as set forth above, or based on previous source code The version and the previous version of the corresponding destination code determine the version status of each module part. In particular, the process determines which module parts have been modified, have not changed, are new, or have been deleted. In particular, the portion of the target module that has been deleted compared to the previous destination code module results in an empty memory space that is used in the updated destination code module to locate the added or modified target module portion. . In a subsequent sub-process 903, each identified module portion is processed to produce a corresponding target module portion. One embodiment of this sub-process will be explained in more detail below. In particular, sub-process 903 further receives information 907 about memory slots that have become available due to the deleted target module portion.

In a subsequent step 904, the generated destination module portions are combined into an updated destination code module. In some embodiments, the process positions the unaltered target module portion at the same memory location as in the previous version, further reducing the difference between the previous version and the updated version.

In step 905, the final size of the generated destination code module is compared with the size of the previous version of the corresponding destination code module (eg, obtained as a data 413 from a destination code repository 310 as described above), and optionally Any size limit/request comparison received from the linker. The process terminates if the generated updated destination code module satisfies the (equal) size limit condition. Otherwise, if the updated destination code module is too large, in particular larger than the previous version, the process splits the destination code module into two or more modules (step 906). An example of such a split has been described above with reference to Figures 7 and 8.

If the combining step 904 is compatible with the subsequent linker process and destination code format, it may be omitted as illustrated in Figure 9b.

Figure 9b shows a flow chart of an alternate embodiment of a destination code generation process. This process is similar to the process of Figure 9a. However, in this embodiment, the generated target module portions are not combined into a larger destination code module. Thus, the process results in the creation of several smaller entities that can be repositioned independently of each other by the linker, allowing the linker to have greater freedom in producing an optimized memory image. For example, it can be beneficial to delay the reuse of empty memory slots to link time, since the linker can implement an overall optimization for the entire software application rather than for a single source module.

Figure 10 is a flow chart showing an embodiment of the module portion generation sub-process 903 of Figures 9a and 9b. Sub-process 903 performs a loop on all identified module portions. For each module part, the process initially determines whether the module part has been modified during the update, whether the module part is a new module part introduced during the update, or whether the module part remains unresolved Update changes. If the module portion is unchanged, the process proceeds to step 1002; if the module portion is modified, the process proceeds to step 1003; and when the module portion is a new module portion, the process proceeds to Step 1007.

In step 1002, the process compiles the (equal) unaltered module portion. When the compiler uses the same compilation options, optimization steps, etc. as during the compilation of the previous version, the compilation results in an updated target module portion that is very similar or even identical to the previous version of the target module portion. Accordingly, the process can, for example, receive information from the repository 310 about compiling the previous version of the information or even the previous version of the destination code itself.

In step 1003, the process processes the modified target module portion. Specifically, the process compiles the modified target module portion to produce a modified destination code. If the size of the modified module portion has been reduced compared to the previous version, the remaining memory space can be filled with padding to provide a modified target module portion of the same size as the corresponding previous version. This padding can be achieved, for example, by leaving only the current memory content in the padded memory space.

In step 1004, the process determines if the size of the modified destination module portion has increased. If the size has not increased, the process continues to step 1009. Otherwise, the process continues at step 1005 where the module portion is split into two: one portion is installed in a predetermined memory slot and the other portion can be placed anywhere else during the subsequent chaining process. Thus, the process produces an overflow module portion that includes a second module portion (step 1006). It should be noted that splitting a target module portion (such as a function) may require the introduction of additional branch instructions. In one embodiment, the process implements a control flow analysis to determine if additional branch instructions can be avoided, and if not avoided, identify one or more suitable split points. For example, it is generally preferred to avoid the busy (ie, frequently executed) portions of the code, such as internal loops. To determine the appropriate split point, conventional control flow analysis techniques can be utilized. For example, Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman, "Compilers: Principles, Techniques and Tools" (Addison-Wesley, 1986), page 604, discloses an algorithm for detecting loops.

In step 1007, the process compiles a new module portion, that is, a portion of the module that was not present in the previous version but added during the update. In one embodiment, the process produces a portion of the target module that is limited in size so that any memory slot that is available, for example, to delete another portion of the module, is suitable for the available memory slot. One of the. If all of the portions are suitable for such a memory slot (step 1008), then the process continues to step 1009. Otherwise, the process continues at step 1006 where a portion of the module that is not suitable for the available memory slots is positioned in an overflow module portion.

Figures 11a-b show block diagrams of further embodiments of a software update process. In the embodiment of FIG. 11a, the update process is performed by a compiler module 1103 and a linker module 1106. In particular, as described herein, the compilation module 1103 receives the updated source code 1102 from a source repository 1101 and generates an updated destination code module 1105. Accordingly, the compiler further receives information 1104 containing one or more of the following: information about changes in source code changes, compiler information about previous versions of compiled source code, destination code information about previous destination codes, and the like. Based on the received information, the compiler generates an updated destination code module 1105 that is as similar as possible to the previous version of the destination code. The updated destination code is transferred to the linker 1106.

In the embodiment of FIG. 11b, the update process is performed by a compiler module 1113, a post-processing module 1123, and a linker module 1106. In this embodiment, the compiler 1113 can be a conventional compiler that receives the updated source code 1102 from the repository 1101 and generates an updated destination code 1115. Post processor 1123 receives destination code 1115 and additional information 1104 as described above. The post processor 1123 repositions the respective destination module portions into the destination code module generated by the compiler 1113 to minimize the difference between the updated destination code and the previous version of the destination code. Therefore, the post processor can rearrange the destination module portion, split the destination code module and/or the destination module portion, and generate the overflow destination code module as described herein, thereby producing the best feed to the linker 1106. The destination code module 1125 is updated.

One advantage of the embodiment of Figure 11b is that the post processor can be constructed as a separate software component that can be used in conjunction with conventional compilers and/or linkers. Therefore, this embodiment requires only a relatively small amount of software design, as it allows reuse of existing software development tools.

On the other hand, the embodiment of Figure 11a has the advantage that the compiler 1103 can perform additional optimization steps to further reduce the difference between the updated version of the object code and the previous version. For example, the compiler can be adapted to generate a destination code similar to the previous version of the destination code, for example, by using the same optimization techniques or the like.

Therefore, a method of integrating a compiler during the creation of a triangular differential update package has been described above. This avoids unnecessary changes by using a nearly uniform memory arrangement in subsequent versions of the software. Unlike linker and linker processors (such as triangular differential file generators), it is possible to give a compiler the ability to generate code and split the size of the module portion of its previous slot under size constraints.

It should be noted that the above embodiments are described herein primarily with reference to flash memory. However, it should be understood that the methods described herein can also be implemented in conjunction with other types of memory, including memory that can be written in smaller units (eg, byte-wise or even bitwise). Types of. Moreover, the methods described herein can also be combined with other storage media applications, such as optical disks, hard drives, floppy disks, magnetic tape, and/or other types of magnetic or optical storage media. For example, the methods described herein can also be applied to computer updates such as desktop computers, where the computer loads a program from a second memory/storage medium into RAM prior to executing the program.

The invention can be implemented by means of a hardware comprising a plurality of distinct components and a suitably programmed computer. In the device request for enumerating several components, one and the same item implementation number may be implemented by hardware (for example, a suitably programmed microprocessor or computer and one or more communication interfaces as described herein) One of these components. The mere fact that the particular method is recited in the <RTIgt;

It should be emphasized that the term "comprising", when used in this specification, is intended to mean the existence of the specified feature, integer, step or component, and does not exclude one or more other features, integers, steps, components or groups thereof Exist or add.

101. . . Mobile terminal

102. . . Software update system

103. . . Communication interface

104. . . Interface circuit

105. . . Processing unit

106. . . Version repository/repository

210. . . Communication block

211. . . Processing unit

212. . . Memory unit

301. . . Source repository

302. . . Source module

303. . . translater

304. . . Change information

305. . . Destination code module

306. . . Chain cutter

307. . . Absolute File/Executable/Linker Output/Binary (Updated) Image

308. . . Triangular differential file generation module

309. . . Triangular differential file

310. . . Repository

412. . . Compilation information

413. . . Compilation information

514. . . Feedback information

615. . . Change information

616. . . News

617. . . Data flow arrow

701. . . Address space

702. . . Code version V1

703. . . Updated version V2

704. . . Optimized memory placement

705. . . Additional memory space

801. . . Source module "A.c"

802. . . Destination code module "A.o"

803. . . Source module "A.c"

804. . . Updated destination code module "A' ₁ .o"

805. . . "Overflow" destination code module "A' ₂ .o"

1101. . . Source repository

1102. . . Updated source

1103. . . Compilation module

1104. . . News

1105. . . Updated destination code module

1106. . . Link module

1113. . . Compilation module

1115. . . Destination code

1123. . . Post processing module

1125. . . Optimized destination code module

The above and other aspects of the present invention will be more apparent and apparent from the embodiments described herein with reference to the accompanying drawings in which: FIG. 1 schematically shows an embodiment of a system for updating software in a mobile terminal. Figure 2 is a block diagram showing an electronic device (e.g., a mobile terminal); Figure 3 is a block diagram showing an embodiment of a software update process; and Figure 4 is a block diagram showing another embodiment of a software update process. FIG. 5 is a block diagram showing still another embodiment of a software update process; FIG. 6 is a block diagram showing still another embodiment of a software update process; and FIG. 7 is a schematic diagram illustrating a flash memory in software. The memory arrangement before and after the update, wherein the step is optimized by introducing an overflow block.

Figure 8 is a schematic diagram illustrating the generation of a destination code module that facilitates the linker to make an optimal memory arrangement; Figure 9 shows a flow diagram of an embodiment of a destination code generation process; Figure 10 shows the destination mode of Figure 9. The group portion produces a flowchart of one embodiment of a sub-process; Figures 11a-b show block diagrams of another embodiment of a software update process.

301. . . Source repository

302. . . Source module

303. . . translater

304. . . Change information

305. . . Destination code module

306. . . Chain cutter

307. . . Absolute File/Executable/Linker Output/Binary (Updated) Image

308. . . Triangular differential file generation module

309. . . Triangular differential file

310. . . Repository

412. . . Compilation information

413. . . Compilation information

514. . . Feedback information

615. . . Change information

616. . . News

617. . . Data flow arrow

Claims (23)

An method for generating an updated object code of a computer program, the updated object code being suitable as an input to an linker component for generating an updated memory image to be loaded into a storage medium The storage medium has stored a current memory image corresponding to the current version of the computer program, the method comprising: - receiving at least one updated input code module, generating an updated destination code therefrom; - processing at least the Updating the input code module to generate at least one updated destination code module adapted to be linked by the linker component to generate the updated memory image; and - performing at least one optimization process to reduce the Updating a difference between the destination code module and a corresponding one of the current destination code modules, the current destination code module corresponding to the current version of the computer program, wherein the updated destination code module is fed Performing the optimization process before the linker component, and wherein the updated input code module is at least one updated by at least one corresponding source code from a compiler (compliler) (source code) The preliminary object module generated in the module. The method of claim 1, wherein the at least one updated input code module is at least one updated source code module, and wherein the method further comprises the step of compiling the updated source code module. The method of claim 1, further comprising receiving control from the linker component The steps to make data. The method of claim 3, wherein the control data includes a size limit condition for the size of the updated destination code module. The method of claim 1, further comprising the step of receiving the current destination code module of the group. The method of claim 1, further comprising the step of receiving change information indicating a difference between the at least one updated input code module and the at least one corresponding current input code module, the at least one current input code module and the The current destination code module of the group corresponds. The method of claim 1, further comprising the step of receiving processing information regarding a previous processing step, the processing step generating the set of current destination code modules from the at least one corresponding current input code module. The method of claim 7, wherein the processing information includes at least one of current placement information and compiler information about a previous compilation step, the current placement information indicating one of the current destination code modules One of the module parts of the group is currently arranged. The method of claim 8, wherein the compiler information includes at least one source-to-machine code map and information indicating which compiler optimization steps are applied during the previous compilation step. The method of claim 1, further comprising the step of storing updated processing information relating to the processing step for generating the updated destination code module for use in a subsequent processing step. The method of claim 10, wherein the updated processing information includes at least one of arrangement information and compiler information about a compilation step, wherein The placement information indicates an arrangement of a set of destination module portions in the updated destination code module. The method of claim 11, wherein the compiler information includes at least one source-to-machine code map and information indicating which compiler optimization steps are applied during the compiling step. The method of claim 1, wherein the updated destination code module comprises a plurality of destination module portions. The method of claim 13, wherein each of the target module portions is repositionable in a memory image to reposition the entity. The method of claim 13, wherein each of the target module portions comprises at least one of a function definition, a program definition, a class definition, a constant definition, and a variable definition. The method of claim 13, wherein the optimizing step comprises determining an order of the ones of the target module portions in the updated destination code module. The method of claim 13, wherein the optimizing step further comprises: placing at least one of the target module portions not included in one of the current destination code modules corresponding to a first updated destination code module And in the second updated destination code module different from the first updated destination code module, to reduce a difference between the first updated destination code module and the corresponding current destination code module. The method of claim 1, further comprising feeding at least the updated destination code module to a linker component for linking at least the updated destination code module to generate a delta differential (delta) The updated memory image that is subsequently processed by the file generator. The method of claim 1, wherein the computer program is adapted to be executed by a mobile terminal. A data processing system for generating an updated destination code of a computer program, the updated destination code being suitable for input as an linker component for generating an updated memory image to be loaded into a memory. One of the current memory images corresponding to the current version of one of the computer programs is stored in the memory, and the data processing system is appropriately programmed to perform the steps of the method of claim 1. A non-transitory computer program product comprising a code component, the code component being adapted to cause the data processing system to perform the method of claim 1 when the code component is executed on a data processing system . The non-transitory computer program product of claim 21, wherein the computer program product comprises a compiler. The non-transitory computer program product of claim 21, wherein the computer program product comprises a post processor of a compiler, the post processor being adapted to receive the destination code generated by the compiler and to generate a feed to a link The modified destination code in the component.