Added lwtools so I can build lwasm for the current platform

Author: cmarrin

lwtools/00README.txt

@@ -0,0 +1,99 @@
+The official distribution point for lwtools is
+http://lwtools.projects.l-w.ca/. If you obtained this distribution from any
+other place, please visit the official site. You may have a modified or out
+of date version.
+
+This is LWTOOLS, a cross development system targetting the 6809 CPU.
+
+It consists of an assembler, lwasm, a linker, lwlink, and an archiver,
+lwar which should compile on any reasonably modern POSIX environment. If you
+have problems building, make sure you are using GNU make. Other make
+programs may work but GNU make is known to work.
+
+There is some source code support for building with Microsoft's compiler on
+Windows. However, this has been contributed by interested users and is not
+well tested. Indeed, the primary maintainer has no access to such a system.
+
+To see if a quick build will work, just type "make". If it works, you're
+ready to go ahead with "make install". This will install in /usr/local/bin.
+
+If you feel adventurous, you can also run the test suite by running "make
+test". However, be warned that it is likely not going to work unless you are
+running on a fairly standard unix system with perl in /usr/bin/perl.
+
+See docs/ for additional information.
+
+CONTRIBUTING
+============
+
+If you wish to contribute patches or code to lwtools, please keep the
+following in mind.
+
+Evangelism
+----------
+
+Any communication that includes evangelism for alternate revision control
+systems, coding styles, development methodologies, or similar will be
+deleted with all other contents ignored. So just don't do it and save
+yourself and the project maintainers time.
+
+Style
+-----
+
+The code formatting style must match the rest of the lwtools code. Code
+submitted in the "1TBS" will be rejected out of hand. Attempts to convince
+me to change my mind on this point will be routed to /dev/null at best and
+likely met with extreme rudeness.
+
+C code should be formatted as follows:
+
+* In general, match the formatting of the surrounding code, whether that
+  uses spaces or tabs. Otherwise, all indentation uses a single TAB
+  character for each step. That is a HARD tab, not a series of spaces. TABs
+  are assumed to be 4 characters though that will largely impact only lining
+  up comments and tabular code. If the actual formatting of the code is
+  critical, spaces may be used for that formatting but the actual initial
+  indentation of the lines MUST use TAB characters.
+* The opening brace for a block appears on the line below the control
+  structure that introduces it. It appears lined up with the preceding line
+  and nothing else appears on the same line.
+* Closing braces appear on a line by themselves ordinarily. The exception is
+  the "while" keyword in a "do-while" statement appears on the same line as
+  the closing brace for the block.
+* Case labels are lined up with the enclosing block (one level back from the
+  code of the block). The same guideline applies for ordinarily labels.
+* No spaces surround parentheses, brackets, or the dot operator. No space
+  precedes a comma but a space should follow it. Other operators should
+  usually be surrounded by spaces. A space should separate a keyword from
+  any surrounding except for sizeof() which should be written like a
+  function call. There is no space between a function name and the start of
+  its parameter list.
+
+In general, study the existing source formatting and copy the style. This is
+what you should do anyway and the above should not be required.
+
+For code accepted to the contrib/ hierarchy, application of the above coding
+style may be less strict.
+
+Submitting
+----------
+
+Any attempts to evangelize git or any other alternative revision control
+system will be deleted with *all* other contents ignored.
+
+When submitting code to lwtools, it should be submitted as a patch file (hg
+diff or diff -u). DO NOT submit entire source files. Remember, others may be
+working on changes, too, and your complete source files are difficult to
+merge with such situations. By submitting complete source files, you are
+making far more work for the maintainer and it is generally considered rude.
+
+Always specify what version of the source you based your patch on. If
+possible, work off the default branch in the mercurial repository. At the
+very least, make sure you are working with the most recent release.
+
+It is also worth checking with the maintainer before submitting a patch.
+There may be some reason why your pet feature is not present in the official
+release.
+
+Finally, be prepared to receive a list of deficiencies or requests for
+improvements or clarification of why or how you did something.

lwtools/COPYING

@@ -0,0 +1,3 @@
+See the file GPL3 for a copy of the GNU General Public License, version 3,
+under which the majority of this distribution is licensed. Any exceptions
+will be noted in the relevant source files.