R1-3

SASIMI 2015 Proceedings

High-Level Synthesis from Programs with External Interrupt Handling
Naoya Ito 1

Nagisa Ishiura 1

Hiroyuki Tomiyama 2

Hiroyuki Kanbara 3

1

School of Science and Technology, Kwansei Gakuin University, Sanda, Hyogo, Japan
College of Science and Engineering, Ritsumeikan University, Kusatsu, Shiga, Japan
3
Advanced Scientiﬁc Technology & Management Research Institute of KYOTO, Kyoto, Kyoto, Japan
2

Abstract—This paper presents a method of synthesizing a given binary program, which contains external interrupt handling, into hardware whose behavior is equivalent to the CPU running the program.
In our method, the system control coprocessor which
CPU uses for interrupt handling is incorporated into
the hardware as a functional unit. Instructions for accessing coprocessor registers, returning from interrupt
handling, and making system calls are scheduled as operations, and bound to the coprocessor. Jump register
instructions for calling and returning from interrupt
service routines are synthesized using operations thatconvert instruction addresses into the corresponding
states of the hardware. Assuming MIPS R3000 as aCPU, the proposed method has been implemented on
top of binary synthesizer ACAP. A program of about
40 lines with an external interrupt service routine wassynthesized into hardware, and it was conﬁrmed thatinterrupt handling works correctly. The execution cycles and the delay were reduced by 14% and 26% respectively, at the cost of 1.1 times increase in hardware
size.

I.

Introduction

While embedded systems are getting increasingly richin functionalities, higher and higher performance is required within limited power consumption. To implement
such systems eﬃciently within limited design periods,
there have been a lot of attempts to utilize high-level
synthesis technology [1] to automatically design hardware
from existing software [2, 3].
While high-level synthesis generates hardware fromhigh-level behavioral languages such as C, binary synthesis [4] generates hardware from low-level programs written
in assembly or machine languages. Binary synthesis canhandle wider range of programs than high-level synthesis
and hence it is suitable for translating programs originallydeveloped as software into hardware. It is even possible
to replace a processor and a binary program by a fasteror smaller hardware module by applying binary synthesis
to the whole binary code.
However, for applications where processors control external devices, the programs contain interrupt processing. Since traditional high-level/binary synthesis methods have not assumed interrupts in behavior speciﬁcation,such programs can not be automatically translated into
hardware.
This paper presents a ﬁrst attempt to extend the abilityof binary synthesis to handle interrupts, where binary programs with interrupt handlers are synthesized into hardware without modiﬁcation. In our method, a system control coprocessor which handles interrupts is incorporated
into the hardware as one of the functional units. The instructions for accessing coprocessor registers, for returning from interrupt handling, and for making system calls
are translated into operations which are scheduled and executed by the coprocessor. Jump register instructions tobranch to interrupt service routines and to return from interrupt handling are also synthesized by using an addressto-state translation function. The proposed method has
been implemented on top of a binary synthesizer ACAP[3]. A program of about 40 lines with an external interrupt service routine was successfully synthesized into
hardware. The execution speed was accelerated by 1.6
times at the cost of 1.1 times increases in the hardware
size.
II.

Binary synthesis

High-level synthesis takes behavioral speciﬁcation as
inputs which are usually written in high-level languages
such as C. However, the behavior may be speciﬁed also in
assembly or machine languages, and such high-level synthesis techniques are called binary synthesis.
It can handle wider range of software programs thanconventional high-level synthesis, although back-end technologies to generate hardware are common. By using theassembly/machine languages as intermediate representation, it can accept multiple high-level languages for which
compilers are available. It can also handle pointers andlibrary calls in a natural way, though this may involvesome loss in performance. While binary synthesis can beused to convert some computationally intensive parts ofgiven software programs, it can also generate a hardware
module which is functionally equivalent to the processor
running a program, by synthesizing the binary code as awhole.
ACAP [3] is a binary synthesizer which generates hardware from MIPS R3000 binary codes. As shown in Fig.
1, it disassembles a binary code to recover an assembly
program, and converts it into CDFG. It then performs
scheduling and binding to generate a Verilog HDL code
based on typical high-level synthesis algorithms. ACAP
has the following three synthesis modes.
1. Separate compilation mode: Selected subprograms ofa given program are converted into hardware modules
which are callable from the software part.

- 10 -

asm
gas

C

InstMem

CDFG

gcc

