MieruCompiler: Integrated Visualization Tool with Horizontal Slicing for Educational Compilers






Full text


MieruCompiler: Integrated Visualization Tool with

“Horizontal Slicing” for Educational Compilers

Katsuhiko Gondow

Tokyo Institute of Technology


Naoki Fukuyasu

Wakayama University fukuyasu@sys.wakayama-u.ac.jp

Yoshitaka Arahori

Tokyo Institute of Technology



This paper proposes a novel visualization tool for educational com-pilers, called MieruCompiler. Educational compilers that generate native assembly code like i386 have many practical and pedagog-ical advantages, but they also have a disadvantage that the under-graduate students need to acquire a wide range of knowledge on na-tive machine instructions, assembly direcna-tives, application binary interface (ABI), and so on. To reduce this learning cost, Mieru-Compiler provides various visualizations as a rich internet appli-cation (RIA) including: (1) highlighting all related slices (called “horizontal slicing” after [13], but not implemented in [13]) among the source code, abstract syntax tree, assembly code, symbol table, stack layout and compiler code, when the user hovers the mouse pointer over a piece of them, (2) displaying tooltips for machine in-structions, assembly directives, etc., and (3) visualizing stack lay-outs which are very likely to be implicit. As a preliminary evalua-tion, MieruCompiler was used in two universities, which produced promising results.

Categories and Subject Descriptors

K.3 [Computers and Information Science Education]: Com-puter Science Education.

General Terms

Design, Languages


Compiler course, Code Generation, Visualization, Program Under-standing, Rich Internet Application (RIA)


For computer science undergraduate students (students for short), compiler courses are common and important at most universities [1, 2]. In the compiler courses, educational compilers are often used to provide hands-on experience through compiler construc-tion. PL/0 compiler [14] is a popular classical educational com-piler, and many other educational compilers have been proposed so far [15–18].

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for proÞt or commercial advantage and that copies bear this notice and the full citation on theÞrst page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior speciÞc permission and/or a fee.

SIGCSE’10,March 10–13, 2010, Milwaukee, Wisconsin, USA. Copyright 2010 ACM 978-1-60558-885-8/10/03 ...$10.00.

Figure 1: Overview of our approach

They are classiÞed into two types according to the generated code. One is anative compilerthat generates native machine code or native assembly code, and the other one is anon-native compiler

that generates virtual machine code (or bytecode). Although both types have their own advantages and disadvantages, we argue that native compilers are more pedagogically effective than non-native compilers (see Section 2.1 for details).

Although there are many important advantages in native educa-tional compilers, the most difÞcult problem in the native compiler approach is that the learning cost is greatly increased. To solve this problem, we took the following approach depicted in Fig. 1 (Sec-tion 2.2).

We carefully deÞned a source language (called XC) of our own educational compiler (called XCC) as a strict syntactic

subsetof the C programming language [22].

We emphasize and focus oncode generation, but not on pars-ing and optimization.

We provide avisualizationtool (called MieruCompiler) for better understanding of the educational compiler and knowl-edge on i386 instructions, etc.

XC is a compact language while preserving the high expressive power (Section 3.1). XCC is our educational compiler, which trans-lates an XC program into i386 or MIPS assembly code (Section 3.2). Since XC is a subset of C, real-world C compilers like GCC can compile any XC program. This means the students can com-pare the two versions of native assembly code; one is generated by XCC, and the other by GCC. This has a great beneÞt in compiler courses, since the students practically know what code should be generated and what alternatives there are.

Here by “code generation” we mean the direct translation from source code to native assembly code (.sÞle) without using inter-mediate code. Fig. 2 shows an example of our “code generation.”


Figure 2: Example of code generation (i386 assembly code for whilestatement)

Figure 3: Example of “horizontal slicing” (awhilestatement and its corresponding assembly code are highlighted)

Thus our term “code generation” corresponds to “intermediate-code generation” in compiler textbooks [4]. A .s Þle generated by our educational compiler XCC can be assembled and linked into a.outÞle, for example, by GCC.

