# HG changeset patch
# User lost
# Date 1268967254 0
# Node ID eb230fa7d28ef52b8b19bf6f621b95e043444b42
# Parent e7885b3ee266db32572ba67354c6d87ca8d7953f
Prepare for migration to hg
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/COPYING
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/COPYING Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,674 @@
+ GNU GENERAL PUBLIC LICENSE
+ Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc.
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+ The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works. By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users. We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors. You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+ To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights. Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received. You must make sure that they, too, receive
+or can get the source code. And you must show them these terms so they
+know their rights.
+
+ Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+ For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software. For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+ Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so. This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software. The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable. Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products. If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+ Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary. To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+ TERMS AND CONDITIONS
+
+ 0. Definitions.
+
+ "This License" refers to version 3 of the GNU General Public License.
+
+ "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+ "The Program" refers to any copyrightable work licensed under this
+License. Each licensee is addressed as "you". "Licensees" and
+"recipients" may be individuals or organizations.
+
+ To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy. The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+ A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+ To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy. Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+ To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies. Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+ An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License. If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+ 1. Source Code.
+
+ The "source code" for a work means the preferred form of the work
+for making modifications to it. "Object code" means any non-source
+form of a work.
+
+ A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+ The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form. A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+ The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities. However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work. For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+ The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+ The Corresponding Source for a work in source code form is that
+same work.
+
+ 2. Basic Permissions.
+
+ All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met. This License explicitly affirms your unlimited
+permission to run the unmodified Program. The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work. This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+ You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force. You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright. Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+ Conveying under any other circumstances is permitted solely under
+the conditions stated below. Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+ 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+ No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+ When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+ 4. Conveying Verbatim Copies.
+
+ You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+ You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+ 5. Conveying Modified Source Versions.
+
+ You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+ a) The work must carry prominent notices stating that you modified
+ it, and giving a relevant date.
+
+ b) The work must carry prominent notices stating that it is
+ released under this License and any conditions added under section
+ 7. This requirement modifies the requirement in section 4 to
+ "keep intact all notices".
+
+ c) You must license the entire work, as a whole, under this
+ License to anyone who comes into possession of a copy. This
+ License will therefore apply, along with any applicable section 7
+ additional terms, to the whole of the work, and all its parts,
+ regardless of how they are packaged. This License gives no
+ permission to license the work in any other way, but it does not
+ invalidate such permission if you have separately received it.
+
+ d) If the work has interactive user interfaces, each must display
+ Appropriate Legal Notices; however, if the Program has interactive
+ interfaces that do not display Appropriate Legal Notices, your
+ work need not make them do so.
+
+ A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit. Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+ 6. Conveying Non-Source Forms.
+
+ You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+ a) Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by the
+ Corresponding Source fixed on a durable physical medium
+ customarily used for software interchange.
+
+ b) Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by a
+ written offer, valid for at least three years and valid for as
+ long as you offer spare parts or customer support for that product
+ model, to give anyone who possesses the object code either (1) a
+ copy of the Corresponding Source for all the software in the
+ product that is covered by this License, on a durable physical
+ medium customarily used for software interchange, for a price no
+ more than your reasonable cost of physically performing this
+ conveying of source, or (2) access to copy the
+ Corresponding Source from a network server at no charge.
+
+ c) Convey individual copies of the object code with a copy of the
+ written offer to provide the Corresponding Source. This
+ alternative is allowed only occasionally and noncommercially, and
+ only if you received the object code with such an offer, in accord
+ with subsection 6b.
+
+ d) Convey the object code by offering access from a designated
+ place (gratis or for a charge), and offer equivalent access to the
+ Corresponding Source in the same way through the same place at no
+ further charge. You need not require recipients to copy the
+ Corresponding Source along with the object code. If the place to
+ copy the object code is a network server, the Corresponding Source
+ may be on a different server (operated by you or a third party)
+ that supports equivalent copying facilities, provided you maintain
+ clear directions next to the object code saying where to find the
+ Corresponding Source. Regardless of what server hosts the
+ Corresponding Source, you remain obligated to ensure that it is
+ available for as long as needed to satisfy these requirements.
+
+ e) Convey the object code using peer-to-peer transmission, provided
+ you inform other peers where the object code and Corresponding
+ Source of the work are being offered to the general public at no
+ charge under subsection 6d.
+
+ A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+ A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling. In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage. For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product. A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+ "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source. The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+ If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information. But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+ The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed. Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+ Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+ 7. Additional Terms.
+
+ "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law. If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+ When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it. (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.) You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+ Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+ a) Disclaiming warranty or limiting liability differently from the
+ terms of sections 15 and 16 of this License; or
+
+ b) Requiring preservation of specified reasonable legal notices or
+ author attributions in that material or in the Appropriate Legal
+ Notices displayed by works containing it; or
+
+ c) Prohibiting misrepresentation of the origin of that material, or
+ requiring that modified versions of such material be marked in
+ reasonable ways as different from the original version; or
+
+ d) Limiting the use for publicity purposes of names of licensors or
+ authors of the material; or
+
+ e) Declining to grant rights under trademark law for use of some
+ trade names, trademarks, or service marks; or
+
+ f) Requiring indemnification of licensors and authors of that
+ material by anyone who conveys the material (or modified versions of
+ it) with contractual assumptions of liability to the recipient, for
+ any liability that these contractual assumptions directly impose on
+ those licensors and authors.
+
+ All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10. If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term. If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+ If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+ Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+ 8. Termination.
+
+ You may not propagate or modify a covered work except as expressly
+provided under this License. Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+ However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+ Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+ Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License. If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+ 9. Acceptance Not Required for Having Copies.
+
+ You are not required to accept this License in order to receive or
+run a copy of the Program. Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance. However,
+nothing other than this License grants you permission to propagate or
+modify any covered work. These actions infringe copyright if you do
+not accept this License. Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+ 10. Automatic Licensing of Downstream Recipients.
+
+ Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License. You are not responsible
+for enforcing compliance by third parties with this License.
+
+ An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations. If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+ You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License. For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+ 11. Patents.
+
+ A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based. The
+work thus licensed is called the contributor's "contributor version".
+
+ A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version. For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+ Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+ In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement). To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+ If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients. "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+ If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+ A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License. You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+ Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+ 12. No Surrender of Others' Freedom.
+
+ If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all. For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+ 13. Use with the GNU Affero General Public License.
+
+ Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work. The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+ 14. Revised Versions of this License.
+
+ The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+ Each version is given a distinguishing version number. If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation. If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+ If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+ Later license versions may give you additional or different
+permissions. However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+ 15. Disclaimer of Warranty.
+
+ THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+ 16. Limitation of Liability.
+
+ IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+ 17. Interpretation of Sections 15 and 16.
+
+ If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+ END OF TERMS AND CONDITIONS
+
+ How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+
+ Copyright (C)
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see .
+
+Also add information on how to contact you by electronic and paper mail.
+
+ If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+ Copyright (C)
+ This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+ You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+.
+
+ The GNU General Public License does not permit incorporating your program
+into proprietary programs. If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library. If this is what you want to do, use the GNU Lesser General
+Public License instead of this License. But first, please read
+.
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/ChangeLog
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/ChangeLog Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,119 @@
+The following includes the various changes in each release of LWTOOLS.
+
+Each item is prefixed by a flag in []. The flags mean:
+
+[*] Project structure or other "meta" change
+[!] critical bug fix - code generation error, etc.
+[+] new feature
+[-] feature removed
+[b] minor bugfix
+[ ] general improvement
+
+Also, the software affected may follow in [].
+
+Version 3.0
+
+[*] Completely new architecture
+[b] Fixed bug that caused segfault on pass 2 if bad expression [LWASM]
+
+Version 2.5
+
+[!] Fixed error in the fix for invalid operands included in 2.4 [LWASM]
+[b] Fixed bug with "include" directive operand parsing [LWASM]
+[b] Fixed additional parsing errors with pseudo ops [LWASM]
+[b] Fixed parsing error with various conditional nesting situations [LWASM]
+[+] Added includebin directive to include the literal contents of a binary
+ file at the current assembly address. [LWASM]
+[+] Added || and && as boolean or and boolean and respectively [LWASM]
+[+] Added COPY, COPY-, IMP, EXP, TFRP, TFRM, TFRS, TFRR as alternatives to
+ the TFM instruction variations for compatibility with other assemblers
+ [LWASM]
+[+] Added --6809/-9 switch to cause 6309 instructions to be rejected; also
+ included --6309/-3 switch to force default allow of 6309 instructions
+ [LWASM]
+[+] ALIGN now takes an optional padding value (ALIGN align,pad) to specify
+ the byte value that will be used for padding if needed [LWASM]
+[+] Added OS9 module target along with the OS9, MOD, and EMOD pseudo ops
+ to allow building OS9 modules [LWASM]
+[+] Added pragma "dollarlocal"/"nodollarlocal" and "dollarnotlocal"/
+ "nodollarnotlocal" to control whether $ localizes a symbol [LWASM]
+[ ] Fixed a few cosmetic issues with error reporting
+
+Version 2.4
+
+[!] Fixed off by one relocation offest for base page external references
+ generated by lwasm [LWASM]
+[b] Fixed segfault in "extern" pseudo op and allowed a symbol list as the
+ operand just like "export" [LWASM]
+[b] Fixed lack of error when there are extraneous characters at the end
+ of the operand. This did not cause incorrect code generation for correct
+ code but would silently generate incorrect code for some easy errors
+[+] 8 bit immediate operands can now be external references [LWASM]
+
+Version 2.3
+
+[*] added support for compiling using MinGW and added portions of gnulib
+ to support argp, among other things. Yah! A Windows build!
+[+] added library search path (-L) and library specification (-l) to LWLINK
+[+] added ability to specify section base addresses on the command line to
+ LWLINK (they get prepended to the built in link script)
+[+] added ability to output a "linkmap" to lwlink (--map, -m)
+[+] added LWEX0 (LWOS simple binary) target to LWLINK
+[+] added ability to extract files in LWAR
+[+] added ability to "replace" members in LWAR
+[+] added support for "sym=expr" in the opcode field; this will define a
+ global symbol (non-section) if it resolves to a constant
+[+] added operator ~ as a prefix operator for a 1s complement in LWASM
+[+] allow exporting multiple symbols (export sym,sym,sym...)
+[+] allow extern references in base page addresing mode, possibly buggy
+ still (LWASM)
+[+] handle 8 bit external references, possibly buggy still (LWLINK)
+[+] arranged for unused members of library files (archives) to be ignored
+ during linking to keep the final size of the binary down (LWLINK)
+[b] arranged for output files for lwasm/lwlink to be removed if the assembly
+ or linking fails
+[b] fixed incorrect handling of library search path which caused only the
+ last directory to ever matter
+[ ] DECB output of LWLINK now collapses contiguous output blocks into single
+ single blocks in the output file; this eliminates the explosion of
+ preambles that previously occurred
+[ ] LWLINK now displays *all* undefined symbols and references instead of
+ bailing out after the first one
+
+Version 2.2
+
+[*] created LWAR to manage library/archive files
+[+] cescapes pragma to allow C-style string escapes in FCC, FCS, and FCN
+[+] .area alias for SECTION
+[+] .globl alias for EXPORT; also accept name of symbol as operand
+[+] various compatibility directive aliases for FCB, FDB, FQB, RMB, FCC,
+ FCS, and FCN
+[+] accept "*" has a prefix for base page addressing mode
+[+] sections named "bss" or ".bss" in any case are now assumed to be
+ BSS sections. The "!bss" flag can be used to remove that assumption.
+[+] ignore lines starting with # to permit C pre-processor output to be used
+ as input to lwasm
+[+] allow "0x" and "0X" as prefixes to identify hexadecimal numbers
+[+] added support for a simple library/archive file format to LWLINK
+[b] actually show assembly errors when no list requested
+[b] pragma and --pragma now actually take multiple pragmas as documented
+
+Version 2.1
+
+[*] merged LWLINK (1.0) and LWASM to create LWTOOLS
+[+] [LWASM] pragmas can be specified on the command line
+[+] [LWASM] undefextern pragma added (undefined symbols treated as external)
+[+] documentation
+[b] [LWASM] made pragmas case insensitive
+[b] [LWASM] made EXTERN symbols never be part of a section in symbol table
+
+
+LWASM Version 2.0
+
+[*] major rewrite of the entire assembler
+[+] object file support
+
+
+LWLINK Version 1.0
+
+[*] initial released version
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/INSTALL
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/INSTALL Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,237 @@
+Installation Instructions
+*************************
+
+Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
+2006, 2007 Free Software Foundation, Inc.
+
+This file is free documentation; the Free Software Foundation gives
+unlimited permission to copy, distribute and modify it.
+
+Basic Installation
+==================
+
+Briefly, the shell commands `./configure; make; make install' should
+configure, build, and install this package. The following
+more-detailed instructions are generic; see the `README' file for
+instructions specific to this package.
+
+ The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation. It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions. Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, and a
+file `config.log' containing compiler output (useful mainly for
+debugging `configure').
+
+ It can also use an optional file (typically called `config.cache'
+and enabled with `--cache-file=config.cache' or simply `-C') that saves
+the results of its tests to speed up reconfiguring. Caching is
+disabled by default to prevent problems with accidental use of stale
+cache files.
+
+ If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release. If you are using the cache, and at
+some point `config.cache' contains results you don't want to keep, you
+may remove or edit it.
+
+ The file `configure.ac' (or `configure.in') is used to create
+`configure' by a program called `autoconf'. You need `configure.ac' if
+you want to change it or regenerate `configure' using a newer version
+of `autoconf'.
+
+The simplest way to compile this package is:
+
+ 1. `cd' to the directory containing the package's source code and type
+ `./configure' to configure the package for your system.
+
+ Running `configure' might take a while. While running, it prints
+ some messages telling which features it is checking for.
+
+ 2. Type `make' to compile the package.
+
+ 3. Optionally, type `make check' to run any self-tests that come with
+ the package.
+
+ 4. Type `make install' to install the programs and any data files and
+ documentation.
+
+ 5. You can remove the program binaries and object files from the
+ source code directory by typing `make clean'. To also remove the
+ files that `configure' created (so you can compile the package for
+ a different kind of computer), type `make distclean'. There is
+ also a `make maintainer-clean' target, but that is intended mainly
+ for the package's developers. If you use it, you may have to get
+ all sorts of other programs in order to regenerate files that came
+ with the distribution.
+
+ 6. Often, you can also type `make uninstall' to remove the installed
+ files again.
+
+Compilers and Options
+=====================
+
+Some systems require unusual options for compilation or linking that the
+`configure' script does not know about. Run `./configure --help' for
+details on some of the pertinent environment variables.
+
+ You can give `configure' initial values for configuration parameters
+by setting variables in the command line or in the environment. Here
+is an example:
+
+ ./configure CC=c99 CFLAGS=-g LIBS=-lposix
+
+ *Note Defining Variables::, for more details.
+
+Compiling For Multiple Architectures
+====================================
+
+You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory. To do this, you can use GNU `make'. `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script. `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'.
+
+ With a non-GNU `make', it is safer to compile the package for one
+architecture at a time in the source code directory. After you have
+installed the package for one architecture, use `make distclean' before
+reconfiguring for another architecture.
+
+Installation Names
+==================
+
+By default, `make install' installs the package's commands under
+`/usr/local/bin', include files under `/usr/local/include', etc. You
+can specify an installation prefix other than `/usr/local' by giving
+`configure' the option `--prefix=PREFIX'.
+
+ You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files. If you
+pass the option `--exec-prefix=PREFIX' to `configure', the package uses
+PREFIX as the prefix for installing programs and libraries.
+Documentation and other data files still use the regular prefix.
+
+ In addition, if you use an unusual directory layout you can give
+options like `--bindir=DIR' to specify different values for particular
+kinds of files. Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them.
+
+ If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+Optional Features
+=================
+
+Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System). The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+ For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+Specifying the System Type
+==========================
+
+There may be some features `configure' cannot figure out automatically,
+but needs to determine by the type of machine the package will run on.
+Usually, assuming the package is built to be run on the _same_
+architectures, `configure' can figure that out, but if it prints a
+message saying it cannot guess the machine type, give it the
+`--build=TYPE' option. TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name which has the form:
+
+ CPU-COMPANY-SYSTEM
+
+where SYSTEM can have one of these forms:
+
+ OS KERNEL-OS
+
+ See the file `config.sub' for the possible values of each field. If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the machine type.
+
+ If you are _building_ compiler tools for cross-compiling, you should
+use the option `--target=TYPE' to select the type of system they will
+produce code for.
+
+ If you want to _use_ a cross compiler, that generates code for a
+platform different from the build platform, you should specify the
+"host" platform (i.e., that on which the generated programs will
+eventually be run) with `--host=TYPE'.
+
+Sharing Defaults
+================
+
+If you want to set default values for `configure' scripts to share, you
+can create a site shell script called `config.site' that gives default
+values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists. Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Defining Variables
+==================
+
+Variables not defined in a site shell script can be set in the
+environment passed to `configure'. However, some packages may run
+configure again during the build, and the customized values of these
+variables may be lost. In order to avoid this problem, you should set
+them in the `configure' command line, using `VAR=value'. For example:
+
+ ./configure CC=/usr/local2/bin/gcc
+
+causes the specified `gcc' to be used as the C compiler (unless it is
+overridden in the site shell script).
+
+Unfortunately, this technique does not work for `CONFIG_SHELL' due to
+an Autoconf bug. Until the bug is fixed you can use this workaround:
+
+ CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
+
+`configure' Invocation
+======================
+
+`configure' recognizes the following options to control how it operates.
+
+`--help'
+`-h'
+ Print a summary of the options to `configure', and exit.
+
+`--version'
+`-V'
+ Print the version of Autoconf used to generate the `configure'
+ script, and exit.
+
+`--cache-file=FILE'
+ Enable the cache: use and save the results of the tests in FILE,
+ traditionally `config.cache'. FILE defaults to `/dev/null' to
+ disable caching.
+
+`--config-cache'
+`-C'
+ Alias for `--cache-file=config.cache'.
+
+`--quiet'
+`--silent'
+`-q'
+ Do not print messages saying which checks are being made. To
+ suppress all normal output, redirect it to `/dev/null' (any error
+ messages will still be shown).
+
+`--srcdir=DIR'
+ Look for the package's source code in directory DIR. Usually
+ `configure' can determine that directory automatically.
+
+`configure' also accepts some other, not widely useful, options. Run
+`configure --help' for more details.
+
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/Makefile.am
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/Makefile.am Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,4 @@
+ACLOCAL_AMFLAGS = -I m4
+SUBDIRS = lib lwlib lwasm
+DIST_SUBDIRS = doc lib lwlib lwasm
+EXTRA_DIST = m4/gnulib-cache.m4
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/README
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/README Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,5 @@
+This distribution constitutes the LWASM cross-assembler for the MC6809 and
+HD6309 microprocessors.
+
+All files that form a part of this distribution use the UTF8 character
+encoding method unless otherwise noted.
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/README.MAINT
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/README.MAINT Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,41 @@
+This file is intended for source package maintainers/distributors.
+
+Before a release is made, a branch for that release must be made. Within
+that branch, all files that will be distributed with the particular release
+must be generated and added to the repository on that branch. Once the
+release is deemed stable and ready for release, the release tag should
+be generated from the head of that particular branch. Thus all release
+series will have the autotool generated files in the repository as well
+as any other generated files intended to be distributed.
+
+Any branch not directly intended to be a release need not include the
+generated files.
+
+The trunk development stream must not include the autotool generated files
+as these are likely to change rapidly and it can cause a great deal of
+confusion for little gain. Also, the main trunk need not contain such
+things as generated documentation files for the same reason.
+
+By including the generated files in the release branches, it is possible
+to replicate any problems users of the package may have, including if it
+is due to problems with the autotools themselves.
+
+
+Naming of branches and tags should conform to the following guidlines.
+
+1. any branch leading to a release series must be named as the base revision
+of the series. Thus, for a 1.0 release, the branch is called 1.0 and will
+contain the results for a 1.0 release, a 1.0.1 release, and so on. If a
+sub-release will occur, say under 1.0.1, then a branch named "1.0.1" would
+be created and then releases such as 1.0.1.1 would be created. This should
+be avoided if at all possible.
+
+2. any tag for a specific release version will be named as the release. So
+for a 1.0 release, the name would be "1.0". For version 1.0.1.1, the name
+would be "1.0.1.1".
+
+3. branches not associated with a release stream - say for feature development
+or what have you should be named sensibly and should be removed when no longer
+needed. They must not appear to be version numbers.
+
+4. tags not specifying a release must not look like version numbers
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/TODO
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/autogen.sh
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/autogen.sh Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,4 @@
+#!/bin/sh
+# run this file to generate any auto-generated files
+gnulib-tool --update
+autoreconf -if
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/configure.ac
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/configure.ac Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,14 @@
+AC_INIT([LWTOOLS], [3.0-pre], [lost@l-w.ca])
+AM_INIT_AUTOMAKE([-Wall -Werror foreign])
+AC_PROG_CC
+gl_EARLY
+# for gnulib
+gl_INIT
+AC_CONFIG_HEADERS([config.h])
+AC_CONFIG_FILES([
+ Makefile
+ lib/Makefile
+ lwlib/Makefile
+ lwasm/Makefile
+])
+AC_OUTPUT
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/doc/Makefile.am
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/doc/Makefile.am Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,3 @@
+EXTRA_DIST = lwasm.txt internals.txt manual.docbook.sgml manual
+
+
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/doc/README
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/doc/README Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,13 @@
+If there are no html files in the "manual" directory and there is no
+"manual.html" file, it means that you have either checked out the source
+repository on a non-release branch or the packager messed up.
+
+In either case, if you have "docbook2html" installed, you should be able
+to build the manual with one of the following:
+
+docbook2html -o manual manual.docbook.sgml
+
+or
+
+docbook2html -u manual.docbook.sgml && mv manual.docbook.html manual/manual.html
+
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/doc/internals.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/doc/internals.txt Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,49 @@
+LWASM Internals
+===============
+
+LWASM is a table-driven assembler that notionally uses two passes. However,
+it implements its assembly in several passes as follows.
+
+Pass 1 - Preprocessing & Parsing
+--------------------------------
+
+This pass reads the source file and all included source files. It handles
+macro definition and expansion.
+
+As it reads the various lines, it also identifies any symbol associated with
+the line, the operation code, and, based on the operation code, the operand,
+if any. Upon examination of the operand, any expressions are stored in an
+internal postfix notation for later evaluation. During this pass,
+preliminary values are assigned to all symbols using the largest possible
+instruction size. A table of lines that reference every symbol is generated
+to be used in the following pass. Note that any symbols for which the value
+is known with no uncertainty factor will be generated with the smallest
+possible instruction.
+
+At this stage, simple optimizations are performed on expressions. This
+includes coalescing constants (1+2+x => 3+x). It also includes some basic
+algebra (x+x => 2*x, 2*x+4*x => 6*x, x-x => 0).
+
+Pass 2 - Optimization
+---------------------
+
+This pass sweeps the code looking for operations which could use a shorter
+instruction. If it finds one, it must then re-define all symbols defined
+subsequently and all symbols defined in terms of one of those symbols in a
+cascade. This process is repeated until no more possible reductions are
+discovered.
+
+If, in the process of implementing an instruction reduction, a phasing error
+or other conflict is encountered, the reduction is backed out and marked as
+forced.
+
+The following may be candidates for reduction, depending on assembler
+options:
+
+- extended addressing -> direct addressing (not in obj target)
+- 16 bit offset -> 8 bit offset (indirect indexed)
+- 16 bit offset -> 8 bit or 5 bit offset (direct indexed)
+- 16 bit offset -> no offset (indexed)
+- 16 bit relative -> 8 bit relative (depending on configuration)
+
+
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/doc/lwasm.txt
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/doc/lwasm.txt Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,43 @@
+LWASM 2.0
+=========
+
+LWASM is a cross-assembler for the MC6809 and HD6309 CPUs. It should
+assemble most reasonable EDTASM compatible source code. This document is not
+intended to teach assembly language for these CPUs but rather to document
+the behaviour of LWASM.
+
+
+TARGETS
+-------
+
+LWASM supports several targets for assembly. These are decb, raw, and obj.
+
+The raw target generates a raw binary output. This is useful for building
+ROMs and other items that are not intended to be loaded by any kind of
+loader. In this mode, the ORG directive is merely advisory and does not
+affect the output except for the addresses symbols are defined to have.
+
+The decb target generates output that can be loaded with the CLOADM or LOADM
+commands in Color Basic. There will be approximately one segment in the
+output file for every ORG statement after which any code is emitted. (That
+is, two ORG statements in a row will not generate two output segments.)
+This is approximately equivalent to running A/AO in EDTASM.
+
+The obj target generates output that is intended to be linked later with
+LWLINK. This target disallows the use of ORG for defining anything other
+than constants. In this target, source files consist of a number of sections
+(SECTION/ENDSECTION). Nothing outside of a section is permitted to cause any
+output at all. Use of an ORG statement within a section is an error. This
+target also permits tagging symbols for export (EXPORT) and marking a symbol
+as externally defined (IMPORT/EXTERN). The linker will resolve any external
+references at link time. Additionally, any inter-section references will be
+resolved by the linker. All code in each section is assembled with an
+implicit origin of 0. SETDP has no effect because the assembler has no idea
+what address the linker will assign to the code when it is linked. Any
+direct addressing modes will default to extended to allow for the linker to
+perform relocations. Intersegment references and external references will
+use 16 bit relative addressing but intrasegment internal references may use
+8 bit relative addressing. Forced 8 bit direct modes are probably an error
+but are permitted on the theory that the programmer might know something the
+assembler doesn't.
+
diff -r e7885b3ee266 -r eb230fa7d28e old-trunk/doc/manual.docbook.sgml
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/old-trunk/doc/manual.docbook.sgml Fri Mar 19 02:54:14 2010 +0000
@@ -0,0 +1,1985 @@
+
+
+
+LW Tool Chain
+WilliamAstle
+2009William Astle
+
+
+
+Introduction
+
+
+The LW tool chain provides utilities for building binaries for MC6809 and
+HD6309 CPUs. The tool chain includes a cross-assembler and a cross-linker
+which support several styles of output.
+
+
+
+History
+
+For a long time, I have had an interest in creating an operating system for
+the Coco3. I finally started working on that project around the beginning of
+2006. I had a number of assemblers I could choose from. Eventually, I settled
+on one and started tinkering. After a while, I realized that assembler was not
+going to be sufficient due to lack of macros and issues with forward references.
+Then I tried another which handled forward references correctly but still did
+not support macros. I looked around at other assemblers and they all lacked
+one feature or another that I really wanted for creating my operating system.
+
+
+
+The solution seemed clear at that point. I am a fair programmer so I figured
+I could write an assembler that would do everything I wanted an assembler to
+do. Thus the LWASM probject was born. After more than two years of on and off
+work, version 1.0 of LWASM was released in October of 2008.
+
+
+
+As the aforementioned operating system project progressed further, it became
+clear that while assembling the whole project through a single file was doable,
+it was not practical. When I found myself playing some fancy games with macros
+in a bid to simulate sections, I realized I needed a means of assembling
+source files separately and linking them later. This spawned a major development
+effort to add an object file support to LWASM. It also spawned the LWLINK
+project to provide a means to actually link the files.
+
+
+
+
+
+
+
+Output Formats
+
+
+The LW tool chain supports multiple output formats. Each format has its
+advantages and disadvantages. Each format is described below.
+
+
+
+Raw Binaries
+
+A raw binary is simply a string of bytes. There are no headers or other
+niceties. Both LWLINK and LWASM support generating raw binaries. ORG directives
+in the source code only serve to set the addresses that will be used for
+symbols but otherwise have no direct impact on the resulting binary.
+
+
+
+
+DECB Binaries
+
+A DECB binary is compatible with the LOADM command in Disk Extended
+Color Basic on the CoCo. They are also compatible with CLOADM from Extended
+Color Basic. These binaries include the load address of the binary as well
+as encoding an execution address. These binaries may contain multiple loadable
+sections, each of which has its own load address.
+
+
+Each binary starts with a preamble. Each preamble is five bytes long. The
+first byte is zero. The next two bytes specify the number of bytes to load
+and the last two bytes specify the address to load the bytes at. Then, a
+string of bytes follows. After this string of bytes, there may be another
+preamble or a postamble. A postamble is also five bytes in length. The first
+byte of the postamble is $FF, the next two are zero, and the last two are
+the execution address for the binary.
+
+
+
+Both LWASM and LWLINK can output this format.
+
+
+
+
+OS9 Modules
+
+
+Since version 2.5, LWASM is able to generate OS9 modules. The syntax is
+basically the same as for other assemblers. A module starts with the MOD
+directive and ends with the EMOD directive. The OS9 directive is provided
+as a shortcut for writing system calls.
+
+
+
+
+
+LWASM does NOT provide an OS9Defs file. You must provide your own. Also note
+that the common practice of using "ifp1" around the inclusion of the OS9Defs
+file is discouraged as it is pointless and can lead to unintentional
+problems and phasing errors. Because LWASM reads each file exactly once,
+there is no benefit to restricting the inclusion to the first assembly pass.
+
+
+
+
+
+It is also critical to understand that unlike many OS9 assemblers, LWASM
+does NOT maintain a separate data address counter. Thus, you must define
+all your data offsets and so on outside of the mod/emod segment. It is,
+therefore, likely that source code targeted at other assemblers will require
+edits to build correctly.
+
+
+
+
+
+LWLINK does not, yet, have the ability to create OS9 modules from object
+files.
+
+
+
+
+
+Object Files
+LWASM supports generating a proprietary object file format which is
+described in . LWLINK is then used to link these
+object files into a final binary in any of LWLINK's supported binary
+formats.
+
+Object files also support the concept of sections which are not valid
+for other output types. This allows related code from each object file
+linked to be collapsed together in the final binary.
+
+
+Object files are very flexible in that they allow references that are not
+known at assembly time to be resolved at link time. However, because the
+addresses of such references are not known at assembly time, there is no way
+for the assembler to deduce that an eight bit addressing mode is possible.
+That means the assember will default to using sixteen bit addressing
+whenever an external or cross-section reference is used.
+
+
+
+As of LWASM 2.4, it is possible to force direct page addressing for an
+external reference. Care must be taken to ensure the resulting addresses
+are really in the direct page since the linker does not know what the direct
+page is supposed to be and does not emit errors for byte overflows.
+
+
+
+It is also possible to use external references in an eight bit immediate
+mode instruction. In this case, only the low order eight bits will be used.
+Again, no byte overflows will be flagged.
+
+
+
+
+
+
+
+
+LWASM
+
+The LWTOOLS assembler is called LWASM. This chapter documents the various
+features of the assembler. It is not, however, a tutorial on 6x09 assembly
+language programming.
+
+
+
+Command Line Options
+
+The binary for LWASM is called "lwasm". Note that the binary is in lower
+case. lwasm takes the following command line arguments.
+
+
+
+
+
+
+
+
+
+This will cause the assembler to accept the additional instructions available
+on the 6309 processor. This is the default mode; this option is provided for
+completeness and to override preset command arguments.
+
+
+
+
+
+
+
+
+
+This will cause the assembler to reject instructions that are only available
+on the 6309 processor.
+
+
+
+
+
+
+
+
+
+Select the DECB output format target. Equivalent to .
+
+
+
+
+
+
+
+
+
+Select the output format. Valid values are for the
+object file target, for the DECB LOADM format,
+ for creating OS9 modules, and for
+a raw binary.
+
+
+
+
+
+
+
+
+
+Cause LWASM to generate a listing. If is specified,
+the listing will go to that file. Otherwise it will go to the standard output
+stream. By default, no listing is generated.
+
+
+
+
+
+
+
+
+Select the proprietary object file format as the output target.
+
+
+
+
+
+
+
+
+
+This option specifies the name of the output file. If not specified, the
+default is .
+
+
+
+
+
+
+
+
+
+Specify assembler pragmas. Multiple pragmas are separated by commas. The
+pragmas accepted are the same as for the PRAGMA assembler directive described
+below.
+
+
+
+
+
+
+
+
+
+Select raw binary as the output target.
+
+
+
+
+
+
+
+
+
+Present a help screen describing the command line options.
+
+
+
+
+
+
+
+
+Provide a summary of the command line options.
+
+
+
+
+
+
+
+
+
+Display the software version.
+
+
+
+
+
+
+
+
+
+Increase the debugging level. Only really useful to people hacking on the
+LWASM source code itself.
+
+
+
+
+
+
+
+
+
+Dialects
+
+LWASM supports all documented MC6809 instructions as defined by Motorola.
+It also supports all known HD6309 instructions. While there is general
+agreement on the pneumonics for most of the 6309 instructions, there is some
+variance with the block transfer instructions. TFM for all four variations
+seems to have gained the most traction and, thus, this is the form that is
+recommended for LWASM. However, it also supports COPY, COPY-, IMP, EXP,
+TFRP, TFRM, TFRS, and TFRR. It further adds COPY+ as a synomym for COPY,
+IMPLODE for IMP, and EXPAND for EXP.
+
+
+By default, LWASM accepts 6309 instructions. However, using the
+--6809 parameter, you can cause it to throw errors on
+6309 instructions instead.
+
+
+The standard addressing mode specifiers are supported. These are the
+hash sign ("#") for immediate mode, the less than sign ("<") for forced
+eight bit modes, and the greater than sign (">") for forced sixteen bit modes.
+
+
+
+Additionally, LWASM supports using the asterisk ("*") to indicate
+base page addressing. This should not be used in hand-written source code,
+however, because it is non-standard and may or may not be present in future
+versions of LWASM.
+
+
+
+
+
+Source Format
+
+
+LWASM accepts plain text files in a relatively free form. It can handle
+lines terminated with CR, LF, CRLF, or LFCR which means it should be able
+to assemble files on any platform on which it compiles.
+
+
+Each line may start with a symbol. If a symbol is present, there must not
+be any whitespace preceding it. It is legal for a line to contain nothing
+but a symbol.
+
+The op code is separated from the symbol by whitespace. If there is
+no symbol, there must be at least one white space character preceding it.
+If applicable, the operand follows separated by whitespace. Following the
+opcode and operand is an optional comment.
+
+
+A comment can also be introduced with a * or a ;. The comment character is
+optional for end of statement comments. However, if a symbol is the only
+thing present on the line other than the comment, the comment character is
+mandatory to prevent the assembler from interpreting the comment as an opcode.
+
+
+
+For compatibility with the output generated by some C preprocessors, LWASM
+will also ignore lines that begin with a #. This should not be used as a general
+comment character, however.
+
+
+
+The opcode is not treated case sensitively. Neither are register names in
+the operand fields. Symbols, however, are case sensitive.
+
+
+
+LWASM does not support line numbers in the file.
+
+
+
+
+
+Symbols
+
+
+Symbols have no length restriction. They may contain letters, numbers, dots,
+dollar signs, and underscores. They must start with a letter, dot, or
+underscore.
+
+
+
+LWASM also supports the concept of a local symbol. A local symbol is one
+which contains either a "?" or a "@", which can appear anywhere in the symbol.
+The scope of a local symbol is determined by a number of factors. First,
+each included file gets its own local symbol scope. A blank line will also
+be considered a local scope barrier. Macros each have their own local symbol
+scope as well (which has a side effect that you cannot use a local symbol
+as an argument to a macro). There are other factors as well. In general,
+a local symbol is restricted to the block of code it is defined within.
+
+
+
+By default, unless assembling to the os9 target, a "$" in the symbol will
+also make it local. This can be controlled by the "dollarlocal" and
+"nodollarlocal" pragmas. In the absence of a pragma to the contrary, For
+the os9 target, a "$" in the symbol will not make it considered local while
+for all other targets it will.
+
+
+
+
+
+Numbers and Expressions
+
+
+Numbers can be expressed in binary, octal, decimal, or hexadecimal. Binary
+numbers may be prefixed with a "%" symbol or suffixed with a "b" or "B".
+Octal numbers may be prefixed with "@" or suffixed with "Q", "q", "O", or
+"o". Hexadecimal numbers may be prefixed with "$", "0x" or "0X", or suffixed
+with "H". No prefix or suffix is required for decimal numbers but they can
+be prefixed with "&" if desired. Any constant which begins with a letter
+must be expressed with the correct prefix base identifier or be prefixed
+with a 0. Thus hexadecimal FF would have to be written either 0FFH or $FF.
+Numbers are not case sensitive.
+
+
+
+ A symbol may appear at any point where a number is acceptable. The
+special symbol "*" can be used to represent the starting address of the
+current source line within expressions.
+
+The ASCII value of a character can be included by prefixing it with a
+single quote ('). The ASCII values of two characters can be included by
+prefixing the characters with a quote (").
+
+
+
+LWASM supports the following basic binary operators: +, -, *, /, and %.
+These represent addition, subtraction, multiplication, division, and
+modulus. It also supports unary negation and unary 1's complement (- and ^
+respectively). It is also possible to use ~ for the unary 1's complement
+operator. For completeness, a unary positive (+) is supported though it is
+a no-op. LWASM also supports using |, &, and ^ for bitwise or, bitwise and,
+and bitwise exclusive or respectively.
+
+
+
+
+
+Operator precedence follows the usual rules. Multiplication, division, and
+modulus take precedence over addition and subtraction. Unary operators take
+precedence over binary operators. Bitwise operators are lower precdence
+than addition and subtraction. To force a specific order of evaluation,
+parentheses can be used in the usual manner.
+
+
+
+
+
+As of LWASM 2.5, the operators && and || are recognized for boolean and and
+boolean or respectively. They will return either 0 or 1 (false or true).
+They have the lowest precedence of all the binary operators.
+
+
+
+
+
+
+Assembler Directives
+
+Various directives can be used to control the behaviour of the
+assembler or to include non-code/data in the resulting output. Those directives
+that are not described in detail in other sections of this document are
+described below.
+
+
+
+Data Directives
+
+FCB expr[,...]
+.DB expr[,...]
+.BYTE expr[,...]
+
+Include one or more constant bytes (separated by commas) in the output.
+
+
+
+
+FDB expr[,...]
+.DW expr[,...]
+.WORD expr[,...]
+
+Include one or more words (separated by commas) in the output.
+
+
+
+
+FQB expr[,...]
+.QUAD expr[,...]
+.4BYTE expr[,...]
+
+Include one or more double words (separated by commas) in the output.
+
+
+
+
+FCC string
+.ASCII string
+.STR string
+
+
+Include a string of text in the output. The first character of the operand
+is the delimiter which must appear as the last character and cannot appear
+within the string. The string is included with no modifications>
+
+
+
+
+
+FCN string
+.ASCIZ string
+.STRZ string
+
+
+Include a NUL terminated string of text in the output. The first character of
+the operand is the delimiter which must appear as the last character and
+cannot appear within the string. A NUL byte is automatically appended to
+the string.
+
+
+
+
+
+FCS string
+.ASCIS string
+.STRS string
+
+
+Include a string of text in the output with bit 7 of the final byte set. The
+first character of the operand is the delimiter which must appear as the last
+character and cannot appear within the string.
+
+
+
+
+ZMB expr
+
+
+Include a number of NUL bytes in the output. The number must be fully resolvable
+during pass 1 of assembly so no forward or external references are permitted.
+
+
+
+
+ZMD expr
+
+
+Include a number of zero words in the output. The number must be fully
+resolvable during pass 1 of assembly so no forward or external references are
+permitted.
+
+
+
+
+ZMQ expr
+
+
+Include a number of zero double-words in the output. The number must be fully
+resolvable during pass 1 of assembly so no forward or external references are
+permitted.
+
+
+
+
+
+RMB expr
+.BLKB expr
+.DS expr
+.RS expr
+
+
+Reserve a number of bytes in the output. The number must be fully resolvable
+during pass 1 of assembly so no forward or external references are permitted.
+The value of the bytes is undefined.
+
+
+
+
+RMD expr
+
+
+Reserve a number of words in the output. The number must be fully
+resolvable during pass 1 of assembly so no forward or external references are
+permitted. The value of the words is undefined.
+
+
+
+
+RMQ expr
+
+
+Reserve a number of double-words in the output. The number must be fully
+resolvable during pass 1 of assembly so no forward or external references are
+permitted. The value of the double-words is undefined.
+
+
+
+
+
+INCLUDEBIN filename
+
+
+Treat the contents of filename as a string of bytes to
+be included literally at the current assembly point. This has the same effect
+as converting the file contents to a series of FCB statements and including
+those at the current assembly point.
+
+
+
+
+
+
+
+
+
+Address Definition
+The directives in this section all control the addresses of symbols
+or the assembly process itself.
+
+
+ORG expr
+
+Set the assembly address. The address must be fully resolvable on the
+first pass so no external or forward references are permitted. ORG is not
+permitted within sections when outputting to object files. For the DECB
+target, each ORG directive after which output is generated will cause
+a new preamble to be output. ORG is only used to determine the addresses
+of symbols when the raw target is used.
+
+
+
+
+
+sym EQU expr
+sym = expr
+
+Define the value of sym to be expr.
+
+
+
+
+sym SET expr
+
+Define the value of sym to be expr.
+Unlike EQU, SET permits symbols to be defined multiple times as long as SET
+is used for all instances. Use of the symbol before the first SET statement
+that sets its value is undefined.
+
+
+
+
+SETDP expr
+
+Inform the assembler that it can assume the DP register contains
+expr. This directive is only advice to the assembler
+to determine whether an address is in the direct page and has no effect
+on the contents of the DP register. The value must be fully resolved during
+the first assembly pass because it affects the sizes of subsequent instructions.
+
+This directive has no effect in the object file target.
+
+
+
+
+
+ALIGN expr[,value]
+
+
+Force the current assembly address to be a multiple of
+expr. If value is not
+specified, a series of NUL bytes is output to force the alignment, if
+required. Otherwise, the low order 8 bits of value
+will be used as the fill. The alignment value must be fully resolved on the
+first pass because it affects the addresses of subsquent instructions.
+However, value may include forward references; as
+long as it resolves to a constant for the second pass, the value will be
+accepted.
+
+Unless value is specified as something like $12,
+this directive is not suitable for inclusion in the middle of actual code.
+The default padding value is $00 which is intended to be used within data
+blocks.
+
+
+
+
+
+
+
+
+
+Conditional Assembly
+
+Portions of the source code can be excluded or included based on conditions
+known at assembly time. Conditionals can be nested arbitrarily deeply. The
+directives associated with conditional assembly are described in this section.
+
+All conditionals must be fully bracketed. That is, every conditional
+statement must eventually be followed by an ENDC at the same level of nesting.
+
+Conditional expressions are only evaluated on the first assembly pass.
+It is not possible to game the assembly process by having a conditional
+change its value between assembly passes. Thus there is not and never will
+be any equivalent of IFP1 or IFP2 as provided by other assemblers.
+
+
+
+IFEQ expr
+
+If expr evaluates to zero, the conditional
+will be considered true.
+
+
+
+
+
+IFNE expr
+IF expr
+
+If expr evaluates to a non-zero value, the conditional
+will be considered true.
+
+
+
+
+
+IFGT expr
+
+If expr evaluates to a value greater than zero, the conditional
+will be considered true.
+
+
+
+
+
+IFGE expr
+
+If expr evaluates to a value greater than or equal to zero, the conditional
+will be considered true.
+
+
+
+
+
+IFLT expr
+
+If expr evaluates to a value less than zero, the conditional
+will be considered true.
+
+
+
+
+
+IFLE expr
+
+If expr evaluates to a value less than or equal to zero , the conditional
+will be considered true.
+
+
+
+
+
+IFDEF sym
+
+If sym is defined at this point in the assembly
+process, the conditional
+will be considered true.
+
+
+
+
+
+IFNDEF sym
+
+If sym is not defined at this point in the assembly
+process, the conditional
+will be considered true.
+
+
+
+
+
+ELSE
+
+
+If the preceding conditional at the same level of nesting was false, the
+statements following will be assembled. If the preceding conditional at
+the same level was true, the statements following will not be assembled.
+Note that the preceding conditional might have been another ELSE statement
+although this behaviour is not guaranteed to be supported in future versions
+of LWASM.
+
+
+
+
+ENDC
+
+
+This directive marks the end of a conditional construct. Every conditional
+construct must end with an ENDC directive.
+
+
+
+
+
+
+
+
+OS9 Target Directives
+
+This section includes directives that apply solely to the OS9
+target.
+
+
+
+
+OS9 syscall
+
+
+
+This directive generates a call to the specified system call. syscall may be an arbitrary expression.
+
+
+
+
+
+
+MOD size,name,type,flags,execoff,datasize
+
+
+
+This tells LWASM that the beginning of the actual module is here. It will
+generate a module header based on the parameters specified. It will also
+begin calcuating the module CRC.
+
+
+
+
+
+The precise meaning of the various parameters is beyond the scope of this
+document since it is not a tutorial on OS9 module programming.
+
+
+
+
+
+
+
+EMOD
+
+
+
+This marks the end of a module and causes LWASM to emit the calculated CRC
+for the module.
+
+
+
+
+
+
+
+
+Miscelaneous Directives
+
+This section includes directives that do not fit into the other
+categories.
+
+
+
+
+INCLUDE filename
+USE filename
+
+ Include the contents of filename at
+this point in the assembly as though it were a part of the file currently
+being processed. Note that if whitespace appears in the name of the file,
+you must enclose filename in quotes.
+
+
+
+Note that the USE variation is provided only for compatibility with other
+assemblers. It is recommended to use the INCLUDE variation.
+
+
+
+
+
+END [expr]
+
+
+This directive causes the assembler to stop assembling immediately as though
+it ran out of input. For the DECB target only, expr
+can be used to set the execution address of the resulting binary. For all
+other targets, specifying expr will cause an error.
+
+
+
+
+
+ERROR string
+
+
+Causes a custom error message to be printed at this line. This will cause
+assembly to fail. This directive is most useful inside conditional constructs
+to cause assembly to fail if some condition that is known bad happens.
+
+
+
+
+
+.MODULE string
+
+
+This directive is ignored for most output targets. If the output target
+supports encoding a module name into it, string
+will be used as the module name.
+
+
+As of version 2.2, no supported output targets support this directive.
+
+
+
+
+
+
+
+
+
+
+Macros
+
+LWASM is a macro assembler. A macro is simply a name that stands in for a
+series of instructions. Once a macro is defined, it is used like any other
+assembler directive. Defining a macro can be considered equivalent to adding
+additional assembler directives.
+
+Macros my accept parameters. These parameters are referenced within
+a macro by the a backslash ("\") followed by a digit 1 through 9 for the first
+through ninth parameters. They may also be referenced by enclosing the
+decimal parameter number in braces ("{num}"). These parameter references
+are replaced with the verbatim text of the parameter passed to the macro. A
+reference to a non-existent parameter will be replaced by an empty string.
+Macro parameters are expanded everywhere on each source line. That means
+the parameter to a macro could be used as a symbol or it could even appear
+in a comment or could cause an entire source line to be commented out
+when the macro is expanded.
+
+
+Parameters passed to a macro are separated by commas and the parameter list
+is terminated by any whitespace. This means that neither a comma nor whitespace
+may be included in a macro parameter.
+
+
+Macro expansion is done recursively. That is, within a macro, macros are
+expanded. This can lead to infinite loops in macro expansion. If the assembler
+hangs for a long time while assembling a file that uses macros, this may be
+the reason.
+
+Each macro expansion receives its own local symbol context which is not
+inherited by any macros called by it nor is it inherited from the context
+the macro was instantiated in. That means it is possible to use local symbols
+within macros without having them collide with symbols in other macros or
+outside the macro itself. However, this also means that using a local symbol
+as a parameter to a macro, while legal, will not do what it would seem to do
+as it will result in looking up the local symbol in the macro's symbol context
+rather than the enclosing context where it came from, likely yielding either
+an undefined symbol error or bizarre assembly results.
+
+
+Note that there is no way to define a macro as local to a symbol context. All
+macros are part of the global macro namespace. However, macros have a separate
+namespace from symbols so it is possible to have a symbol with the same name
+as a macro.
+
+
+
+Macros are defined only during the first pass. Macro expansion also
+only occurs during the first pass. On the second pass, the macro
+definition is simply ignored. Macros must be defined before they are used.
+
+
+The following directives are used when defining macros.
+
+
+
+macroname MACRO
+
+This directive is used to being the definition of a macro called
+macroname. If macroname already
+exists, it is considered an error. Attempting to define a macro within a
+macro is undefined. It may work and it may not so the behaviour should not
+be relied upon.
+
+
+
+
+
+ENDM
+
+
+This directive indicates the end of the macro currently being defined. It
+causes the assembler to resume interpreting source lines as normal.
+
+
+
+
+
+
+
+Object Files and Sections
+
+The object file target is very useful for large project because it allows
+multiple files to be assembled independently and then linked into the final
+binary at a later time. It allows only the small portion of the project
+that was modified to be re-assembled rather than requiring the entire set
+of source code to be available to the assembler in a single assembly process.
+This can be particularly important if there are a large number of macros,
+symbol definitions, or other metadata that uses resources at assembly time.
+By far the largest benefit, however, is keeping the source files small enough
+for a mere mortal to find things in them.
+
+
+
+With multi-file projects, there needs to be a means of resolving references to
+symbols in other source files. These are known as external references. The
+addresses of these symbols cannot be known until the linker joins all the
+object files into a single binary. This means that the assembler must be
+able to output the object code without knowing the value of the symbol. This
+places some restrictions on the code generated by the assembler. For
+example, the assembler cannot generate direct page addressing for instructions
+that reference external symbols because the address of the symbol may not
+be in the direct page. Similarly, relative branches and PC relative addressing
+cannot be used in their eight bit forms. Everything that must be resolved
+by the linker must be assembled to use the largest address size possible to
+allow the linker to fill in the correct value at link time. Note that the
+same problem applies to absolute address references as well, even those in
+the same source file, because the address is not known until link time.
+
+
+
+It is often desired in multi-file projects to have code of various types grouped
+together in the final binary generated by the linker as well. The same applies
+to data. In order for the linker to do that, the bits that are to be grouped
+must be tagged in some manner. This is where the concept of sections comes in.
+Each chunk of code or data is part of a section in the object file. Then,
+when the linker reads all the object files, it coalesces all sections of the
+same name into a single section and then considers it as a unit.
+
+
+
+The existence of sections, however, raises a problem for symbols even
+within the same source file. Thus, the assembler must treat symbols from
+different sections within the same source file in the same manner as external
+symbols. That is, it must leave them for the linker to resolve at link time,
+with all the limitations that entails.
+
+
+
+In the object file target mode, LWASM requires all source lines that
+cause bytes to be output to be inside a section. Any directives that do
+not cause any bytes to be output can appear outside of a section. This includes
+such things as EQU or RMB. Even ORG can appear outside a section. ORG, however,
+makes no sense within a section because it is the linker that determines
+the starting address of the section's code, not the assembler.
+
+
+
+All symbols defined globally in the assembly process are local to the
+source file and cannot be exported. All symbols defined within a section are
+considered local to the source file unless otherwise explicitly exported.
+Symbols referenced from external source files must be declared external,
+either explicitly or by asking the assembler to assume that all undefined
+symbols are external.
+
+
+
+It is often handy to define a number of memory addresses that will be
+used for data at run-time but which need not be included in the binary file.
+These memory addresses are not initialized until run-time, either by the
+program itself or by the program loader, depending on the operating environment.
+Such sections are often known as BSS sections. LWASM supports generating
+sections with a BSS attribute set which causes the section definition including
+symbols exported from that section and those symbols required to resolve
+references from the local file, but with no actual code in the object file.
+It is illegal for any source lines within a BSS flagged section to cause any
+bytes to be output.
+
+
+The following directives apply to section handling.
+
+
+
+SECTION name[,flags]
+SECT name[,flags]
+.AREA name[,flags]
+
+
+Instructs the assembler that the code following this directive is to be
+considered part of the section name. A section name
+may appear multiple times in which case it is as though all the code from
+all the instances of that section appeared adjacent within the source file.
+However, flags may only be specified on the first
+instance of the section.
+
+There is a single flag supported in flags. The
+flag bss will cause the section to be treated as a BSS
+section and, thus, no code will be included in the object file nor will any
+bytes be permitted to be output.
+
+If the section name is "bss" or ".bss" in any combination of upper and
+lower case, the section is assumed to be a BSS section. In that case,
+the flag !bss can be used to override this assumption.
+
+
+If assembly is already happening within a section, the section is implicitly
+ended and the new section started. This is not considered an error although
+it is recommended that all sections be explicitly closed.
+
+
+
+
+
+ENDSECTION
+ENDSECT
+ENDS
+
+
+This directive ends the current section. This puts assembly outside of any
+sections until the next SECTION directive.
+
+
+
+
+sym EXTERN
+sym EXTERNAL
+sym IMPORT
+
+
+This directive defines sym as an external symbol.
+This directive may occur at any point in the source code. EXTERN definitions
+are resolved on the first pass so an EXTERN definition anywhere in the
+source file is valid for the entire file. The use of this directive is
+optional when the assembler is instructed to assume that all undefined
+symbols are external. In fact, in that mode, if the symbol is referenced
+before the EXTERN directive, an error will occur.
+
+
+
+
+
+sym EXPORT
+sym .GLOBL
+
+EXPORT sym
+.GLOBL sym
+
+
+
+This directive defines sym as an exported symbol.
+This directive may occur at any point in the source code, even before the
+definition of the exported symbol.
+
+
+Note that sym may appear as the operand or as the
+statement's symbol. If there is a symbol on the statement, that will
+take precedence over any operand that is present.
+
+
+
+
+
+
+
+
+
+Assembler Modes and Pragmas
+
+There are a number of options that affect the way assembly is performed.
+Some of these options can only be specified on the command line because
+they determine something absolute about the assembly process. These include
+such things as the output target. Other things may be switchable during
+the assembly process. These are known as pragmas and are, by definition,
+not portable between assemblers.
+
+
+LWASM supports a number of pragmas that affect code generation or
+otherwise affect the behaviour of the assembler. These may be specified by
+way of a command line option or by assembler directives. The directives
+are as follows.
+
+
+
+
+PRAGMA pragma[,...]
+
+
+Specifies that the assembler should bring into force all pragmas
+specified. Any unrecognized pragma will cause an assembly error. The new
+pragmas will take effect immediately. This directive should be used when
+the program will assemble incorrectly if the pragma is ignored or not supported.
+
+
+
+
+
+*PRAGMA pragma[,...]
+
+
+This is identical to the PRAGMA directive except no error will occur with
+unrecognized or unsupported pragmas. This directive, by virtue of starting
+with a comment character, will also be ignored by assemblers that do not
+support this directive. Use this variation if the pragma is not required
+for correct functioning of the code.
+
+
+
+
+
+Each pragma supported has a positive version and a negative version.
+The positive version enables the pragma while the negative version disables
+it. The negatitve version is simply the positive version with "no" prefixed
+to it. For instance, "pragma" vs. "nopragma". Only the positive version is
+listed below.
+
+Pragmas are not case sensitive.
+
+
+
+index0tonone
+
+
+When in force, this pragma enables an optimization affecting indexed addressing
+modes. When the offset expression in an indexed mode evaluates to zero but is
+not explicity written as 0, this will replace the operand with the equivalent
+no offset mode, thus creating slightly faster code. Because of the advantages
+of this optimization, it is enabled by default.
+
+
+
+
+
+cescapes
+
+
+This pragma will cause strings in the FCC, FCS, and FCN pseudo operations to
+have C-style escape sequences interpreted. The one departure from the official
+spec is that unrecognized escape sequences will return either the character
+immediately following the backslash or some undefined value. Do not rely
+on the behaviour of undefined escape sequences.
+
+
+
+
+
+importundefexport
+
+
+This pragma is only valid for targets that support external references. When
+in force, it will cause the EXPORT directive to act as IMPORT if the symbol
+to be exported is not defined. This is provided for compatibility with the
+output of gcc6809 and should not be used in hand written code. Because of
+the confusion this pragma can cause, it is disabled by default.
+
+
+
+
+
+undefextern
+
+
+This pragma is only valid for targets that support external references. When in
+force, if the assembler sees an undefined symbol on the second pass, it will
+automatically define it as an external symbol. This automatic definition will
+apply for the remainder of the assembly process, even if the pragma is
+subsequently turned off. Because this behaviour would be potentially surprising,
+this pragma defaults to off.
+
+
+The primary use for this pragma is for projects that share a large number of
+symbols between source files. In such cases, it is impractical to enumerate
+all the external references in every source file. This allows the assembler
+and linker to do the heavy lifting while not preventing a particular source
+module from defining a local symbol of the same name as an external symbol
+if it does not need the external symbol. (This pragma will not cause an
+automatic external definition if there is already a locally defined symbol.)
+
+
+This pragma will often be specified on the command line for large projects.
+However, depending on the specific dynamics of the project, it may be sufficient
+for one or two files to use this pragma internally.
+
+
+
+
+
+dollarlocal
+
+
+When set, a "$" in a symbol makes it local. When not set, "$" does not
+cause a symbol to be local. It is set by default except when using the OS9
+target.
+
+
+
+
+
+dollarnotlocal
+
+
+ This is the same as the "dollarlocal" pragma except its sense is
+reversed. That is, "dollarlocal" and "nodollarnotlocal" are equivalent and
+"nodollarlocal" and "dollarnotlocal" are equivalent.
+
+
+
+
+
+
+
+
+
+
+
+LWLINK
+
+The LWTOOLS linker is called LWLINK. This chapter documents the various features
+of the linker.
+
+
+
+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.
+
+
+
+
+
+
+
+Selects the DECB output format target. This is equivalent to
+
+
+
+
+
+
+
+
+
+This option specifies the name of the output file. If not specified, the
+default is .
+
+
+
+
+
+
+
+
+
+This option specifies the output format. Valid values are
+and
+
+
+
+
+
+
+
+
+
+This option specifies the raw output format.
+It is equivalent to .
+and
+
+
+
+
+
+
+
+
+
+This option allows specifying a linking script to override the linker's
+built in defaults.
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+This will output a description of the link result to FILE.
+
+
+
+
+
+
+
+
+
+Load a library using the library search path. LIBSPEC will have "lib" prepended
+and ".a" appended.
+
+
+
+
+
+
+
+
+
+Add DIR to the library search path.
+
+
+
+
+
+
+
+
+
+This option increases the debugging level. It is only useful for LWTOOLS
+developers.
+
+
+
+
+
+
+
+
+
+This provides a listing of command line options and a brief description
+of each.
+
+
+
+
+
+
+
+
+This will display a usage summary.
+of each.
+
+
+
+
+
+
+
+
+
+
+This will display the version of LWLINK.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+If all of the above steps are successful, the linker opens the output file
+and actually constructs the binary.
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+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.
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+This will display a list of the files contained in the archive.
+
+
+
+
+
+
+
+
+
+This option increases the debugging level. It is only useful for LWTOOLS
+developers.
+
+
+
+
+
+
+
+
+
+This provides a listing of command line options and a brief description
+of each.
+
+
+
+
+
+
+
+
+This will display a usage summary.
+of each.
+
+
+
+
+
+
+
+
+
+
+This will display the version of LWLINK.
+of each.
+
+
+
+
+
+
+
+
+
+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:
+
+
+
+section name
+flags
+list of local symbols (and addresses within the section)
+list of exported symbols (and addresses within the section)
+list of incomplete references along with the expressions to calculate them
+the actual object code (for non-BSS sections)
+
+
+
+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).
+
+
+
Object File Term Types
+
+
+
+TERMTYPE
+Meaning
+
+
+
+
+00
+end of expression
+
+
+
+01
+integer (16 bit in big endian order follows)
+
+
+02
+ external symbol reference (NUL terminated symbol name follows)
+
+
+
+03
+local symbol reference (NUL terminated symbol name follows)
+
+
+
+04
+operator (1 byte operator number)
+
+
+05
+section base address reference
+
+
+
+FF
+This 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. There is currently only one flag defined. Flag 01 indicates an 8 bit relocation.
+
+
+
+
+
+
+
+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.
+
+
+