# HG changeset patch # User lost@l-w.ca # Date 1288462500 21600 # Node ID a9521955554f2bb026f82902577493bfa22c019e # Parent 7b8d89435f30221b649af48f3dd4eebe6396633e Added pragma pcaspcr to treat PC as PCR; additional fixes for PCR addressing modes diff -r 7b8d89435f30 -r a9521955554f configure --- a/configure Sat Oct 30 11:51:25 2010 -0600 +++ b/configure Sat Oct 30 12:15:00 2010 -0600 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.65 for LWTools 3.0. +# Generated by GNU Autoconf 2.65 for LWTools 3.0.1. # # Report bugs to . # @@ -551,8 +551,8 @@ # Identity of this package. PACKAGE_NAME='LWTools' PACKAGE_TARNAME='lwtools' -PACKAGE_VERSION='3.0' -PACKAGE_STRING='LWTools 3.0' +PACKAGE_VERSION='3.0.1' +PACKAGE_STRING='LWTools 3.0.1' PACKAGE_BUGREPORT='lost@l-w.ca' PACKAGE_URL='' @@ -1641,7 +1641,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures LWTools 3.0 to adapt to many kinds of systems. +\`configure' configures LWTools 3.0.1 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1711,7 +1711,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of LWTools 3.0:";; + short | recursive ) echo "Configuration of LWTools 3.0.1:";; esac cat <<\_ACEOF @@ -1798,7 +1798,7 @@ test -n "$ac_init_help" && exit $ac_status if $ac_init_version; then cat <<\_ACEOF -LWTools configure 3.0 +LWTools configure 3.0.1 generated by GNU Autoconf 2.65 Copyright (C) 2009 Free Software Foundation, Inc. @@ -2440,7 +2440,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by LWTools $as_me 3.0, which was +It was created by LWTools $as_me 3.0.1, which was generated by GNU Autoconf 2.65. Invocation command line was $ $0 $@ @@ -3271,7 +3271,7 @@ # Define the identity of the package. PACKAGE='lwtools' - VERSION='3.0' + VERSION='3.0.1' cat >>confdefs.h <<_ACEOF @@ -11303,7 +11303,7 @@ # report actual input values of CONFIG_FILES etc. instead of their # values after options handling. ac_log=" -This file was extended by LWTools $as_me 3.0, which was +This file was extended by LWTools $as_me 3.0.1, which was generated by GNU Autoconf 2.65. Invocation command line was CONFIG_FILES = $CONFIG_FILES @@ -11369,7 +11369,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`" ac_cs_version="\\ -LWTools config.status 3.0 +LWTools config.status 3.0.1 configured by $0, generated by GNU Autoconf 2.65, with options \\"\$ac_cs_config\\" diff -r 7b8d89435f30 -r a9521955554f doc/manual.docbook.sgml --- a/doc/manual.docbook.sgml Sat Oct 30 11:51:25 2010 -0600 +++ b/doc/manual.docbook.sgml Sat Oct 30 12:15:00 2010 -0600 @@ -1529,6 +1529,20 @@ + +pcaspcr + + + Normally, LWASM makes a distinction between PC and PCR in program +counter relative addressing. In particular, the use of PC means an absolute +offset from PC while PCR causes the assembler to calculate the offset to the +specified operand and use that as the offset from PC. By setting this +pragma, you can have PC treated the same as PCR. + + + + + diff -r 7b8d89435f30 -r a9521955554f doc/manual/c625.html --- a/doc/manual/c625.html Sat Oct 30 11:51:25 2010 -0600 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,336 +0,0 @@ - -LWLINK
LW Tool Chain
PrevNext

Chapter 4. LWLINK

The LWTOOLS linker is called LWLINK. This chapter documents the various features -of the linker.

4.1. Command Line Options

The binary for LWLINK is called "lwlink". Note that the binary is in lower -case. lwlink takes the following command line arguments.

--decb, -b

Selects the DECB output format target. This is equivalent to --format=decb

--output=FILE, -o FILE

This option specifies the name of the output file. If not specified, the -default is a.out.

--format=TYPE, -f TYPE

This option specifies the output format. Valid values are decb -and raw

--raw, -r

This option specifies the raw output format. -It is equivalent to --format=raw -and -f raw

--script=FILE, -s

This option allows specifying a linking script to override the linker's -built in defaults.

--section-base=SECT=BASE

Cause section SECT to load at base address BASE. This will be prepended -to the built-in link script. It is ignored if a link script is provided.

--map=FILE, -m FILE

This will output a description of the link result to FILE.

--library=LIBSPEC, -l LIBSPEC

Load a library using the library search path. LIBSPEC will have "lib" prepended -and ".a" appended.

--library-path=DIR, -L DIR

Add DIR to the library search path.

--debug, -d

