CA1293810C - Method and apparatus using variable ranges to support symbolic debuggingof optimized code - Google Patents
Method and apparatus using variable ranges to support symbolic debuggingof optimized codeInfo
- Publication number
- CA1293810C CA1293810C CA000576769A CA576769A CA1293810C CA 1293810 C CA1293810 C CA 1293810C CA 000576769 A CA000576769 A CA 000576769A CA 576769 A CA576769 A CA 576769A CA 1293810 C CA1293810 C CA 1293810C
- Authority
- CA
- Canada
- Prior art keywords
- range
- resource
- code
- user
- instructions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3628—Software debugging of optimised code
Abstract
Abstract A method and apparatus is presented which uses variable ranges to support symbolic debugging of optimized code. A
debug symbol table is constructed which includes descriptions of each user resource in source code. Additionally, a range table is constructed. The range table contains, for each user resource which is stored in numerous locations during execution of the code, a list of ranges and a description of where the user resource may be found during each range. If the user resource is stored as a constant during a particular range, the value of the constant may be stored in the range table. The description of each user resource in the debug symbol table includes a flag which indicates whether there is a list of ranges in the range table for a particular user resource. If there is, the description of the particular user resource will include a pointer to the list of ranges for that user resource.
debug symbol table is constructed which includes descriptions of each user resource in source code. Additionally, a range table is constructed. The range table contains, for each user resource which is stored in numerous locations during execution of the code, a list of ranges and a description of where the user resource may be found during each range. If the user resource is stored as a constant during a particular range, the value of the constant may be stored in the range table. The description of each user resource in the debug symbol table includes a flag which indicates whether there is a list of ranges in the range table for a particular user resource. If there is, the description of the particular user resource will include a pointer to the list of ranges for that user resource.
Description
METHOD AND APPARATUS USING VA~IA~LE RANGES ~0 SUPPORT SYMBOLIC
DEBUGGING OF OPTIMIZED CODE
Baokground The pre~ent inventlon is concerned with debugging code whioh has been compiled using an optimizing compiler.
Code i9 generally written in a high level programming language. This high level language, often referred to a~
; source code, is tran~lated by a compiler program into a~
aq~embly language. The binary form of the a~sembly language, called ob~ect code, i~ the form Or the code actually executed by a computer.
Code debuggers are programs wbich aid a programmer in ~inding errora in oode. They are extremely u~ePul tools rOr improving the efficlency of the code debugging prooess. Many code debuggers supply lnformatlon pertaining to operation of the code on the a~embly code level. If the original code i~
written in a higher level language, however, this makes program debugging a difficult operation. When a programmer writes hi~
program in a high level language, he does not want to search for the appearance of these errors in the a3sembly code.
To avoid this problem, it is desirable to develop debugger program~ which allow a programmer to debug his program with reference to the level of code in which he originally wrote the program. Such a debugger program i9 often called a ~ource-level debugger.
One of the important re~tures of a code debugger is to ; allow a programmer to 9top the exeoution of code and to check ~Z93~
the values in each user resource the code is operating upon. Auser resource is typically a variable defined in the source code. The values in the user resources give clues to indicate the source of trouble when a program i3 not operating correctly.
Since the computer operates on ob~ect code, a source levsl debugger needs to know where user reqources named in the source code are actually stored by the computer during operation, 30 that when a user requests the current value for a user resource, the debugging program know~ where to find the user resource. Typically, a compiler will allocate a storage looation Por the user resouroe where the user resource i~
always stored. In this oase~ the debugger need simply go to the loaation and aocess the value o~ user resource.
Difriculties arise when compilers are used which 6enerate optimized code. Usually the design goal o~ an optimizer within a compiler, is to generate code that executes as rast as possible. In optimized code it may be desirable not to store a user resource in the same place all the time. For instance, i~
a user resource is accessed often and/or modified often in a particular section of code, during execution of that particular section Or code the current value Or a user resource may be stored in a register which is accessed and updated~ without concurrent update of any other storaee location. A standard debugging program, therefore, would have no way o~ acce3sing this user resouroe during execut~on Or the partioular seotion.
o Thus a programmer is forced to return to attempting to debug code based on the object code, or to use some other method.
SUMMARY OF THE INVENTION
In accordance with the preferred embodiment of the present in~ention a method and apparatus are presented which uses variable ranges to support symbolic debugging of optimized code. A debug symbol is constructed which includes ; descriptions of each user resource in source code.
Additionally, a range table is constructed. The range table contains, for each user resource which is stored in numerous locations during execution of the coda, a list of ranges and a description of where the user resource may be found during each range. If the user resource is stored as a constant during a particular range, the value of the constant may be stored in the range table. The description of each user resource in the debug symbol table includes a flag which indicates whether there is a list of ranges in the range table for a particular user resource. If there is, the description of the particular user resource will include a pointer tG the list of ranges for that user resource. The pointer may, for example, be an index into the range table for the appropriate list.
Various aspects of this invention are as follows:
In a computing system which includes a debugger which is used to debug compiled code generated by a compiler from source code, wherein the debugger accesses a debug symbol table containing a plurality of entries, each entry in the plurality of entries describing user resources used by the source code, an improvement to the computing system comprising:
a range table accessible by the debugger, including specification of locations where user resources reside in the computing system when the computing system executes the compiled code, and specification of ranges within the compiled code when the user resources reside in each of the specified locations, wherein when a list of ranges in the range table specify ~L293~
3a locations of a first user resource, a first entr~ from the plurality of entries in the debugger table which describes the first user resource includes a pointer which identifies the list of ranges.
: 5 A method useful for calculating, during optimization of code, ranges for which user resources res:ide in certain locations within a computing system, the method comprising:
(a) dividing the code up into basic blocks of straight line code sequences with a single entry point and a single exit point, (b) calculating webs for each user resource;
(c) determining the range of instructions within each basic block when webs for each user resource is alive;
(d) allocating, for each determined range of instructions for each web, lo~ations in which user resources are stored; and, (e) storing in a table a description of allocated locations for each determined range.
In a computing system which includes a debugger which is used to debug compiled code generated by a compiler from source code, an improvement to the computing system comprlslng:
a resource table including a plurality of resource table entries, the entries describing resources in the compiled code;
a debug symbol table including a plurality of debug symbol table entries, the debug symbol table entries describing resources in the source code, wherein when a first resource table entry from the plurality of resource table entries describes a first resource in the compiled code which is e~uivalent to a first resource in the source code, the first resource table entry will contain a pointer which points to a first debug symbol table entry which describes the first resource in the source code; and, a range table including a range list for at least one of the resources in the source code, wherein when a range list for the first resource in the source code is in the range .. .~,. , " . ~ ., ,, .: . .. ~.
1~333~0 3b table, the first debug symbol table entry will contain a pointer which points to the first range list.
Brief Description of the Drawings Figure lA shows a computing system in which sourcs code is compiled into object code before being run on a computer.
Figure lB shows the computing system of Figure lA with the addition of a debugger.
3~l~1l Figure 2A show~ a prior art structure which would be found within a data debugger table such as that ~hown in Figure 1B.
Figure 2B shows the structure dis¢losed in Figure 2~
modified in conformance with ~he preferred embodlment of the present invention.
Figure 3 show~ a range table in accordance with the prePerred embodiment of the present invention.
Figure 4 ~hows a sectlon of non-optimized code generated by a compiler.
Figure 5 shows the section of code shown in Figure 4 a~ter a oode opti~izer ha~ perrormed regi~ter promotion.
Figure 5A shows a resource table in accordance with the preferred embodiment of the pre~ent invention.
Figure 5~ shows the re~ourae table of Figure B after certain user resouroes have been promoted to registers.
Figure 6 shows the section of code shown in Figure 5 9 being used to build an interference graph.
Figure 7 shows the section of code shown in Figure 6 after calculation of ranges in accordance with the preferred embodiment oP the present invention.
Figure 7A shows a range table whioh could be developed as a result of the ranges determined in Figure 7 in accordance with the prePerred embodiment oP the present 1nvention.
Figure 8 shows the section of code 3hown in Flgure 7 aPter an optimizer has performed copy elimination~.
Figure 9 shows the section of code shown in Figure 8 a~ter ranges for constants have been spi}led.
5 ~Z93~1~
Figure 9A ~how3 tbe range table shown in Figure 7A after ; it has been modified to take into account the change~ to the code a~ recorded in Figure 9 in aooordanoe with the preferred embodiment of the present invention.
Figure 10 shows the section of code shown in Figure 9 after registers have been assigned.
Figure 10A shows the range table shown in Figure 9A after it has been modified to take into account the change~ to the oode aQ recorded in Figure 10 in accordance with the preferred embodiment of the prc~ent invention.
Figure 11 shows the seotion oP oode shown in Figure 10 after a soheduler has switohed the looation of exeoution o~ two instruotions.
Figure 11A shows the range table shown in Figure 10A a~ter it ha3 been modified to take into acoount the ohanges to the oode as reoorded in Figure 11 in aooordance with the preferred embodiment of the present invention.
Desoription of the Preferred Embodiment In Figure 1A, a oompiler 42 reoeives ~ouroe oode 41 and produoes ob~ect oode 43. The ob~eot oode i9 run on a oomputer 44.
In Figure 18, in order to disoover errors in souroe cods 41, a debugger 45 running on oomputer 44 exeoutes ob~ect code 43. During debugging, debugger 45 aooesses a debug symbol table 55. Compiler 42 is shown to inolude a oode generator 51 whioh generates generated oode 52. A oode optimizer 53 within oompiler 42 optimizes generated code 52 to produoe obJeot oode 6 lZ~13~1~
43. Code optimizer 53 i~ a multi-pass global optimizer. Code optimizer 53 keeps track of ~emory locations and registers through a re~ource table 54. Fach memory location and register has a unique entry in resource table 54. Herein, memory locations are 30meti~e~ referred to as ~emory resources and registers are sometimes referrPd to a register resources, and memory locations and regi3ters are sometimes collectively referred to as re~ources.
For each user resource within ~ouroe code 41~ debugger 45 keep~ in debug symbol table 55 a data ~tructure. The~e data structures are entries within debug ~ymbol table 55. A prior art format of the data struoture is shown in Figure 2A. In Figure 2A a data struoture 106 is oomprised Or a thirty-two bit word 100~ a thirty-two bit word 101, a thirty-two bit word 102 a thirty-two bit word 103 and a thirty-two bit word 104.
Word 100 includes various Pields whioh indicate information about the user resource. a one-bit Pield 107 stores information which in~orms the debugger a~ to ~ize parameters o~ struoture 106. A ten-bit fleld 108 indicate~ to debugger 45 what type of structure structure 106 is. For instance, field 108 may indicate to debugger 45 that structure 106 contains a dynamic variable. A one-bit field 109 indioates whether the resource defined by structure 106 19 globally recognized in souroe oode 41. A one-bit Pield 110 indicates whether oertain addresses are lndirect or direct. A
one-bit f~eld 111 indlcates whether the resouroe 19 a register 7 ~293~10 type, or a dynamic variable. Eighteen bit field 112 is unused .
Word 101 contains a pointer, for instance an actual address or an index, which points to a location in ~emory in which is kept a name ror the resource. The name is how the resource is addressed in source code 41. Word 102 contains a pointer indicating where in memory the resource i9 ~tored.
Word 103 point~ to a location in which i~ storzd information about the type o~ resource. Word 104 contalns a post indirection byte offset Por use in CO~OL structures.
In Figure 2A, debugger 45 always expects to find the re30urce derined by 3truoture 106 in the same plaoe. Aa di3cussed berore, thi~ ls surricient only if compiler 42 is not an optimizing compiler.
Figure 2B shows prior art struoture 106 modi~ied in accordance with the preferred embodiment of the pre~ent invention. Word 101, word 102 word 103 and word 104 remain unchanged. In word 100, a one-bit ~ield 213, and a one-bit field 214 have been added. Field 213 is a pad 90 that field 214 i9 in a position that is more conYenient ror acces~ by debugger 45. Field 214 is reset when there is no range table associated with the resouroe defined by ~tructure 106. Field 214 i9 set when there is a range table a3sociated with the resource defined by ~tructure 106.
Additionally, in Figure 2B, a word 205 i3 added. When ~ield 214 is set, word 205 contain~ an index in~o a range ~ 8 ~IL2~3810 table. The index points to the rirst range for the resource de~ined by atructure 1 o6 0 Figure 3 shows a range table in aocordance Nith a preferred embodiment o~ the pre~ent invention. Pointers 311 from debug symbol table, for user resourceQ i and ;, point to ranges within the range table. A column 312 contains low bound3 for range for user resource~ i and ~. A column 313 contains high bounds for ranges for user resouroes i and ~. A
column 314 locations for user resources i and ~. A column 315 contains flags indicatlng information about each range.
For instance, a range 301, a range 302 and a range 303 6ive information about a user resource "i". From program location 4 to program looation 100~ user resource 1 is stored as a register resource in register 5. From program locatlon 15 120 to program looation 136, user resource i i~ stor~d a~ a constant wlth a value of 500. From program locatlon 200 to program location 204 user resource i i~ is stored as a regtster resource in register 31. This is the last range for u~er resource i. For the program locations not given in the range table, the value for user resource i is unavailable.
Similarly, a range 304 and a range 305 give information about a user resource "~". From program location 8 to program location 2C, user resource ~ is stored as a regi~ter resouroe in register 6. From program location 100 to program location 200 user resource ; i~ stored in a memory stack at location -80 on the stack. This i9 the last range for user resource ~I For `- 9 ~Z93~310 the program locatlons not given in the range table, the value Por resource is unavailable.
If therefore data structure 106 were describing user re~ource i, then field 214 would be set and word 205 would contain an index pointing to ranee 301. If the data structure 106 were de~cribing user resource ~, then field 214 would be set and word 205 would contain an index pointlng to range 304.
Field 112 has been reduced to sixteen unused bits.
The following is an explanation of how ranges are oalculated when code optimizer 53 optimizes generated oode 52.
In Figure 4 is shown an example Or generated code produced by oode generator 51. The oode in Figure 4 oontains three user re90UrOe9 S u9er re90UrOe X ~ U9er re90UrOe y 7 and user resouroe z. lt is a goal of this dlsousslon to show how ranges for these user resource~ may be oaloulated when code optimizer 53 optimizes eenerated code 52.
Figure 5 show~ generated code 52 of Figure 4 after oode optimizer make~ a regi3ter promotion pass. The oode is broken up into four basi¢ blocks: a blook 501, a b~ook 502, a blook 503 and a blook 504. A basio blook is a straight-line code sequenoe with a single entry point and a single exit point.
During the register promotion pass, oode optimizer caloulates webs for eaoh reglster or memory looation used by generatsd oode 52. What 19 mean~ by a web is a set o~
instruotions which ao¢ess a partioular resource. The web begins when the resource is defined to have a particular value.
Every 3uocessive instruotion that uses the resource ls included o ~29~1~
in the web, until the resource i~ defined to have a new value.
More than one web may be built upon a single re30urce. Thi occurs when instructions which define and u~e the resource are completely dis~oint from other instruction3 which define and use the resource.
Since code run~ fa~ter when re~ource~ are stored in registers, rather than memory locations, on this pas~ code optimizer looks ~or memory resources which can be promoted to register resources. As is apparent from close comparlson of Figure 5 with Figure 4, user resouroes x, y and z are promoted rrom memory resour¢es to reglsters r9, r10 and rl1 respeotively. As oan be seen in Figure 5 each store to user re90UrCe X i9 changed into a copy to register r9, each ~tore to user resource y is changed into a copy to register rlO and each store to resource z is changed into a copy to register rl1.
The webs generated with regard to the code in Figure 5 are shown in the ~ollowing Table 1:
Table t Web Number Instruotions Resource User Resouroe Pointer web1 , 1,2 r1 Null web2 2,6,15 r9 x web3 3,4 r2 Null web4 4,7 r10 z wab5 6,8 r3 Null web6 7,8 r4 Null web7 8,12,16,17 r5 Null web8 10,12 r11 y web9 15,16 r3 Null web10 16,19 r6 Null web11 17,19 r9 x It is an ob~ect Or the present invention to keep track of which webs are concerned with usPr resources. ThiY in~ormation 1 1 129~ l0 i9 stored in the form of a field in eaoh resouroe table entry within resource table 54. For every re30uroe in re~ouroe table 54, i~ there is a user resourGe as~ociated therewith, the pointer will point to the entry within debug symbol table 55 for the user resource. If there i9 not a user resource as~ociated with a resource table entry, the pointer will be null. In Table 1 this pointer ~or eaoh web is represented by the Column labelled "User Re~ouroe Pointer".
In Figure 5A, a portlon of re~ource table 54 is shown. An entry 510 for user re30uroe x inoludes a pointer 510a whioh points to an entry for user resouroe x ln debug symbol table 55. An entry 511 for user resouroe y lnoludes a pointer 511a whioh points to an entry for user resouroe y in debug symbol table 55. An entry 512 for user resouroe z ino1udes a pointer 512a whioh points to an entry for user resource z in debug symbol table 55.
Figure 5B shows resouroe table 54 after the register promotion pass. Entries 510, 511 and 512 remain in resource table 54 unchanged. A new entry 520, a new entry 521 and a new entry 522 have been added to resouroe table 54. Entry 520 for register r9 includes pointer 510a whioh points to the entry for user resouroe x in debug symbol table 55. Bntry 521 for register r11 inoludes pointer 51la whioh points to the entry for user resouroe y in debug qymbol table 55. Entry 522 for register r10 inoludes pointer 512a which point~ to the entry for user resource z in debug symbol table 55.
, 12 lZ ~ l ~
In addition, durlng the register promotlon pass, code optimi3er 53 calculates the set of webs which are alive at the end Or each of the basic block3. What is meant by a web being alive at the end of a partioular basic block, is that the current value of the resource assooiated with the web i9 need by other basic blocks whioh are executed ~ub~equent to the particular basic block. For the code in Figure 5, the following Table Z shows which webs are alive at the end of blooks 501, 502, 503 and 504.
Table 2 Basic Block ~lve Webs Block 501 web2, web7 Block 502 Web7 Block 503 web7~ weblO
Blook 504 weblO
Code optimizer 53 make3 another pass to determine interferences between webs. The results of the pa3s are shown in Yigure 6. In Flgure 6, each resource is replaced by the web associated with it in Table 1. Additionally, for each 15 instruction the local live web set (llws) is calculated for each instruotion. The llws for eaoh instruction is that set of webs which is currently active during the execution of that 1nstruction. The llws for each in~truction is calculated as follows. Code optimi~er 53 traverses instructions in each of blocks 501-504 in reverse order. The llws for the last instruction in each block is the set of live webs eiven in Table 2. While traversing the instructions in each block in reverse order, whenever ¢ode optimizer 53 encounters a web not 13 1;:9~8~
in the current llws, code optimi~er 53 adds the web to the llws. When code optimizer 53 comes across a definition for a web~ the web is removed from the llw8. The llws which exists after each ln~truction i~ processed-i~ shown in Figure 6.
From the in~ormation derived during thi~ pas3 it i9 determined inter~erences between webq 7 that is, which webs are alive during the time other webs are ali~e. The followin6 Table 3 shows web interrerences for the code in Flgure 6.
Table 3 Web Interfering Webs web1 web2 web3~ web4, web5, web6, web7 web3 web2 web4 web2, web5 web5 web2, web4 web6 web2,web5 web7 web2~ web9, weblO
web8 web9 web7 web10 web7 web11 The 3ame information which code optimizer 53 u3es to build the interferenoe graph, may also be u~ed to caloulate information on ranges. ~anges may be calculated as follows.
In Table ~1 certain webs ha~e poirters to a user resource entry in debug table 55. Information about these webs, are u3ed to calculate ranges rOr their associated user resources.
In calculating these range~ high-water marks and low water marks are used. A high water mark is the instruction before a high bound Or a range. A low water mark is the in3truction before a low bound Or a range.
11~
12~3l310 If at the end of a block a web i8 still in the llws~ the la~t instruction is a high water mark for the u~er resource a~sociated with that web. Also, at the point where, code optimizer 53 add~ a web to the llws, while traversing the instructions in each block in reverse order, this instruction al~o i3 considered a high water mark for the user resource associated with that web. Slmilarly, when a web is removed from the llws, that in~truction is considered a low water mark for~the user resource associated with that web. Also the top of a block may be considered a low water mark for any user resource. The above-given system can be improved when the blocks themselves (in additlon to the oode within each block) are traversed in reverse order. In thls case, i r a web is in the llw3 at the end of the next-to-be traversed blook, it l~
no~ necessary to place a low water mark at the top of the most reoently traversed block.
Using Figure 6 and Figure 7 it ~9 possible to see how the method of determining ranges de~crlbed above~ may be performed on the code shown in Figure 6. Starting with instruction 19, webl1 is in the llws. As oan be seen from Table 1, web11 has a user resource pointer to user resource x. Therefore, instruction 19 is a high water mark ~or user resource x. In in~truction 17, web11 is defined, and therefore removed from the llws. There~ore, instruction 17 i~ a low water mark for user resouroe x. A high bound and a low bound for Range 701 for user resource x may be determined ~rom the high water mark and the low water mark given.
~a2938io In instruction 15, web2 is u~ed and it is not ourrently in the llws, therefore it i~ the last u~e of web2. From Table 1, web2 has a u~er resource pointer to u~er resouroe x.
Therefore, instruction 15 i9 a high water mark for user re~ource x. Instruotion 14 i~ the top of blook 503. Web2 is not in the llw9 at the end of block 502. Therefore, instruction 14 i~ a low water mark for user resource x. Range 702 for user relource x may be determined from the high water mark and the low water mark.
In instruction 12, web8 i9 used and it i~ not currently in the llw9~ therefore it is the last use of web8. From Table 1, web8 ha~ a user resource pointer to user resouroe y.
Thererorc, instruation 12 is a high water mark for user reaouroe y. In instruction 10~ web8 is defined. Therefore instruction 10 is a low water mark for uaer resouroe y. Range 703 for user resource x may be determined from the high water mark and the low water mark.
Instruction 9 is the end o~ blook 50t. Web2 i9 in the llws in in~tructlon 9 at the end of block 501. From Table 1, web2 has a user resource pointer to user resource x.
There~ore, in~truction 12 is a hi~h water mark for user resource x.
In instruction 7, web4 is u~ed and it is not in the llw3~
therefore it i8 the last use Or web4. From Table 1, web4 has a resouroe pointer to user resourae z. Tb~refore, in~tructlon 7 is a high water mark for user resource z. In instruction 4, web4 is defined. Therefore, instruction 4 is a low water mark 16 ~9381~
for u3er re~ource z. Range 704 for u3er re30uroe z may be determined from the high water mark and the low ~ater mark.
In in3truction 2, web2 i3 de~ined. There~ore, inqtruction 2 i9 a low water mark for user resouroe x. Range 705 ~or user resource x may be determined from the high water mark ard the low water mark. At this point a range table could be constructed, as is 3hown in Figure 7A.
In the range table, in Figure 7A pointers ~31 from debug symbol table, for user resources x, y and z, point to ranges within the range table. A column 132 contain3 low bound3 for range~ for u3er resouroes x~ y and z. ~ column 133 oontain3 high bounds for ranges for user resouroes x, y and z. A oolumn 134 oontains a looation Por the user resource for the respeotlve ranges. A oolumn 135 indioates the type of resource in whioh user resouroe resides during the given range.
Information about the ranges are associated with the re~pective webs~ For instance, this may be done by addlng a list o~
ranges to a data 3tructure built and used by a portion ~called a register allocator) of code optim~zer 53 whioh allo¢ates registers. Thè data struoture built by the allooator i3 called an inter~erence graph. Each web ha3 a separate entry. The list of ranges for each web is added to the web's entry in the interferenoe graph.
When oode optimizer 53 makes additional passes in the code~ the ranges may neéd to be ad~usted aocordingly. For instance, oode optimizer 53 may perform a copy elimination. A
oopy elimination ~ay be performed when oode optlmizer 53 2 ~ 8l 0 determines that two webs do not interfere, but ~hare a copy instruction in oommon. The copy is removed and the two web~
become a single composite web.
If a web is removed which i9 as~ociated with a user resource, the list of ranges ror the removed web must be added to the composite web~ Figure 8 shows the code of Figure 7 after code optimizer 53 perform~ copy elimination. The following Table 4 show~ the nece~sary modifications to Table 1, resulting from the copy elimination:
Table 4 User Resource Web Number Instructions Resource Pointer web1:web2 web2~web9 web3:web4 web4:web6 web5 6,8 r3 Null web6 7,8,3,4,4,7 r4, r2, r10 z web7:web11 web8:web7 web9 15~16,2,6, r3~ r9, r1 x 15,1,2 web10 16,19 r6 Null web11 17,19,8,12, r9, r5, r11 x,y 16,17,10,12 .
Code optimizer 53 may also perform a constant spill. For in~tance, if a web contains only a constant variable, code optimizer 53 may determine that it is advantageous to free up a regi~ter by reloading the-constant into a register before each use, rather than leaving the constant continually in the register. In this case the ranges, which previously were of type register range, are changed to type constant range. The 18 1~3810 lo¢ation of the user resource i~ changed to equal the constant.
Figure 9 ~hows how the code of Figure 8 i3 modified after code optimizer 53 performs a constant spill. Figure 9A shows how the range table showed in Figure 7A would be modified as a result of the constant spill.
At this point code optimizer 53 allooates register~ to webY. Figure 10 shows the code of Figure 9 after registers have been allocated. Once register~ are allocated to webs, the infor~ation about tho~e register may be filled into the range table. Figure 10A shows the range table of Figure 9A after register allooation.
If, during the register allooation, there are not suffioient registers~ oode optimizer 53 spills some o~ the webs to memory. A spilled web is stored to memory after belng defined, and reloaded before it is used. Nhen thls ooours entries in the range table are changed to 8pill ranges. The low water mark and high water mark remain the same, but the location i8 ohanged to the spill memory looation and the type of range 19 ohanged to spill.
The ranges can often be axpanded by making another pass.
The high water mark may be moved to the end of a basio block or to an instruction that might wipe out the oontents Or the register in which the user resource resides, whiohever first ocoursO
In order to do this, the oode i~ again traversed in reverse order, keeping traok Or the last lnstruction of the basic block aA an extend instruction for each web. A set of 1 9 ~IL29381(~
Plags keeps traok of the registers dePined between the current instruction and the last instruction of the basic block. When a definition of a register is seen, the flag for the appropriate register is set and a pointer to the defining instruction is attached to the web. The defining instruction beoomes a nsw extend instruction for that web.
When an instruction performing a call i9 seen, the call instruction becomes the extend instruction ln all the webs.
This i9 because a call could wipe out the values in any register.
When the use of a web is seen, if the register assigned to that web had been de~ined be~ore the last instru~tion, that instruotion becomes the extend instruotion for that web.
When the traverse i8 finished, for those webs which oontain a range whose high water mark i9 lower than the extend instruction, the extend in3truction becomes the new high water mark, and the range is ad~usted ac¢ordingly.
Finally, additional funotional units within code optimizer may operate on the code to produce ranges which overlap existing ranges. In this oase the range with the lowest priority must be shortened. For example, in Figure 11, a scheduler within code optimi~er 53 has reversed the operations of instructions 11 and instruotion 10. This has oreated a scheduler range 119 which overlapped range 703. Range 703 was created first 9 so has the lowest priority. Therefore, range 703 wa3 shortened. Figure 11A shows how the range table shown ~ '--20 ~z93~
in Figure 1aA i~ modif'ied to re~leot the ~hortening of ran~e 7Q3 .
'; :
: :
.~:
' :
:
. : .
., , '. ~
DEBUGGING OF OPTIMIZED CODE
Baokground The pre~ent inventlon is concerned with debugging code whioh has been compiled using an optimizing compiler.
Code i9 generally written in a high level programming language. This high level language, often referred to a~
; source code, is tran~lated by a compiler program into a~
aq~embly language. The binary form of the a~sembly language, called ob~ect code, i~ the form Or the code actually executed by a computer.
Code debuggers are programs wbich aid a programmer in ~inding errora in oode. They are extremely u~ePul tools rOr improving the efficlency of the code debugging prooess. Many code debuggers supply lnformatlon pertaining to operation of the code on the a~embly code level. If the original code i~
written in a higher level language, however, this makes program debugging a difficult operation. When a programmer writes hi~
program in a high level language, he does not want to search for the appearance of these errors in the a3sembly code.
To avoid this problem, it is desirable to develop debugger program~ which allow a programmer to debug his program with reference to the level of code in which he originally wrote the program. Such a debugger program i9 often called a ~ource-level debugger.
One of the important re~tures of a code debugger is to ; allow a programmer to 9top the exeoution of code and to check ~Z93~
the values in each user resource the code is operating upon. Auser resource is typically a variable defined in the source code. The values in the user resources give clues to indicate the source of trouble when a program i3 not operating correctly.
Since the computer operates on ob~ect code, a source levsl debugger needs to know where user reqources named in the source code are actually stored by the computer during operation, 30 that when a user requests the current value for a user resource, the debugging program know~ where to find the user resource. Typically, a compiler will allocate a storage looation Por the user resouroe where the user resource i~
always stored. In this oase~ the debugger need simply go to the loaation and aocess the value o~ user resource.
Difriculties arise when compilers are used which 6enerate optimized code. Usually the design goal o~ an optimizer within a compiler, is to generate code that executes as rast as possible. In optimized code it may be desirable not to store a user resource in the same place all the time. For instance, i~
a user resource is accessed often and/or modified often in a particular section of code, during execution of that particular section Or code the current value Or a user resource may be stored in a register which is accessed and updated~ without concurrent update of any other storaee location. A standard debugging program, therefore, would have no way o~ acce3sing this user resouroe during execut~on Or the partioular seotion.
o Thus a programmer is forced to return to attempting to debug code based on the object code, or to use some other method.
SUMMARY OF THE INVENTION
In accordance with the preferred embodiment of the present in~ention a method and apparatus are presented which uses variable ranges to support symbolic debugging of optimized code. A debug symbol is constructed which includes ; descriptions of each user resource in source code.
Additionally, a range table is constructed. The range table contains, for each user resource which is stored in numerous locations during execution of the coda, a list of ranges and a description of where the user resource may be found during each range. If the user resource is stored as a constant during a particular range, the value of the constant may be stored in the range table. The description of each user resource in the debug symbol table includes a flag which indicates whether there is a list of ranges in the range table for a particular user resource. If there is, the description of the particular user resource will include a pointer tG the list of ranges for that user resource. The pointer may, for example, be an index into the range table for the appropriate list.
Various aspects of this invention are as follows:
In a computing system which includes a debugger which is used to debug compiled code generated by a compiler from source code, wherein the debugger accesses a debug symbol table containing a plurality of entries, each entry in the plurality of entries describing user resources used by the source code, an improvement to the computing system comprising:
a range table accessible by the debugger, including specification of locations where user resources reside in the computing system when the computing system executes the compiled code, and specification of ranges within the compiled code when the user resources reside in each of the specified locations, wherein when a list of ranges in the range table specify ~L293~
3a locations of a first user resource, a first entr~ from the plurality of entries in the debugger table which describes the first user resource includes a pointer which identifies the list of ranges.
: 5 A method useful for calculating, during optimization of code, ranges for which user resources res:ide in certain locations within a computing system, the method comprising:
(a) dividing the code up into basic blocks of straight line code sequences with a single entry point and a single exit point, (b) calculating webs for each user resource;
(c) determining the range of instructions within each basic block when webs for each user resource is alive;
(d) allocating, for each determined range of instructions for each web, lo~ations in which user resources are stored; and, (e) storing in a table a description of allocated locations for each determined range.
In a computing system which includes a debugger which is used to debug compiled code generated by a compiler from source code, an improvement to the computing system comprlslng:
a resource table including a plurality of resource table entries, the entries describing resources in the compiled code;
a debug symbol table including a plurality of debug symbol table entries, the debug symbol table entries describing resources in the source code, wherein when a first resource table entry from the plurality of resource table entries describes a first resource in the compiled code which is e~uivalent to a first resource in the source code, the first resource table entry will contain a pointer which points to a first debug symbol table entry which describes the first resource in the source code; and, a range table including a range list for at least one of the resources in the source code, wherein when a range list for the first resource in the source code is in the range .. .~,. , " . ~ ., ,, .: . .. ~.
1~333~0 3b table, the first debug symbol table entry will contain a pointer which points to the first range list.
Brief Description of the Drawings Figure lA shows a computing system in which sourcs code is compiled into object code before being run on a computer.
Figure lB shows the computing system of Figure lA with the addition of a debugger.
3~l~1l Figure 2A show~ a prior art structure which would be found within a data debugger table such as that ~hown in Figure 1B.
Figure 2B shows the structure dis¢losed in Figure 2~
modified in conformance with ~he preferred embodlment of the present invention.
Figure 3 show~ a range table in accordance with the prePerred embodiment of the present invention.
Figure 4 ~hows a sectlon of non-optimized code generated by a compiler.
Figure 5 shows the section of code shown in Figure 4 a~ter a oode opti~izer ha~ perrormed regi~ter promotion.
Figure 5A shows a resource table in accordance with the preferred embodiment of the pre~ent invention.
Figure 5~ shows the re~ourae table of Figure B after certain user resouroes have been promoted to registers.
Figure 6 shows the section of code shown in Figure 5 9 being used to build an interference graph.
Figure 7 shows the section of code shown in Figure 6 after calculation of ranges in accordance with the preferred embodiment oP the present invention.
Figure 7A shows a range table whioh could be developed as a result of the ranges determined in Figure 7 in accordance with the prePerred embodiment oP the present 1nvention.
Figure 8 shows the section of code 3hown in Flgure 7 aPter an optimizer has performed copy elimination~.
Figure 9 shows the section of code shown in Figure 8 a~ter ranges for constants have been spi}led.
5 ~Z93~1~
Figure 9A ~how3 tbe range table shown in Figure 7A after ; it has been modified to take into account the change~ to the code a~ recorded in Figure 9 in aooordanoe with the preferred embodiment of the present invention.
Figure 10 shows the section of code shown in Figure 9 after registers have been assigned.
Figure 10A shows the range table shown in Figure 9A after it has been modified to take into account the change~ to the oode aQ recorded in Figure 10 in accordance with the preferred embodiment of the prc~ent invention.
Figure 11 shows the seotion oP oode shown in Figure 10 after a soheduler has switohed the looation of exeoution o~ two instruotions.
Figure 11A shows the range table shown in Figure 10A a~ter it ha3 been modified to take into acoount the ohanges to the oode as reoorded in Figure 11 in aooordance with the preferred embodiment of the present invention.
Desoription of the Preferred Embodiment In Figure 1A, a oompiler 42 reoeives ~ouroe oode 41 and produoes ob~ect oode 43. The ob~eot oode i9 run on a oomputer 44.
In Figure 18, in order to disoover errors in souroe cods 41, a debugger 45 running on oomputer 44 exeoutes ob~ect code 43. During debugging, debugger 45 aooesses a debug symbol table 55. Compiler 42 is shown to inolude a oode generator 51 whioh generates generated oode 52. A oode optimizer 53 within oompiler 42 optimizes generated code 52 to produoe obJeot oode 6 lZ~13~1~
43. Code optimizer 53 i~ a multi-pass global optimizer. Code optimizer 53 keeps track of ~emory locations and registers through a re~ource table 54. Fach memory location and register has a unique entry in resource table 54. Herein, memory locations are 30meti~e~ referred to as ~emory resources and registers are sometimes referrPd to a register resources, and memory locations and regi3ters are sometimes collectively referred to as re~ources.
For each user resource within ~ouroe code 41~ debugger 45 keep~ in debug symbol table 55 a data ~tructure. The~e data structures are entries within debug ~ymbol table 55. A prior art format of the data struoture is shown in Figure 2A. In Figure 2A a data struoture 106 is oomprised Or a thirty-two bit word 100~ a thirty-two bit word 101, a thirty-two bit word 102 a thirty-two bit word 103 and a thirty-two bit word 104.
Word 100 includes various Pields whioh indicate information about the user resource. a one-bit Pield 107 stores information which in~orms the debugger a~ to ~ize parameters o~ struoture 106. A ten-bit fleld 108 indicate~ to debugger 45 what type of structure structure 106 is. For instance, field 108 may indicate to debugger 45 that structure 106 contains a dynamic variable. A one-bit field 109 indioates whether the resource defined by structure 106 19 globally recognized in souroe oode 41. A one-bit Pield 110 indicates whether oertain addresses are lndirect or direct. A
one-bit f~eld 111 indlcates whether the resouroe 19 a register 7 ~293~10 type, or a dynamic variable. Eighteen bit field 112 is unused .
Word 101 contains a pointer, for instance an actual address or an index, which points to a location in ~emory in which is kept a name ror the resource. The name is how the resource is addressed in source code 41. Word 102 contains a pointer indicating where in memory the resource i9 ~tored.
Word 103 point~ to a location in which i~ storzd information about the type o~ resource. Word 104 contalns a post indirection byte offset Por use in CO~OL structures.
In Figure 2A, debugger 45 always expects to find the re30urce derined by 3truoture 106 in the same plaoe. Aa di3cussed berore, thi~ ls surricient only if compiler 42 is not an optimizing compiler.
Figure 2B shows prior art struoture 106 modi~ied in accordance with the preferred embodiment of the pre~ent invention. Word 101, word 102 word 103 and word 104 remain unchanged. In word 100, a one-bit ~ield 213, and a one-bit field 214 have been added. Field 213 is a pad 90 that field 214 i9 in a position that is more conYenient ror acces~ by debugger 45. Field 214 is reset when there is no range table associated with the resouroe defined by ~tructure 106. Field 214 i9 set when there is a range table a3sociated with the resource defined by ~tructure 106.
Additionally, in Figure 2B, a word 205 i3 added. When ~ield 214 is set, word 205 contain~ an index in~o a range ~ 8 ~IL2~3810 table. The index points to the rirst range for the resource de~ined by atructure 1 o6 0 Figure 3 shows a range table in aocordance Nith a preferred embodiment o~ the pre~ent invention. Pointers 311 from debug symbol table, for user resourceQ i and ;, point to ranges within the range table. A column 312 contains low bound3 for range for user resource~ i and ~. A column 313 contains high bounds for ranges for user resouroes i and ~. A
column 314 locations for user resources i and ~. A column 315 contains flags indicatlng information about each range.
For instance, a range 301, a range 302 and a range 303 6ive information about a user resource "i". From program location 4 to program looation 100~ user resource 1 is stored as a register resource in register 5. From program locatlon 15 120 to program looation 136, user resource i i~ stor~d a~ a constant wlth a value of 500. From program locatlon 200 to program location 204 user resource i i~ is stored as a regtster resource in register 31. This is the last range for u~er resource i. For the program locations not given in the range table, the value for user resource i is unavailable.
Similarly, a range 304 and a range 305 give information about a user resource "~". From program location 8 to program location 2C, user resource ~ is stored as a regi~ter resouroe in register 6. From program location 100 to program location 200 user resource ; i~ stored in a memory stack at location -80 on the stack. This i9 the last range for user resource ~I For `- 9 ~Z93~310 the program locatlons not given in the range table, the value Por resource is unavailable.
If therefore data structure 106 were describing user re~ource i, then field 214 would be set and word 205 would contain an index pointing to ranee 301. If the data structure 106 were de~cribing user resource ~, then field 214 would be set and word 205 would contain an index pointlng to range 304.
Field 112 has been reduced to sixteen unused bits.
The following is an explanation of how ranges are oalculated when code optimizer 53 optimizes generated oode 52.
In Figure 4 is shown an example Or generated code produced by oode generator 51. The oode in Figure 4 oontains three user re90UrOe9 S u9er re90UrOe X ~ U9er re90UrOe y 7 and user resouroe z. lt is a goal of this dlsousslon to show how ranges for these user resource~ may be oaloulated when code optimizer 53 optimizes eenerated code 52.
Figure 5 show~ generated code 52 of Figure 4 after oode optimizer make~ a regi3ter promotion pass. The oode is broken up into four basi¢ blocks: a blook 501, a b~ook 502, a blook 503 and a blook 504. A basio blook is a straight-line code sequenoe with a single entry point and a single exit point.
During the register promotion pass, oode optimizer caloulates webs for eaoh reglster or memory looation used by generatsd oode 52. What 19 mean~ by a web is a set o~
instruotions which ao¢ess a partioular resource. The web begins when the resource is defined to have a particular value.
Every 3uocessive instruotion that uses the resource ls included o ~29~1~
in the web, until the resource i~ defined to have a new value.
More than one web may be built upon a single re30urce. Thi occurs when instructions which define and u~e the resource are completely dis~oint from other instruction3 which define and use the resource.
Since code run~ fa~ter when re~ource~ are stored in registers, rather than memory locations, on this pas~ code optimizer looks ~or memory resources which can be promoted to register resources. As is apparent from close comparlson of Figure 5 with Figure 4, user resouroes x, y and z are promoted rrom memory resour¢es to reglsters r9, r10 and rl1 respeotively. As oan be seen in Figure 5 each store to user re90UrCe X i9 changed into a copy to register r9, each ~tore to user resource y is changed into a copy to register rlO and each store to resource z is changed into a copy to register rl1.
The webs generated with regard to the code in Figure 5 are shown in the ~ollowing Table 1:
Table t Web Number Instruotions Resource User Resouroe Pointer web1 , 1,2 r1 Null web2 2,6,15 r9 x web3 3,4 r2 Null web4 4,7 r10 z wab5 6,8 r3 Null web6 7,8 r4 Null web7 8,12,16,17 r5 Null web8 10,12 r11 y web9 15,16 r3 Null web10 16,19 r6 Null web11 17,19 r9 x It is an ob~ect Or the present invention to keep track of which webs are concerned with usPr resources. ThiY in~ormation 1 1 129~ l0 i9 stored in the form of a field in eaoh resouroe table entry within resource table 54. For every re30uroe in re~ouroe table 54, i~ there is a user resourGe as~ociated therewith, the pointer will point to the entry within debug symbol table 55 for the user resource. If there i9 not a user resource as~ociated with a resource table entry, the pointer will be null. In Table 1 this pointer ~or eaoh web is represented by the Column labelled "User Re~ouroe Pointer".
In Figure 5A, a portlon of re~ource table 54 is shown. An entry 510 for user re30uroe x inoludes a pointer 510a whioh points to an entry for user resouroe x ln debug symbol table 55. An entry 511 for user resouroe y lnoludes a pointer 511a whioh points to an entry for user resouroe y in debug symbol table 55. An entry 512 for user resouroe z ino1udes a pointer 512a whioh points to an entry for user resource z in debug symbol table 55.
Figure 5B shows resouroe table 54 after the register promotion pass. Entries 510, 511 and 512 remain in resource table 54 unchanged. A new entry 520, a new entry 521 and a new entry 522 have been added to resouroe table 54. Entry 520 for register r9 includes pointer 510a whioh points to the entry for user resouroe x in debug symbol table 55. Bntry 521 for register r11 inoludes pointer 51la whioh points to the entry for user resouroe y in debug qymbol table 55. Entry 522 for register r10 inoludes pointer 512a which point~ to the entry for user resource z in debug symbol table 55.
, 12 lZ ~ l ~
In addition, durlng the register promotlon pass, code optimi3er 53 calculates the set of webs which are alive at the end Or each of the basic block3. What is meant by a web being alive at the end of a partioular basic block, is that the current value of the resource assooiated with the web i9 need by other basic blocks whioh are executed ~ub~equent to the particular basic block. For the code in Figure 5, the following Table Z shows which webs are alive at the end of blooks 501, 502, 503 and 504.
Table 2 Basic Block ~lve Webs Block 501 web2, web7 Block 502 Web7 Block 503 web7~ weblO
Blook 504 weblO
Code optimizer 53 make3 another pass to determine interferences between webs. The results of the pa3s are shown in Yigure 6. In Flgure 6, each resource is replaced by the web associated with it in Table 1. Additionally, for each 15 instruction the local live web set (llws) is calculated for each instruotion. The llws for eaoh instruction is that set of webs which is currently active during the execution of that 1nstruction. The llws for each in~truction is calculated as follows. Code optimi~er 53 traverses instructions in each of blocks 501-504 in reverse order. The llws for the last instruction in each block is the set of live webs eiven in Table 2. While traversing the instructions in each block in reverse order, whenever ¢ode optimizer 53 encounters a web not 13 1;:9~8~
in the current llws, code optimi~er 53 adds the web to the llws. When code optimizer 53 comes across a definition for a web~ the web is removed from the llw8. The llws which exists after each ln~truction i~ processed-i~ shown in Figure 6.
From the in~ormation derived during thi~ pas3 it i9 determined inter~erences between webq 7 that is, which webs are alive during the time other webs are ali~e. The followin6 Table 3 shows web interrerences for the code in Flgure 6.
Table 3 Web Interfering Webs web1 web2 web3~ web4, web5, web6, web7 web3 web2 web4 web2, web5 web5 web2, web4 web6 web2,web5 web7 web2~ web9, weblO
web8 web9 web7 web10 web7 web11 The 3ame information which code optimizer 53 u3es to build the interferenoe graph, may also be u~ed to caloulate information on ranges. ~anges may be calculated as follows.
In Table ~1 certain webs ha~e poirters to a user resource entry in debug table 55. Information about these webs, are u3ed to calculate ranges rOr their associated user resources.
In calculating these range~ high-water marks and low water marks are used. A high water mark is the instruction before a high bound Or a range. A low water mark is the in3truction before a low bound Or a range.
11~
12~3l310 If at the end of a block a web i8 still in the llws~ the la~t instruction is a high water mark for the u~er resource a~sociated with that web. Also, at the point where, code optimizer 53 add~ a web to the llws, while traversing the instructions in each block in reverse order, this instruction al~o i3 considered a high water mark for the user resource associated with that web. Slmilarly, when a web is removed from the llws, that in~truction is considered a low water mark for~the user resource associated with that web. Also the top of a block may be considered a low water mark for any user resource. The above-given system can be improved when the blocks themselves (in additlon to the oode within each block) are traversed in reverse order. In thls case, i r a web is in the llw3 at the end of the next-to-be traversed blook, it l~
no~ necessary to place a low water mark at the top of the most reoently traversed block.
Using Figure 6 and Figure 7 it ~9 possible to see how the method of determining ranges de~crlbed above~ may be performed on the code shown in Figure 6. Starting with instruction 19, webl1 is in the llws. As oan be seen from Table 1, web11 has a user resource pointer to user resource x. Therefore, instruction 19 is a high water mark ~or user resource x. In in~truction 17, web11 is defined, and therefore removed from the llws. There~ore, instruction 17 i~ a low water mark for user resouroe x. A high bound and a low bound for Range 701 for user resource x may be determined ~rom the high water mark and the low water mark given.
~a2938io In instruction 15, web2 is u~ed and it is not ourrently in the llws, therefore it i~ the last u~e of web2. From Table 1, web2 has a u~er resource pointer to u~er resouroe x.
Therefore, instruction 15 i9 a high water mark for user re~ource x. Instruotion 14 i~ the top of blook 503. Web2 is not in the llw9 at the end of block 502. Therefore, instruction 14 i~ a low water mark for user resource x. Range 702 for user relource x may be determined from the high water mark and the low water mark.
In instruction 12, web8 i9 used and it i~ not currently in the llw9~ therefore it is the last use of web8. From Table 1, web8 ha~ a user resource pointer to user resouroe y.
Thererorc, instruation 12 is a high water mark for user reaouroe y. In instruction 10~ web8 is defined. Therefore instruction 10 is a low water mark for uaer resouroe y. Range 703 for user resource x may be determined from the high water mark and the low water mark.
Instruction 9 is the end o~ blook 50t. Web2 i9 in the llws in in~tructlon 9 at the end of block 501. From Table 1, web2 has a user resource pointer to user resource x.
There~ore, in~truction 12 is a hi~h water mark for user resource x.
In instruction 7, web4 is u~ed and it is not in the llw3~
therefore it i8 the last use Or web4. From Table 1, web4 has a resouroe pointer to user resourae z. Tb~refore, in~tructlon 7 is a high water mark for user resource z. In instruction 4, web4 is defined. Therefore, instruction 4 is a low water mark 16 ~9381~
for u3er re~ource z. Range 704 for u3er re30uroe z may be determined from the high water mark and the low ~ater mark.
In in3truction 2, web2 i3 de~ined. There~ore, inqtruction 2 i9 a low water mark for user resouroe x. Range 705 ~or user resource x may be determined from the high water mark ard the low water mark. At this point a range table could be constructed, as is 3hown in Figure 7A.
In the range table, in Figure 7A pointers ~31 from debug symbol table, for user resources x, y and z, point to ranges within the range table. A column 132 contain3 low bound3 for range~ for u3er resouroes x~ y and z. ~ column 133 oontain3 high bounds for ranges for user resouroes x, y and z. A oolumn 134 oontains a looation Por the user resource for the respeotlve ranges. A oolumn 135 indioates the type of resource in whioh user resouroe resides during the given range.
Information about the ranges are associated with the re~pective webs~ For instance, this may be done by addlng a list o~
ranges to a data 3tructure built and used by a portion ~called a register allocator) of code optim~zer 53 whioh allo¢ates registers. Thè data struoture built by the allooator i3 called an inter~erence graph. Each web ha3 a separate entry. The list of ranges for each web is added to the web's entry in the interferenoe graph.
When oode optimizer 53 makes additional passes in the code~ the ranges may neéd to be ad~usted aocordingly. For instance, oode optimizer 53 may perform a copy elimination. A
oopy elimination ~ay be performed when oode optlmizer 53 2 ~ 8l 0 determines that two webs do not interfere, but ~hare a copy instruction in oommon. The copy is removed and the two web~
become a single composite web.
If a web is removed which i9 as~ociated with a user resource, the list of ranges ror the removed web must be added to the composite web~ Figure 8 shows the code of Figure 7 after code optimizer 53 perform~ copy elimination. The following Table 4 show~ the nece~sary modifications to Table 1, resulting from the copy elimination:
Table 4 User Resource Web Number Instructions Resource Pointer web1:web2 web2~web9 web3:web4 web4:web6 web5 6,8 r3 Null web6 7,8,3,4,4,7 r4, r2, r10 z web7:web11 web8:web7 web9 15~16,2,6, r3~ r9, r1 x 15,1,2 web10 16,19 r6 Null web11 17,19,8,12, r9, r5, r11 x,y 16,17,10,12 .
Code optimizer 53 may also perform a constant spill. For in~tance, if a web contains only a constant variable, code optimizer 53 may determine that it is advantageous to free up a regi~ter by reloading the-constant into a register before each use, rather than leaving the constant continually in the register. In this case the ranges, which previously were of type register range, are changed to type constant range. The 18 1~3810 lo¢ation of the user resource i~ changed to equal the constant.
Figure 9 ~hows how the code of Figure 8 i3 modified after code optimizer 53 performs a constant spill. Figure 9A shows how the range table showed in Figure 7A would be modified as a result of the constant spill.
At this point code optimizer 53 allooates register~ to webY. Figure 10 shows the code of Figure 9 after registers have been allocated. Once register~ are allocated to webs, the infor~ation about tho~e register may be filled into the range table. Figure 10A shows the range table of Figure 9A after register allooation.
If, during the register allooation, there are not suffioient registers~ oode optimizer 53 spills some o~ the webs to memory. A spilled web is stored to memory after belng defined, and reloaded before it is used. Nhen thls ooours entries in the range table are changed to 8pill ranges. The low water mark and high water mark remain the same, but the location i8 ohanged to the spill memory looation and the type of range 19 ohanged to spill.
The ranges can often be axpanded by making another pass.
The high water mark may be moved to the end of a basio block or to an instruction that might wipe out the oontents Or the register in which the user resource resides, whiohever first ocoursO
In order to do this, the oode i~ again traversed in reverse order, keeping traok Or the last lnstruction of the basic block aA an extend instruction for each web. A set of 1 9 ~IL29381(~
Plags keeps traok of the registers dePined between the current instruction and the last instruction of the basic block. When a definition of a register is seen, the flag for the appropriate register is set and a pointer to the defining instruction is attached to the web. The defining instruction beoomes a nsw extend instruction for that web.
When an instruction performing a call i9 seen, the call instruction becomes the extend instruction ln all the webs.
This i9 because a call could wipe out the values in any register.
When the use of a web is seen, if the register assigned to that web had been de~ined be~ore the last instru~tion, that instruotion becomes the extend instruotion for that web.
When the traverse i8 finished, for those webs which oontain a range whose high water mark i9 lower than the extend instruction, the extend in3truction becomes the new high water mark, and the range is ad~usted ac¢ordingly.
Finally, additional funotional units within code optimizer may operate on the code to produce ranges which overlap existing ranges. In this oase the range with the lowest priority must be shortened. For example, in Figure 11, a scheduler within code optimi~er 53 has reversed the operations of instructions 11 and instruotion 10. This has oreated a scheduler range 119 which overlapped range 703. Range 703 was created first 9 so has the lowest priority. Therefore, range 703 wa3 shortened. Figure 11A shows how the range table shown ~ '--20 ~z93~
in Figure 1aA i~ modif'ied to re~leot the ~hortening of ran~e 7Q3 .
'; :
: :
.~:
' :
:
. : .
., , '. ~
Claims (10)
1. In a computing system which includes a debugger which is used to debug compiled code generated by a compiler from source code, wherein the debugger accesses a debug symbol table containing a plurality of entries, each entry in the plurality of entries describing user resources used by the source code, an improvement to the computing system comprising:
a range table accessible by the debugger, including specification of locations where user resources reside in the computing system when the computing system executes the compiled code, and specification of ranges within the compiled code when the user resources reside in each of the specified locations, wherein when a list of ranges in the range table specify locations of a first user resource, a first entry from the plurality of entries in the debugger table which describes the first user resource includes a pointer which identifies the list of ranges.
a range table accessible by the debugger, including specification of locations where user resources reside in the computing system when the computing system executes the compiled code, and specification of ranges within the compiled code when the user resources reside in each of the specified locations, wherein when a list of ranges in the range table specify locations of a first user resource, a first entry from the plurality of entries in the debugger table which describes the first user resource includes a pointer which identifies the list of ranges.
2. A computing system as in Claim 1 wherein the range table does not specify locations for all user resources;
wherein the first plurality of entries includes a first subset of entries which describe user resources for which the range table does specify locations and includes a second subset of entries which describe user resources for which the range table does not specify locations; and, wherein, each entry within the first plurality of entries contains a field which indicates whether the entry is in the first subset of entries or the second subset of entries.
wherein the first plurality of entries includes a first subset of entries which describe user resources for which the range table does specify locations and includes a second subset of entries which describe user resources for which the range table does not specify locations; and, wherein, each entry within the first plurality of entries contains a field which indicates whether the entry is in the first subset of entries or the second subset of entries.
3. A computing system as in Claim 2 wherein each entry in the second set of entries contains a pointer which indicates a location in the computing system where a user resource described by the entry resides when the computing system executes the compiled code.
4. A method useful for calculating, during optimization of code, ranges for which user resources reside in certain locations within a computing system, the method comprising:
(a) dividing the code up into basic blocks of straight line code sequences with a single entry point and a single exit point;
(b) calculating webs for each user resource;
(c) determining the range of instructions within each basic block when webs for each user resource is alive;
(d) allocating, for each determined range of instructions for each web, locations in which user resources are stored;
and, (e) storing in a table a description of allocated locations for each determined range.
(a) dividing the code up into basic blocks of straight line code sequences with a single entry point and a single exit point;
(b) calculating webs for each user resource;
(c) determining the range of instructions within each basic block when webs for each user resource is alive;
(d) allocating, for each determined range of instructions for each web, locations in which user resources are stored;
and, (e) storing in a table a description of allocated locations for each determined range.
5. A method as in Claim 4, wherein after step (c) the determined range of instructions for some webs is extended by the following steps:
(c1) combining a first range of instructions for a first web with a second range of instructions for the first web when the first range of instructions is in a first basic block of code and the second range of instructions is in a second basic block of code which immediately follows the first block of code, and when the first web is alive at the last instruction of the first block and is alive at the first instruction of the second block, and wherein the first range of instructions and the second range of instructions are combined into a third range of instructions which includes all the instructions in the first range of instructions and the second range of instructions.
(c1) combining a first range of instructions for a first web with a second range of instructions for the first web when the first range of instructions is in a first basic block of code and the second range of instructions is in a second basic block of code which immediately follows the first block of code, and when the first web is alive at the last instruction of the first block and is alive at the first instruction of the second block, and wherein the first range of instructions and the second range of instructions are combined into a third range of instructions which includes all the instructions in the first range of instructions and the second range of instructions.
6. A method as in Claim 4, additionally comprising the step of:
(f) storing in the table a constant value when the user resource is stored as a constant.
(f) storing in the table a constant value when the user resource is stored as a constant.
7. A method as in Claim 4, additionally comprising the step of:
(f) changing the description of the allocated location for a determined range of instructions when the location in which the user resources are stored are changed for that determined range of instructions.
(f) changing the description of the allocated location for a determined range of instructions when the location in which the user resources are stored are changed for that determined range of instructions.
8. A method as in Claim 4 addditionally comprising the step of:
(f) redetermining a first range of instructions which use a first user resource when a second range of instructions uses the first resource and overlaps the first range of instructions, and when the second range of instructions has a higher priority than the first range of instructions.
(f) redetermining a first range of instructions which use a first user resource when a second range of instructions uses the first resource and overlaps the first range of instructions, and when the second range of instructions has a higher priority than the first range of instructions.
9. A method as in Claim 4 wherein after step (b) is added the following steps:
(b1) combining a first web for a first user resource with a second web for a second resource into a composite web when the first web and the second web share a copy instruction; but do not interfere with each other;
(b2) substituting the composite web for the first web and for the second web as the calculated web for the first user resource and for the second user resource.
(b1) combining a first web for a first user resource with a second web for a second resource into a composite web when the first web and the second web share a copy instruction; but do not interfere with each other;
(b2) substituting the composite web for the first web and for the second web as the calculated web for the first user resource and for the second user resource.
10. In a computing system which includes a debugger which is used to debug compiled code generated by a compiler from source code, an improvement to the computing system comprising:
a resource table including a plurality of resource table entries the entries describing resources in the compiled code;
a debug symbol table including a plurality of debug symbol table entries, the debug symbol table entries describing resources in the source code, wherein when a first resource table entry from the plurality of resource table entries describes a first resource in the compiled code which is equivalent to a first resource in the source code, the first resource table entry will contain a pointer which points to a first debug symbol table entry which describes the first resource in the source code; and, a range table including a range list for at least one of the resources in the source code, wherein when a range list for the first resource in the source code is in the range table, the first debug symbol table entry will contain a pointer which points to the first range list.
a resource table including a plurality of resource table entries the entries describing resources in the compiled code;
a debug symbol table including a plurality of debug symbol table entries, the debug symbol table entries describing resources in the source code, wherein when a first resource table entry from the plurality of resource table entries describes a first resource in the compiled code which is equivalent to a first resource in the source code, the first resource table entry will contain a pointer which points to a first debug symbol table entry which describes the first resource in the source code; and, a range table including a range list for at least one of the resources in the source code, wherein when a range list for the first resource in the source code is in the range table, the first debug symbol table entry will contain a pointer which points to the first range list.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/121,311 US4953084A (en) | 1987-11-16 | 1987-11-16 | Method and apparatus using variable ranges to support symbolic debugging of optimized code |
| US121,311 | 1987-11-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1293810C true CA1293810C (en) | 1991-12-31 |
Family
ID=22395855
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA000576769A Expired - Lifetime CA1293810C (en) | 1987-11-16 | 1988-09-08 | Method and apparatus using variable ranges to support symbolic debuggingof optimized code |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US4953084A (en) |
| EP (1) | EP0317080B1 (en) |
| JP (1) | JP2810675B2 (en) |
| CA (1) | CA1293810C (en) |
| DE (1) | DE3853981T2 (en) |
Families Citing this family (69)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5193190A (en) * | 1989-06-26 | 1993-03-09 | International Business Machines Corporation | Partitioning optimizations in an optimizing compiler |
| US5048018A (en) * | 1989-06-29 | 1991-09-10 | International Business Machines Corporation | Debugging parallel programs by serialization |
| FR2649507B1 (en) * | 1989-07-07 | 1994-07-08 | Bull Sa | METHOD FOR OBSERVING THE EXECUTION OF A PROGRAM LOADED IN A COMPUTER SYSTEM AND DEVICE FOR CARRYING OUT SAID METHOD |
| US5394544A (en) * | 1989-08-07 | 1995-02-28 | Ricoh Co., Ltd. | Software system debugger with distinct interrupt vector maps for debugging and application programs |
| US5274820A (en) * | 1989-08-14 | 1993-12-28 | International Business Machines Corporation | Method and system for eliminating operation codes from intermediate prolog instructions |
| JPH03150636A (en) * | 1989-11-08 | 1991-06-27 | Matsushita Electric Ind Co Ltd | Compiling method |
| US5428793A (en) * | 1989-11-13 | 1995-06-27 | Hewlett-Packard Company | Method and apparatus for compiling computer programs with interproceduural register allocation |
| JP2978189B2 (en) * | 1989-11-16 | 1999-11-15 | シャープ株式会社 | Automatic flowchart creation device |
| US5029170A (en) * | 1989-11-30 | 1991-07-02 | Hansen Robert G | Assembly language programming potential error detection scheme which recognizes incorrect symbolic or literal address constructs |
| US5560009A (en) * | 1990-09-21 | 1996-09-24 | Hewlett-Packard Company | Generating symbolic debug information by merging translation and compiler debug information |
| JPH0816871B2 (en) * | 1990-12-07 | 1996-02-21 | 富士ゼロックス株式会社 | Program translation device and program translation method |
| US5511218A (en) * | 1991-02-13 | 1996-04-23 | Hughes Aircraft Company | Connectionist architecture for weapons assignment |
| US5193180A (en) | 1991-06-21 | 1993-03-09 | Pure Software Inc. | System for modifying relocatable object code files to monitor accesses to dynamically allocated memory |
| US5339428A (en) * | 1991-09-04 | 1994-08-16 | Digital Equipment Corporation | Compiler allocating a register to a data item used between a use and store of another data item previously allocated to the register |
| US5488727A (en) * | 1991-09-30 | 1996-01-30 | International Business Machines Corporation | Methods to support multimethod function overloading with compile-time type checking |
| US5535318A (en) * | 1992-04-30 | 1996-07-09 | Ricoh Company, Ltd. | Debugging system for a hierarchically structured page description language |
| AU4598593A (en) * | 1992-06-05 | 1994-01-04 | Convex Computer Corporation | Computer program debugging in the presence of compiler synthesized variables |
| US5371747A (en) * | 1992-06-05 | 1994-12-06 | Convex Computer Corporation | Debugger program which includes correlation of computer program source code with optimized object code |
| JP3205406B2 (en) * | 1992-11-10 | 2001-09-04 | 富士通株式会社 | Reference target variable determination processing method and translation processing system |
| US5555419A (en) * | 1993-01-06 | 1996-09-10 | Digital Equipment Corporation | Correlation system |
| JP2856663B2 (en) * | 1993-01-15 | 1999-02-10 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Optimization method and apparatus for defining visible boundaries in compiled code |
| JPH06242943A (en) * | 1993-02-15 | 1994-09-02 | Nec Corp | Source code level debugging device |
| US5548761A (en) * | 1993-03-09 | 1996-08-20 | International Business Machines Corporation | Compiler for target machine independent optimization of data movement, ownership transfer and device control |
| US6178547B1 (en) | 1993-06-17 | 2001-01-23 | Metaware Incorporated | Method and apparatus for generating non-redundant symbolic debug information in computer programs |
| US5495561A (en) * | 1993-06-21 | 1996-02-27 | Taligent, Inc. | Operating system with object-oriented printing interface |
| US5758160A (en) * | 1993-06-28 | 1998-05-26 | Object Technology Licensing Corporation | Method and apparatus for building a software program using dependencies derived from software component interfaces |
| US5325533A (en) * | 1993-06-28 | 1994-06-28 | Taligent, Inc. | Engineering system for modeling computer programs |
| US5519866A (en) * | 1993-06-28 | 1996-05-21 | Taligent, Inc. | Method and apparatus of incrementally linking components of a modeled computer program |
| US5613063A (en) * | 1994-07-01 | 1997-03-18 | Digital Equipment Corporation | Method and apparatus for checking validity of memory operations |
| US5694539A (en) * | 1994-08-10 | 1997-12-02 | Intrinsa Corporation | Computer process resource modelling method and apparatus |
| US5537620A (en) * | 1994-09-16 | 1996-07-16 | International Business Machines Corporation | Redundant load elimination on optimizing compilers |
| CA2153032A1 (en) * | 1994-09-16 | 1996-03-17 | William Martin Schell | Method of and apparatus for efficiently debugging programs given limited system resources |
| US5696973A (en) * | 1995-02-17 | 1997-12-09 | International Business Machines Corporation | Index-based method for supporting multimethod function overloading with compile-time type checking and run-time dispatch |
| JPH1021086A (en) * | 1996-06-28 | 1998-01-23 | Matsushita Electric Ind Co Ltd | Program converting device and debugging device |
| US5758061A (en) * | 1995-12-15 | 1998-05-26 | Plum; Thomas S. | Computer software testing method and apparatus |
| US6091896A (en) * | 1995-12-22 | 2000-07-18 | Hewlett-Packard Company | Debugging optimized code using data change points |
| US5860008A (en) * | 1996-02-02 | 1999-01-12 | Apple Computer, Inc. | Method and apparatus for decompiling a compiled interpretive code |
| US5764989A (en) * | 1996-02-29 | 1998-06-09 | Supercede, Inc. | Interactive software development system |
| US5848274A (en) * | 1996-02-29 | 1998-12-08 | Supercede, Inc. | Incremental byte code compilation system |
| US6067413A (en) * | 1996-06-13 | 2000-05-23 | Instantations, Inc. | Data representation for mixed-language program development |
| US6249881B1 (en) * | 1997-07-01 | 2001-06-19 | National Semiconductor Corporation | Method for enabling and servicing critical interrupts while running an interrupt based debug monitor |
| US6016556A (en) * | 1997-07-17 | 2000-01-18 | Tektronix, Inc. | System for identifying an acquisition sample corresponding to a source code statement |
| US6016557A (en) * | 1997-09-25 | 2000-01-18 | Lucent Technologies, Inc. | Method and apparatus for nonintrusive passive processor monitor |
| US6263489B1 (en) * | 1998-04-30 | 2001-07-17 | Hewlett-Packard Company | Method and apparatus for debugging of optimized code |
| US6434741B1 (en) | 1998-04-30 | 2002-08-13 | Hewlett-Packard Company | Method and apparatus for debugging of optimized code using emulation |
| US6202175B1 (en) * | 1998-08-05 | 2001-03-13 | International Business Machines Corporation | Debuggin client server programs from third party workstations |
| US6223307B1 (en) * | 1998-08-05 | 2001-04-24 | International Business Machines Corporation | Debugging client server programs from third party workstations |
| US6256777B1 (en) * | 1998-10-09 | 2001-07-03 | Hewlett-Packard Company | Method and apparatus for debugging of optimized machine code, using hidden breakpoints |
| US6108659A (en) * | 1998-12-22 | 2000-08-22 | Computer Associates Think, Inc. | Method and apparatus for executing stored code objects in a database |
| CA2368472A1 (en) * | 1999-06-03 | 2000-12-14 | Algorithmics International Corp. | Risk management system and method providing rule-based evolution of a portfolio of instruments |
| US20020100031A1 (en) * | 2000-01-14 | 2002-07-25 | Miguel Miranda | System and method for optimizing source code |
| US6968543B2 (en) * | 2000-03-10 | 2005-11-22 | Fujitsu Limited | Information processing apparatus |
| JP2002108756A (en) * | 2000-09-28 | 2002-04-12 | Hitachi Ltd | User interface integrating method |
| US7293264B2 (en) * | 2003-09-17 | 2007-11-06 | Nokia Corporation | Method and a device for abstracting instruction sequences with tail merging |
| US9111033B2 (en) | 2012-04-17 | 2015-08-18 | International Business Machines Corporation | Compiling source code for debugging with user preferred snapshot locations |
| US8910126B2 (en) | 2012-04-18 | 2014-12-09 | International Business Machines Corporation | Compiling source code for debugging with variable value restoration based on debugging user activity |
| US8826240B1 (en) | 2012-09-29 | 2014-09-02 | Appurify, Inc. | Application validation through object level hierarchy analysis |
| US9015832B1 (en) | 2012-10-19 | 2015-04-21 | Google Inc. | Application auditing through object level code inspection |
| US9113358B1 (en) | 2012-11-19 | 2015-08-18 | Google Inc. | Configurable network virtualization |
| US9268668B1 (en) | 2012-12-20 | 2016-02-23 | Google Inc. | System for testing markup language applications |
| US9274935B1 (en) | 2013-01-15 | 2016-03-01 | Google Inc. | Application testing system with application programming interface |
| US9122791B2 (en) * | 2013-03-05 | 2015-09-01 | International Business Machines Corporation | Identifying a storage location for a storage address requested during debugging |
| US9021443B1 (en) | 2013-04-12 | 2015-04-28 | Google Inc. | Test automation API for host devices |
| US9268670B1 (en) | 2013-08-08 | 2016-02-23 | Google Inc. | System for module selection in software application testing including generating a test executable based on an availability of root access |
| US9367415B1 (en) | 2014-01-20 | 2016-06-14 | Google Inc. | System for testing markup language applications on a device |
| US9491229B1 (en) | 2014-01-24 | 2016-11-08 | Google Inc. | Application experience sharing system |
| US9170922B1 (en) | 2014-01-27 | 2015-10-27 | Google Inc. | Remote application debugging |
| US9864655B2 (en) | 2015-10-30 | 2018-01-09 | Google Llc | Methods and apparatus for mobile computing device security in testing facilities |
| US10929216B2 (en) * | 2019-01-29 | 2021-02-23 | EMC IP Holding Company LLC | Application crash analysis techniques when memory dump and debug symbols are not co-located |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4462077A (en) * | 1982-06-24 | 1984-07-24 | Bell Telephone Laboratories, Incorporated | Trace facility for use in multiprocessing environment |
| US4567574A (en) * | 1983-03-14 | 1986-01-28 | International Business Machines Corporation | Optimizing cobol object code instruction path length with respect to perform statements |
| US4589068A (en) * | 1983-10-03 | 1986-05-13 | Digital Equipment Corporation | Segmented debugger |
| US4667290A (en) * | 1984-09-10 | 1987-05-19 | 501 Philon, Inc. | Compilers using a universal intermediate language |
| DE3678893D1 (en) * | 1985-10-03 | 1991-05-29 | Mitsubishi Electric Corp | COMPUTER PROGRAM DEBUG SYSTEM. |
| US4782444A (en) * | 1985-12-17 | 1988-11-01 | International Business Machine Corporation | Compilation using two-colored pebbling register allocation method such that spill code amount is invariant with basic block's textual ordering |
| US4819234A (en) * | 1987-05-01 | 1989-04-04 | Prime Computer, Inc. | Operating system debugger |
-
1987
- 1987-11-16 US US07/121,311 patent/US4953084A/en not_active Expired - Lifetime
-
1988
- 1988-09-08 CA CA000576769A patent/CA1293810C/en not_active Expired - Lifetime
- 1988-10-19 DE DE3853981T patent/DE3853981T2/en not_active Expired - Fee Related
- 1988-10-19 EP EP88309777A patent/EP0317080B1/en not_active Expired - Lifetime
- 1988-11-16 JP JP63289913A patent/JP2810675B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| DE3853981D1 (en) | 1995-07-20 |
| US4953084A (en) | 1990-08-28 |
| EP0317080B1 (en) | 1995-06-14 |
| DE3853981T2 (en) | 1995-10-12 |
| EP0317080A2 (en) | 1989-05-24 |
| JP2810675B2 (en) | 1998-10-15 |
| JPH01166141A (en) | 1989-06-30 |
| EP0317080A3 (en) | 1991-01-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA1293810C (en) | Method and apparatus using variable ranges to support symbolic debuggingof optimized code | |
| US4951195A (en) | Condition code graph analysis for simulating a CPU processor | |
| US5301302A (en) | Memory mapping and special write detection in a system and method for simulating a CPU processor | |
| US5956512A (en) | Computer program debugging in the presence of compiler synthesized variables | |
| Gabriel | Performance and evaluation of Lisp systems | |
| US5652889A (en) | Alternate execution and interpretation of computer program having code at unknown locations due to transfer instructions having computed destination addresses | |
| US8726257B2 (en) | File attributes for flexible linking | |
| US5742802A (en) | Method and system for efficiently mapping guest instruction in an emulation assist unit | |
| US7856627B2 (en) | Method of SIMD-ization through data reshaping, padding, and alignment | |
| KR100947137B1 (en) | Method and apparatus for implementing a bi-endian capable compiler | |
| US20030093780A1 (en) | Annotations to executable images for improved dynamic optimization of functions | |
| US20120198427A1 (en) | Ensuring Register Availability for Dynamic Binary Optimization | |
| WO1984002013A1 (en) | Adaptive domain partitioning of cache memory space | |
| US20120198428A1 (en) | Using Aliasing Information for Dynamic Binary Optimization | |
| Bailey et al. | A formal model and specification language for procedure calling conventions | |
| US6658657B1 (en) | Method and apparatus for reducing the overhead of virtual method invocations | |
| JPH03219331A (en) | Apparatus and method for storing firmware in rearrangeable format | |
| Tarditi | Design and implementation of code optimizations for a type- directed compiler for Standard ML | |
| US6330691B1 (en) | Use of dynamic translation to provide breakpoints in non-writeable object code | |
| EP0327198B1 (en) | Processor simulation | |
| WO2001057656A2 (en) | Reduced size object headers | |
| Jay | The FISh language definition | |
| JPH02292648A (en) | Multiplex virtual storage system and address controller | |
| CN112199217A (en) | Software and hardware cooperative thread private data access optimization method | |
| Dowd et al. | Run time type information in Mercury |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKLA | Lapsed |