MieruCompiler1 is our integrated visualization tool with “hor-izontal slicing.” MieruCompiler statically visualizes the source code, assembly code, abstract syntax tree (AST), compiler code2, symbol table and stack layout in XCC. By “horizontal slicing” [13], we mean highlighting all related slices from any selected piece. As shown in Fig. 3, for example, the corresponding assembly code (Fig. 3, right) is highlighted when selecting awhile state-ment (Fig. 3, left). “Horizontal slicing” is bidirectional; not only what are generated from the selected piece, but also what generated the selected piece are highlighted. For example, when selecting a cmplinstruction in the assembly code, the correspondingwhile statement in the source code will be highlighted.

Our major contribution in this paper is two fold:

We have proposed and implemented a novel visualization tool called MieruCompiler for our educational compiler XCC. MieruCompiler is integrated and has a feature of “horizon-tal slicing.” As mentioned in Section 5, [13] introduced the term “horizontal slicing”, but did not implemented it in [13]. The source code of XCC and MieruCompiler is freely avail-able onhttp://www.sde.cs.titech.ac.jp/~gondow/ MieruCompiler/.

We show valuable educational experiences obtained through the projects where 15 students in two universities developed (a part of) code generator in XCC using MieruCompiler. The rest of this paper is organized as follows. Section 2 dis-cusses the native compiler approach. Section 3 describes our XC, XCC and MieruCompiler. Section 4 gives a preliminary evalua-tion. Section 5 describes related work. Finally, Section 6 gives the conclusion.

1Mierumeans “visible” in Japanese.

2The compiler code in MieruCompiler can be hidden by option for educational purpose.


2.1 Why native compiler approach is better

We argue that native compilers are more pedagogically effective than non-native compilers because of the following reasons:

Generating native (i.e., real) assembly code motivates stu-dents to learn whatsoever are required in developing educa-tional compilers, which results in a high learning effect. The reasons for this tendency are (probably) because:

Knowledge and experiences obtained from real assem-bly code will be widely applicable for many other areas including embedded systems, computer architectures, and operating systems. Also they are extensible in the sense that further learning leads students to more ad-vanced topics like real compilers (eg., GCC) and tech-niques on JIT compilers or optimizers.

Real assembly code is complex as a result of satisfy-ing real-world constraints and requirements, so learn-ing real assembly code is simply interestlearn-ing and chal-lenging for students; it is just a kind of happy hacking. In some senses, virtual machines areimitations, which

demotivates students to learn them. For example, most native machines are register-based, while most virtual machines are stack-based. There are many differences and gaps in design decisions on real CPU instruction sets and virtual ones. Furthermore, real CPU instruc-tion sets cannot be modiÞed, while most virtual ones can be easily modiÞed. A mission of real-world com-piler is to generate low-level code using aÞxed instruc-tion set, but this does not often hold true for non-native compilers.

By comparing the two versions of native assembly code: one generated byreal-worldcompilers (eg., GCC) and the other generated by theeducationalcompiler, students practically know what code should be generated and what alternatives there are. Even if the technique mentioned in [12] is used, it is still quite difÞcult for students to understand the internal data structures of real-world compilers. On the other hand, it is not so difÞcult for students to understand the assembly code generated by GCC.

For this purpose, it is desirable that a source language of the educational compiler is a strict syntactic subset of the exist-ing programmexist-ing language (eg., C), to make it possible to compare different results for the same source program. This is the reason why XC is a subset of C.

There are many high quality documents (eg., [20, 23]) and tools (eg., GCC and GNU Binutils) for real machines, while not for most virtual machines3.

Library functions (eg.,printf in the C standard library) can be directly called from the source program, if the educa-tional compiler conforms to the application binary interface (ABI). This is the case for XCC.

This widens the application area written in the source code of the educational compiler, and gives another reality to the students.


2.2 Problems in native compiler approach and

our solutions

As mentioned in Section 2.1, there are many important advan-tages in native educational compilers. Unfortunately, however, the most difÞcult problem in the native compiler approach is that the learning cost is greatly increased, since students need to acquire a wide range of knowledge on native machine instructions, assembly directives, application binary interface (ABI), and so on. Moreover, data structures for AST, symbol table, and type representation are difÞcult for students to understand and implement.

To solve these problems while preserving the good essence of the native compiler approach, we took the following three ways:

We carefully deÞned the source language of our own educa-tional compiler as a strict syntactic subset of the C program-ming language, which has the following beneÞts:

This saves the time spent in teaching the syntax and semantics of the source language, since the instructors only have to explain the syntactic difference from C. This helps students more deeply understand the C

