Fix a few typos in the docs;

This commit is contained in:
Benjamin Bouvier
2016-10-28 18:56:52 +02:00
committed by Jakob Stoklund Olesen
parent 409ce91513
commit de10910324
6 changed files with 16 additions and 16 deletions

View File

@@ -129,7 +129,7 @@ LLVM uses `phi instructions
<http://llvm.org/docs/LangRef.html#phi-instruction>`_ in its SSA
representation. Cretonne passes arguments to EBBs instead. The two
representations are equivalent, but the EBB arguments are better suited to
handle EBBs that main contain multiple branches to the same destination block
handle EBBs that may contain multiple branches to the same destination block
with different arguments. Passing arguments to an EBB looks a lot like passing
arguments to a function call, and the register allocator treats them very
similarly. Arguments are assigned to registers or stack locations.
@@ -145,7 +145,7 @@ can hold.
:cton:type:`i64`. LLVM can represent integer types of arbitrary bit width.
- Floating point types are limited to :cton:type:`f32` and :cton:type:`f64`
which is what WebAssembly provides. It is possible that 16-bit and 128-bit
types will be added in the future/
types will be added in the future.
- Addresses are represented as integers---There are no Cretonne pointer types.
LLVM currently has rich pointer types that include the pointee type. It may
move to a simpler 'address' type in the future. Cretonne may add a single
@@ -173,7 +173,7 @@ Since Cretonne instructions are used all the way until the binary machine code
is emitted, there are opcodes for every native instruction that can be
generated. There is a lot of overlap between different ISAs, so for example the
:cton:inst:`iadd_imm` instruction is used by every ISA that can add an
immediate integer to a register. A simle RISC ISA like RISC-V can be defined
immediate integer to a register. A simple RISC ISA like RISC-V can be defined
with only shared instructions, while an Intel ISA needs a number of specific
instructions to model addressing modes.

View File

@@ -514,7 +514,7 @@ simply represent a contiguous sequence of bytes in the stack frame.
:arg SS: Stack slot declared with :inst:`stack_slot`.
:arg Offset: Immediate non-negative offset.
The dedicated stack access instructions are easy ofr the compiler to reason
The dedicated stack access instructions are easy for the compiler to reason
about because stack slots and offsets are fixed at compile time. For example,
the alignment of these stack memory accesses can be inferred from the offsets
and stack slot alignments.
@@ -583,7 +583,7 @@ than the native pointer size, for example unsigned :type:`i32` offsets on a
Trap if the heap access would be out of bounds.
:arg H: Heap indetifier created by :inst:`heap`.
:arg H: Heap identifier created by :inst:`heap`.
:arg T x: Value to be stored.
:arg iN p: Unsigned base address in heap.
:arg Offset: Immediate signed offset.

View File

@@ -139,7 +139,7 @@ indicated with an instance of :class:`ImmediateKind`.
Entity references
-----------------
Instruction operands can also refer to other entties in the same function. This
Instruction operands can also refer to other entities in the same function. This
can be extended basic blocks, or entities declared in the function preamble.
.. autoclass:: EntityRefKind
@@ -248,7 +248,7 @@ Encodings
=========
Encodings describe how Cretonne instructions are mapped to binary machine code
for the target architecture. After the lealization pass, all remaining
for the target architecture. After the legalization pass, all remaining
instructions are expected to map 1-1 to native instruction encodings. Cretonne
instructions that can't be encoded for the current architecture are called
:term:`illegal instruction`\s.
@@ -256,7 +256,7 @@ instructions that can't be encoded for the current architecture are called
Some instruction set architectures have different :term:`CPU mode`\s with
incompatible encodings. For example, a modern ARMv8 CPU might support three
different CPU modes: *A64* where instructions are encoded in 32 bits, *A32*
where all instuctions are 32 bits, and *T32* which has a mix of 16-bit and
where all instructions are 32 bits, and *T32* which has a mix of 16-bit and
32-bit instruction encodings. These are incompatible encoding spaces, and while
an :cton:inst:`iadd` instruction can be encoded in 32 bits in each of them, it's
not the same 32 bits. It's a judgement call if CPU modes should be modelled as

View File

@@ -145,10 +145,10 @@ See the :file:`lib/filecheck` `documentation <https://docs.rs/filecheck/>`_ for
details of its syntax.
Comments in :file:`.cton` files are associated with the entity they follow.
This typically means and instruction or the whole function. Those tests that
This typically means an instruction or the whole function. Those tests that
use filecheck will extract comments associated with each function (or its
entities) and scan them for filecheck directives. The test output for each
function is then matched againts the filecheck directives for that function.
function is then matched against the filecheck directives for that function.
Note that LLVM's file tests don't separate filecheck directives by their
associated function. It verifies the concatenated output against all filecheck