This option increases the debugging level. It is only useful for LWTOOLS -developers.

--help, -?

This provides a listing of command line options and a brief description -of each.

--usage

This will display a usage summary -of each command line option.

--version, -V

This will display the version of LWLINK.


PrevHomeNext
Assembler Modes and Pragmas Linker Operation
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c629.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/c629.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,336 @@ + +LWLINK
LW Tool Chain
PrevNext

Chapter 4. LWLINK

The LWTOOLS linker is called LWLINK. This chapter documents the various features +of the linker.

4.1. Command Line Options

The binary for LWLINK is called "lwlink". Note that the binary is in lower +case. lwlink takes the following command line arguments.

--decb, -b

Selects the DECB output format target. This is equivalent to --format=decb

--output=FILE, -o FILE

This option specifies the name of the output file. If not specified, the +default is a.out.

--format=TYPE, -f TYPE

This option specifies the output format. Valid values are decb +and raw

--raw, -r

This option specifies the raw output format. +It is equivalent to --format=raw +and -f raw

--script=FILE, -s

This option allows specifying a linking script to override the linker's +built in defaults.

--section-base=SECT=BASE

Cause section SECT to load at base address BASE. This will be prepended +to the built-in link script. It is ignored if a link script is provided.

--map=FILE, -m FILE

This will output a description of the link result to FILE.

--library=LIBSPEC, -l LIBSPEC

Load a library using the library search path. LIBSPEC will have "lib" prepended +and ".a" appended.

--library-path=DIR, -L DIR

Add DIR to the library search path.

--debug, -d

This option increases the debugging level. It is only useful for LWTOOLS +developers.

--help, -?

This provides a listing of command line options and a brief description +of each.

--usage

This will display a usage summary +of each command line option.

--version, -V

This will display the version of LWLINK.


PrevHomeNext
Assembler Modes and Pragmas Linker Operation
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c630.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/c630.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,336 @@ + +LWLINK
LW Tool Chain
PrevNext

Chapter 4. LWLINK

The LWTOOLS linker is called LWLINK. This chapter documents the various features +of the linker.

4.1. Command Line Options

The binary for LWLINK is called "lwlink". Note that the binary is in lower +case. lwlink takes the following command line arguments.

--decb, -b

Selects the DECB output format target. This is equivalent to --format=decb

--output=FILE, -o FILE

This option specifies the name of the output file. If not specified, the +default is a.out.

--format=TYPE, -f TYPE

This option specifies the output format. Valid values are decb +and raw

--raw, -r

This option specifies the raw output format. +It is equivalent to --format=raw +and -f raw

--script=FILE, -s

This option allows specifying a linking script to override the linker's +built in defaults.

--section-base=SECT=BASE

Cause section SECT to load at base address BASE. This will be prepended +to the built-in link script. It is ignored if a link script is provided.

--map=FILE, -m FILE

This will output a description of the link result to FILE.

--library=LIBSPEC, -l LIBSPEC

Load a library using the library search path. LIBSPEC will have "lib" prepended +and ".a" appended.

--library-path=DIR, -L DIR

Add DIR to the library search path.

--debug, -d

This option increases the debugging level. It is only useful for LWTOOLS +developers.

--help, -?

This provides a listing of command line options and a brief description +of each.

--usage

This will display a usage summary +of each command line option.

--version, -V

This will display the version of LWLINK.


PrevHomeNext
Assembler Modes and Pragmas Linker Operation
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c773.html --- a/doc/manual/c773.html Sat Oct 30 11:51:25 2010 -0600 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,270 +0,0 @@ - -Libraries and LWAR
LW Tool Chain
PrevNext

Chapter 5. Libraries and LWAR

LWTOOLS also includes a tool for managing libraries. These are analogous to -the static libraries created with the "ar" tool on POSIX systems. Each library -file contains one or more object files. The linker will treat the object -files within a library as though they had been specified individually on -the command line except when resolving external references. External references -are looked up first within the object files within the library and then, if -not found, the usual lookup based on the order the files are specified on -the command line occurs.

The tool for creating these libary files is called LWAR.

5.1. Command Line Options

The binary for LWAR is called "lwar". Note that the binary is in lower -case. The options lwar understands are listed below. For archive manipulation -options, the first non-option argument is the name of the archive. All other -non-option arguments are the names of files to operate on.

--add, -a

This option specifies that an archive is going to have files added to it. -If the archive does not already exist, it is created. New files are added -to the end of the archive.

--create, -c

This option specifies that an archive is going to be created and have files -added to it. If the archive already exists, it is truncated.

--merge, -m

If specified, any files specified to be added to an archive will be checked -to see if they are archives themselves. If so, their constituent members are -added to the archive. This is useful for avoiding archives containing archives.

--list, -l

This will display a list of the files contained in the archive.

