Fix it's -> its where applicable. (Stefan Haubenthal).
git-svn-id: svn://svn.cc65.org/cc65/trunk@5065 b7a2c559-68d2-44c3-8de9-860c34a00d81
This commit is contained in:
parent
1a0571fdc3
commit
70d5eb7456
5 changed files with 10 additions and 10 deletions
|
@ -554,7 +554,7 @@ expression:
|
|||
<item> If the expression contains symbols that are not defined, and these
|
||||
symbols are local symbols, the enclosing scopes are searched for a
|
||||
symbol with the same name. If one exists and this symbol is defined,
|
||||
it's attributes are used to determine the result size.
|
||||
its attributes are used to determine the result size.
|
||||
<item> In all other cases the expression is assumed to be word sized.
|
||||
</itemize>
|
||||
|
||||
|
@ -3564,7 +3564,7 @@ Here's a list of all control commands and a description, what they do:
|
|||
Delete a define style macro definition. The command is followed by an
|
||||
identifier which specifies the name of the macro to delete. Macro
|
||||
replacement is switched of when reading the token following the command
|
||||
(otherwise the macro name would be replaced by it's replacement list).
|
||||
(otherwise the macro name would be replaced by its replacement list).
|
||||
|
||||
See also the <tt><ref id=".DEFINE" name=".DEFINE"></tt> command and
|
||||
section <ref id="macros" name="Macros">.
|
||||
|
@ -3645,7 +3645,7 @@ were specified when the macro was defined.
|
|||
|
||||
<sect1>Macros without parameters<p>
|
||||
|
||||
In it's simplest form, a macro does not have parameters. Here's an
|
||||
In its simplest form, a macro does not have parameters. Here's an
|
||||
example:
|
||||
|
||||
<tscreen><verb>
|
||||
|
|
|
@ -101,7 +101,7 @@ constant. The compiler emits code to add a constant to the secondary register.
|
|||
Same thing again for the constant 3. So the code produced contains a fetch
|
||||
of 'i', two additions of constants, and a store (into 'i'). Unfortunately, the
|
||||
compiler does not see, that "OFFS + 3" is a constant for itself, since it does
|
||||
it's evaluation from left to right. There are some ways to help the compiler
|
||||
its evaluation from left to right. There are some ways to help the compiler
|
||||
to recognize expression like this:
|
||||
|
||||
<enum>
|
||||
|
|
|
@ -249,7 +249,7 @@ file; then, the actual application code in &dquot;<tt/test.o/&dquot;, and the
|
|||
last is the GEOS system library.
|
||||
|
||||
The resulting file &dquot;<tt/test.cvt/&dquot; is an executable that's
|
||||
contained in the well-known GEOS <em/Convert/ format. Note that it's name
|
||||
contained in the well-known GEOS <em/Convert/ format. Note that its name
|
||||
(<tt/test/) isn't important; the real name, after deconverting, is the DOS name
|
||||
that was given in the header definition.
|
||||
|
||||
|
|
|
@ -237,7 +237,7 @@ available for execution. Here, we list sample emulators and instructions for
|
|||
running the program. Unless noted, similar instructions would also apply to a
|
||||
real machine. One word of advice: we suggest you clear the screen at the
|
||||
start, and wait for a keypress at the end of your program, as each target
|
||||
varies in it's start and exit conditions.
|
||||
varies in its start and exit conditions.
|
||||
|
||||
|
||||
<sect1>Apple
|
||||
|
@ -489,7 +489,7 @@ the emulator.
|
|||
</quote>
|
||||
|
||||
Find the <bf/CONVERT/ program on the boot disk [tap the 6-key; then, you
|
||||
should see it's icon in the fourth position on the <bf/deskTop/'s directory
|
||||
should see its icon in the fourth position on the <bf/deskTop/'s directory
|
||||
notePad]. Move GEOS's pointer over to <bf/CONVERT/'s icon; double-click
|
||||
it to run that program. Click on the <bf/Disk/ icon; put the disk with
|
||||
"<tt/hello1/" into the drive; and, click the <bf/OK/ icon. Use the little
|
||||
|
|
|
@ -278,7 +278,7 @@ Here is a description of all the command line options:
|
|||
written to this file. Using the <tt/-g/ option for the compiler and assembler
|
||||
will increase the amount of information available. Please note that debug
|
||||
information generation is currently being developed, so the format of the
|
||||
file and it's contents are subject to change without further notice.
|
||||
file and its contents are subject to change without further notice.
|
||||
|
||||
|
||||
<tag><tt>--lib file</tt></tag>
|
||||
|
@ -399,7 +399,7 @@ for the segments and define any linker symbols (see <ref id="config-files"
|
|||
name="Configuration files">).
|
||||
|
||||
After that, the linker is ready to produce an output file. Before doing that,
|
||||
it checks it's data for consistency. That is, it checks for unresolved
|
||||
it checks its data for consistency. That is, it checks for unresolved
|
||||
externals (if the output format is not relocatable) and for symbol type
|
||||
mismatches (for example a zero page symbol is imported by a module as absolute
|
||||
symbol).
|
||||
|
@ -659,7 +659,7 @@ Let's have a closer look at this <tt/SEGMENTS/ section. We specify that the
|
|||
goes into <tt/ROM2/. Read/write data will be loaded into <tt/ROM2/ but is run
|
||||
in <tt/RAM2/. That means that all references to labels in the <tt/DATA/
|
||||
segment are relocated to be in <tt/RAM2/, but the segment is written to
|
||||
<tt/ROM2/. All your startup code has to do is, to copy the data from it's
|
||||
<tt/ROM2/. All your startup code has to do is, to copy the data from its
|
||||
location in <tt/ROM2/ to the final location in <tt/RAM2/.
|
||||
|
||||
So, how do you know, where the data is located? This is the second point,
|
||||
|
|
Loading…
Add table
Reference in a new issue