2016 5th IIAI International Congress on Advanced Applied Informatics

Reverse Engineering from Mainframe Assembly to
C Codes in Legacy Migration
Daisuke Fujiwara and Nagisa Ishiura

Ryo Sakai, Ryo Aoki, and Takashi Ogawara

School of Science and Technology
Kwansei Gakuin University
2–1 Gakuen, Sanda, Hyogo, 669–1337, JapanSYSTEM’S Co., Ltd.
7–24–5 Nishigotanda
Shinagawa-ku, Tokyo, 141–0031 Japan

Abstract—This paper presents a method of constructing C
programs from mainframe assembly programs. IBM mainframe
assembly programs, which are called as subroutines from programs written in high-level language such as COBOL, areautomatically translated into equivalent C programs. The assembly programs are converted into intermediate representation(IR) of the SSA form on which dataﬂow analysis, recognitionof control structures, and pattern match based transformation
are applied to produce codes with readability. Our methodfeatures documentation of the translation process. Along withtranslation, correspondence between the source assembly codes
and the resulting C codes are generated as documents, whichplays very important role in manually correcting incomplete
C codes from architecture dependent codes or self morphingcodes. Furthermore, comments in the assembly programs areembedded into appropriate positions in the resulting C programs.
A prototype system based on our method successfully translated
some assembly codes into C program with function, if, and dowhile structures.

I.

IBM mainframe assembly codes into to C programs. Assembly
codes are converted into intermediate representation, to whichreverse engineering such as reconstruction of control structures
are performed to generate C codes with reasonable readability.
However, it should be noted that static translation does notalways succeed; architecture speciﬁc codes and self morphingcodes may not always be converted to correct codes. In
such cases, the resulting codes must be ﬁrst inspected to see
what went wrong and be modiﬁed manually. In this situation,
resulting C codes alone are not enough; it is very important thatthe process of translation or correspondence between original
assembly code fragments and the resulting code sequence
should be well documented.
This paper proposes a method of translating IBM assembly
programs to equivalent C programs, with emphasis on generating auxiliary information to understand the resulting C codes
and the conversion process. C codes with high readability are
generated via intermediate representation extracted from thegiven assembly codes, in the similar way as [5], [6], [7]. At
the same time, a table to show the correspondence between
the assembly instructions and the resulting C code fragment isgenerated. Furthermore, the comments in the assembly codes,
which hold important information to understand the program
such as the authors of the codes, how the codes should be used,
the intent of each code fragment, etc., are embedded into theproper position of the resulting C programs.

I NTRODUCTION

In many business and enterprise systems, mainframe computers have long been used as core computing systems, fortheir high reliability and fault tolerance. In recent years,
however, as lower cost open systems such as Linux andWindows servers have gained higher performance, there has
been motivation to move from the legacy systems to the open
systems. Since the legacy systems accumulate business knowhow of many years, it is often a rational choice to port theexisting systems to operate on the open systems than to redevelop equivalent systems. Such kind of porting is called“legacy migration,” on which there is a growing demand.

The tool based on the proposed method is implemented in
Perl5, which has successfully converted some assembly programs consisting of about 100 lines into working C programs.

One of the core technologies in legacy migration is portingof programs on the mainframe computers, written in COBOL,
PL/1, assembly languages, etc., to run on the modern systems. Programs written in high-level languages may work byre-compilation, or they can be auto-converted [1] or autocorrected to run on the target systems. Since they are relatively
easy to understand, manual modiﬁcation on the resulting codesis also easy. On the other hand, assembly programs needs
manual translation to some languages, after understanding their
behavior. Although those assembly programs are usually small,a single legacy system may contain hundreds, or sometimes
thousands of assembly codes, which needs enormous manhours for migration.

II.

A. Target of Conversion
In this paper, we deal with the problem of converting hand
written assembly programs of the IBM 370–390 mainframes
into C programs, for there is a big demand for migration fromthis architecture. As shown in Fig. 1, we assume that theassembly programs are called as subroutines from the otherprograms written in assembly, COBOL, etc. We also assume
that C libraries equivalent to the library routines and macros
called from the assembly programs are already prepared.
The ﬁrst priority in this kind of conversion is that theresulting C programs should work correctly. This needs thesame technology as binary translation [2]. The second priority
is readability of the reconstructed C programs. This is because
the new programs must be maintained, or sometimes be