MIPS binary-32756 -32760

library info

+ lw +

optimizationL

objdumplw

L

DataMemInterrupt
Handlerschedulingbinding...
lw v1,-32756(gp)lw v0,-32764(gp)nopaddu v0,v1,v0
sll v0,v0,0x2
sw v0,-32760(gp)...

+ addu
<<

sll

+
S

RTL IRCPU-32764

CDFG generatorsw

Fig. 3: Synthesis from a code with an interrupt handler

Verilog
HDL

PC
Device...
DeviceHardwarecomposer

Fig. 1: Flow of synthesis in ACAP

EPC
Cause
StatusCP0
CPU

Fig. 2: CPU and system control coprocessor (CP0)2. Full synthesis mode: A whole linked executable code
is synthesized into a hardware module.
3. Accelerator synthesis mode: User speciﬁed sectionsof linked executable code are transformed into a hardware accelerator which is tightly coupled with theCPU.
This paper focuses on the second mode where the synthesized hardware module can replace the CPU and the
instruction memory. The source program may be written
in C language or assembly/machine language, and may belinked with start-up routines and library codes for ﬂoating point emulation, string processing, etc. Synthesized
hardware is expected to run faster than MIPS, owing to
instruction level parallelism and operation chaining. The
hardware size is also expected to be smaller, for the instruction memory is no longer necessary.
III.

DataMemInterrupt handling of MIPS R3000

MIPS R3000 handles interrupts by using CP0, the system control coprocessor, which is embedded in the CPU.
CP0 has the following three registers to handle externalinterrupts.
• EPC registerkeeps the PC (Program Counter) value at which theinterrupt is triggered.
• Cause registerkeeps the information regarding the cause of the interrupt, i.e., whether it is an external interrput, aninternal interrupt, or a system call, and also its detailed cause in the case of an external interrupt.
• Status registerkeeps the system’s status information such as the execution mode (the user mode or the kernel mode),and the interrupt mask.
The interrupt signals from external devices are sent toCP0, and then each of them is handled in the following
way. Note that MIPS R3000 doesn’t handle multilevelinterrupt and all the other interrupts happened during
one interrupt handling are ignored.
• CP0 saves the PC value in the EPC register and thecause of the interrupt in the Cause register, and updates the Status register so that the system may run
in the kernel mode and interrupts will be prohibited.
• CP0 sends an interrupt execution signal to the CPU,and writes the starting address of the interrupt handler into PC so that the CPU will jump to the handler.
• The handler saves the values of the general purpose
registers to the main memory and calls the routine
corresponding to the cause in the Cause register.
• After the routine ﬁnishes its tasks, the handler restores the general purpose registers.
• The handler restores the execution mode and clears
interrupt prohibition, and the address in the EPC register is written back to PC so that the CPU can resume execution (or just jumps to the speciﬁed address for error handling).
To handle interrupts, the following instructions areused.
• mfc0 and mtc0 (move from/to CP0)
mfc0 rt,rd moves the value in a CP0 register rd toa general purpose register rt, and mtc0 rt,rd does
the move in the opposite way. Those instructions
are used to access to the EPC, Cause, and Status
registers.
• rfe (return from exception)
It is executed at the end of the interrupt handler
and restores the execution mode and the interrupt
permission.

IV.
A.

High level synthesis of externalinterrupt handling

Overview

This paper proposes a high-level synthesis method
which can generate hardware from programs containing
external interrupt handlers. As illustrated in Fig. 3, theproposed method translates a linked executable code including an interrupt handler to a hardware module, which
replaces the CPU and the instruction memory.
In the following sections, we assume MIPS R3000 as aCPU. We also base our method on the following assumptions.
• When the hardware accepts an interrupt, the control
is transfered to the interrupt handler at the end of
the basic block where the interrupt is accepted.

- 11 -

DataMem

Device...

CP0

HW_sigint_sig
ESTATE

int_sig

(b)

CP0

DFG3
(Handler)

DFG1

(a)
State
MachineDevice

s0

+

s1

-

-

s20

+

s21
s22

+

s2

(f)

+
+

+

(c)
+

s3

Hardware

DFG2