--debug, -d

This option increases the debugging level. It is only useful for LWTOOLS -developers.

--help, -?

This provides a listing of command line options and a brief description -of each.

--usage

This will display a usage summary -of each command line option.

--version, -V

This will display the version of LWLINK. -of each.


PrevHomeNext
Linking Scripts Object Files
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c777.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/c777.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,270 @@ + +Libraries and LWAR
LW Tool Chain
PrevNext

Chapter 5. Libraries and LWAR

LWTOOLS also includes a tool for managing libraries. These are analogous to +the static libraries created with the "ar" tool on POSIX systems. Each library +file contains one or more object files. The linker will treat the object +files within a library as though they had been specified individually on +the command line except when resolving external references. External references +are looked up first within the object files within the library and then, if +not found, the usual lookup based on the order the files are specified on +the command line occurs.

The tool for creating these libary files is called LWAR.

5.1. Command Line Options

The binary for LWAR is called "lwar". Note that the binary is in lower +case. The options lwar understands are listed below. For archive manipulation +options, the first non-option argument is the name of the archive. All other +non-option arguments are the names of files to operate on.

--add, -a

This option specifies that an archive is going to have files added to it. +If the archive does not already exist, it is created. New files are added +to the end of the archive.

--create, -c

This option specifies that an archive is going to be created and have files +added to it. If the archive already exists, it is truncated.

--merge, -m

If specified, any files specified to be added to an archive will be checked +to see if they are archives themselves. If so, their constituent members are +added to the archive. This is useful for avoiding archives containing archives.

--list, -l

This will display a list of the files contained in the archive.

--debug, -d

This option increases the debugging level. It is only useful for LWTOOLS +developers.

--help, -?

This provides a listing of command line options and a brief description +of each.

--usage

This will display a usage summary +of each command line option.

--version, -V

This will display the version of LWLINK. +of each.


PrevHomeNext
Linking Scripts Object Files
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c778.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/c778.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,270 @@ + +Libraries and LWAR
LW Tool Chain
PrevNext

Chapter 5. Libraries and LWAR

LWTOOLS also includes a tool for managing libraries. These are analogous to +the static libraries created with the "ar" tool on POSIX systems. Each library +file contains one or more object files. The linker will treat the object +files within a library as though they had been specified individually on +the command line except when resolving external references. External references +are looked up first within the object files within the library and then, if +not found, the usual lookup based on the order the files are specified on +the command line occurs.

The tool for creating these libary files is called LWAR.

5.1. Command Line Options

The binary for LWAR is called "lwar". Note that the binary is in lower +case. The options lwar understands are listed below. For archive manipulation +options, the first non-option argument is the name of the archive. All other +non-option arguments are the names of files to operate on.

--add, -a

This option specifies that an archive is going to have files added to it. +If the archive does not already exist, it is created. New files are added +to the end of the archive.

--create, -c

This option specifies that an archive is going to be created and have files +added to it. If the archive already exists, it is truncated.

--merge, -m

If specified, any files specified to be added to an archive will be checked +to see if they are archives themselves. If so, their constituent members are +added to the archive. This is useful for avoiding archives containing archives.

--list, -l

This will display a list of the files contained in the archive.

--debug, -d

This option increases the debugging level. It is only useful for LWTOOLS +developers.

--help, -?

This provides a listing of command line options and a brief description +of each.

--usage

This will display a usage summary +of each command line option.

--version, -V

This will display the version of LWLINK. +of each.


PrevHomeNext
Linking Scripts Object Files
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c835.html --- a/doc/manual/c835.html Sat Oct 30 11:51:25 2010 -0600 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,376 +0,0 @@ - -Object Files
LW Tool Chain
Prev 

Chapter 6. Object Files

LWTOOLS uses a proprietary object file format. It is proprietary in the sense -that it is specific to LWTOOLS, not that it is a hidden format. It would be -hard to keep it hidden in an open source tool chain anyway. This chapter -documents the object file format.

An object file consists of a series of sections each of which contains a -list of exported symbols, a list of incomplete references, and a list of -"local" symbols which may be used in calculating incomplete references. Each -section will obviously also contain the object code.

Exported symbols must be completely resolved to an address within the -section it is exported from. That is, an exported symbol must be a constant -rather than defined in terms of other symbols.

Each object file starts with a magic number and version number. The magic -number is the string "LWOBJ16" for this 16 bit object file format. The only -defined version number is currently 0. Thus, the first 8 bytes of the object -file are 4C574F424A313600

Each section has the following items in order:

The section starts with the name of the section with a NUL termination -followed by a series of flag bytes terminated by NUL. There are only two -flag bytes defined. A NUL (0) indicates no more flags and a value of 1 -indicates the section is a BSS section. For a BSS section, no actual -code is included in the object file.

