Commit d1348ff0 authored by Mael Cravero's avatar Mael Cravero
Browse files

source_code: update backend for tree rework

* source/source_code/project_layout/index.rst,
* source/source_code/project_layout/lib_misc.rst,
* source/source_code/project_layout/src_assem.rst,
* source/source_code/project_layout/src_canon.rst,
* source/source_code/project_layout/src_llvmtranslate.rst,
* source/source_code/project_layout/src_regalloc.rst,
* source/source_code/project_layout/src_target.rst,
* source/source_code/project_layout/src_target_arm.rst,
* source/source_code/project_layout/src_target_ia32.rst,
* source/source_code/project_layout/src_target_mips.rst,
* source/source_code/project_layout/src_translate.rst,
* source/source_code/project_layout/src_tree.rst: here.
parent 261c2a99
......@@ -20,6 +20,7 @@ This section desribes the mandatory layout of the package.
.. :src/desugar: Removing Syntactic Sugar
.. :src/inlining: Inlining of function bodies
.. :src/combine: Combine different extensions together
.. :src/llvmtranslate: Translation to LLVM IR
.. :src/temp: Fresh Registers and Labels
.. :src/tree: Intermediate Representations
.. :src/frame: Function Arguments and Variables
......@@ -31,7 +32,6 @@ This section desribes the mandatory layout of the package.
.. :src/target/ia32: Translation to IA-32 assembly
.. :src/target/arm: Translation to ARM assembly
.. :src/liveness: Flowgraph and Liveness
.. :src/llvmtranslate: Translation to LLVM IR
.. :src/regalloc: Register Allocation
.. toctree::
......@@ -51,6 +51,7 @@ This section desribes the mandatory layout of the package.
src_desugar
src_inlining
src_combine
src_llvmtranslate
src_temp
src_tree
src_frame
......@@ -62,5 +63,4 @@ This section desribes the mandatory layout of the package.
src_target_ia32
src_target_arm
src_liveness
src_llvmtranslate
src_regalloc
......@@ -11,16 +11,19 @@ Convenient C++ tools.
**File: error.\* (lib/misc/)**
The class :code:`misc::error` implements an error register. Because libraries are expected to be pure,
they cannot issue error messages to the error output, nor exit with failure. One could pass call-backs
(as functions or as objects) to set up error handling. Instead, we choose to register the errors in an
object, and have the library functions return this register: it is up the caller to decide what to do
with these errors. Note also that direct calls to :code:`std::exit` bypass stack unwinding. In other
words, with :code:`std::exit` (instead of :code:`throw`) your application leaks memory.
An instance of :code:`misc:error` can be used as if it were a steam to output error messages. It also
keeps the current exit status until is "triggered", i.e., until it is thrown. Each module has its own
error handler. For instance, the :code:`Binder` has an :code:`error_` attribute, and uses it to report
The class :code:`misc::error` implements an error register. Because libraries
are expected to be pure, they cannot issue error messages to the error output,
nor exit with failure. One could pass call-backs (as functions or as objects)
to set up error handling. Instead, we choose to register the errors in an
object, and have the library functions return this register: it is up the
caller to decide what to do with these errors. Note also that direct calls to
:code:`std::exit` bypass stack unwinding. In other words, with
:code:`std::exit` (instead of :code:`throw`) your application leaks memory.
An instance of :code:`misc:error` can be used as if it were a steam to output
error messages. It also keeps the current exit status until is "triggered",
i.e., until it is thrown. Each module has its own error handler. For instance,
the :code:`Binder` has an :code:`error_` attribute, and uses it to report
errors:
.. code-block:: c++
......@@ -32,9 +35,10 @@ Convenient C++ tools.
<< loc.location_get() << ": " << msg << std::endl;
}
Then the task system fetches the local error handler, and merges it into the global error handler
:code:`error` (see :code:`common.\*`). Some tasks trigger the error handler: if errors were registered,
an exception is raised to exit the program cleanly. The following code demonstrates both aspects.
Then the task system fetches the local error handler, and merges it into the
global error handler :code:`error` (see :code:`common.\*`). Some tasks trigger
the error handler: if errors were registered, an exception is raised to exit
the program cleanly. The following code demonstrates both aspects.
.. code-block:: c++
......@@ -48,7 +52,8 @@ Convenient C++ tools.
**File: escape.\* (lib/misc/)**
The file implements a means to output string while escaping non printable characters. An exemple:
The file implements a means to output string while escaping non printable
characters. An exemple:
.. code-block:: c++
......@@ -58,8 +63,8 @@ Convenient C++ tools.
**File: flex-lexer.hh (lib/misc/)**
The skeleton of the C++ scanner. Adapted from Flex's :code:`FlexLexer.h` and used as a replacement,
thanks to :code:`flex++` (see flex++.in).
The skeleton of the C++ scanner. Adapted from Flex's :code:`FlexLexer.h` and
used as a replacement, thanks to :code:`flex++` (see flex++.in).
**File: graph.\* (lib/misc/)**
......@@ -76,16 +81,19 @@ Convenient C++ tools.
**File: set.\* (lib/misc/)**
A wrapper around :code:`std::set` that introduce convenient operators (:code:`operator+` and so forth).
A wrapper around :code:`std::set` that introduce convenient operators
(:code:`operator+` and so forth).
.. _scoped_map:
**File: scoped-map.\* (lib/misc/)**
The handling of :code:`misc::scoped_map<Key, Data>`, generic scoped map, serving as a basis for symbol
tables used by the :code:`Binder`. :code:`misc::scoped_map` maps a :code:`Key` top a :code:`Data` (that
should ring a bell ...). You are encouraged to implement something simple, based on stacks (see
:code:`std::stack`, or better yet, :code:`std::vector`) and maps (see :code:`std::map`).
The handling of :code:`misc::scoped_map<Key, Data>`, generic scoped map,
serving as a basis for symbol tables used by the :code:`Binder`.
:code:`misc::scoped_map` maps a :code:`Key` top a :code:`Data` (that should
ring a bell ...). You are encouraged to implement something simple, based on
stacks (see :code:`std::stack`, or better yet, :code:`std::vector`) and maps
(see :code:`std::map`).
It must provide this interface:
......@@ -95,14 +103,16 @@ Convenient C++ tools.
**Data get(const Key& key) const**
If *key* was associated to some :code:`Data` in the open scoped, return the most recent insertion.
Otherwise, if :code:`Data` is a pointer type, then return the empty pointer, else throw a
:code:`std::range_error`. To implement this feature, see `<type_traits>
If *key* was associated to some :code:`Data` in the open scoped, return the
most recent insertion. Otherwise, if :code:`Data` is a pointer type, then
return the empty pointer, else throw a :code:`std::range_error`. To
implement this feature, see `<type_traits>
<https://en.cppreference.com/w/cpp/header/type_traits>`_.
**std::ostream& dump(std::ostream& ostr) const**
Send the content of this table on ostr *in a human-readable manner*, and return the stream.
Send the content of this table on ostr *in a human-readable manner*, and
return the stream.
**void scope_begin()**
......@@ -110,28 +120,34 @@ Convenient C++ tools.
**void scope_end()**
Close the last scope, forgetting everything since the latest :code:`scope_begin()`.
Close the last scope, forgetting everything since the latest
:code:`scope_begin()`.
**File: symbol.\* (lib/misc/)**
In a program, the rule for identifiers is to be used many times: at least once for its definition, and
once for each use. Just think about the number of occurrences of :code:`size_t` in a C program for instance.
In a program, the rule for identifiers is to be used many times: at least once
for its definition, and once for each use. Just think about the number of
occurrences of :code:`size_t` in a C program for instance.
To save space one keeps a single copy of each identifier. This provides additional benefits: the address of
this single copy can be used as a key: comparisons (equality or order) are much faster.
To save space one keeps a single copy of each identifier. This provides
additional benefits: the address of this single copy can be used as a key:
comparisons (equality or order) are much faster.
The class :code:`misc::symbol` is an implementation of this idea; See lecture notes, :lectures:`02-scanner-parser.pdf`.
:code:`misc::symbol` is based on :code:`misc::unique`.
The class :code:`misc::symbol` is an implementation of this idea; See lecture
notes, :lectures:`02-scanner-parser.pdf`. :code:`misc::symbol` is based on
:code:`misc::unique`.
**File: time.\* (lib/misc/)**
A class that makes it possible to have timings of processes, similarly to :code:`gcc`'s :code:`--time-report`,
or :code:`bison`'s :code:`--report=time`. It is used in the :code:`Task` machinery, but can be used to
provide better timings (e.g., separating the scanner from the parser).
A class that makes it possible to have timings of processes, similarly to
:code:`gcc`'s :code:`--time-report`, or :code:`bison`'s :code:`--report=time`.
It is used in the :code:`Task` machinery, but can be used to provide better
timings (e.g., separating the scanner from the parser).
**File: unique.\* (lib/misc/)**
A generic class implementing the Flyweight design pattern; It maps identical objects to a unique reference.
A generic class implementing the Flyweight design pattern; It maps identical
objects to a unique reference.
**File: variant.\* (lib/misc/)**
......@@ -142,3 +158,11 @@ Convenient C++ tools.
**File: singleton.\* (lib/misc/)**
A generic class implementing the Singleton design pattern.
**File: list.\* (lib/misc/)**
Functional-style manipulation of vectors.
**File: lambda-viitor.\* (lib/misc/)**
Helper class for :code:`std::visit` based pattern-matching with lambdas.
......@@ -5,9 +5,10 @@ The :code:`src/assem` Directory
Namespace assem, delivered for TC-7.
This directory contains the implementation of the Assem language: yet another intermediate representation
that aims at encoding an assembly language, plus a few needed features so that register allocation can be
performed afterward. Given in full.
This directory contains the implementation of the Assem language: yet another
intermediate representation that aims at encoding an assembly language, plus a
few needed features so that register allocation can be performed afterward.
Given in full.
**Files: instr.* & move.* & oper.* & label.* & comment.* (src/assem/)**
......@@ -15,8 +16,9 @@ performed afterward. Given in full.
**File: fragment.* (src/assem/)**
Implementation of :code:`assem::Fragment`, :code:`assem::ProcFrag`, and :code:`assem::DataFrag`. They are
very similar to :code:`tree::Fragment`: aggregate some information that must remain together, such as a
Implementation of :code:`assem::Fragment`, :code:`assem::ProcFrag`, and
:code:`assem::DataFrag`. They are very similar to :code:`tree::Fragment`:
aggregate some information that must remain together, such as a
:code:`frame::Frame` and the instructions (a list of :code:`assem::Instr`).
**File: visitor.hh (src/assem/)**
......
......@@ -3,4 +3,34 @@
The :code:`src/canon` Directory
-------------------------------
Namespace :code:`canon`.
Namespace :code:`canon`. Canonicalization and linearization of the HIR down to
LIR.
Reading the corresponding explanations in Appel's book is mandatory.
**File: libcanon.* (src/canon/)**
The interface.
**File: basic-block.* (src/canon/)**
A *basic block* is a location independent piece of code, starting with a label
and ending with a jump. The ordering of a program's basic blocks has an impact
on its performances.
**File: canon.* (src/canon/)**
Canonicalize the intermediate representation: remove :code:`tree::Eseq`,
flatten nested :code:`tree::Seq`...
**File: *-matcher.* (src/canon/)**
Functors used to perform pattern-matching on IR for canonicalization. These
make use of :code:`misc::list` functions in order to ease the writing and
reading of the code which is heavily inspired from A. Appel's functional
implementation in ML.
**File: traces.* (src/canon/)**
Linearize the canonicalized intermediate representation to generate basic
blocks.
......@@ -3,23 +3,26 @@
The :code:`src/llvmtranslate` Directory
---------------------------------------
Namespace :code:`llvmtranslate`, delivered for TC-5. Translate the AST to LLVM intermediate code using the
LLVM libraries.
Namespace :code:`llvmtranslate`, delivered for TC-L. Translate the AST to LLVM
intermediate code using the LLVM libraries.
**File: escapes-collector.* (src/llvmtranslate/)**
The :code:`FrameBuilder` and the :code:`EscapesCollector`.
LLVM IR doesn't support static link and nested functions. In order to translate those functions to LLVM IR,
we use Lambda Lifting, which consists in passing a pointer to the escaped variables to the nested function
using that variable.
LLVM IR doesn't support static link and nested functions. In order to
translate those functions to LLVM IR, we use Lambda Lifting, which consists in
passing a pointer to the escaped variables to the nested function using that
variable.
In order to do that, we need a visitor to collect these kind of variables and associate them to each function.
In order to do that, we need a visitor to collect these kind of variables and
associate them to each function.
This visitor is the :code:`EscapesCollector`.
In order for the :code:`EscapesCollector` to work properly, the variables located in the function's frame
have to be excluded. The :code:`FrameBuilder` is building a frame for the :code:`EscapesCollector` to use.
In order for the :code:`EscapesCollector` to work properly, the variables
located in the function's frame have to be excluded. The :code:`FrameBuilder`
is building a frame for the :code:`EscapesCollector` to use.
**File: libllvmtranslate.* (src/llvmtranslate/)**
......@@ -27,13 +30,16 @@ LLVM libraries.
**File: llvm-type-visitor.* (src/llvmtranslate/)**
The LLVM IR is a typed language. In order to ensure type safety, the Tiger types (:code:`type::Type`)
have to be translated to LLVM types (:code:`llvm::Type`). In order to do that, this visitor defined
in src/llvmtranslate is used to traverse the type hierarcy and translate it to LLVM types.
The LLVM IR is a typed language. In order to ensure type safety, the Tiger
types (:code:`type::Type`) have to be translated to LLVM types
(:code:`llvm::Type`). In order to do that, this visitor defined in
src/llvmtranslate is used to traverse the type hierarcy and translate it to
LLVM types.
**File: translator.hh (src/llvmtranslate/)**
Implements the class :code:`Translator` which performs the LLVM IR generation using the LLVM API.
Implements the class :code:`Translator` which performs the LLVM IR generation
using the LLVM API.
For instance, here is the translation of a :code:`ast::SimpleVar`:
......@@ -46,26 +52,33 @@ LLVM libraries.
**File: tiger-runtime.c (src/llvmtranslate/)**
This is the specific runtime for TC-L. It is based on the original runtime, with some adaptations for LLVM.
This is the specific runtime for TC-L. It is based on the original runtime,
with some adaptations for LLVM.
It is compiled to LLVM IR in :code:`$(build_dir)/src/llvmtranslate/runtime.ll`, then a function
:code:`llvmtranslate::runtime_string()` is generated in :code:`$(build_dir)/src/llvmtranslate/runtime.cc`.
It is compiled to LLVM IR in
:code:`$(build_dir)/src/llvmtranslate/runtime.ll`, then a function
:code:`llvmtranslate::runtime_string()` is generated in
:code:`$(build_dir)/src/llvmtranslate/runtime.cc`.
This function is used by the task :code:`--llvm-runtime-display` to print the runtime along the LLVM IR.
This function is used by the task :code:`--llvm-runtime-display` to print the
runtime along the LLVM IR.
**Strings**
Strings are implemented as :code:`char*` 0-terminated buffers, like C strings.
Strings are implemented as :code:`char*` 0-terminated buffers, like C
strings.
**Functions**
Most of the built-ins are just calls to the C standard library functions.
**Characters**
Since the type :code:`char` doesn't exist in TC, a :code:`char` is nothing more than a :code:`string`
of length 1.
In order to avoid allocations every time a character is asked for, an array containing all the characters
followed by a \0 is initialized at the beginning of the program.
Since the type :code:`char` doesn't exist in TC, a :code:`char` is nothing
more than a :code:`string` of length 1.
In order to avoid allocations every time a character is asked for, an array
containing all the characters followed by a \0 is initialized at the
beginning of the program.
**main**
The runtime initializes the one-character strings, then calls :code:`tc_main`, which is the :code:`main`
that your compiler should have provided.
The runtime initializes the one-character strings, then calls
:code:`tc_main`, which is the :code:`main` that your compiler should have
provided.
......@@ -15,7 +15,8 @@ Namespace :code:`regalloc`, register allocation, delivered for TC-9.
**File: libregalloc.* (src/regalloc/)**
Removing useless moves once the register allocation performed, and allocating the register for fragments.
Removing useless moves once the register allocation performed, and allocating
the register for fragments.
**File: test-regalloc.cc (src/regalloc/)**
......
......@@ -16,7 +16,8 @@ Namespace :code:`target`, delivered for TC-7. Some data on the back end.
**File: assembly.* (src/target/)**
The abstract class :code:`target::Assembly`, the interface for elementary assembly instructions generation.
The abstract class :code:`target::Assembly`, the interface for elementary
assembly instructions generation.
**File: codegen.* (src/target/)**
......@@ -24,8 +25,9 @@ Namespace :code:`target`, delivered for TC-7. Some data on the back end.
**Directories: mips, ia32 and arm (src/target/)**
The instruction selection per se split into a generic part, and a target specific (MIPS, IA-32 and ARM) part.
See src/target/mips, src/target/ia32 and src/target/arm.
The instruction selection per se split into a generic part, and a target
specific (MIPS, IA-32 and ARM) part. See src/target/mips, src/target/ia32 and
src/target/arm.
**File: libtarget.* (src/target/)**
......@@ -33,26 +35,32 @@ Namespace :code:`target`, delivered for TC-7. Some data on the back end.
**File: tiger-runtime.c (src/target/)**
This is the Tiger runtime, written in C, based on Andrew Appel's runtime.c. The actual :code:`runtime.s` file
for MIPS was written by hand, but the IA-32 was a compiled version of this file. It should be noted that:
This is the Tiger runtime, written in C, based on Andrew Appel's runtime.c.
The actual :code:`runtime.s` file for MIPS was written by hand, but the IA-32
was a compiled version of this file. It should be noted that:
**Strings**
Strings are implemented as 4 bytes to encode the length, and then a 0-terminated a la C string. The length
part is due to conformance to the Tiger Reference Manual, which specifies that 0 is a regular character
that can be part of the strings, but it is nevertheless terminated by 0 to be compliant with SPIM/Nolimips
:code:`print` syscall. This might change in the future.
Strings are implemented as 4 bytes to encode the length, and then a
0-terminated a la C string. The length part is due to conformance to the
Tiger Reference Manual, which specifies that 0 is a regular character that
can be part of the strings, but it is nevertheless terminated by 0 to be
compliant with SPIM/Nolimips :code:`print` syscall. This might change in the
future.
**Special Strings**
There are some special strings: 0 and 1 character long strings are all implemented via a singleton. That
is to say there is only one allocated string "", a single "1" etc. These singletons are allocated by
:code:`main`. It is essential to preserve this invariant/convention in the whole runtime.
There are some special strings: 0 and 1 character long strings are all
implemented via a singleton. That is to say there is only one allocated
string "", a single "1" etc. These singletons are allocated by :code:`main`.
It is essential to preserve this invariant/convention in the whole runtime.
**strcmp vs. stringEqual**
We don't know how Appel wants to support :code:`"bar" < "foo"` since he doesn't provide :code:`strcmp`.
We do. His implementation of equality is more efficient than ours though, since he can decide just be
looking at the lengths. That could be improved in the future...
We don't know how Appel wants to support :code:`"bar" < "foo"` since he
doesn't provide :code:`strcmp`. We do. His implementation of equality is
more efficient than ours though, since he can decide just be looking at the
lengths. That could be improved in the future...
**main**
The runtime has some initializations to make, such as strings singletons, and then calls the compiled
program. This is why the runtime provides :code:`main`, and calls :code:`tc_main`, which is the main
that your compiler should provide.
The runtime has some initializations to make, such as strings singletons,
and then calls the compiled program. This is why the runtime provides
:code:`main`, and calls :code:`tc_main`, which is the main that your
compiler should provide.
......@@ -3,9 +3,10 @@
The :code:`src/target/arm` Directory
-------------------------------------
Namespace :code:`target::arm`, delivered for TC-7. Code generation for ARM.This is not part of the student
project, but it is left to satisfy their curiosity. In addition its presence is a sane invitation to respect
the constraints of a multi-back-end compiler.
Namespace :code:`target::arm`, delivered for TC-7. Code generation for ARM. This
is not part of the student project, but it is left to satisfy their curiosity.
In addition its presence is a sane invitation to respect the constraints of a
multi-back-end compiler.
**File: cpu.* (src/target/arm/)**
......@@ -13,22 +14,27 @@ the constraints of a multi-back-end compiler.
**File: arm-assembly.* (src/target/arm/)**
The ARM assembly language (syntax, opcodes and layout); it abstracts the generation of ARM instructions
using the GNU Assembler (Gas) Syntax. :code:`target::arm::ArmAssembly` derives from
:code:`target::Assembly`.
The ARM assembly language (syntax, opcodes and layout); it abstracts the
generation of ARM instructions using the GNU Assembler (Gas) Syntax.
:code:`target::arm::ArmAssembly` derives from :code:`target::Assembly`.
**File: arm-layout.* (src/target/arm/)**
How ARM fragments are to be displayed. In other words, that's where the (global) syntax of the target
assembly file is selected.
How ARM fragments are to be displayed. In other words, that's where the
(global) syntax of the target assembly file is selected.
**Files: codegen.* & tree.brg & exp.brg & binop.brg & call.brg & temp.brg & mem.brg & stm.brg & move.brg &
move_load.brg & move_store.brg & cjump.brg & prologue.hh & epilogue.cc (src/target/arm/)**
**File: arm-codegen.* (src/target/arm/)**
A translator from LIR to ASSEM using the ARM instruction set defined by :code:`target::arm::ArmAssembly.`
It is implemented as a dynamic programming algorithm generated by MonoBURG from a set of :code:`brg` files.
A translator from LIR to ASSEM using the ARM instruction set defined by
:code:`target::arm::ArmAssembly`. This relies on
:code:`target::arm::ArmMatcher` for instruction scheduling.
:code:`target::arm::Codegen` derives from :code:`target::Codegen`.
**File: arm-matcher.* (src/target/arm/)**
Functor used for pattern-matching based instruction selection, making use of
:code:`misc::LambdaVisitor` for nested matching.
**File: target.* (src/target/arm/)**
The ARM back end, based on a ARM CPU and a ARM code generator.
......
......@@ -3,9 +3,10 @@
The :code:`src/target/ia32` Directory
-------------------------------------
Namespace :code:`target::ia32`, delivered for TC-7. Code generation for IA-32.This is not part of the student
project, but it is left to satisfy their curiosity. In addition its presence is a sane invitation to respect
the constraints of a multi-back-end compiler.
Namespace :code:`target::ia32`, delivered for TC-7. Code generation for
IA-32. This is not part of the student project, but it is left to satisfy their
curiosity. In addition its presence is a sane invitation to respect the
constraints of a multi-back-end compiler.
**File: cpu.* (src/target/ia32/)**
......@@ -13,22 +14,27 @@ the constraints of a multi-back-end compiler.
**File: gas-assembly.* (src/target/ia32/)**
The IA-32 assembly language (syntax, opcodes and layout); it abstracts the generation of IA-32 instructions
using the GNU Assembler (Gas) Syntax. :code:`target::ia32::GasAssembly` derives from
:code:`target::Assembly`.
The IA-32 assembly language (syntax, opcodes and layout); it abstracts the
generation of IA-32 instructions using the GNU Assembler (Gas) Syntax.
:code:`target::ia32::GasAssembly` derives from :code:`target::Assembly`.
**File: gas-layout.* (src/target/ia32/)**
How IA-32 fragments are to be displayed. In other words, that's where the (global) syntax of the target
assembly file is selected.
How IA-32 fragments are to be displayed. In other words, that's where the
(global) syntax of the target assembly file is selected.
**Files: codegen.* & tree.brg & exp.brg & binop.brg & call.brg & temp.brg & mem.brg & stm.brg & move.brg &
move_load.brg & move_store.brg & cjump.brg & prologue.hh & epilogue.cc (src/target/ia32/)**
**File: gas-codegen.* (src/target/ia32/)**
A translator from LIR to ASSEM using the IA-32 instruction set defined by :code:`target::ia32::GasAssembly.`
It is implemented as a dynamic programming algorithm generated by MonoBURG from a set of :code:`brg` files.
A translator from LIR to ASSEM using the IA-32 instruction set defined by
:code:`target::ia32::GasAssembly`. This relies on
:code:`target::ia32::GasMatcher` for instruction scheduling.
:code:`target::ia32::Codegen` derives from :code:`target::Codegen`.
**File: gas-matcher.* (src/target/ia32/)**
Functor used for pattern-matching based instruction selection, making use of
:code:`misc::LambdaVisitor` for nested matching.
**File: target.* (src/target/ia32/)**
The IA-32 back end, based on a IA-32 CPU and a IA-32 code generator.
......
......@@ -3,7 +3,8 @@
The :code:`src/target/mips` Directory
-------------------------------------
Namespace :code:`target::mips`, delivered for TC-7. Code generation for MIPS R2000.
Namespace :code:`target::mips`, delivered for TC-7. Code generation for MIPS
R2000.
**File: cpu.* (src/target/mips/)**
......@@ -11,21 +12,26 @@ Namespace :code:`target::mips`, delivered for TC-7. Code generation for MIPS R20
**File: spim-assembly.* (src/target/mips/)**
Our assembly language (syntax, opcodes and layout); it abstracts the generation of MIPS R2000 instructions.
:code:`target::mips::SpimAssembly` derives from :code:`target::Assembly`.
Our assembly language (syntax, opcodes and layout); it abstracts the
generation of MIPS R2000 instructions. :code:`target::mips::SpimAssembly`
derives from :code:`target::Assembly`.
**File: spim-layout.* (src/target/mips/)**
How MIPS (and SPIM/Nolimips) fragments are to be displayed. In other words, that's where the (global) syntax
of the target assembly file is selected.
How MIPS (and SPIM/Nolimips) fragments are to be displayed. In other words,
that's where the (global) syntax of the target assembly file is selected.
**Files: codegen.* & tree.brg & exp.brg & binop.brg & call.brg & temp.brg & mem.brg & stm.brg & move.brg &
move_load.brg & move_store.brg & cjump.brg & prologue.hh & epilogue.cc (src/target/mips/)**
**File: spim-codegen.* (src/target/mips/)**
A translator from LIR to ASSEM using the MIPS R2000 instruction set defined by
:code:`target::mips::SpimAssembly.` It is implemented as a dynamic programming algorithm generated by
MonoBURG from a set of :code:`brg` files. :code:`target::mips::Codegen` derives from
:code:`target::Codegen`.
A translator from LIR to ASSEM using the MIPS R2000 instruction set defined by
:code:`target::mips::SpimAssembly`. This relies on
:code:`target::mips::SpimMatcher` for instruction scheduling.
:code:`target::mips::Codegen` derives from :code:`target::Codegen`.
**File: spim-matcher.* (src/target/mips/)**
Functor used for pattern-matching based instruction selection, making use of
:code:`misc::LambdaVisitor` for nested matching.
**File: target.* (src/target/mips/)**
......@@ -33,5 +39,6 @@ move_load.brg & move_store.brg & cjump.brg & prologue.hh & epilogue.cc (src/targ
**File: runtime.s & runtime.cc (src/target/mips/)**
The Tiger runtime in MIPS assembly language: :code:`print` etc. The C++ file :code:`runtime.cc` is built
from :code:`runtime.s`: do not edit the former. See src/target, :code:`tiger-runtime.c`.
The Tiger runtime in MIPS assembly language: :code:`print` etc. The C++ file
:code:`runtime.cc` is built from :code:`runtime.s`: do not edit the former.
See src/target, :code:`tiger-runtime.c`.
......@@ -3,7 +3,8 @@
The :code:`src/translate` Directory
-----------------------------------
Namespace :code:`translate`. Translation to intermediate code translation. It includes:
Namespace :code:`translate`. Translation to intermediate code translation. It
includes:
**File: libtranslate.* (src/translate/)**
......@@ -15,27 +16,30 @@ Namespace :code:`translate`. Translation to intermediate code translation. It in
**File: level.* (src/translate/)**
:code:`translate::Level` are wrappers :code:`frame::Frame` that support the static links, so that we can
find an access to the variables of the parent function.
:code:`translate::Level` are wrappers :code:`frame::Frame` that support the
static links, so that we can find an access to the variables of the parent
function.
**File: exp.hh (src/translate/)**
Implementation of :code:`translate::Ex` (expressions), :code:`Nx` (instructions), :code:`Cx` (conditions),
and :code:`Ix` (if) shells. They wrap :code:`tree::Tree` to delay their translation until the actual use
is known.
Implementation of :code:`translate::Ex` (expressions), :code:`Nx`
(instructions), :code:`Cx` (conditions), and :code:`Ix` (if) shells. They wrap
:code:`tree::Tree` to delay their translation until the actual use is known.
**File: translation.hh (src/translate/)**
Functions used by the :code:`translate::Translator` to translate the AST into HIR. For instance, it contains
:code:`Exp* simpleVar(const Access& access, const Level& level)`,