Fig. 4: The structure of synthesized hardwares8• Multilevel interrupts are not considered. Any otherinterrupts during interrupt handling are ignored.
• The interrupt handler cannot refer to the instruction
address where the interrupt occurred nor access tothe instruction memory.
Although internal interrupts are not handled, system calls
can be synthesized. This is to enable mutual exclusion of
the accesses to shared resources.
In our method, the synthesized hardware module includes the CP0 coprocessor of MIPS R3000 as one of thefunctional units. Instructions, mfc0, mtc0 and rfe, aresynthesized and bound to CP0. Register jumps used tobranch to interrupt service routines and to return frominterrupts are synthesized by using an operation to translate instruction addresses to the corresponding states of
the hardware.

s9

B. Handling of external interrupts
The structure of the hardware generated by this method
is shown in Fig. 4. The hardware has CP0 of MIPS R3000
as a functional unit and three registers HW sig, int sig
and ESTATE.
The ﬂow of interrupt handling is as shown in Fig. 5.
DFG1 through DFG4 are DFGs (data ﬂow graphs) corresponding to the basic blocks of a given program, and s0
through s28 are states (control steps). An external interrupt triggered during the execution of DFG1 is processedin the following way.
1. The interrupt signal is sent to CP0 (a).
2. The interrupt execution signal from CP0 is latchedin the int sig register (b).
3. At the last state (s3) of DFG1, int sig is tested(c). If it is 1, the next state of s3 (s8) is saved in the
ESTATE register as the return state, and the hardware
jumps to the starting state (s20) of the interrupt handler (Handler) (e).
4. At the initial state of the handler, int sig is cleared(f).
5. At the last state (s28) of the last DFG (DFG4) of
the handler, the status is restored and the hardware
returns to the state saved in the ESTATE register.
C. Synthesis of instructions for interrupt handlingIn the stage of high-level synthesis, mfc0, mtc0, rfe,
and syscall instructions are dealt with as operations executed by CP0, so that they are scheduled and bound to
CP0. They are processed as follows.

s10

-

(d)

(e)
ESTATE
s8

DFG4
s26

...

Datapath

+

s27

-

-

s28

rfe

jr

+
(g)

+

Fig. 5: Flow of interrupt handling by hardware
mfc0 v0,c0_sr

0xc

mtc0 v0,c0_sr

0xc

v0

mfc0

mtc0

v0

(b)

(a)

register
addr
c0_context
0x4
c0_badvaddr
0x8
0xc
c0_sr
0xd
c0_cause0xe
c0_epc0xf
c0_prid(c)Fig. 6: Operations corresponding to mfc0 and mtc0

• mfc0, mtc0
Each of the mfc0 and mtc0 instructions is translated
to an operations, as shown in Fig. 6 (a) and (b) respectively, where the source/destination register isselected by the numbers shown in Fig. 6 (c).
• rfe
The rfe instruction is translated to an operation
without input nor output and is scheduled at the laststate of the DFG.
• syscall
Before the scheduling phase, the basic block is
divided just after the syscall instruction. The
syscall instruction is translated to an operation
without input nor output and is scheduled at the laststate of the DFG so that it is executed independently
from the other operations.
The syscall operation triggers a transition to the interrupt handler, just like external interrupts, by sending
an execution signal of syscall to CP0. Since we assume
the transitions to the interrupt handler occur only at theend of the basic blocks, an external interrupt and a systemcall may happen in a same basic block. In this case, thesystem call is ignored, since CP0 stores the informationof an external interrupt in Cause register. In order toavoid this situation, we ﬁrst handle external interrupts,
and then process the system call. The revised ﬂow of
the process is shown in Fig. 7, where an external interrupt occurs during the execution of DFG1 which contains
syscall.
• The external interrupt signal is sent to CP0 (a) andstored in the int sig register as well as (c) in HW sig
register (b).
• At the last state (s3) of DFG1, int sig and HW sig
are tested (d). If only one of them is 1, it is handled- 12 -

int_sig

(c)

CP0

(g)

DFG3
(Handler)

DFG1

(a)

0: 0x8000066c
1: 0x800006d0
2: 0x800006e8
3: 0x80000730
4:0

HW_sig

(b)

s0

+

-

s20

+

s1

-

+

s21

JumpTable+s3

syscall+s22

0x800006d0

0x800006e8

...

s2

0x8000066c

0x80000730

+

(d)
...

(f)
DFG2

(e)

ESTATE
s3

-

s8
-

s9
s10

-

s26

+
+

DFG

DFG4

(h)

Fig. 9: Deviding basic blocks according to a jump table
+

s27

-

-

s28

rfe

jr