Either a NULL section name or end of file indicate the presence of no more -sections.

Each entry in the exported and local symbols table consists of the symbol -(NUL terminated) followed by two bytes which contain the value in big endian -order. The end of a symbol table is indicated by a NULL symbol name.

Each entry in the incomplete references table consists of an expression -followed by a 16 bit offset where the reference goes. Expressions are -defined as a series of terms up to an "end of expression" term. Each term -consists of a single byte which identifies the type of term (see below) -followed by any data required by the term. Then end of the list is flagged -by a NULL expression (only an end of expression term).

Table 6-1. Object File Term Types

TERMTYPEMeaning
00end of expression
01integer (16 bit in big endian order follows)
02 external symbol reference (NUL terminated symbol name follows)
03local symbol reference (NUL terminated symbol name follows)
04operator (1 byte operator number)
05section base address reference
FFThis term will set flags for the expression. Each one of these terms will set a single flag. All of them should be specified first in an expression. If they are not, the behaviour is undefined. The byte following is the flag. Flag 01 indicates an 8 bit relocation. Flag 02 indicates a zero-width relocation (see the EXTDEP pseudo op in LWASM).

External references are resolved using other object files while local -references are resolved using the local symbol table(s) from this file. This -allows local symbols that are not exported to have the same names as -exported symbols or external references.

Table 6-2. Object File Operator Numbers

NumberOperator
01addition (+)
02subtraction (-)
03multiplication (*)
04division (/)
05modulus (%)
06integer division (\) (same as division)
07bitwise and
08bitwise or
09bitwise xor
0Aboolean and
0Bboolean or
0Cunary negation, 2's complement (-)
0Dunary 1's complement (^)

An expression is represented in a postfix manner with both operands for -binary operators preceding the operator and the single operand for unary -operators preceding the operator.


PrevHome 
Libraries and LWAR  
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c839.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/c839.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,376 @@ + +Object Files
LW Tool Chain
Prev 

Chapter 6. Object Files

LWTOOLS uses a proprietary object file format. It is proprietary in the sense +that it is specific to LWTOOLS, not that it is a hidden format. It would be +hard to keep it hidden in an open source tool chain anyway. This chapter +documents the object file format.

An object file consists of a series of sections each of which contains a +list of exported symbols, a list of incomplete references, and a list of +"local" symbols which may be used in calculating incomplete references. Each +section will obviously also contain the object code.

Exported symbols must be completely resolved to an address within the +section it is exported from. That is, an exported symbol must be a constant +rather than defined in terms of other symbols.

Each object file starts with a magic number and version number. The magic +number is the string "LWOBJ16" for this 16 bit object file format. The only +defined version number is currently 0. Thus, the first 8 bytes of the object +file are 4C574F424A313600

Each section has the following items in order:

The section starts with the name of the section with a NUL termination +followed by a series of flag bytes terminated by NUL. There are only two +flag bytes defined. A NUL (0) indicates no more flags and a value of 1 +indicates the section is a BSS section. For a BSS section, no actual +code is included in the object file.

Either a NULL section name or end of file indicate the presence of no more +sections.

Each entry in the exported and local symbols table consists of the symbol +(NUL terminated) followed by two bytes which contain the value in big endian +order. The end of a symbol table is indicated by a NULL symbol name.

Each entry in the incomplete references table consists of an expression +followed by a 16 bit offset where the reference goes. Expressions are +defined as a series of terms up to an "end of expression" term. Each term +consists of a single byte which identifies the type of term (see below) +followed by any data required by the term. Then end of the list is flagged +by a NULL expression (only an end of expression term).

Table 6-1. Object File Term Types

TERMTYPEMeaning
00end of expression
01integer (16 bit in big endian order follows)
02 external symbol reference (NUL terminated symbol name follows)
03local symbol reference (NUL terminated symbol name follows)
04operator (1 byte operator number)
05section base address reference
FFThis term will set flags for the expression. Each one of these terms will set a single flag. All of them should be specified first in an expression. If they are not, the behaviour is undefined. The byte following is the flag. Flag 01 indicates an 8 bit relocation. Flag 02 indicates a zero-width relocation (see the EXTDEP pseudo op in LWASM).

External references are resolved using other object files while local +references are resolved using the local symbol table(s) from this file. This +allows local symbols that are not exported to have the same names as +exported symbols or external references.

Table 6-2. Object File Operator Numbers

NumberOperator
01addition (+)
02subtraction (-)
03multiplication (*)
04division (/)
05modulus (%)
06integer division (\) (same as division)
07bitwise and
08bitwise or
09bitwise xor
0Aboolean and
0Bboolean or
0Cunary negation, 2's complement (-)
0Dunary 1's complement (^)

An expression is represented in a postfix manner with both operands for +binary operators preceding the operator and the single operand for unary +operators preceding the operator.


