Mercurial > hg > index.cgi
view 00README.txt @ 333:507f442dc71e
Add support for 6800 compatibility instructions.
The occasional program uses the 6800 compatibility instructions since they
are actually specified by Motorola in at least some documentation. They
advertised the 6809 as source compatible with the 6800.
This mode is not enabled by default, however. It is my belief that receiving
an error when using a non-6809 instruction is more useful since it is
unlikely that much 6800 source code is being assembled for the 6809 these
days. Nevertheless, the --6809compat option is present for just those
purposes so one does not have to resort to using macros (which would work
equally well in most cases).
author | William Astle <lost@l-w.ca> |
---|---|
date | Tue, 15 Apr 2014 10:57:34 -0600 |
parents | 69adaab94ffd |
children | 48b1cc3991d8 |
line wrap: on
line source
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. 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. 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: * 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 ---------- 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.