Fig. 7: Handling of syscall overlapping with an external interrupt

-

27:

+

-

28:

-

+
+

29:

+

30:

+

Address
0x8000066c
0x800006d0
0x800006e8
0x80000700

STATE
34
38
41
47

...

...

pc2state

0x800006d0
STATE

jr

(a)

Basically, the addresses that the pc2state operation has
to convert are those of the entry points of the subroutinesand the return addresses. However, jr instructions may
be also used to implement switch-case statements, so theirtarget addresses must be considered. Since the jump addresses of the switch-case statements are listed in a jump
table, these addresses can be extracted from the table byscanning the data section of the binary code and enumerate the values which are multiples of 4 and within a rangeof the instruction addresses.

34:
35:

-

-

...

38:
39:

V.
+

+
-

41:

-

42:

+

...

A.

...

(b)

Fig. 8: Converting addresses into states

as described before. If both of them are 1, the current
state (s3), instead of the next state (s8), is stored in
ESTATE (e) and the hardware jumps to the interrupt
handler (Handler) (f).
• At the ﬁrst state (s20) of Handler, int sig andHW sig are cleared (g).
• At the last state (s28) of the handler, the hardware
jumps to the state saved in ESTATE (h). If both ofthe external interrupt and the system call are present,
the hardware returns to s3 and executes the system
call.
D. Synthesis of register jump instructions
For the jalr and jr instructions used to select interrupt
service routines and return from interrupt, their branch
destinations cannot be determined by static analysis, because they depend on operand values computed at runtime. In this paper, these instructions are synthesized into
hardware by using operations which convert instruction
addresses into the corresponding states of the hardware.
For example, the jr instruction is translated into an
operation whose input is a target address and is scheduled
at the last state of the basic block as shown Fig. 8 (a). It isthen further translated into a “pc2state” operation whichconverts a given program address to the corresponding
state of the state machine, and writes the results to thestate register as shown Fig. 8 (b). This conversion will be
implemented as a combinational circuit.

Experimental results

Simulation results

A binary synthesizer based on the proposed method has
been implemented on top of ACAP. It is written in Perl5
and runs on Linux, Mac OS X, Cygwin on Windows, etc.
The synthesized hardware is in the form of Verilog HDL.
A test program with external interrupt handling waswritten in C and assembly languages. After its behavior
is veriﬁed on a MIPS R3000 compatible processor, theprogram is synthesized into hardware. The behavior of
the resulting hardware was conﬁrmed to be correct on
the same test stimulus. The simulation is performed by
Xilinx ISim 14.3.
Programs used in the experiment are shown in Fig. 10,
11, and 12. The program shown in Fig. 10 gets integer
data by interrupts, stores them in a buﬀer, and calculates
the sum of squares of the input data in the main routine.
Upon the interrupt function int routine (lines 33–39) iscalled and values in variable input, which is mapped tothe external input, are moved to array buffer. The main
routine (lines 14–31) calculates the sum of squares in theloop in lines 22–24. In lines 26–28, buffer is initialized
under an exclusive control between interrupt prohibition
function int prohibition and an interrupt permissionfunction int permission. A registration of int routine
is performed in line 19. In the program, int routine isregistered to be called for the zeroth external interrupt(EXC Int0). Also, function init interrupt in line 18
performs initial setting to handle interrupts.
The program shown in Fig. 11 is the interrupt handler.
When an external interrupt occurs, CPU ﬁrst jumps tothe top of the handler. The handler 1) saves the general
purpose registers, 2) saves the return address, 3) calls theinterrupt service routine function, 4) restores the general
purpose registers, and 5) returns from the interrupt.
The program shown in Fig. 12 consists of libraryfunctions to handle interrupts which is written in- 13 -

01: #include "interrupt lib.h"02:
03: #define N 10
04: #define LOOP NUM 30
05:
06: void int routine(void);
07:
08: volatile int input;
09:
10: int sp = 5;
11: int buffer[N] = {10, 20, 30, 40, 50};
12: int output[LOOP NUM];
13:
14: int main(void)
15: {
16:
int i, j;17:18:
init interrupt();
19:
register exc handler(EXC Int0, int routine);20:
21:
for (i = 0; i < LOOP NUM; i++) {22:
for (j = 0; j < sp; j++) {23:
output[i] += buffer[j] * buffer[j];
24:
}
25:
26:
int prohibition();27:
sp = 0;28:
int permission();
29:
}
30:
return 0;
31: }32:
33: void int routine(void)
34: {
35:
if (sp < N) {36:
buffer[sp] = input;
37:
sp++;
38:
}
39: }