To solve this problem, there have been several attempts on
automated conversion of assembly codes to high-level codes.
Literatures [5], [6], [7] have presented methods of translating
978-1-4673-8985-3/16 $31.00 © 2016 IEEE
DOI 10.1109/IIAI-AAI.2016.37

M IGRATION OF A SSEMBLY P ROGRAMS

1058

Fig. 1.

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:

Target of conversion.

debugged, on the new platforms. This needs the technologies
used in decompilation [3], [4].
There have been several attempts to convert mainframe assemblies to higher-level programs. Feldman [5] translates IBM
assemblies to C programs via an intermediate representation
named HLL. Ward [6], [7] makes use of a formal intermediate
model FermaT to generate C programs with high readability
from IBM assembly codes.
However, automatic translation does not always succeed.
Since the character codes used on the mainframe computers
and the open systems are different, routines that directly manipulate character bit patterns may not be converted to intended
programs. Differences of the address spaces and addressing
conventions, such as the use of the most signiﬁcant bit on the
IBM mainframes, cause the same problems. Many unexpected
coding techniques are often used in hand written assemblies.
Furthermore, it is impossible to convert self morphing codes
completely by static translation.
Thus, in a practical point of view, resulting codes must
be investigated to see if the translation was correct or to see
what went wrong. For this purpose, documentation of how
codes are translated would be very important. At the sametime, comments in the original assembly codes would be very
helpful, for they describe the intentions behind the codes orgive explanations to complicated logic.

Fig. 2.

EMONTH

ER_FMT
FC_EOM
EOM

EOM1

RET

MLAST

SAVE
WORK

CSECT
USING EMONTH,12
STM
14,12,12(13)LA
12,0(,15)
LA
15,SAVE
ST
13,4(,15)ST
15,8(,13)
LR
13,15
LM
3,4,0(1)CLC
0(6,4),=C’00000000’
BNE
ER_FMTB
FC_EOMEQU*
ABEND 0999,DUMP
BAL
14,EOM
EQU*
MVC
0(8,4),=CL9’ ’
LA
0,6
LR
1,3
EQU
*
CLI
0(1),C’0’
BL
RET
CLI
0(1),C’9’
BH
RET
LA
1,1(,1)BCT
0,EOM1CLC
4(2,3),=C’01’
BL
RET
CLC
4(2,3),=C’12’
BH
RET
PACK WORK,4(2,3)
CVB
2,WORKBCTR 2,0MH
2,=H’4’LA
5,MLAST
AR
2,5
LH
0,4(,2)SH0,0(,2)CVD
0,WORKUNPK 6(2,4),WORKOI
7(4),X’F0’
MVC
0(6,4),0(3)
B
RET
EQU
*
L
13,4(,13)
LM
14,12,12(13)
SLR
15,15
BR
14
DC
H’000’,H’000’
DC
H’031’,H’031’
DC
H’059’,H’060’
DC
H’090’,H’091’
DC
H’120’,H’121’
DC
H’151’,H’152’
DC
H’181’,H’182’
DC
H’212’,H’213’
DC
H’243’,H’244’
DCH’273’,H’274’
DCH’304’,H’305’
DC
H’334’,H’335’
DCH’365’,H’366’
LTORG
DS
18F
DS
D
DROP 12
LTORG
SPACE
END

IBM assembly program.

B. IBM Assembly
The IBM mainframes have 32bit architecture. It has 16
general purpose registers numbered 0 through 15. It deals
with 32bit, 16bit, and 8bit binaries as well as character stringsand packed/zone decimals. The instruction set consists of 631
instructions with 0, 1, 2, or 3 operands.
An example of the IBM assembly program is shown in
Fig. 2. This code deﬁnes a subroutine named EMONTH which
receives the address to a date in YYYYMMDD form as theﬁrst parameter, and write the last day of the month of the datein the same form at the address passed as the second parameter.
III.

C ONVERSION OF M AINFRAME A SSEMBLY TO C

A. Overview
The ﬂow of our translation process is shown in Fig. 3.
A given assembly program is compiled into an intermediate
representation (IR) of the SSA (static single assignment) form,
where each instruction is decomposed into atomic operations.
Dataﬂow analysis and a various kind of transformation on the
IR are performed to generate a resulting C program.
B. Intermediate Representation (IR)The structure of the IR in our method is shown in Fig. 4.
The root node Assembly, representing the assembly program