PrevHome 
Libraries and LWAR  
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/c840.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/c840.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,376 @@ + +Object Files
LW Tool Chain
Prev 

Chapter 6. Object Files

LWTOOLS uses a proprietary object file format. It is proprietary in the sense +that it is specific to LWTOOLS, not that it is a hidden format. It would be +hard to keep it hidden in an open source tool chain anyway. This chapter +documents the object file format.

An object file consists of a series of sections each of which contains a +list of exported symbols, a list of incomplete references, and a list of +"local" symbols which may be used in calculating incomplete references. Each +section will obviously also contain the object code.

Exported symbols must be completely resolved to an address within the +section it is exported from. That is, an exported symbol must be a constant +rather than defined in terms of other symbols.

Each object file starts with a magic number and version number. The magic +number is the string "LWOBJ16" for this 16 bit object file format. The only +defined version number is currently 0. Thus, the first 8 bytes of the object +file are 4C574F424A313600

Each section has the following items in order:

The section starts with the name of the section with a NUL termination +followed by a series of flag bytes terminated by NUL. There are only two +flag bytes defined. A NUL (0) indicates no more flags and a value of 1 +indicates the section is a BSS section. For a BSS section, no actual +code is included in the object file.

Either a NULL section name or end of file indicate the presence of no more +sections.

Each entry in the exported and local symbols table consists of the symbol +(NUL terminated) followed by two bytes which contain the value in big endian +order. The end of a symbol table is indicated by a NULL symbol name.

Each entry in the incomplete references table consists of an expression +followed by a 16 bit offset where the reference goes. Expressions are +defined as a series of terms up to an "end of expression" term. Each term +consists of a single byte which identifies the type of term (see below) +followed by any data required by the term. Then end of the list is flagged +by a NULL expression (only an end of expression term).

Table 6-1. Object File Term Types

TERMTYPEMeaning
00end of expression
01integer (16 bit in big endian order follows)
02 external symbol reference (NUL terminated symbol name follows)
03local symbol reference (NUL terminated symbol name follows)
04operator (1 byte operator number)
05section base address reference
FFThis term will set flags for the expression. Each one of these terms will set a single flag. All of them should be specified first in an expression. If they are not, the behaviour is undefined. The byte following is the flag. Flag 01 indicates an 8 bit relocation. Flag 02 indicates a zero-width relocation (see the EXTDEP pseudo op in LWASM).

External references are resolved using other object files while local +references are resolved using the local symbol table(s) from this file. This +allows local symbols that are not exported to have the same names as +exported symbols or external references.

Table 6-2. Object File Operator Numbers

NumberOperator
01addition (+)
02subtraction (-)
03multiplication (*)
04division (/)
05modulus (%)
06integer division (\) (same as division)
07bitwise and
08bitwise or
09bitwise xor
0Aboolean and
0Bboolean or
0Cunary negation, 2's complement (-)
0Dunary 1's complement (^)

An expression is represented in a postfix manner with both operands for +binary operators preceding the operator and the single operand for unary +operators preceding the operator.


PrevHome 
Libraries and LWAR  
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/index.html --- a/doc/manual/index.html Sat Oct 30 11:51:25 2010 -0600 +++ b/doc/manual/index.html Sat Oct 30 12:15:00 2010 -0600 @@ -179,45 +179,45 @@ >
4. LWLINK
4.1. Command Line Options
4.2. Linker Operation
4.3. Linking Scripts
5. Libraries and LWAR
5.1. Command Line Options
6. Object Files
6-1. Object File Term Types
6-2. Object File Operator Numbers
4. LWLINK
4.1. Command Line Options
4.2. Linker Operation
4.3. Linking Scripts
5. Libraries and LWAR
5.1. Command Line Options
6-1. Object File Term Types
6-2. Object File Operator Numbers
pcaspcr

Normally, LWASM makes a distinction between PC and PCR in program +counter relative addressing. In particular, the use of PC means an absolute +offset from PC while PCR causes the assembler to calculate the offset to the +specified operand and use that as the offset from PC. By setting this +pragma, you can have PC treated the same as PCR.


Chapter 4. LWLINK


4.1. Command Line Options


4.2. Linker Operation


4.3. Linking Scripts


Chapter 5. Libraries and LWAR


5.1. Command Line Options

LWASM supports generating a proprietary object file format which is described in Chapter 6. LWLINK is then used to link these object files into a final binary in any of LWLINK's supported binary diff -r 7b8d89435f30 -r a9521955554f doc/manual/x580.html --- a/doc/manual/x580.html Sat Oct 30 11:51:25 2010 -0600 +++ b/doc/manual/x580.html Sat Oct 30 12:15:00 2010 -0600 @@ -17,7 +17,7 @@ HREF="x517.html">Next

