KR102150386B1 - Electronic device, a method of compiling in an electronic device and a method of operating an electronic device - Google Patents

Abstract

The electronic device includes a compiler, a runtime module, and a memory subsystem. The compiler compiles source codes related to execution of an application into an intermediate expression, generates a target code based on the intermediate expression, and based on profiling information including context information of each of one or more objects related to the application. A performance cost when allocating memory for each of the one or more objects is calculated. The runtime module executes the application based on the target code. The memory subsystem is connected to the compiler and includes a first memory device and a second memory device having different data retention characteristics. The compiler allocates each of the one or more objects to one of the first memory device and the second memory device based on the performance cost of each of the one or more objects.

Description

Electronic device, a method of compiling in an electronic device, and a method of operating an electronic device

The present invention relates to the field of computing, and more particularly, to an electronic device, a method of compiling an electronic device, and a method of operating the electronic device.

Two methods commonly used for compiling a programming language are AOTC (Ahead-of Time Compilation) and JITC (Just-in-Time Compilation).

In JITC, which is mainly used in dynamic programming languages such as JavaScript, compilation into machine code (or machine language) is performed while executing a program. It divides the source code into specific units (mainly, function units), and compiles and executes the code at the first call. The compiled machine code is cached and reused when the same part is called again. Thus, the programmer provides a high-level source code, and the program user executes the compilation in the JITC method every time the program is executed.

The JITC method has two main advantages. First, JITC can use program analysis information that can only be obtained at runtime, that is, because compilation proceeds during program execution. For example, when executing a JavaScript program, the exact type of the function argument is information that can be obtained only when the function is called. With these advantages, JITC is suitable for dynamic languages such as JavaScript. The second is that the size of the code area among the memory areas can be reduced because only the code called at runtime is compiled. In other words, JITC does not load the parts of the source code that are not actually executed into memory. However, since program analysis and compilation are performed during execution, additional memory and power consumption may increase.

Meanwhile, the AOTC method, which is mainly used for compiling static programming languages such as C, compiles the entire source code of a program before execution (of a program) and provides it to the program user in the form of a machine code. The biggest advantage of AOTC is that it shows higher performance compared to JITC in terms of execution time because it does not compile source codes during runtime.

Accordingly, an object of the present invention relates to an electronic device that performs memory allocation to different types of memory devices without modifying an application.

An object of the present invention is to provide a method for compiling an electronic device that allocates memory to different types of memory devices without modifying an application.

An object of the present invention is to provide a method of operating an electronic device in which memory allocation is performed to different types of memory devices without modifying an application.

An electronic device according to an embodiment of the present invention for achieving the above object includes a compiler, a runtime module, and a memory subsystem. The compiler compiles source codes related to execution of an application into an intermediate expression, generates a target code based on the intermediate expression, and based on profiling information including context information of each of one or more objects related to the application. A performance cost when allocating memory for each of the one or more objects is calculated. The runtime module executes the application based on the target code. The memory subsystem is connected to the compiler and includes a first memory device and a second memory device having different data retention characteristics. The compiler allocates each of the one or more objects to one of the first memory device and the second memory device based on the performance cost of each of the one or more objects.

In an embodiment, the compiler may include a front-end module, an optimization module, and a back-end module. The front-end module may compile the source code into an initial intermediate expression. The optimization module may receive the initial intermediate expression, optimize the initial intermediate expression, compile it into a final intermediate expression, and calculate the performance cost based on the profiling information. The backend module may generate the target code based on the final intermediate expression.

The profiling information includes information on the size of the memory to which each of the one or more objects is allocated and information on the number of loads/stores based on the context information including information related to a call path and a loop of a function called when the application is executed. Can include.

The optimization module may calculate the performance cost based on the performance of the application when the memory is allocated to each of the one or more objects based on the profiling information.

The optimization module may perform the memory allocation for each of the one or more objects based on the performance cost so as not to degrade the performance of the application.

The optimization module may include one or more pass modules, and each of the one or more pass modules may include an allocation history recording module, a reference history recording module, and a release history recording module. When a memory allocation request is called for each of the one or more objects, the allocation history recording module includes a first time stamp related to the time point of the memory allocation request, an identifier of an object related to the memory allocation request, and an address of the allocated memory. And information on the size of the allocated memory may be recorded/stored. When a load/store reference occurs in the application with respect to the memory area to which the object is allocated, the reference history recording module includes a second time stamp related to the time when the reference is made to the object, identifier information of the object, and the reference It is possible to record/store the type of and the number of times the reference to the object occurs. When the use of the object is completed, the release history recording module releases the allocation of the memory area allocated to the object, a third time stamp related to the time of the memory allocation release request, and identifier information of the object that releases the allocation And information on the size of the memory from which the allocation has been released may be recorded/stored.