Fig. 10: A test program; 1) Storing values of general registers
80000080: lui k0,0xc000
80000084: ori k0,k0,0x90
80000088: sw at,4(k0)8000008c: sw v0,8(k0)80000090: sw v0,12(k0)...
800000f8: sw sp,116(k0)800000fc: sw s8,120(k0)80000100: sw ra,124(k0); 2) Storeing the teturn address
80000104: mfc0 ra,c0 epc
80000108: sll zero,zero,0x0
8000010c: sw ra,0(k0); 3) Calling the interrupt servece routine execution function
80000110: lui ra,0xc000
80000114: ori ra,ra,0x2c
80000118: lw t0,0(ra)8000011c: sll zero,zero,0x0
80000120: beqz t0,80000134
80000124: sll zero,zero,0x0
80000128: jalr t08000012c: sll zero,zero,0x0
80000130: sll zero,zero,0x0; 4) Recovering values of general registers
80000134: lui k0,0xc000
80000138: ori k0,k0,0x90
8000013c: lw at,4(k0)80000140: lw v0,8(k0)80000144: lw v1,12(k0)...
800001b0: lw sp,116(k0)800001b4: lw s8,120(k0)800001b8: lw ra,124(k0); 5) Returning from the interrupt
800001bc: lw k0,0(k0)800001c0: sll zero,zero,0x0
800001c4: jr k0
800001c8: rfe
800001cc: sll zero,zero,0x0

Fig. 11: Interrupt handler

C and inline assembly.
Function init interrupt(lines 7–11) registers interrupt service routine execution function run exc handler (lines 20–41), which
are called from the interrupt handler, and a routine run syscall handler (lines 43–53) for system call
(EXC Sys). Function int prohibition (lines 55–59) isan interface function to set interrupt prohibition by calling run syscall handler through system call and then,calling int prohibiton func (lines 61–68). Function
int permission (lines 70–75) sets interrupt permission.
It was conﬁrmed by simulation that the synthesized
hardware switched to the interrupt handler at the endof the basic block in which the external interrupt signal
was accepted, and that after the handler ﬁnished it resumed the original process. It is also conﬁrmed that the
CPU and the hardware produced exactly the same memory dump after the simulation, when the same numbers ofinterrupts were requested at the same timing. However,
the CPU and the hardware behaved diﬀerently in termsof timing; the hardware branched to the handler at theend of the DFG where interrupt was accepted while theCPU switched to the handler just after the instruction atwhich the interrupt was signaled.
B.

Synthesis results

The Verilog code generated from the test program
was synthesized by Xilinx ISE 14.3 targeting the Xilinx Spartan-3E FPGA. Three ALUs were used but ALU
chaining was not applied.
The result is summarized in TABLE. I. Rows “SW” and“HW” show the results of the software running on MIPS
and synthesized hardware, respectively. “Slices”, “FFs”,“LUTs” and “Delay” are the numbers of slices, ﬂip-ﬂops,
LUTs and delay times, respectively, and ”Cycles” indicates the number of cycles spent on the main process andthe external interrupt handler. The presented method reduced the delay and execution cycles by 14% and 26%, respectively which results in a speed up by about 1.6 times,
at the cost of hardware increase by about 1.1 times. The
increase is due to the increase in binary code size; theinterrupt handler and interrupt-lib.c compiled to 84
and 85 instructions, respectively, where codes for normal
routines consisted of 94 instructions.
VI.

Discussion

The proposed method allows jumps to the handler onlyat the end of the DFG. This is because register save andrestore are done precisely as written in the handler code.
However, high-level synthesizers generally generate extra
registers to keep intermediate values, which will not besaved nor restored on interrupt handling. ACAP guarantees that such intermediate registers don’t appear at
the end of basic blocks, so we can just let the synthesized
hardware save and restore the registers, as long as thejumps occur only at the end of the DFG.
If we can completely separate the codes for interrupt
handling from those for normal processing and can synthesize them into independent hardware modules, we may
be able to get rid of this restriction. We are now working
on this issue.

- 14 -TABLE I: Result of synthesis
TargetSW
HW

Slices3144 (1.00)
3563 (1.13)

FFs
1771 (1.00)
2003 (1.13)