se-mantics, for example, about “left-to-right evaluation” [22] in&&and ||operators, pointer arithmetic in+ and-operators, the difference between “call by value” and “call by reference”, and the lifetime of automatic variables. This is required to preserve the meaning of the source program being compiled, which is a very ba-sic compiler’s mission.

Note that PL/0 [14], for example, is not a syntactic subset of Pascal, even though PL/0 is a simpliÞed version of Pascal. For example, no type is speciÞed in PL/0 (var i;), while a type is always speciÞed in Pascal (var i: integer). This implies Pascal compilers cannot compile PL/0 programs, while C compilers can always compile any XC program with-out modiÞcation.

We emphasize and focus on code generation, but not on pars-ing and optimization.

For example, we would like to put more emphasis on how to translate awhilestatement into i386 assembly code in Fig. 2 than on parsing and optimization. This is because in our opinion the most important thing is, for example, to teach awhilestatement can be implemented by combining a con-ditional branch (jein Fig. 2) and an unconditional branch (jmpin Fig. 2).

Parsing techniques are often emphasized in compiler courses, since LALR parser generator is regarded as a great victory in computer science (eg., in [19]). Unfortunately, LALR parser generator is not the best solution. The grammar and action rules by GNU Bison (an LALR parser generator) are of-ten complicated, since somekludgesusing “Actions in Mid-Rules”, etc. are required to handle context dependencies [21]. As a result, the parsers in GCC-3.4 and later are changed to hand-written recursive descent one, while the parser in old GCC was implemented by GNU Bison.

In order to avoid the tedious kludges and to maximize the time for the students to concentrate on code generation, we decided to use the strategy of providing to the students the source code of the XCC front-end (scanner, parser and se-mantic analyzer) and course materials that explain how to access the AST, symbol table, etc. in the XCC front-end. Optimization plays a great important role in compiler sys-tems. For aÞrst course in compiler construction, however, optimization is too complicated for the students to under-stand and implement. For this reason, our educational com-piler XCC only uses a very naive register allocation method

where general-purpose registers are used as a part of stack frame. This keeps XCC very compact.

We provide a visualization tool for better understanding. As mentioned before, in native compiler approach, the stu-dents need to understand native machine instructions, assem-bly directives, and internal data structures in the educational compiler itself. The cost of learning and understanding them is very high. There is a limit to reduce the cost by enrich-ing the course materials, or by improvenrich-ing the source code using software engineering techniques (eg., modularization and refactoring). Using a debugger (eg., GDB), students can examine the internal data structures, but they often get lost in the AST with hundreds of nodes. Also, technical documents tend to be large (eg., [20] has about 3,000 pages), so students often get lost in those large documents.

Therefore, we provide a visualization tool to solve this prob-lem, which includes:

(1) Highlighting “horizontal slices”, that is, all related slices among the source code, assembly code, AST, symbol table, stack layout and compiler code. (2) Interactive tooltips4 that explain machine

instruc-tion mnemonics, assembly directives, fundamental ar-chitecture components like registers, etc.

(3) Visualization of the AST, symbol table and stack layout.

This visualization tool is implemented as a rich internet ap-plication (RIA), which implies that students do not have to install it.

3. XCC AND MieruCompiler DETAILED

3.1 XC

XC is a very compact language while preserving the high expres-sive power. XC has only 57 grammar rules in GNU Bison, while C has about 200 ones. XC has most features of C including types (eg.,int,char,void, function types, pointer types), operators (eg.,=,||,&, *,+), control structures (eg.,if-else,while, goto,return), and function (calls) with parameters.

In XC, we eliminated most features that have alternative ways to write. For example, XC does not have the array operator ([]), but as a substitute for it, we can usemallocand pointer arithmetic in XC. Forint a[10]; a[3]=5;in C, we can writeint *a; a=malloc(40); *(a+3)=5;in XC.

3.2 XCC

XCC is the educational compiler we developed; XCC translates an XC program into native assembly code (i386 and MIPS as-sembly code for now5). To keep XCC simple, XCC does not have intermediate code nor optimizers. The code size of XCC for i386 is about 2,100 lines in C, GNU Bison and GNU Flex. So far, the projects using XCC have been conducted in Japan Advanced Insti-tute of Science and Technology (JAIST) in 2000, in Tokyo InstiInsti-tute of Technology from 2003 through 2009, and in Wakayama Univer-sity in 2009.