Each of the one or more pass modules further includes a profiling information generation module storing information stored in the allocation history recording module, the reference history recording module, and the dismantling history recording module as separate files, and providing the profiling information as the profiling information. Can include.

When the application calls a memory allocation function, each of the one or more pass modules estimates the performance cost when allocating the memory of each of the one or more objects based on the profiling information, and calculates the performance cost. A memory type to be allocated for all of the objects allocated to the entire application and for which allocation is requested is determined based on the determined memory type, and each of the one or more objects is assigned to the first memory device and the second memory device according to the determined memory type. Can be assigned to either.

Each of the one or more pass modules may rearrange an object previously allocated based on the performance cost to a different type of memory device.

When the application calls the memory release function, each of the one or more pass modules releases the memory allocation of the object for which the memory release is requested, and calculates the performance cost of the currently allocated objects based on the profiling information. It is possible to estimate and determine the relocation of the currently allocated objects based on the re-estimated performance cost.

Each of the one or more pass modules may improve performance of the application by rearranging the currently allocated objects based on the re-estimated performance cost.

In an embodiment, the first memory device is a volatile memory device, the second memory device is a nonvolatile memory device, and the compiler is a memory connected to the optimization module, the first memory device, and the second memory device. It may further include an interface.

The first memory device may be a DRAM and the second memory device may be a phase change memory device.

In the compiling method of an electronic device that executes an application according to embodiments of the present invention for achieving the above object, context information related to execution of the application is recognized, and source code related to execution of the application is first intermediate A first memory device having different data retention characteristics for each of the one or more objects based on a performance cost when compiling into an expression and allocating memory for each of the one or more objects related to the application based on the context information, and While allocating to one of the second memory devices, the first intermediate expression is compiled into a final intermediate expression, and a target code to execute the application is generated based on the final intermediate expression.

In a method of operating an electronic device according to embodiments of the present invention for achieving the above object, while compiling a source code related to execution of an application into an intermediate expression, context information of each of one or more objects related to the application is included. A first memory device and a second memory device having different data retention characteristics for calculating a performance cost when allocating memory of each of the one or more objects based on profiling information, and each of the one or more objects based on the performance cost Allocates to one of the memory devices and executes the application according to the target code generated based on the intermediate expression.

In an embodiment, the first memory device may be a volatile memory device, and the second memory device may be a nonvolatile memory device. The first memory device may be a DRAM and the second memory device may be a phase change memory device.

According to exemplary embodiments of the present invention, each of one or more objects used or generated during the compilation process of an application is one based on profiling information including context information related to at least one of a function call and a loop. A system that uses different types of memories by calculating a performance cost when allocating memory of each of the above objects and allocating each of the one or more objects to a first memory device and a second memory device according to the calculated performance cost You can increase performance by performing memory allocation without modifying the application.

1 is a block diagram illustrating an electronic device according to embodiments of the present invention.
2 is a block diagram showing the configuration of an optimization module in the compiler of FIG. 1 according to embodiments of the present invention.
3 is a block diagram showing the configuration of one pass module in the optimization module of FIG. 2 according to embodiments of the present invention.
4 is a table showing contents that may be included in the profiling information of FIG. 3.
5 is a block diagram illustrating a memory interface in the compiler of FIG. 1 according to embodiments of the present invention.
6 is a block diagram illustrating a configuration of a runtime module in the electronic device of FIG. 1 according to embodiments of the present invention.
7 is a flowchart illustrating an operation of a compiler when the application of FIG. 1 calls a memory allocation function and a memory release function.
8 is a flowchart illustrating an operation of a compiler when the application of FIG. 1 calls a memory allocation function.
9 is a flowchart illustrating an operation of a compiler when the application of FIG. 1 calls a memory release function.
10 is a block diagram illustrating a first memory device in the memory subsystem of FIG. 1 according to example embodiments.
11 is a block diagram illustrating a second memory device in the memory subsystem of FIG. 1 according to example embodiments.
12 is a flowchart illustrating a method of compiling an electronic device according to embodiments of the present invention.
13 is a flowchart illustrating a method of operating an electronic device according to example embodiments.

With respect to the embodiments of the present invention disclosed in the text, specific structural or functional descriptions have been exemplified only for the purpose of describing the embodiments of the present invention, and the embodiments of the present invention may be implemented in various forms. It should not be construed as being limited to the embodiments described in.