00000000
00000100
00000200
00000300
00000400
00000500
00000600
00000700
00000800
00001100
00001200
00001300
00001400
00001500
00001600
00001700
00001800
00001900
00002000
00002100
00002200
00002300
00002400
00002500
00002600
00002700
00003000
00003100
00003200
00003300
00003400
00003500
00003600
00003700
00003800
00003900
00004000
00004100
00004200
00004300
00004400
00004500
00004600
00004700
00004800
00004900
00005000
00005100
00005200
00005300
00005400
00005500
00005600
00005700
00005800
00005900
00006000
00006100
00006200
00006300
00006400
00006500
00006600
00006700
00006800
00006900
00007000
00007100transformations
assembly
programFig. 3.

parse

IR
(SSA)

generation

C
programFlow of translation process.

under conversion, consists of a list of Sections and a SymbolTable. The SymbolTable keeps track of all the variable names,
function names, label names, etc. in the program. The Section
represents a section in the program, a group of instructions anddata placed in contiguous storage locations, which has a listof Functions. The Function represents a subroutine and has alist of Ifs, Loops, and BasicBlocks. The If and Loop represent
if and do-while structures having then/else parts and a bodypart, respectively. The BasicBlock represents a basic block
consisting of a list of Operations and links to its next basic
blocks. The Operation represents an atomic operation, such asarithmetic/logical, load/store, string and decimal operations.
Fig. 5 shows some examples of conversion from instructions to IR. A load instruction (L) is decomposed into a
32bit addition (addu32) to calculate the address and a 4-bytememory access operation (load32). String and decimal data
manipulation to implement instructions like AP (add packed
decimal) and CLC (compare logical character) are dealt with1059

reachable to b
1

1reachable from t
body

t

9

t

3

10

3

4

4

5

6

5
11
b

12

12

8

Fig. 4.

assembly⇒

AP DAT1,DAT2+5(3)CLC 4(2,4),=C’01’

⇒
⇒

IR

Fig. 6.

addr = addu32(r13, 4)
r11 = load32(addr)
cc=addpack(DAT1, 8, DAT2, 8)
addr=addu32(r4, 4)
cc=compstr(addr, C’01’, 2)

Recognition of loop body.

10f

Conversion from instructions to IR.
4

as atomic operations.
85Fig. 7.

1)

C. Recognition of Control Structures
1) Recognition of Functions: Firstly, all the entry points
in the IR are identiﬁed. The entry points are either 1) thebasic blocks starting with nop operations converted fromENTRY instructions, or 2) the basic blocks which are thetargets of jump operations converted from BAL, BALR, andBAS instructions. A function is extracted by enumerating all
the basic blocks reachable from each entry point. In hand
written assembly codes, there are cases where a basic blockis reachable from multiple entry points. For simplicity, suchsituation is averted by cloning the basic blocks.

2)2) Recognition of Loops: Do-while loops are recognizedaccording to the following steps.

2)

3)
4)
5)

1

2

0

3

11

6

12

7

13

reachable ffrom tt
4

14

2

reachablefrom e

3

e 11

6

12

7

13

14

j

The lists of the operations translated from the instructions
are converted to the SSA form. This normalizes different
assembly code sequences of the same meaning to the same IR.
The SSA form is also useful in unnecessary code elimination(in III-D) and transformation by pattern matching (in III-F).
After the SSA conversion, dataﬂow analysis is performed anddeﬁnition/reference relation is stored into the IR.

1)8Structure of IR.

L 11,4(,13)

Fig. 5.

9
10

6

11
b

loop

Enumerate all the loops by traversing basic blocks
from the starting point of recognition (which is theentry point of the function in the ﬁrst iteration).
Choose a loop, whose bottom basic block b is thefarthest from the starting point and the top basic
block t is the nearest to the starting point. This is torecognize the outermost loop ﬁrst and to avoid jump
into the loop.
Determine set B of the basic blocks that form thebody of the loop, which are reachable from t andreachable to b (as shown in Fig. 6).
Extract the continuation condition of the loop fromthe branch condition of the bottom basic block b, andconstruct the data structure of the loop.
Apply this process to the other basic blocks in thefunction and the body of the loop until no loop is
detected.

3)
4)

8

9
10

5

9
10

Choice of branch and join nodes.