3.3 MieruCompiler

MieruCompiler is our integrated visualization tool with “hori-zontal slicing.” MieruCompiler statically visualizes the source code (XC), assembly code (i386 and MIPS), AST, compiler code (op-tional), symbol table and stack layout in XCC.

4Tooltip is a small message window appearing when the user hov-ers the mouse pointer over an item, without clicking it.

5XCC was originally developed to generate SPARC assembly code, but SPARC is not supported in the current XCC.


Figure 4: Example of tooltips in MieruCompiler (a tooltip for poplinstruction appearing6)

Figure 5: Example of stack layouts in MieruCompiler (local variableiis highlighted)

3.3.1 Visualization in MieruCompiler

As mentioned in Section 1, MieruCompiler provides a mecha-nism of “horizontal slicing.” As an example of “horizontal slicing”, in Fig. 3, the corresponding assembly code is highlighted when se-lecting awhilestatement. Note that all the other related slices in the AST, compiler code, symbol table and stack layout are also highlighted in MieruCompiler, but they are not shown in Fig. 3 for the lack of space.

Fig. 4 shows an example of tooltips in MieruCompiler, which shows a compact description about i386poplinstruction (its for-mat, semantics and usage example). In MieruCompiler, a tooltip will appear when the user hovers the mouse pointer over machine instructions, assembly directives (eg.,.text), register names (eg., %esp) and any form of addressing mode (eg.,4(%ebp)andr/m32) in assembly code and other tooltips. Note that MieruCompiler tooltips can be nested; theÞrst tooltip contains many items which show a second tooltip. Thus the user can see two or more tooltips simultaneously by hovering the mouse pointer over several items successively.

Fig. 5 shows an example of the stack layout visualized in Mieru-Compiler, which shows that, from the bottom to the top, the stack consists of two arguments (sizeanddata), a return address, an old value of%ebppointed by%ebp, two local variables (iandj), and other intermediate values unknown at compile-time; and the stack top is pointed by%esp. This graphical information about the stack layouts is quite important to help the students to map a local variable or function argument to its corresponding location on the stack relative to the base pointer (%ebpfor i386). This is necessary because application binary interface (ABI), including calling con-vention, alignment constraints and stack layouts, is often implicit and not clear, and thus ABI should be explicitly and compactly (i.e., graphically) provided.

3.3.2 Design and Implementation

The code size of MieruCompiler is about 6,500 lines in C, GNU Flex and JavaScript (including JSON dataÞles). JSON dataÞles have all the data required by the MieruCompiler tooltips. As a GUI toolkit for Web browsers, we use ExtJS 2.2.

MieruCompiler is implemented as a rich internet application (RIA), which implies no installation procedure is required. Moreover, MieruCompiler is easy for the students to use, since it runs on Web browsers like Firefox and Google Chrome.

6Slightly modiÞed for presentation purpose. Some descriptions in MieruCompiler are localized (i.e., Japanese is used) considering that most our undergraduate students are not good at English.