01: #include "interrupt lib.h"
02:
03: extern void *interrupt call;
04: extern void (*exc handler[24])();
05: extern void * reg store;06:
07: void init interrupt(void)
08: {
09:
(*((unsigned int*)&interrupt call))10:= (unsigned int)run exc handler;
11:
register exc handler(EXC Sys, run syscall handler);
12: }
13:
14: void register exc handler(unsigned int exc, void (*f)(void))
15: {
16:
if (EXC MOD <= exc && exc <= EXC Int5) {17:
exc handler[exc] = f;
18:
}
19: }
20:
21: void run exc handler(void)
22: {
23:
int i;
24:
unsigned int cause reg, exc code, int field;
25:
void (*handler)() = 0x00000000;
26:
27:
asm("mfc0 %0, $13" : "=r" (cause reg));28:
exc code = (cause reg >> 2) & 0xf;
29:
int field = (cause reg >> 8) & 0xff;
30:
31:
if (!exc code) {32:
for (i = EXC Sw0; i <= EXC Int5; i++) {33:
if (int field & 0x1) {34:
handler = exc handler[i]; break;
35:
}
36:
int field = int field >> 1;
37:
}
38:
} else {39:
handler = exc handler[exc code];
40:
}
41:
if (*handler) {(*handler)();}
42: }
43:
44: void run syscall handler(void)
45: {
46:
unsigned int reg k1;
47:
48:
asm("add %0, $0, $27" : "=r" (reg k1));
49:
50:
if (reg k1 == 1) {51:
int prohibition func();
52:((unsigned int *)& reg store)[0] += 4;
53:
}
54: }
55:
56: void int prohibition(void)
57: {
58:
asm("addiu $27,$0,1");59:
asm("syscall");
60: }
61:
62: void int prohibition func(void)
63: {
64:
asm("lui $8, 0xffff");
65:
asm("ori $8, 0xfffb");66:
asm("mfc0 $9, $12");67:
asm("and $9, $9, $8");
68:
asm("mtc0 $9, $12");
69: }
70:
71: void int permission(void)
72: {
73:
asm("mfc0 $8, $12");74:
asm("ori $8, $8, 0x1");
75:
asm("mtc0 $8, $12");
76: }

LUTs
5632 (1.00)
6801 (1.21)

Delay [ns]25.24 (1.00)
21.57 (0.85)

Cycles5192 (1.00)
3816 (0.74)

In this paper, internal interrupts (software interrupts)
are not considered. This is partly because of the register save/restore problem and also because architecture
dependent codes are often written in internal interrupt
handlers which are very diﬃcult synthesize into equivalent hardware. If they are written as architecture independent or rewritten to work on synthesized hardware, it
should not be diﬃcult to synthesize the handlers.
VII.

Conclusion

We have presented a high-level synthesis for programswith an external interrupt handling. The presented
method has been implemented and it was conﬁrmed thatthe interrupt handler runs correctly.
We are now working on response improvement discussed in Section IV, as well as trying to reduce the area
and to improve the execution time of generated hardware.
Acknowledgements
We would like to thank to Mr. Takayuki Nakatani who
was with Ritsumeikan University, Mr. Masaharu Yano
who was with Kyoto University, Mr. Shimpei Tamura who
was with Kwansei Gakuin University and all the membersof Ishiura Lab. of Kwansei Gakuin University for their discussion and advices on this research.
References[1] D. D. Gajski, N. D. Dutt, A. C-H Wu, and S. Y-L Lin:
High-Level Synthesis: Introduction to Chip and System
Design, Kluwer Academic Publishers (1992).
[2] S. Shibata, S. Honda, H. Tomiyama, and H. Takada: “Advanced System-Builder: A tool set for multiprocessor design space exploration,” in Proc. ISOCC 2010, pp. 79–82(Nov. 2010).
[3] N. Ishiura, H. Kanbara, and H. Tomiyama: “ACAP: Binary synthesizer based on MIPS object codes,” in Proc.
ITC-CSCC 2014, pp. 725–728 (July 2014).
[4] G. Stitt and F. Vahid: “Binary synthesis,” ACM TODAES, vol. 12, no. 3, article 34, pp. 1–30 (Aug. 2007).
[5] J. L. Hennessy and D. A. Patterson: Computer Architecture, Third Edition, Morgan Kaufmann (Aug. 2004).

Fig. 12: interrupt lib.c- 15 -