pcaspcr

Normally, LWASM makes a distinction between PC and PCR in program +counter relative addressing. In particular, the use of PC means an absolute +offset from PC while PCR causes the assembler to calculate the offset to the +specified operand and use that as the offset from PC. By setting this +pragma, you can have PC treated the same as PCR.

Next -Linker Operation
LW Tool Chain
PrevChapter 4. LWLINKNext

4.2. Linker Operation

LWLINK takes one or more files in supported input formats and links them -into a single binary. Currently supported formats are the LWTOOLS object -file format and the archive format used by LWAR. While the precise method is -slightly different, linking can be conceptualized as the following steps.

  1. First, the linker loads a linking script. If no script is specified, it -loads a built-in default script based on the output format selected. This -script tells the linker how to lay out the various sections in the final -binary.

  2. Next, the linker reads all the input files into memory. At this time, it -flags any format errors in those files. It constructs a table of symbols -for each object at this time.

  3. The linker then proceeds with organizing the sections loaded from each file -according to the linking script. As it does so, it is able to assign addresses -to each symbol defined in each object file. At this time, the linker may -also collapse different instances of the same section name into a single -section by appending the data from each subsequent instance of the section -to the first instance of the section.

  4. Next, the linker looks through every object file for every incomplete reference. -It then attempts to fully resolve that reference. If it cannot do so, it -throws an error. Once a reference is resolved, the value is placed into -the binary code at the specified section. It should be noted that an -incomplete reference can reference either a symbol internal to the object -file or an external symbol which is in the export list of another object -file.

  5. If all of the above steps are successful, the linker opens the output file -and actually constructs the binary.


PrevHomeNext
LWLINKUpLinking Scripts
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/x729.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/x729.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,191 @@ + +Linker Operation
LW Tool Chain
PrevChapter 4. LWLINKNext

4.2. Linker Operation

LWLINK takes one or more files in supported input formats and links them +into a single binary. Currently supported formats are the LWTOOLS object +file format and the archive format used by LWAR. While the precise method is +slightly different, linking can be conceptualized as the following steps.

  1. First, the linker loads a linking script. If no script is specified, it +loads a built-in default script based on the output format selected. This +script tells the linker how to lay out the various sections in the final +binary.

  2. Next, the linker reads all the input files into memory. At this time, it +flags any format errors in those files. It constructs a table of symbols +for each object at this time.

  3. The linker then proceeds with organizing the sections loaded from each file +according to the linking script. As it does so, it is able to assign addresses +to each symbol defined in each object file. At this time, the linker may +also collapse different instances of the same section name into a single +section by appending the data from each subsequent instance of the section +to the first instance of the section.

  4. Next, the linker looks through every object file for every incomplete reference. +It then attempts to fully resolve that reference. If it cannot do so, it +throws an error. Once a reference is resolved, the value is placed into +the binary code at the specified section. It should be noted that an +incomplete reference can reference either a symbol internal to the object +file or an external symbol which is in the export list of another object +file.

  5. If all of the above steps are successful, the linker opens the output file +and actually constructs the binary.


PrevHomeNext
LWLINKUpLinking Scripts
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/x730.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/x730.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,191 @@ + +Linker Operation
LW Tool Chain
PrevChapter 4. LWLINKNext

4.2. Linker Operation

LWLINK takes one or more files in supported input formats and links them +into a single binary. Currently supported formats are the LWTOOLS object +file format and the archive format used by LWAR. While the precise method is +slightly different, linking can be conceptualized as the following steps.

  1. First, the linker loads a linking script. If no script is specified, it +loads a built-in default script based on the output format selected. This +script tells the linker how to lay out the various sections in the final +binary.

  2. Next, the linker reads all the input files into memory. At this time, it +flags any format errors in those files. It constructs a table of symbols +for each object at this time.

  3. The linker then proceeds with organizing the sections loaded from each file +according to the linking script. As it does so, it is able to assign addresses +to each symbol defined in each object file. At this time, the linker may +also collapse different instances of the same section name into a single +section by appending the data from each subsequent instance of the section +to the first instance of the section.

  4. Next, the linker looks through every object file for every incomplete reference. +It then attempts to fully resolve that reference. If it cannot do so, it +throws an error. Once a reference is resolved, the value is placed into +the binary code at the specified section. It should be noted that an +incomplete reference can reference either a symbol internal to the object +file or an external symbol which is in the export list of another object +file.

  5. If all of the above steps are successful, the linker opens the output file +and actually constructs the binary.


PrevHomeNext
LWLINKUpLinking Scripts
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/x739.html --- a/doc/manual/x739.html Sat Oct 30 11:51:25 2010 -0600 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,243 +0,0 @@ - -Linking Scripts
LW Tool Chain
PrevChapter 4. LWLINKNext