static void emit_code (struct AST *ast, char *fmt, ...) { va_list argp;

va_start (argp, fmt);

vfprintf (fp, fmt, argp); /* fp is a global variable. */ va_end (argp);


#define emit_code(ast, fmt, ...) \ emit_code(ast, "%s_%d,%s,%d," fmt, ast->ast_type, \ ast->ast_nth, __FILE__ , __LINE__, ##__VA_ARGS__) Figure 6: The macroemit_codefor minimal modiÞcation

We needed to modify XCC so that MieruCompiler can obtain data being visualized from XCC. One important design policy is to minimize this modiÞcation to XCC, which is required because it becomes much difÞcult for the students to understand the XCC source code if XCC is heavily modiÞed.

Although we cannot go into detail for the lack of space, we achieved this goal; only 5 manual source code instrumentations to XCC were required, whose total code size is only 15 lines. One way we took is to deÞne a macroemit_code(Fig. 6, bottom) to trans-parently override the original functionemit_code(Fig. 6, top). The functionemit_codeis just a wrapper function ofprintf with an extra parameterastfor debugging purpose. The macro emit_codeis recursively deÞned, but this works well since the C standard guarantees to expand a recursive macro only once ( in [22]).


In this section, we discuss our experience using XCC and Mieru-Compiler in Tokyo Institute of Technology and Wakayama Uni-versity. 15 students tried to implement (a part of) code generator for i386 architecture using XCC and MieruCompiler. The student skills vary widely from a student with no experience on compiler to a student with experience on developing PL/0 compiler. At the beginning of the projects, we gave the source code of XCC front-end to the students. XCC and MieruCompiler were well received by most our students.

4.1 Experience on XCC

The following are comments from the students.

XCC is suitable for learning a foundation of i386 assembly language programming.

It is good that after the projects XCC gives other advanced exercises for eager students like implementing optimizers (reg-ister allocation in particular) and their own front-end.

XCC gave me a new point of view for programming through understanding XCC’s AST and compilation mechanism.

It is not clear for me to what extent XCC’s semantic analysis is done in the given front-end. (eg., in XCC, a type analysis is done, but no analysis on L-value and R-value is done.)

XCC is difÞcult for less experienced students. Simpler com-piler projects might be better for them using a simpler source language with basic operators, control structures (eg., if andwhile) and no functions; and a simpler virtual machine code like P-code.

4.2 Experience on MieruCompiler

The following are comments from the students.

“Horizontal slicing” in MieruCompiler enables me to quickly understand the corresponding i386 assembly code when point-ing at a code fragment of XCC, and thus it is quite useful. Stack layouts shown in MieruCompiler are also useful.


Tooltips are popped up in MieruCompiler when pointing at a code fragment of i386 assembly code. This immediately reminds me of its meaning. Thus the tooltips are quite useful since the i386 addressing mode is complex in particular.

I did not use the visualization mechanism at all. (Note: he is a relatively experienced student.)

More detailed information should be provided in MieruCom-piler, for example, about all members in AST (struct AST) and types (struct Type).

I want MieruCompiler to provide a comprehensive tutorial and reference for i386 assembly language programming, since tooltips are not enough for less experienced students to learn i386 from the scratch.


To our knowledge, there are no ones available on the Internet that have the same concept as XCC and MieruCompiler, although many educational compilers/visualizers have been proposed so far.

5.1 Educational compilers

Unexpectedly, there are few educational compilers that have all the following features, (1) which generate native code, (2) whose source language is a strict syntactic subset of real-world procedu-ral programming languages like C, (3) which have an integrated visualization tool with “horizontal slicing.”

PL/0 [14] do not generate native code, and the source language is not a subset of real-world procedural languages. [15] generate native code, but their source languages are not a subset of real-world procedural languages. Conversely, [16]’s source language are a subset of real-world procedural languages, but they do not generate native code.

MiniJava [3], Cool [15] and Bantam Java [17] are educational compilers whose source languages are object-oriented. Although the features in object-oriented languages like information hiding or inheritance are very important, but we believe that they are too

dif-Þcult for undergraduate students to learn in aÞrst compiler course. All the above do not have an integrated visualization tool with “horizontal slicing.”

5.2 Visualization tools for compilers

Many visualization tools have been proposed so far, but most of them are point solutions and thus not integrated. For exam-ple, many tools have a speciÞc feature like visualizing only pars-ing [5]AC AST [6]þ AC assembly code [7]þ AC symbol tables [8]þ ACþ

optimizers [9]AC compiler behaviors [10, 11]þ ADþ

Only the UW illustrated compiler [13] provides an integrated visualization for the scanner, parser, PL/0 source code, generated P-code, AST, the runtime stack, etc. [13] mentioned that “horizontal slicing” is important, but it is not implemented due to the following reason:

There is nothing intrinsically difÞcult about implementing this slicing but maintaining the maps between IRs, including the graphical display of the IRs, was too complex for our imple-mentation.

To our knowledge, there are no visualization tools that provide “horizontal slicing” even at present, while MieruCompiler provides an integrated visualization with “horizontal slicing.”


This paper proposes a novel visualization tool called MieruCom-piler and an educational comMieruCom-piler called XCC for undergraduate students. To reduce the learning cost of XCC, MieruCompiler pro-vides visualizations for (1) “horizontal slicing”, (2) tooltips for na-tive machine instructions, etc., (3) stack layouts, etc. XCC and

MieruCompiler support native code generation for students in a

Þrst compiler course without sacriÞcing their learning experience. As a preliminary evaluation, MieruCompiler was used in two uni-versities, which produced promising results.


[1] Association for Computing Machinery and IEEE Computer Society, Computer Science Curriculum Update 2008,

http://www.acm.org/education/curricula/ ComputerScience2008.pdf, 2008.

[2] Saumya Debray, Making compiler design relevant for students who will (most likely) never design a compiler, Proc. 33rd SIGCSE tech. sympo. on Computer science education, pp.220–223, 2002. [3] Andrew W. Appel and Jens Palsberg, Modern Compiler

Implementation in Java (2nd ed.), ISBN: 052182060X, 2002ADþ [4] Alfred V. Aho, Ravi Sethi and Jeffrey D. Ullman, Compilers:

Principles, Techniques, and Tools, ISBN: 0321428900, Addison-Wesley, 2006.

[5] Alan Kaplan and Denise Shoup, CUPV—a visualization tool for generated parsers, SIGCSE’00: Proc. 31st SIGCSE tech. sympo. on Computer science education, pp.11–15, 2000.

[6] Steven R. Vegdahl, Using visualization tools to teach compiler design, Journal of Comput. Sci. in Colleges, 16(2), pp.72–83, 2001. [7] Joshua C. Estep and Christopher A. Healy, Aßexible tool for

visualizing assembly code, Journal of Comput. Sci. in Colleges, pp.55–67, 2005.

[8] Jaime Urquiza-Fuentes and Micael Gallego-Carrillo and Francisco Gortázar-Bellas and J. Ángel Velázquez-Iturbide, Visualizing the symbol table, ITICSE ’06: Proc. 11th annual SIGCSE conf. on Innovation and technology in computer science education, Poster session, pp. 341–341, 2006.

[9] Boyd, M. and Whalley, D., Graphical visualization of compiler optimizations, Journal of Prog. Lang., 3(2), pp.69–94, 1995. [10] R. Daniel Resler, VisiCLANG—a visible compiler for CLANG,

SIGPLAN Not., 25(8), pp.120–123, 1990.

[11] M. Eduard Tudoreanu, Designing Effective Program Visualization Tools for Reducing User’s Cognitive Effort, ACM Sympo. on Software Visualization, pp.105–114, 2003.

[12] Elizabeth White, Ranjan Sen and Nina Stewart, Hide and show: using real compiler code for teaching, Proc. 36th SIGCSE tech. sympo. on Computer Science Education, pp.12–16, 2005. [13] K. Andrews and R. R. Henry and W. K. Yamamoto, Design and

implementation of the UW illustrated compiler, SIGPLAN Not., 23(7), pp.105–114, 1988.

[14] Niklaus Wirth, Algorithms + Data Structures = Programs, ISBN-10: 0130224189, Prentice Hall, 1976.

[15] Alexander Aiken, Cool: A portable project for teaching compiler construction, ACM SIGPLAN Notices, 31(7), pp.19–26, 1996. [16] Evgeny A. Eremin, Educational Pascal compiler into MMIX code,

Proc. 6th Baltic Sea Conf. on Computing education research, Koli Calling, Poster Session, pp.143–144, 2006.

[17] Marc L. Corliss and E. Christopher Lewis, Bantam: a customizable, Java-based, classroom compiler, ACM SIGCSE Bulletin, 40(1), pp.38–42, 2008.

[18] Martin Ruckert, Teaching compiler construction and language design: making the case for unusual compiler projects with postscript as the target language, Proc. 38th SIGCSE tech. sympo. on Computer science education, pp. 435–439, 2007.

[19] John S. Mallozzi, Thoughts on and tools for teaching compiler design, Journal of Comput. Sci. in Colleges, 21(2), pp.177–184, 2005.

[20] Intel, Intel 64 and IA-32 Architectures Software Developer’s Manuals,http:

//www.intel.com/products/processor/manuals/. [21] GNU Project, Bison Manual — The Yacc-compatible Parser

Generator,http://www.gnu.org/software/bison/. [22] Programming languages–C: ISO/IEC 9899:1999.

[23] System V Application Binary Interface, Intel386 Architecture Processor Supplement 4th Ed.,http://www.caldera.com/ developers/devspecs/abi386-4.pdf, 1997.





Related subjects :