In the present invention, various modifications may be made and various forms may be applied, and specific embodiments will be illustrated in the drawings and described in detail in the text. However, this is not intended to limit the present invention to a specific form disclosed, it should be understood to include all changes, equivalents, and substitutes included in the spirit and scope of the present invention. In describing each drawing, similar reference numerals have been used for components.

Terms such as first and second may be used to describe various elements, but the elements should not be limited by the terms. These terms are used only for the purpose of distinguishing one component from another component. For example, without departing from the scope of the present invention, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element.

When a component is referred to as being "connected" or "connected" to another component, it is understood that it may be directly connected or connected to the other component, but other components may exist in the middle. Should be. On the other hand, when a component is referred to as being "directly connected" or "directly connected" to another component, it should be understood that there is no other component in the middle.

The terms used in the present application are only used to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In the present application, terms such as "comprise" or "have" are intended to designate the presence of a set feature, number, step, action, component, part, or combination thereof, and one or more other features or numbers It is to be understood that the possibility of addition or presence of, steps, actions, components, parts, or combinations thereof is not preliminarily excluded.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs. Terms as defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in this application. Does not.

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. The same reference numerals are used for the same elements in the drawings, and duplicate descriptions for the same elements are omitted.

1 is a block diagram illustrating an electronic device according to embodiments of the present invention.

Referring to FIG. 1, an electronic device (or user terminal) 10 may include a compiler 100, a runtime module 300, and a memory subsystem 350.

The compiler 100 compiles the source code (SCD) related to the execution of the application 20 into an intermediate expression, generates a target code (TCD) based on the intermediate expression, and converts the target code (TCD) into a runtime module ( 300) can be provided.

The compiler 100 also includes one or more objects based on profiling information (OUPI) including context information of each of the one or more objects 31, 33, 35, 35, 37 related to the application 20. 31, 33, 35, 37) calculates a performance cost when allocating memory, and assigns each of the one or more objects 31, 33, 35, 37 to the first of the memory subsystem 350 based on the performance cost. It may be allocated to one of the memory device 400 and the second memory device 500.

The runtime module 300 may receive the target code TCD and execute the application 20 based on the target code TCD.

The memory subsystem 350 may include a first memory device 400 and a second memory device 500.

The first memory device 400 is a volatile memory device and may be a DRAM. The second memory device 500 is a nonvolatile memory device and may be a phase change memory device. The configuration and operation of each of the first and second memory devices 400 and 500 will be described in detail with reference to FIGS. 10 and 11.

The compiler 100 may include a frontend module 110, an optimization module 200 and a backend module 170. The compiler 100 may also include a memory interface 190.

The frontend module 110 compiles the source code (SCD) into an initial intermediate representation (IIR). The optimization module 200 compiles the initial intermediate expression (IIR) into a final intermediate expression (OIR), and performs performance of each of the one or more objects 31, 33, 35, 35, 37 based on the profiling information (OUPI). A cost is calculated, and each of the one or more objects 31, 33, 35, 35, and 37 is allocated to one of the first memory device 400 and the second memory device 500 based on the performance cost.

The profiling information (OUPI) is the one or more objects (31, 33, 35, 35, 37) based on context information including information related to a call path and loop of a function called when the application 20 is executed. Each may include information on the size of the allocated memory and information on the number of times of loading/storing.

The optimization module 200 calculates the performance cost based on the performance of the application 20 when allocating the memory of the one or more objects 31, 33, 35, 35, 37 based on the profiling information (OUPI) can do. That is, the optimization module 200 may calculate a high performance cost in proportion to the performance degradation of the application during memory allocation. The optimization module may perform the memory allocation so that the performance cost is reduced.

The backend module 170 may generate a target code TCD based on the final intermediate expression OIR, and may provide the generated target code TCD to the runtime module 300.

The memory interface 190 is connected to the optimization module 200 and is connected to the first memory device 400 and the second memory device 500 so that each of the one or more objects 31, 33, 35, and 37 It may be provided to one of the memory device 400 and the second memory device 500. The memory interface 190 may be connected to the first memory device 400 through a first path 181 and may be connected to the second memory device 500 through a second path 183.