Choose a set of branch point f and join point j.
By traversing basic blocks from the starting point ofrecognition (the entry point of the function in the ﬁrst
iteration), select the basic block f that has branch
and is nearest to the starting point. Let t and e be
the next basic blocks of f . Then, identify the joining
basic block j that are reachable from both t and e andyet nearest to f (see Fig. 7). This is to avoid jump
into then and else parts of the if statement. Note that
there are cases where there is no joining point j.
Identify the sets of basic blocks T and E that belong
to then part and else part, respectively, of the if
statement. Let T  be the set of the basic blocks
reachable from t. Let X be the set of basic blocks inT  that are directly reachable from the basic blocks
in T  , and X  be the set of the basic blocks reachable
from X. Then T is deﬁned as T  ∪ X  (see Fig. 8).
E is computed in the same way.
Extract the branch condition from the basic block f
and construct the data structure of the if statement.
Apply this process to the other basic blocks in thefunction and the then part and else part of the if
statement, until no branch is detected.

D. Elimination of Register Save/Restore and Dead Codes
Based on the result of the data ﬂow analysis, codes forregister save and restore of each function, which are no morenecessary in C programs, are deleted. Store operation s of
32bit data is judged as save codes and is removed from the IR
if 1) the address operand of s is obtained by adding offset of0, 4, · · ·, or 68 to register 13, and 2) no operation deﬁnes thedata operand of s. Similarly, 32bit load operation l is regarded
as restore codes and is eliminated if 1) the address operand ofl is obtained by adding offset of 0, 4, · · ·, or 68 to register 13,
and 2) no operation uses the result of l.

3) Recognition of Conditionals: If statements are recognized in the following steps.
1060

C
1
0

reachable ffrom t
t
4

1

2

0

3

e 11

6

12

7
8
5

13

T
t
4

14

2

8
5

reachablefrom e
e 11

6

12

7

j
9
10

f

3

13

0

T
t
4

14

2

E
e 11

6

12

7

j
9
10

f

3

8
5

13

C
14

j
9
10

Recognition of then and else parts.
IR

Generation of expression with multiple operations.

DAT1 DSECTA DS FB DS 4C
・・・
MAIN CSECT⇒USING DAT1,2
MVI
A,123
MVC
B,=C’abcd’C

r10=add32(r10,r7)⇒ r10=r10+r7;
cc=addpack(D1,8,D2,8) ⇒ cc=addpack(D1,8,D2,8);
cc=compstr(s,C’01’,2) ⇒ cc=compstr((char*)s, "01",2);Fig. 9.

C’

r1_1=mul32(r1,X)
r2 = r1*X;
r2_1=load32(r1_1)
r1 = (r2+Y)*z;⇒
r1_2=add32(r1_1,Y)r2 = r2+T
r1_3=mul32(r1_2,Z)r2_2=add32(r2_1,T)

Fig. 10.
Fig. 8.

C’

r1_1=mul32(r1,X)
r1 = ((r1*X)+Y)*Z;⇒
r1_2=add32(r1_1,Y)
r1_3=mul32(r1_2,Z)

1

IR to C Conversion.

・・・

Dead codes, which are often created during long years’
maintenance, are eliminated during the function recognition
process (in III-C1).

Fig. 11.