4.3. Linking Scripts

A linker script is used to instruct the linker about how to assemble the -various sections into a completed binary. It consists of a series of -directives which are considered in the order they are encountered.

The sections will appear in the resulting binary in the order they are -specified in the script file. If a referenced section is not found, the linker will behave as though the -section did exist but had a zero size, no relocations, and no exports. -A section should only be referenced once. Any subsequent references will have -an undefined effect.

All numbers are in linking scripts are specified in hexadecimal. All directives -are case sensitive although the hexadecimal numbers are not.

A section name can be specified as a "*", then any section not -already matched by the script will be matched. The "*" can be followed -by a comma and a flag to narrow the section down slightly, also. -If the flag is "!bss", then any section that is not flagged as a bss section -will be matched. If the flag is "bss", then any section that is flagged as -bss will be matched.

The following directives are understood in a linker script.

section name load addr

This causes the section name to load at -addr. For the raw target, only one "load at" entry is -allowed for non-bss sections and it must be the first one. For raw targets, -it affects the addresses the linker assigns to symbols but has no other -affect on the output. bss sections may all have separate load addresses but -since they will not appear in the binary anyway, this is okay.

For the decb target, each "load" entry will cause a new "block" to be -output to the binary which will contain the load address. It is legal for -sections to overlap in this manner - the linker assumes the loader will sort -everything out.

section name

This will cause the section name to load after the previously listed -section.

exec addr or sym

This will cause the execution address (entry point) to be the address -specified (in hex) or the specified symbol name. The symbol name must -match a symbol that is exported by one of the object files being linked. -This has no effect for targets that do not encode the entry point into the -resulting file. If not specified, the entry point is assumed to be address 0 -which is probably not what you want. The default link scripts for targets -that support this directive automatically starts at the beginning of the -first section (usually "init" or "code") that is emitted in the binary.

pad size

This will cause the output file to be padded with NUL bytes to be exactly -size bytes in length. This only makes sense for a raw target.


PrevHomeNext
Linker OperationUpLibraries and LWAR
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/x743.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/x743.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,243 @@ + +Linking Scripts
LW Tool Chain
PrevChapter 4. LWLINKNext

4.3. Linking Scripts

A linker script is used to instruct the linker about how to assemble the +various sections into a completed binary. It consists of a series of +directives which are considered in the order they are encountered.

The sections will appear in the resulting binary in the order they are +specified in the script file. If a referenced section is not found, the linker will behave as though the +section did exist but had a zero size, no relocations, and no exports. +A section should only be referenced once. Any subsequent references will have +an undefined effect.

All numbers are in linking scripts are specified in hexadecimal. All directives +are case sensitive although the hexadecimal numbers are not.

A section name can be specified as a "*", then any section not +already matched by the script will be matched. The "*" can be followed +by a comma and a flag to narrow the section down slightly, also. +If the flag is "!bss", then any section that is not flagged as a bss section +will be matched. If the flag is "bss", then any section that is flagged as +bss will be matched.

The following directives are understood in a linker script.

section name load addr

This causes the section name to load at +addr. For the raw target, only one "load at" entry is +allowed for non-bss sections and it must be the first one. For raw targets, +it affects the addresses the linker assigns to symbols but has no other +affect on the output. bss sections may all have separate load addresses but +since they will not appear in the binary anyway, this is okay.

For the decb target, each "load" entry will cause a new "block" to be +output to the binary which will contain the load address. It is legal for +sections to overlap in this manner - the linker assumes the loader will sort +everything out.

section name

This will cause the section name to load after the previously listed +section.

exec addr or sym

This will cause the execution address (entry point) to be the address +specified (in hex) or the specified symbol name. The symbol name must +match a symbol that is exported by one of the object files being linked. +This has no effect for targets that do not encode the entry point into the +resulting file. If not specified, the entry point is assumed to be address 0 +which is probably not what you want. The default link scripts for targets +that support this directive automatically starts at the beginning of the +first section (usually "init" or "code") that is emitted in the binary.

pad size

This will cause the output file to be padded with NUL bytes to be exactly +size bytes in length. This only makes sense for a raw target.


PrevHomeNext
Linker OperationUpLibraries and LWAR
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f doc/manual/x744.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/x744.html Sat Oct 30 12:15:00 2010 -0600 @@ -0,0 +1,243 @@ + +Linking Scripts
LW Tool Chain
PrevChapter 4. LWLINKNext

4.3. Linking Scripts

A linker script is used to instruct the linker about how to assemble the +various sections into a completed binary. It consists of a series of +directives which are considered in the order they are encountered.

The sections will appear in the resulting binary in the order they are +specified in the script file. If a referenced section is not found, the linker will behave as though the +section did exist but had a zero size, no relocations, and no exports. +A section should only be referenced once. Any subsequent references will have +an undefined effect.