The compiler 100 may have a compiler infrastructure such as LLVM (http://llvm.org/). The compiler 100 receives an application source code (SCD) written in a language such as C or C++.

The front-end module 110 changes the source code (SCD) to an intermediate code that the compiler 100 can understand. The intermediate code may be referred to as an intermediate representation (IR).

The backend module 170 compiles the final intermediate expression (OIR) to generate a target code (or executable code, TCD) of a binary executable in the runtime module 300.

2 is a block diagram showing the configuration of an optimization module in the compiler of FIG. 1 according to embodiments of the present invention.

Referring to FIG. 2, the optimization module 200 may include one or more pass modules 210 and 260.

In FIG. 2, a case where the optimization module 200 includes two pass modules 210 and 260 has been described, but the number of pass modules can be changed by a programmer.

The pass module 210 optimizes the initial intermediate expression (IIR) to generate a first intermediate expression (IR1), and the pass module 260 optimizes the first intermediate expression (IR1) to obtain a final intermediate expression. Generate the representation (OIR).

At least one of the one or more pass modules 210 and 260 may perform memory allocation for each of the one or more objects 31, 33, 35, 35, and 37 by calculating the above-described performance cost.

3 is a block diagram showing the configuration of one pass module in the optimization module of FIG. 2 according to embodiments of the present invention.

Referring to FIG. 3, the pass module 210 may include an allocation history recording module 220, a reference history recording module 230, a release history recording module 240, and a profile information generation module 245.

When a memory allocation request is called for each of the one or more objects 31, 33, 35, 35, 37, the allocation history recording module 220 includes a first time stamp TP1 related to the time point of the memory allocation request, The object identifier OID1, the allocated memory address ADDR1, and the allocated memory size information SZ11 related to the memory allocation request may be recorded/stored.

When a load/store reference occurs in the application 20 with respect to the memory area allocated to the object, the reference history recording module 230 performs a second time stamp (TP2) related to the time when the reference occurs to the object. ), the object identifier information (OID2), the type of reference (RT), and the number of times the reference to the object occurs (RN) may be recorded/stored.

When the use of the object is completed, the release history recording module 240 releases the allocation of the memory area allocated to the object, and releases a third time stamp (TP3) related to the time of the memory allocation release request, and releases the allocation. The object identifier information (OID3) and the allocated memory size information (SZ31) may be recorded/stored.

The profiling information generation module 245 stores information stored in each of the allocation history recording module 220, the reference history recording module 230, and the release history recording module 240 as separate files, and profils the stored information. It can be provided as information (OUPI).

4 is a table showing contents that may be included in the profiling information of FIG. 3.

Referring to FIG. 4, one or more objects 31, 33, 35, and 37 may each receive different identifier information OID11, OID12, OID13, and OID14 according to context information.

The object 31 may have the allocated memory size information SZ1 and the number of load/store times LD/ST_N1 as profiling information OUPI. The object 32 may have memory size information (SZ2) to be allocated and the number of load/store times (LD/ST_N2) as profiling information (OUPI). The object 35 may have memory size information SZ3 to be allocated and the number of times of load/storage (LD/ST_N3) as profiling information (OUPI). The object 37 may have the allocated memory size information SZ4 and the number of load/store times LD/ST_N4 as profiling information OUPI.

5 is a block diagram illustrating a memory interface in the compiler of FIG. 1 according to embodiments of the present invention.

Referring to FIG. 5, the memory interface 190 may include a first library 191 and a second library 193.

The first library 191 may be a glibc library that processes a request for the first memory device 400, or may be a library function that processes an allocation for the first memory device 400.

The second library 193 may be a pmem library that processes a request for the first memory device 500 or a library function that processes allocation for the second memory device 500.

6 is a block diagram illustrating a configuration of a runtime module in the electronic device of FIG. 1 according to embodiments of the present invention.

Referring to FIG. 6, the runtime module 300 may include a device monitor 310, a scheduler 320, and a compiler runtime module 330. The runtime module 300 may optionally further include an additional API module 340 at an operation system (OS) level or an OpenCL driver module 350 for driving a GPU.

The scheduler 320 uses the device monitor 310 as a service type of the system software to check the status of the computing devices included in the electronic device 10 before executing the target code (TCD), and uses the device monitor 310 as a service type of the system software to compile the status information of the computing devices. It can communicate with the runtime module 330.

The scheduler 320 determines an efficient workload value to be allocated to the computing devices by using the state information, and drives the target code TCD to the computing devices according to the determined workload.

The compiler runtime module 330 provides a compiler runtime library. The compiler runtime library closely interlocks with the compiler 100 so that the scheduler 320 can drive the target code TCD of the application 20.

7 is a flowchart illustrating an operation of a compiler when the application of FIG. 1 calls a memory allocation function and a memory release function.