typedef struct {int A;
char B[4];} DAT1_t;
int main(void){((DAT1_t*) r2)->A = 123;
strncpy( ((DAT1_t*) r2)->B,"abcd", 4);・・・

DSECT Conversion

IV.

D OCUMENTATION

Due to limitation of static translation and to architecturalissues, C programs generated from assembly programs may notalways work. In such cases, the C programs must be inspected
and modiﬁed manually. Even after the new C programs run
successfully, they must be altered for maintenance. In such asituation, understanding of the code must be important. This
paper proposes (1) to generate a table to show correspondence
between the original and the resulting codes, and (2) toembed comments in the original assembly program into proper
positions of the translated C program.

E. IR to C Conversion and Handling of Dummy Sections
The IR is almost straightforwardly converted into a Cprogram. The registers and variables in the original assembly
program are treated as global variables in the C program.
Arithmetic/logic operations and load/store operations are also
converted into the corresponding operations in the C program.
Operations on strings and decimals are translated into function
calls to the the support library. Fig. 9 shows examples of
the conversion, where r10 and r7 are registers, cc is thecondition code, addpack and compstr are support librarycalls for addition on packed decimals and comparison on
strings, respectively.

A. Correspondence between Instructions and Statements
Along with a working C programs for a given assembly
program, a table to show the correspondence between original
instructions and resulting C code fragments is generated in an
HTML ﬁle. Fig. 13(a) shows an example. The STM instruction
in line 113 has no corresponding C code because it is recognized as a save code and deleted. The L instruction in line 114
has been translated into the two C statements. The resulting
C statements for the AH and SH instructions in lines 115–116
are grouped because their relation is many-to-many. Note thatthe rows of the table is based on the order of the statements in
the C program, so the assembly instructions are reordered as
123, 124, 127, 125, 126, and 128 as the result of if statement
recognition.

In order to enhance readability, arithmetic operations arecollected into a single expression whenever possible. Fig. 10shows examples. If the results of all the operations are referenced only once, they are grouped into a single expression.
A dummy section of the IBM assembly, initiated by DSECT
instruction, is a section that results in no machine instruction
nor data area but is used to specify the layout of the aggregate
data passed between subroutines. In our method, the memory
layout described by DSECT is converted to deﬁnition of thecorresponding struct type and the data are accessed using theregister variable designated by USING instruction as a basepointer. Fig. 11 shows an example. The DSECT instruction
deﬁnes data layout with two items A and B, and the MAIN
routine accesses the data area pointed by register 2 according to
the layout. The dummy section is expressed by type DAT1_t
and the data are accessed using r2 as a base pointer.

The table is generated by referencing the back pointers (depicted in dashed arrows in Fig. 13(b)) from the IR operations
to the assembly instructions. If there is no IR operation for
1 a virtual IR operation NOP
an assembly instruction (as ),is generated. When one or more IR operations have links to
1 and ),2 a table entry isa single assembly instruction (as created after all the IR operations for the assembly instruction
are translated to C statements. If multiple IR operations aregrouped to form a single C statement, all the instructions linked
3
to the operations are put into an entry of the table (as ).

F. Readability Improvement by Pattern Matching
In our method, further readability improvement is attempted by pattern matching based transformation. This is realized by deﬁning rewriting rules on tree structures consistingof IR operations. Fig. 12(a) deﬁnes a tree rewriting rule to
make a conditional statement based on string comparison morereadable. IR in Fig. 12(b) is converted into IR’ by the rule,
resulting in program C’ which should be better than C.

B. Embedding Assembly Comments to C
A comment of the IBM assembly are either 1) a string
placed in the same line of an instruction at the right of the1061

C’MXD’ r3 3...
0: STM 14,12,12(13)1: *calculate
2: *(modified 2005.10.3)
3: SH 0,0(,2) SUB
4: AH 0,0(,3) ADD
5: *end calculate
6: EJECT
7: L 15,CALLADR LOAD
8: *call BDISPLAY
9: BALR 14,15 CALL...

C’MXD’ r3 3
strncmpcompstr

E

0

MXD
==

NZ

MXD

next
next

(a) Rewriting rule

upper comments of 3: SH

right comment of 3: SH
right comment of 4: AH
lower comment of 4: AH

ASM
CLC
BE

=C’MXD’,0(R3)MXD

Fig. 14.

IR
cc = compstr(C’MXD’, r3, 3)
BB.next = {condv=>cc, cond=>E, then=>MXD}

Assembly...
0: STM 14,12,12(13)1: *calculate
2: *(modified 2005.10.3)
3: SH 0,0(,2) SUB
4: AH 0,0(,3) ADD
5: *end calculate
6: EJECT
7: L 15,CALLADR LOAD
8: *call BDISPLAY
9: BALR 14,15 CALL...

tmp0 = strncmp(C’MXD’, r3, 3)
tmp1 = equ32(tmp0,0)BB.next = {condv=>tmp1, cond=>NZ, then=>MXD}

C
cc = compstr("MXD", (char*) r3, 3);
if ( cc & cc_E )goto MXD;

C’
if (strncmp("MXD", (char*) r3, 3)== 0)
goto MXD;(b) Application of the ruleFig. 12.

Readability improvement by pattern matching.
Fig. 15.

2)3)(a) Correspondence table (HTML)

Generation of correspondence table.

1)

operands of the instruction, or 2) a string in a line startingfrom character ’*’. In our method, assembly comments are
lined to instructions, and are embedded into the resulting C
program as their corresponding C statements are generated.
2)

Assembly comments are classiﬁed into the following 3
types and are linked to instructions. Two instructions END(marking the end of the program) and EJECT (forcing a page
break in source code listing) plays different role in comment
classiﬁcation than the other instructions, so in this paper,
they are referred to as delimiter instructions and the other
instructions as normal instructions.
1)

