From 2d7c1c51de7dd6540e9379f6d2c19089c2fc8765 Mon Sep 17 00:00:00 2001 From: Nick Clifton Date: Mon, 24 Jul 2006 13:49:48 +0000 Subject: [PATCH] Fix spelling typos --- ChangeLog | 6 ++++++ doc/app.texi | 38 +++++++++++++++++++------------------- doc/internals.texi | 6 +++--- doc/intro.texi | 6 +++--- doc/notes.texi | 4 ++-- doc/porting.texi | 6 +++--- doc/running.texi | 2 +- doc/sim.texi | 2 +- 8 files changed, 38 insertions(+), 32 deletions(-) diff --git a/ChangeLog b/ChangeLog index f3b4c68..f1cabf4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2006-07-24 Ralk Wildenhues + + * doc/app.texi, doc/internals.texi, doc/intro.texi, + doc/notes.texi, doc/porting.texi, doc/running.texi, + doc/sim.texi: Fix some typos. + 2006-07-14 Dave Brolley * sid.scm (-op-gen-delayed-set-maybe-trace): If delay used, note the diff --git a/doc/app.texi b/doc/app.texi index 27142e3..0a2bd6c 100644 --- a/doc/app.texi +++ b/doc/app.texi @@ -92,7 +92,7 @@ the code must write to @code{(current-output-port)}. Some files require heavy duty processing of the cpu description. For example the simulator computes the instruction formats from the -instruction field lists of each instruction. This computation is defered +instruction field lists of each instruction. This computation is deferred to each cgen- procedure that needs it and must be explicitly requested by them. The results are cached so this is only done once of course. @@ -156,7 +156,7 @@ access functions. - return the attributes specified with `define-arch' (current-arch-default-alignment) - - return a symbol indicated the default aligment + - return a symbol indicated the default alignment - one of aligned, unaligned, forced (current-arch-insn-lsb0?) @@ -273,14 +273,14 @@ and thunks as arguments and writes each argument in turn to stdout. String-lists are lists of strings (nested arbitrarily deep). It's cheaper to @code{cons} long strings together than to use @code{string-append}. Thunks return string-lists to write out, but isn't computed until all -preceeding arguments to `string-write' have been written out. This allows -defering building up of large amounts of text until it needs to be. +preceding arguments to `string-write' have been written out. This allows +deferring building up of large amounts of text until it needs to be. The main procedures for building strings and writing them out are: @itemize @bullet -@item (string-write string-list-or-thunk1 string-list-or-thunk2 ...) +@item (string-write string-list-or-thunk1 string-list-or-thunk2 @dots{}) Loops over arguments writing them out in turn. @@ -289,7 +289,7 @@ Loops over arguments writing them out in turn. Apply proc to each element in string-list-or-thunk-list and write out the result. -@item (string-list arg1 arg2 ...) +@item (string-list arg1 arg2 @dots{}) Return list of arguments. This is identical to @code{list} except it is intended to take string-lists as arguments. @@ -300,7 +300,7 @@ Return list of @code{proc} applied to each element of @code{arg-list}. This is identical to @code{map} except it is intended to take strings as arguments. -@item (string-append string1 string2 ...) +@item (string-append string1 string2 @dots{}) For small arguments it's just as well to use @code{string-append}. This is a standard Scheme procedure. The output is also easier to read @@ -333,8 +333,8 @@ Use @code{class-make} to define a class. @smallexample name: symbol, parent-name-list: list of symbols, names of each parent class -element-list: list of either symbols or (symbol . initial-value) -method-list: list of (symbol . lambda) +element-list: list of either symbols or (symbol .@: initial-value) +method-list: list of (symbol .@: lambda) @end smallexample The result is the class's definition. It is usually assigned to a global @@ -362,7 +362,7 @@ This is a macro so don't quote anything. Write accessors are defined with @code{define-setters}, which creates one procedure for each element, each defined as -@code{(prefix-set-element-name! object new-value)}. +@code{(prefix-set-element-name!@: object new-value)}. This is a macro so don't quote anything. @@ -370,7 +370,7 @@ This is a macro so don't quote anything. This can only be used in method definitions (blech, blah blah blah). -@item (elm-set! object elm-name new-value) +@item (elm-set!@: object elm-name new-value) This can only be used in method definitions (blech, blah blah blah). @@ -386,18 +386,18 @@ The convention is to put this in a cover fn: Same as @code{send} except only usable in methods and is used to invoke the method in the parent class. -@item (make object . args) +@item (make object .@: args) One standard way to create a new object is with @code{make}. It is a wrapper, defined as @smallexample -(define (make object . args) - (apply send (cons (new object) (cons 'make! args))) +(define (make object .@: args) + (apply send (cons (new object) (cons 'make!@: args))) ) @end smallexample -@item (vmake class . args) +@item (vmake class .@: args) The other standard way to create objects is with @code{vmake}. @@ -405,16 +405,16 @@ The other standard way to create objects is with @code{vmake}. ??? Not completely implemented yet. -@item (method-make! class method-name lambda) +@item (method-make!@: class method-name lambda) The normal way of creating methods is to use @code{method-make!}, not define them with the class. It's just easier to define them separately. -@item (method-make-virtual! class method-name lambda) +@item (method-make-virtual!@: class method-name lambda) Create virtual methods created with @code{method-make-virtual!}. -@item (method-make-forward! class elm-name methods) -> unspecified +@item (method-make-forward!@: class elm-name methods) -> unspecified Forwarding a method invocation on one object to another is extremely useful so some utilities have been created to simplify creating forwarding @@ -425,6 +425,6 @@ that forwards the method onto the object contained in element ELM-NAME. @item (method-make-virtual-forward!) -Same as method-make-forward! except that it creates virtual methods. +Same as method-make-forward!@: except that it creates virtual methods. @end itemize diff --git a/doc/internals.texi b/doc/internals.texi index 3cbf9a4..f650066 100644 --- a/doc/internals.texi +++ b/doc/internals.texi @@ -83,7 +83,7 @@ This manual documents the internals of CGEN, version @value{VERSION}. * Source file overview:: * Option processing:: * Parsing:: -* Debuging:: Debugging applications +* Debugging:: Debugging applications * Version numbering:: * Glossary:: Glossary * Index:: Index @@ -108,7 +108,7 @@ understand. @item Procedures and variables local to a file are named @code{-foo}. @item Only routines that emit application code begin with @code{gen-}. @item Symbols beginning with @code{c-} are either variables containing C code - or procedures that generate C code, similarily for C++ and @code{c++-}. + or procedures that generate C code, similarly for C++ and @code{c++-}. @item Variables containing C code begin with @code{c-}. @item Only routines that emit an entire file begin with @code{cgen-}. @item All @file{.cpu} file elements shall have @code{-foo-parse} and @@ -244,7 +244,7 @@ Hardware description routines. Instruction fields. @item insn.scm -Instruction defintions. +Instruction definitions. @item mach.scm Architecture description routines. diff --git a/doc/intro.texi b/doc/intro.texi index c22f465..9e7f75c 100644 --- a/doc/intro.texi +++ b/doc/intro.texi @@ -177,7 +177,7 @@ compiled and then the new version of the target program is run. The second way is to do the translation from target instruction set to host instruction set while the target program is running. This is often -refered to as JIT (Just In Time) simulation (FIXME: proper phrasing here?). +referred to as JIT (Just In Time) simulation (FIXME: proper phrasing here?). One way to implement this is to simulate instructions the way existing CGEN simulators do, but keep track of how frequently a basic block is executed. If a block gets executed often enough, then compile a translation @@ -414,7 +414,7 @@ this is using RTL to describe instruction semantics rather than, say, C. The assembler can also make use of the instruction semantics. It doesn't make use of the semantics, per se, but what it does use is the input and output operand information that is machine generated from the semantics. -Groking operand usage from C is possible I guess, but a lot harder. +Grokking operand usage from C is possible I guess, but a lot harder. So by writing the semantics in RTL multiple applications can make use if it. One can also generate from the RTL code in languages other than C. @@ -599,7 +599,7 @@ well as supporting routines. @section Simulator support Simulator support comes in the form of machine generated the decoder/executer -as well as the structure that records CPU state information (ie. registers). +as well as the structure that records CPU state information (i.e., registers). @node Testing support @section Testing support diff --git a/doc/notes.texi b/doc/notes.texi index b21a59b..8ccf595 100644 --- a/doc/notes.texi +++ b/doc/notes.texi @@ -201,7 +201,7 @@ similar speed in file generation. Guile isn't fast enough. And while Guile+Hobbit may be, for the one-time builder the time taken to compile Hobbit, run it, and compile the result, will appear to swamp any gains. There is also the additional burden of -building Guile first (though with my prefered Guile implementation +building Guile first (though with my preferred Guile implementation I'm _hoping_ that wouldn't be a problem). The pragmatic choice is C. Blech. @@ -214,7 +214,7 @@ Java would also be a better implementation language than C [an interesting experiment would be Kawa]. But it's worse as a pragmatic choice than C++. -My prefered choice is a small-and-fast subset of Guile that gets +My preferred choice is a small-and-fast subset of Guile that gets distributed with binutils, gdb, etc. IMO Guile is too bloated and unmaintainable for the casual maintainer (hacking on its innards requires too steep a learning curve, and is one that is easily slipped back diff --git a/doc/porting.texi b/doc/porting.texi index 9d748ef..2cd3d24 100644 --- a/doc/porting.texi +++ b/doc/porting.texi @@ -519,11 +519,11 @@ The instruction conditionally sets pc. @item SKIP-CTI -NB. This is an expermental attribute. Its usage needs to evolve. +NB. This is an experimental attribute. Its usage needs to evolve. @item DELAY-SLOT -NB. This is an expermental attribute. Its usage needs to evolve. +NB. This is an experimental attribute. Its usage needs to evolve. @end itemize @end itemize @@ -995,7 +995,7 @@ are various ways to do this, and several are supported. Which one to choose depends on the environment in which the CPU will be used. For example when executing a program in a single-CPU environment without devices, most or all available cycles can be devoted to simulation of the -atarget CPU. However, in an environment with devices or multiple cpus, one +target CPU. However, in an environment with devices or multiple cpus, one may wish the CPU to execute one instruction then relinquish control so a device operation may be done or an instruction can be simulated on a second cpu. Efficient techniques for the former aren't necessarily the best diff --git a/doc/running.texi b/doc/running.texi index 644dad1..0798405 100644 --- a/doc/running.texi +++ b/doc/running.texi @@ -6,4 +6,4 @@ @chapter Running CGEN This chapter needs to explain how to run CGEN, how it fits together, and -what to expect when you do run it (ie. output, resultant files, etc). +what to expect when you do run it (i.e., output, resultant files, etc). diff --git a/doc/sim.texi b/doc/sim.texi index 3d13e4c..f52848c 100644 --- a/doc/sim.texi +++ b/doc/sim.texi @@ -7,7 +7,7 @@ @cindex Simulation support Simulator support comes in the form of machine generated the decoder/executer -as well as the structure that records CPU state information (ie. registers). +as well as the structure that records CPU state information (i.e., registers). There are 3 architecture-wide generated files: -- 2.43.5