All numbers are in linking scripts are specified in hexadecimal. All directives +are case sensitive although the hexadecimal numbers are not.

A section name can be specified as a "*", then any section not +already matched by the script will be matched. The "*" can be followed +by a comma and a flag to narrow the section down slightly, also. +If the flag is "!bss", then any section that is not flagged as a bss section +will be matched. If the flag is "bss", then any section that is flagged as +bss will be matched.

The following directives are understood in a linker script.

section name load addr

This causes the section name to load at +addr. For the raw target, only one "load at" entry is +allowed for non-bss sections and it must be the first one. For raw targets, +it affects the addresses the linker assigns to symbols but has no other +affect on the output. bss sections may all have separate load addresses but +since they will not appear in the binary anyway, this is okay.

For the decb target, each "load" entry will cause a new "block" to be +output to the binary which will contain the load address. It is legal for +sections to overlap in this manner - the linker assumes the loader will sort +everything out.

section name

This will cause the section name to load after the previously listed +section.

exec addr or sym

This will cause the execution address (entry point) to be the address +specified (in hex) or the specified symbol name. The symbol name must +match a symbol that is exported by one of the object files being linked. +This has no effect for targets that do not encode the entry point into the +resulting file. If not specified, the entry point is assumed to be address 0 +which is probably not what you want. The default link scripts for targets +that support this directive automatically starts at the beginning of the +first section (usually "init" or "code") that is emitted in the binary.

pad size

This will cause the output file to be padded with NUL bytes to be exactly +size bytes in length. This only makes sense for a raw target.


PrevHomeNext
Linker OperationUpLibraries and LWAR
\ No newline at end of file diff -r 7b8d89435f30 -r a9521955554f lwasm/insn_indexed.c --- a/lwasm/insn_indexed.c Sat Oct 30 11:51:25 2010 -0600 +++ b/lwasm/insn_indexed.c Sat Oct 30 12:15:00 2010 -0600 @@ -257,7 +257,7 @@ } // PCR? then we have PC relative addressing (like B??, LB??) - if (rn == 5) + if (rn == 5 || (rn == 6 && CURPRAGMA(l, PRAGMA_PCASPCR))) { lw_expr_t e1, e2; // external references are handled exactly the same as for @@ -274,12 +274,26 @@ lwasm_save_expr(l, 0, e2); if (l -> lint == 1) { - l -> pb = (indir * 0x80) | 0x8C; + l -> pb = indir ? 0x9C : 0x8C; return; } if (l -> lint == 2) { - l -> pb = (indir * 0x80) | 0x8D; + l -> pb = indir ? 0x9D : 0x8D; + return; + } + } + + if (rn == 6) + { + if (l -> lint == 1) + { + l -> pb = indir ? 0x9C : 0x8C; + return; + } + if (l -> lint == 2) + { + l -> pb = indir ? 0x9D : 0x8D; return; } } diff -r 7b8d89435f30 -r a9521955554f lwasm/lwasm.h --- a/lwasm/lwasm.h Sat Oct 30 11:51:25 2010 -0600 +++ b/lwasm/lwasm.h Sat Oct 30 12:15:00 2010 -0600 @@ -75,7 +75,8 @@ PRAGMA_NOINDEX0TONONE = 0x0002, // do not change implicit 0,R to ,R PRAGMA_UNDEFEXTERN = 0x0004, // undefined symbols are considered to be external PRAGMA_CESCAPES = 0x0008, // allow C style escapes in fcc, fcs, fcn, etc. - PRAGMA_IMPORTUNDEFEXPORT = 0x0010 // imports symbol if undefined upon export + PRAGMA_IMPORTUNDEFEXPORT = 0x0010, // imports symbol if undefined upon export + PRAGMA_PCASPCR = 0x0020 // treats ,PC as ,PCR instead of constant offset }; diff -r 7b8d89435f30 -r a9521955554f lwasm/pragma.c --- a/lwasm/pragma.c Sat Oct 30 11:51:25 2010 -0600 +++ b/lwasm/pragma.c Sat Oct 30 12:15:00 2010 -0600 @@ -39,6 +39,7 @@ { "undefextern", PRAGMA_UNDEFEXTERN }, { "cescapes", PRAGMA_CESCAPES }, { "importundefexport", PRAGMA_IMPORTUNDEFEXPORT }, + { "pcaspcr", PRAGMA_PCASPCR }, { 0, 0 } }; @@ -49,6 +50,7 @@ { "noundefextern", PRAGMA_UNDEFEXTERN }, { "nocescapes", PRAGMA_CESCAPES }, { "noimportundefexport", PRAGMA_IMPORTUNDEFEXPORT }, + { "nopcaspcr", PRAGMA_PCASPCR }, { 0, 0 } };