C
...
0: //*calculate
1: //*(modified 2005.10.3)
2: uint32_t addr0=r2;// SUB
3: int16_t tmpvar0=*(int16_t*)addr0;
4: uint32_t addr1=r3;// ADD
5: int16_t tmpvar1=*(int16_t*)addr1;
6: r0=r0-(int32_t)tmpvar0+(int32_t)tmpvar1;
7: //*end calculate
8: //*call BDISPLAY
9: BDISPLAY( (void**) r1 ); // LOAD
10:// CALL...

Comment embedding.

previous instruction of i are deﬁned as the upper
comments of i. In Fig. 14, for example, lines 1–2
are the upper comments of the SH instruction in line
3.
Right comments
A comment placed at the right of normal instruction
i is deﬁned as the right comment of i. In Fig. 14,
string SUB in line 3 is the right comment of the SH
instruction.
Lower comments
The lower comments of normal instruction i exist
only when i’s next instruction is a delimiter instruction. Let k be the next normal instruction ofi, and j be the previous (delimiter) instruction ofk. Then comments between i and j are deﬁned aslower comments of i. In Fig. 14, line 5 is the lower
comment of the AH instruction in line 4.

Based on the above classiﬁcation, the positions of thecomments in the C program are determined as follows.

(b) Establishing the correspondence
Fig. 13.

Classiﬁcation of comments.

IR’

3)

The upper comments of instruction i are placed above
the ﬁrst C statement generated from i. In Fig. 15, forexample, since SH instruction in line 3 is expanded tostatements in lines 2, 3, and 6, the upper commentsof SH (assembly lines 1–2) are embedded into lines
0–1 of the C program.
The right comment of instruction i is placed at theright of the ﬁrst C statement generated from i, as //SUB in line 2 of the C program.
The lower comments of instruction i are placed below
the last C statement generated from i. The assemblycomments in line 5 goes to line 7 of the C program.

Comment generation according to this policy is implemented by making use of the back pointer from the IR
operations to the assembly instructions.

Upper comments
Comments between normal instruction i and the
1062

V.

IMPLEMENTATION

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:
99:
100:

A migration system based on the proposed method has been
implemented in Perl 5. It operates on Ubuntu 14.04LTS, Mac
OSX 10.10, and Cygwin on Windows. Currently, translationof 86 instructions out of 631 has been supported.
Fig. 16(a) is the result of conversion from the assembly
program in Fig. 2. Subroutine EOM (in lines 16-48) of theassembly was converted to the function in lines 30–75. The
code is structured with a do-while loop (in lines 34–46) and
if statements (in lines 36–45, 48–71, and 51–70). In line 54,
multiple operations are grouped into a single statement. Patternmatching based transformation proposed in III-F was applied
to the string comparison in lines 36, 39, 48, and 51. The
behavior of the converted program was conﬁrmed by the driverprogram in Fig. 16(b).
There are some limitations in our current implementation.
The resulting C programs do not run properly on 64bit
machines, for the memory layout of the original IBM assemblyis based on 32bit architecture. The current system does notsupport EX instruction which modiﬁes other instructions.
VI.

C ONCLUSION

This paper has proposed a method of converting IBM
assembly programs to C programs, and at the same time
generating a document of conversion and embedding assemblycomments into C programs. Future work includes supportof the remaining instructions, improvement of readability byadding tree rewriting rules, and migration to 64bit architecture.
ACKNOWLEDGMENT
The authors would like to thank Kenji Okamoto of SYSTEM’S Co., Ltd. for valuable advice for this research. We
would also like to thank all the members of Ishiura Lab.
of Kwansei Gakuin University for their help developing theprototype systems. This work was partly supported by Smalland Medium Enterprise Agency’s “Services for reforming
SMEs and micro-businesses, manufacturing, commerce andservices” of ﬁscal 2013.
R EFERENCES[1]