1 to 5 and 7, when the application 20 of FIG. 1 calls the memory allocation function, the pass module 210 of FIG. 2 is configured to determine the one or more based on profiling information (OUPI). Estimating (calculating) the performance cost at the time of allocating the memory of each of the objects 31, 33, 35, 37 (S110), allocated to the entire application 20 based on the performance cost, and requested the allocation A memory type to be allocated to all of the objects is determined (S120), and each of the one or more objects 31, 33, 35, 37 is assigned to the first memory device 400 and the first memory type according to the determined memory type. 2 It is allocated to one of the memory devices 500 (S130).

According to an exemplary embodiment, the pass module 210 may rearrange an object allocated in advance based on the performance cost to another type of memory device.

8 is a flowchart illustrating an operation of a compiler when the application of FIG. 1 calls a memory allocation function.

Referring to FIGS. 1 to 5 and 8, when the application 20 of FIG. 1 calls a memory allocation function, the pass module 210 of FIG. 2 includes the one or more values based on profiling information (OUPI). Estimating (calculating) the performance cost at the time of allocating the memory of each of the objects 31, 33, 35, 37 (S210), allocated to the entire application 20 based on the performance cost, and requested the allocation A memory type to be allocated to all of the objects is determined (S220), and each of the one or more objects 31, 33, 35, 37 is assigned to the first memory device 400 and the first memory type according to the determined memory type. 2 It is allocated to one of the memory devices 500 (S240). According to an embodiment, the pass module 210 may rearrange the object allocated in advance based on the performance cost to another type of memory device (S230).

9 is a flowchart illustrating an operation of a compiler when the application of FIG. 1 calls a memory release function.

1 to 5 and 9, when the application 20 of FIG. 1 calls the memory release function, the pass module 210 of FIG. 2 releases the memory allocation of the object for which memory release is requested ( S310), the performance cost of currently allocated objects is reestimated (calculated) based on profiling information (OUPI) (S320), and the arrangement of the currently allocated objects may be determined based on the recalculated performance cost. Yes (S330). According to an embodiment, the pass module 210 may improve the performance of the application 20 by rearranging the currently allocated objects based on the recalculated performance cost (S340).

10 is a block diagram illustrating a first memory device in the memory subsystem of FIG. 1 according to example embodiments.

In FIG. 10, it is assumed that the first memory device 400 is implemented as a DRAM.

Referring to FIG. 10, a first memory device 400 implemented as a DRAM includes a command/address input buffer 410, a control logic circuit 420, bank control logics 430A to 430D, and memory cell arrays 440A to 440D. ), write driver and data input/output sense amplifier units 450A to 450D, ECC engines 460A to 460D, input/output data buffer 470, and input/output circuit 480.

The memory cell arrays 440A to 440D may include first to fourth bank arrays 440A to 440D in which a plurality of memory cells are arranged in rows and columns. A row decoder and a column decoder for selecting word lines and bit lines connected to memory cells may be connected to each of the first to fourth bank arrays 440A to 440D.

The command/address input buffer 410 may receive a clock signal CLK, a command CMD, and an address ADDR received from the outside. The command CMD and the address ADDR may be input through the same terminals, so-called CA pads. Command CMD and address ADDR may be sequentially input through CA pads.

The control logic circuit 420 may receive a command CMD and an address ADDR received through the command/address input buffer 410 and generate an internal command ICMD and an address signal. The internal command ICMD may include an internal read command and an internal write command. The address signal may include a bank address BA, a row address RA, and a column address CA. The internal command ICMD and the address signals BA/RA/CA may be provided to the bank control logics 430A to 430D. That is, the control logic circuit 420 may control access to the memory cell arrays 440A to 440D.

The control logic circuit 420 may include a command decoder 421 and a mode register 422. The command decoder 421 may decode the command CMD to generate an internal command ICMD, and the mode register 222 may generate an internal command ICMD of the first memory device 400 based on the command CMD and the address ADDR. You can set the operation mode.

Each of the bank control logics 430A to 430D may be activated corresponding to the bank address BA. The activated bank control logics 430A to 430D may generate bank control signals in response to an internal command ICMD, a row address RA, and a column address CA. In response to the bank control signal, a row decoder and a column decoder of the first to fourth bank arrays 440A to 440D connected to the activated bank control logics 430A to 430D may be activated.

The row decoder of the first to fourth bank arrays 440A to 440D may enable a word line corresponding to the row address RA by decoding the row address RA. The column addresses CA of the first to fourth bank arrays 440A to 440D may be temporarily stored in the column address latch. The column address latch may gradually increase the column address CA in the burst mode. The temporarily stored or gradually increased column address CA may be provided to the column decoder. The column decoder may decode the column address CA to activate the column selection signal CSL corresponding to the column address CA.

