aboutsummaryrefslogtreecommitdiff
path: root/tcg
diff options
context:
space:
mode:
authorbellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>2008-02-01 13:01:47 +0000
committerbellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>2008-02-01 13:01:47 +0000
commit9804c8e203dae31e31c198d5bfddfe880c81d08b (patch)
tree6e6f63ced087ef54c5169639cd3c4f452f4e6e4f /tcg
parent57fec1fee94aa9f7d2519e8c354f100fc36bc9fa (diff)
typos
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@3945 c046a42c-6fe2-441c-8c8c-71466251a162
Diffstat (limited to 'tcg')
-rw-r--r--tcg/README8
1 files changed, 4 insertions, 4 deletions
diff --git a/tcg/README b/tcg/README
index f5b1280913..466e330368 100644
--- a/tcg/README
+++ b/tcg/README
@@ -17,7 +17,7 @@ from the host, although it is never the case for QEMU.
A TCG "function" corresponds to a QEMU Translated Block (TB).
A TCG "temporary" is a variable only live in a given
-function. Temporaries are allocated explicitely in each function.
+function. Temporaries are allocated explicitly in each function.
A TCG "global" is a variable which is live in all the functions. They
are defined before the functions defined. A TCG global can be a memory
@@ -103,7 +103,7 @@ optimizations:
information is used to suppress moves from a dead temporary to
another one. It is also used to remove instructions which compute
dead results. The later is especially useful for condition code
- optimisation in QEMU.
+ optimization in QEMU.
In the following example:
@@ -118,7 +118,7 @@ optimizations:
that some results of a computation are indeed not useful. With the
macro system, the user can provide several alternative
implementations which are used depending on the used results. It is
- especially useful for condition code optimisation in QEMU.
+ especially useful for condition code optimization in QEMU.
Here is an example:
@@ -413,7 +413,7 @@ register.
TCG is backward compatible with QEMU "dyngen" operations. It means
that TCG instructions can be freely mixed with dyngen operations. It
is expected that QEMU targets will be progressively fully converted to
-TCG. Once a target is fully converted to dyngen, it will be possible
+TCG. Once a target is fully converted to TCG, it will be possible
to apply more optimizations because more registers will be free for
the generated code.