T. Ogawara: “Information processing apparatus, information processing
method, and program,” Japanese patent, 2014–215938 (Nov. 2014).
[2] C. Cifuentes, M. Van Emmerik, D. Ung, D. Simon, and T. Waddington:“Preliminary experiences with the use of the UQBT binary translation
framework,” in Proc. Workshop on Binary Translation, pp.12–22 (Oct.
1999).
[3] M. Van Emmerik: Static single assignment for decompilation, PhD
Thesis, University of Queensland (2007).
[4] G. Chen, Z. Wang, R. Zhang, K. Zhou, S. Huang, K. Ni, Z. Qi, K.
Chen, and H. Guan: “A reﬁned decompiler to generate C code withhigh readability,” in Proc. Working Conference on Reverse Engineering,
pp.150–154 (Oct. 2010).
[5] Y. A. Feldman: “Portability by automatic translation: A large-scale casestudy,” in Proc. Knowledge-Based Software Engineering Conference,
pp.123–130 (Nov. 1995).
[6] M. P. Ward: “Assembler to C migration using the FermaT transformation
system,” in Proc. IEEE International Conference on Software Maintenance 1999 (ICSM 99), pp. 67–76 (Aug.–Sept. 1999).
[7] Martin Ward: “Assembler restructuring in FermaT,” in Proc. IEEE International Working Conference on Source Code Analysis and Manipulation(SCAM 2013), pp. 147–156 (Sept. 2013).

#include <stdio.h>#include <stdlib.h>#include <string.h>#include <stdint.h>#include "miglib.h"static uint32_t r0, r1, r2, r3, r4, r5, r6, r7;
static uint32_t r8, r9, r10, r11, r12, r13, r14, r15;
static int cc;
static char savearea[72];
int16_t MLAST[] = {0, 0,
31, 31,59, 60,90, 91,
120, 121,
151, 152,
181, 182,
212, 213,
243, 244,
273, 274,
304, 305,
334, 335,
365, 366};
uint32_t SAVE[18];uint64_t WORK;
void EOMfunc(void){
strncpy( (char*) r4, "", 8 );
r0 = 6;
r1 = r3;do {EOM1: ;
if ( strncmp( (char*) r1, "0", 1 ) < 0 ) { goto RET; }else {
BB1: ;
if ( strncmp( (char*) r1, "9", 1 ) > 0 ) { goto RET; }else {
BB2: ;
r1 = r1 + 1;
r0 = r0 - 1;}}
} while ( r0 );BB3: ;
if ( strncmp( (char*) r3+4, "01", 2 ) < 0 ) { goto RET; }else {
BB4: ;
if ( strncmp( (char*) r3+4, "12", 2 ) > 0 ) { goto RET; }else {
BB5: ;
zone_to_pack( (char*) &WORK, 8, (char*) r3+4, 2 );r2 = pack_to_int32( (char*) &WORK, 8) - 1;
BB6: ;
r2 = (r2 * 4) + (uint32_t) MLAST;
uint32_t addr27 = r2 + 4;
r0 = * (uint16_t* ) addr27;
int16_t tmpvar29 = * (int16_t*) r2;
r0 = r0 - (int32_t) tmpvar29;
int32_to_pack( (char*) &WORK, 8, r0);
pack_to_zone( (char*) r4+6, 2, (char*) &WORK, 8 );uint32_t addr31 = r4 + 7;
unsigned char tmp32 = * (unsigned char *) addr31;
unsigned char tmp33 = tmp32 & 0x0f;
unsigned char tmp34 = tmp33 | 0x30;* (unsigned char*) addr31 = tmp34;
strncpy( (char*) r4, (char*) r3, 6 );}}RET: ;
r15 = r15 - r15;
return;}int32_t EMONTH( void** param ){r1 = (uint32_t) param;
r13 = (uint32_t) savearea;
r14 = (uint32_t) &&RETURN;EMONTHbb: ;r12 = r15;
r15 = (uint32_t) SAVE;
uint32_t addr15 = r15 + 4;
* (uint32_t*) addr15 = r13;
uint32_t addr16 = r13 + 8;
* (uint32_t*) addr16 = r15;
r13 = r15;
r3 = * (uint32_t* ) r1;
r4 = * (uint32_t* ) (r1 + 4);
if ( strncmp((char*) r4, "00000000", 6 ) ) {ER_FMT: ;abend( 999 );}else {
FC_EOM: ;EOMfunc();}
RETURN: ;return r15;}(a) Generated C program from the assembly of Fig. 2
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

#include <stdio.h>#include <stdint.h>#include <string.h>
int32_t EMONTH(void **param);
int main(void){char gdate[] = "20141215";
char result[] = "00000000";
void* param[2] = {gdate, result};
int32_t rc = EMONTH(param);
printf("rc = %d, result = \"%s\"\n", rc, result);
return 0;}(b) Test driverFig. 16.

1063

Resulting C program.