Each of the bank control logics 430A to 430D is an ECC encoding signal that controls the operation of the ECC engines 460A to 460D connected to the first to fourth bank arrays 440A to 440D in response to the bank control signal ( ENC) and ECC decoding signal (DEC) can be generated.

The write driver and data input/output sense amplifier units 450A to 450D sense and amplify the read data DTA output from each of the first to fourth bank arrays 440A to 440D, and the first to fourth bank arrays ( Write data DTA to be stored in each of 440A to 440D may be delivered.

During the write operation, the ECC engines 460A to 460D store in each of the first to fourth bank arrays 440A to 440D in response to the ECC encoding signal ENC output from the bank control logics 430A to 430D. Parity bits may be generated by performing an ECC encoding operation on the to-be-write data DTA.

During the read operation, the ECC engines 460A to 460D read from each of the first to fourth bank arrays 440A to 440D in response to the ECC decoding signal DEC output from the bank control logics 430A to 430D. An ECC decoding operation may be performed using the data DTA and parity bits to detect/correct an error bit generated in the read data.

The input/output data buffer 470 includes circuits for gating data DTA input/output to/from the first to fourth bank arrays 440A to 440D, and the first to fourth bank arrays 440A to 440D. It may include read data latches for storing the data output from and write data latches for writing data to the first to fourth bank arrays 440A to 440D.

The input/output data buffer 470 may convert parallel data bits output from the first to fourth bank arrays 440A to 440D into serial data bits through read data latches. The input/output data buffer 470 may convert serially received write data into parallel data bits using a write data latch.

The input/output circuit 480 may receive serial data bits output from the input/output data buffer 470, sequentially arrange data bits DQs corresponding to the burst length, and output them to data input/output pads. The input/output circuit 480 may provide serially received write data having a burst length to the input/output data buffer 470.

11 is a block diagram illustrating a second memory device in the memory subsystem of FIG. 1 according to example embodiments.

In FIG. 11, it is assumed that the second memory device 500 is implemented as a phase change memory device.

Referring to FIG. 11, a second memory device 500 implemented as a phase change memory device may include a memory cell array 510, a write/read circuit 540, and a control circuit 550. Further, the second memory device 500 may further include a row decoder 510, a column decoder 530, a voltage generator 570, and a reference signal generator 560. Also, the write/read circuit 540 may include a write driver 541, a sense amplifier 542, a write buffer 543, a page buffer 544, and a verify circuit 545.

Memory cells included in the memory cell array 510 may be connected to word lines WL and bit lines BL. As various voltage signals or current signals are provided through the bit lines BL and the word lines WL, data is written or read for selected memory cells, and writing or reading is performed for the remaining non-selected memory cells. Can be prevented.

An address (or an access address, ADDR) for indicating a memory cell to be accessed may be received along with the command CMD, and the address ADDR selects the word lines WL of the memory cell array 510 A row address R_ADDR for selection and a column address C_ADDR for selecting bit lines BL of the memory cell array 510 may be included. The row decoder 220 performs a word line selection operation in response to the row address R_ADDR, and the column decoder 230 performs a bit line selection operation in response to the column address C_ADDR.

The write/read circuit 540 may be connected to the bit lines BL to write data to or read data from the memory cell. For example, the set voltage VST or the reset voltage VRST from the voltage generator 570 may be provided to the selected memory cell, and in the read operation, the read voltage VRD from the voltage generator 570 is selected to the selected memory cell. Can be provided. The write/read circuit 540 may provide a write voltage or a write current according to data to the memory cell array 510 through the column decoder 530. In addition, during the data read operation, the write/read circuit 540 includes a comparison unit connected to a node (eg, a sensing node) of the bit line BL to determine data, and the sensing voltage or sensing current of the sensing node The data value can be read through the comparison operation on. As the reference voltage VREF and/or the reference current IRF are provided to the write/read circuit 400, they may be used for a data read operation.

The write/read circuit 540 may provide the control circuit 550 with a pass/fail signal P/F indicating whether the write attempt is successful in the read result of the read data. The control circuit 550 may control write and read operations of the memory cell array 510 by referring to the pass/fail signals P/F.

The control circuit 550 includes a plurality of control signals CTL1 to CTL3 based on a command CMD, an address ADDR, a control signal CTRL, and a pass/fail signal P/F received from an external device. ) Can be created. The control circuit 550 provides the first control signal CTL1 to the voltage generator 570, applies the second control signal CTL2 to the reference signal generator 560, and writes the third control signal CTL3. / Can be applied to the read circuit 540.

The memory cell array 510 may include a plurality of memory cells (not shown) disposed in regions where a plurality of first signal lines and a plurality of second signal lines cross each other. Each of the plurality of memory cells may be a single level cell (SLC) that stores one bit, or may be a multi-level cell (MLC) capable of storing at least two bits or more of data. .

Alternatively, the memory cell array 510 may include both single-level cells and multi-level cells. When one bit of data is written to one memory cell, the memory cells may have two resistance level distributions according to the written data. Alternatively, when two bits of data are written to one memory cell, the memory cells may have four resistance level distributions according to the written data. In another embodiment, in the case of a triple level cell (TLC) in which three bits of data are stored in one memory cell, the memory cells may have eight resistance level distributions according to the written data.

In an embodiment, the memory cell array 510 may include memory cells having a two-dimensional horizontal structure. In another embodiment, the memory cell array 510 may include memory cells having a three-dimensional vertical structure.

Meanwhile, the memory cell array 210 may include resistive memory cells or resistive memory cells including a variable resistance element (not shown). For example, when the variable resistance element is a phase change material (GST, Ge-Sb-Te) whose resistance changes according to temperature, the resistive memory device may be a PRAM. For another example, when the variable resistance element is formed of an upper electrode, a lower electrode, and a complex metal oxide interposed therebetween, the resistive memory device may be an RRAM. For another example, when the variable resistance element is formed of an upper electrode of a magnetic material, a lower electrode of the magnetic material, and a dielectric material therebetween, the resistive memory device may be an MRAM.

12 is a flowchart illustrating a method of compiling an electronic device according to embodiments of the present invention.

1 to 9 and 12, in the method of compiling the electronic device 10 that executes the application 20 according to the embodiments of the present invention, the compiler 100 is related to the execution of the application 20. Recognize context information (S410). The front-end module 110 of the compiler 100 compiles the source code (SCD) related to the execution of the application 20 related to the execution of the application 20 to the earliest intermediate expression (IIR) (S420).

One or more objects based on the performance cost when the optimization module 200 of the compiler 100 allocates memory of each of the one or more objects 31, 33, 35, and 37 related to the application 20 based on context information. Assigning each (31, 33, 35, 37) to one of the first memory device 400 and the second memory device 500 having different data retention characteristics, and assigning the first intermediate expression (IIR) to the final intermediate expression ( OIR) is compiled (S430).

The backend module 170 of the compiler 100 generates a target code (TCD) to execute the application 20 on the basis of the final intermediate expression (OIR) (S440) and transfers the generated target code (TCD) to the runtime module 300 ).

13 is a flowchart illustrating a method of operating an electronic device according to example embodiments.

1 to 9 and 13, in the operating method of the electronic device 10 according to the embodiments of the present invention, the compiler 100 intermediates the source code (SCD) related to the execution of the application 20. While compiling to an expression, one or more objects related to the application 20, one or more objects based on profiling information (OUPI) including context information of each of the one or more objects 31, 33, 35, 37 The performance cost of allocating memory for each of the objects 31, 33, 35, and 37 is calculated (S510).

One of the first memory device 400 and the second memory device 500 having different data retention characteristics for each of the one or more objects 31, 33, 35, and 37 by the compiler 100 based on the performance cost. Allocate to (S520).

The runtime module 300 of the electronic device 10 executes the application 20 according to the target code TCD generated based on the intermediate expression (S530).

According to embodiments of the present invention, each of the one or more objects used or generated in the compilation process of the application is one or more objects based on profiling information including context information related to at least one of a function call and a loop. In a system that uses different types of memories, an application in a system using different types of memories is performed by calculating a performance cost when allocating memory of each of the two objects and allocating each of the one or more objects to a first memory device and a second memory device according to the calculated performance cost. You can increase performance by performing memory allocation without modifying.

The present invention can be used in a system that uses different memories, such as cloud computing.

Although the above has been described with reference to embodiments of the present invention, those of ordinary skill in the art will variously modify and change the present invention within the scope not departing from the spirit and scope of the present invention described in the following claims. You will understand that you can.

Claims (16)

Compiling a source code related to execution of an application into an intermediate expression, generating a target code based on the intermediate expression, and the at least one based on profiling information including context information of each of the one or more objects related to the application A compiler that calculates a performance cost when allocating memory for each of the objects;
A runtime module executing the application based on the target code; And
A memory subsystem connected to the compiler and including a first memory device and a second memory device having different data retention characteristics,
The compiler allocates each of the one or more objects to one of the first memory device and the second memory device based on the performance cost of each of the one or more objects,
The above compiler,
A frontend module that compiles the source code into an initial intermediate expression;
An optimization module for receiving the initial intermediate expression, optimizing the initial intermediate expression, compiling into a final intermediate expression, and calculating the performance cost based on the profiling information; And
And a backend module that generates the target code based on the final intermediate expression,
The profiling information includes information on the size of the memory to which each of the one or more objects is allocated and information on the number of loads/stores based on the context information including information related to a call path and a loop of a function called when the application is executed. Electronic device comprising. delete delete The method of claim 1,
The optimization module calculates the performance cost based on the performance of the application when the memory is allocated to each of the one or more objects based on the profiling information. The method of claim 4,
The optimization module performs the memory allocation for each of the one or more objects based on the performance cost so as not to degrade the performance of the application. The method of claim 1, wherein the optimization module comprises one or more pass modules,
Each of the one or more pass modules
When a memory allocation request is called for each of the one or more objects, a first time stamp related to the time point of the memory allocation request, an identifier of the object related to the memory allocation request, an address of the allocated memory, and the size of the allocated memory An allocation history recording module for recording/storing information;
When a load/store reference occurs in the application with respect to the memory area allocated to the object, a second time stamp related to the time when the reference was made to the object, the identifier information of the object, the type of the reference, and the object. A reference history recording module for recording/storing the number of times of reference occurs; And
When the use of the object is completed, the allocation of the memory area allocated to the object is released, a third time stamp related to the time of the memory allocation release request, the identifier information of the object that has released the allocation, and the allocation is released Electronic device including a release history recording module for recording/storing size information of a memory. The method of claim 6, wherein each of the one or more pass modules
The electronic device further comprises a profiling information generation module storing information stored in the allocation history recording module, the reference history recording module, and the release history recording module as separate files and providing the profiling information as the profiling information. The method of claim 6,
When the application calls a memory allocation function, each of the one or more pass modules
Estimating the performance cost when the memory is allocated for each of the one or more objects based on the profiling information,
Determine the type of memory to be allocated for all objects allocated to the entire application and for which allocation is requested based on the performance cost,
An electronic device that allocates each of the one or more objects to one of the first memory device and the second memory device according to the determined memory type. The method of claim 8,
Each of the one or more pass modules rearranges an object previously allocated based on the performance cost to a different type of memory device. The method of claim 6,
When the application calls the memory release function, each of the one or more pass modules
Release the memory allocation of the object for which the memory release is requested,
Re-estimating the performance cost of currently allocated objects based on the profiling information,
An electronic device that determines rearrangement of the currently allocated objects based on the re-estimated performance cost. The method of claim 10,
Each of the one or more pass modules rearranges the currently allocated objects based on the re-estimated performance cost to improve performance of the application. The method of claim 1,
The first memory device is a volatile memory device, the second memory device is a nonvolatile memory device,
The compiler further includes a memory interface connected to the optimization module, the first memory device, and the second memory device. The method of claim 12,
The first memory device is a DRAM and the second memory device is a phase change memory device. As a method of compiling an electronic device that runs an application,
Recognizing context information related to execution of the application;
Compiling a source code related to execution of the application into an initial intermediate expression;
Holding different data for each of the one or more objects based on the performance cost at the time of memory allocation, calculated based on profiling information including context information of each of the one or more objects related to the application based on the context information Compiling the first intermediate expression into a final intermediate expression while allocating to one of a first memory device and a second memory device having characteristics; And
Generating a target code to execute the application based on the final intermediate expression,
The profiling information includes information on the size of the memory to which each of the one or more objects is allocated and information on the number of loads/stores based on the context information including information related to a call path and a loop of a function called when the application is executed. Compiling method of an electronic device including. As a method of operating an electronic device,
Compiling the source code related to the execution of the application into an intermediate expression, calculating the performance cost when allocating memory for each of the one or more objects based on profiling information including context information of each of the one or more objects related to the application Step to do;
Allocating each of the one or more objects to one of a first memory device and a second memory device having different data retention characteristics based on the performance cost; And
And executing the application according to the target code generated based on the intermediate expression,
The profiling information includes information on the size of the memory to which each of the one or more objects is allocated and information on the number of loads/stores based on the context information including information related to a call path and a loop of a function called when the application is executed. Operating method of an electronic device including. The method of claim 15,
The first memory device is a volatile memory device, the second memory device is a nonvolatile memory device,
The first memory device is a DRAM and the second memory device is a phase change memory device.

Images