pax_global_header00006660000000000000000000000064134516431540014520gustar00rootroot0000000000000052 comment=985c9657bb9b550a2d9b5327f3eaf6925bbd71b6 pmars-0.9.2/000077500000000000000000000000001345164315400126525ustar00rootroot00000000000000pmars-0.9.2/AUTHORS000066400000000000000000000012171345164315400137230ustar00rootroot00000000000000Authors ------- pMARS is brought to you by: Albert Ma (ama@athena.mit.edu) Nandor Sieben (nandor.sieben@asu.edu) Stefan Strack (stst@vuse.vanderbilt.edu) Mintardjo Wangsaw (wangsawm@csos.orst.edu) Alex Macaulay (macaulay@mundil.cs.mu.oz.au) wrote the Macintosh front-end. Martin Maierhofer (m.maierhofer@ieee.org) contributed the code for the X-Windows and the linux SVGA displays. Nathan Summers (00ncsummers@bsuvc.bsu.edu) ported pMARS to VMS. Ken Espiritu provided an optimized version of sim.c which runs fast on x86 machines. Ilmari Karonen (iltzu@sci.fi) added the -P option and various improvements. pmars-0.9.2/CONTRIB000066400000000000000000000035771345164315400137110ustar00rootroot00000000000000pMARS is a team project, and we're always glad to see it ported to new machines, operating systems and graphical environments. If you want your code contributions to be incorporated into future pMARS release, please follow these simple guidelines: * before you start changing the main files, request a copy of the most recent code. pMARS is constantly changing, and we likely have "unreleased working code" that outdates the archive you downloaded from the corewar ftp site. We can merge updates to old pMARS code with our current working code, but this is error-prone. Another reason for letting us know about your changes ahead of time is that someone else may already be working on it. * don't send patches or diffs to the main files, but rather the entire file. This is related to the previous point: you are unlikely to have an up-to-date copy of the source. * new display code should go in seperate *disp.[ch] files to keep the source modular. For consistency, try to maintain the "look-and-feel" of preexisting displays and user-interfaces and use similar variable naming and formatting conventions. * use a descriptive preprocessor symbol to bracket your code additions to the main files. Try not to use a compiler-predefined symbol (__SYMBOL__), but rather come up with a name yourself and add a section to config.h that automatically #defines your symbol if a compiler-predefined symbol is defined. This makes it easier to adapt your code to a different compiler that happens not to predefine the same symbol. * in general, follow the examples of previous contributors, and if you have any questions, let us know. Contact Stefan.Strack@Vanderbilt.edu if you plan on contributing code or if you would simply like to know who is doing what. pmars-0.9.2/COPYING000066400000000000000000000431151345164315400137110ustar00rootroot00000000000000 GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) 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 this service 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 make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. 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. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute 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 and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), 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 distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the 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 a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, 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. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE 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. END OF TERMS AND CONDITIONS Appendix: 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 convey 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) 19yy 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 2 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, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111 USA Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision 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, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This 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 Library General Public License instead of this License. pmars-0.9.2/ChangeLog000066400000000000000000000013231345164315400144230ustar00rootroot000000000000002000-12-25 Ilmari Karonen - Release 0.9.2 - Added -P option to run all possible warrior placements in random order (only if compiled with -DPERMUTATE). - Added warning if arithmetic overflow occurs during evaluation. - Removed upper limit from -F option to prevent KotH abuse. - Fixed curdisp.c so that it compiles - patch by Philip Kendall. 2000-10-23 Anton Marsden - Release 0.9.1 - Fixed a bug in the multi-warrior code, which was apparently introduced in pmars-0.8.5. - Added support for a private colourmap if no colours can be allocated in X-Windows - patch by Philip Kendall. 2000-08-20 Anton Marsden - Release 0.9.0 - New GPL license pmars-0.9.2/README000066400000000000000000000201421345164315400135310ustar00rootroot00000000000000README for pMARS version 0.9.0 - portable corewar system with ICWS'94 extensions ____________________ What is Core War? Core War is a game in which two or more virus-like programs fight against each other in a simulated memory space or core. Core War programs are written in an assembly language called Redcode which is interpreted by a Core War simulator or MARS (Memory Array Redcode Simulator). The object of the game is to prevent the other program(s) from executing. For more information about Core War check out the usenet newsgroup rec.games.corewar and its FAQ list ftp://rtfm.mit.edu/pub/usenet/games/corewar-faq or go to http://www.koth.org/. ____________________ pMARS highlights * portable, run it on your Mac at home or VAX at work * free and comes with source * core displays for DOS, Mac and UNIX * implements a new redcode dialect, ICWS'94, while remaining compatible with ICWS'88 * powerful redcode extensions: multi-line EQUates, FOR/ROF text repetition * one of the fastest simulators written in a high level language * full-featured, programmable debugger * runs the automated tournament "KotH" at http://www.koth.org and http://www.ecst.csuchico.edu/~pizza/koth/ and the annual ICWS tournaments ____________________ Documentation pmars.6 is the nroff-source for UNIX man pages. You can install it in /usr/man/man6 for use with the UNIX "man" command or format it with nroff -man. pmars.doc contains man pages without control characters that have been formatted for printing. doc/primer.94 and doc/primer.cdb contain short introductions to the ICWS'94 draft and the cdb debugger respectively. redcode.ref is a quick reference to the redcode syntax supported by pMARS. CONTRIB has guidelines for porting pMARS to new platforms and contributing new display code. ____________________ Compiling the source There are a number of C preprocessor symbols that control which version of pMARS is compiled. To enable an option, include -DSYMBOLNAME in CFLAGS of the makefile or uncomment the relevant section in config.h. GRAPHX This option enables a platform-specific graphical core display. SERVER Disables the debugger for a non-interactive tournament version. The pMARS program that runs the KotH email tournaments is compiled with SERVER enabled. EXT94 Enables the experimental opcodes SEQ, SNE and NOP, as well as the A-field relative addressing modes *, {, and }. This option should usually be enabled. EXT94 also enables the P-space extensions LDP, STP and PIN. SMALLMEM makes all addresses 16-bit as opposed to the usual 32-bit wide. This limits core size to 65535, but also drastically reduces the memory footprint of the program. We found that SMALLMEM reduces the simulation speed of pMARS on most CPUs, with the exception of those with a very small primary cache. There are other compile directives described in config.h, in particular some that fine-tune the UNIX curses display. pMARS has been tested with various ANSI and non-ANSI C compilers. If you can't get it to run or you had to change the source extensively, contact the authors with a full description of the problems and diffs to the source if applicable. ____________________ Platforms UNIX A standard UNIX makefile is provided. If you specify the GRAPHX directive, a character-based display using the curses library is built. On some systems, it may be necessary to remove -ltermcap from the LIB variable in the makefile. UNIX/X11 If you specify the XWINGRAPHX directive, the X-Windows display version of pMARS is compiled. You also need to change the link library by uncommenting the "LIB = -lX11" line in makefile. X11 pMARS has a few new command line options that are described in pmars.doc. LINUX The Linux/SVGA version of pMARS has been derived from the DOS graphical version and therefore should behave very much like that one. Some notes for compiling the Linux/SVGA version: * You will need the Linux SVGA library (libvga) version 1.12 or above to compile pMARS for Linux (it may work with older libraries, but I have not had an opportunity to test it). * If you #define GRAPHX in config.h or in the makefile, the graphical version will automatically be built unless you explicitely specify CURSESGRAPHX. * You will have to link with -lvgagl -lvga. makefile already contains a sample definition of LIB with these libraries. * The code assumes that Function keys etc. map to the 'standard' escape sequences. pMARS will not recognize these keys otherwise. * You need root privileges for the SVGA library, so either run pMARS as root, or a better solution is to set the SUID bit of the executable (do the following with root privileges). # chown root pmars # chmod u+s pmars * The code assumes your mouse is available via /dev/mouse. This is usually a link to the 'real' mouse interface, e.g. on my system: # cd /dev # ls -l mouse lrwxrwxrwx 1 root root 5 Mar 2 00:22 mouse -> ttyS0 * The second digit of the the argument to -v indicates (just like in the DOS version) the graphics mode: 1 ... 640x480 with 256 colors 2 ... 800x600 with 256 colors 3 ...1024x768 with 256 colors 6 ... 320x200 with 256 colors all other digits will result in the 640x480x256 mode. Deficiencies/bugs of the Linux/SVGA version: * Currently, the following keys are recognized by pMARS: F1-F10, the cursor keys, insert, delete, home, end, page up and page down, and Alt-a to Alt-z. * The result of a fight is printed to the console after returning from the graphical display -- only the last two lines or so are not visible until you press . * Bug reports are welcome - just drop a note to m.maierhofer@ieee.org DOS You will need the free 32-bit DOS compiler DJGPP - a DOS port of gcc - and ndmake or some other make program. pMARS also compiles with the 16-bit DOS compilers of the Borland/Turbo C family, but the maximum number of warriors is limited to 8 because of memory constraints. The GRAPHX compile directive enables the combined VGA/textmode display of pmarsv.exe. You can enable the graphics and textmode displays selectively with the DOSGRXGRAPHX and DOSTXTGRAPHX directives. If you so desire, you can even link in a curses display using the PDCurses library by specifying the CURSESGRAPHX directive. MAC The Mac GUI version of pMARS, MacpMARS, will compile with Think C and MPW C, possibly others. Source code for the interface/display of MacpMARS as well as instructions on how to make the executable are in MacpMARS*s.cpt.hqx. The GUI code has not been updated for v0.7 of pMARS yet, so you need the base archive for v0.6 (pmars06s.zip). VMS pvms*s.zip contains command files to build pMARS for VMS flavors. You need DEC C; VAX C will not work. This file also contains a complete VMS help system. OTHERS pMARS should compile with Borland C++ for OS/2, although we haven't tried it. The OS/2 version currently doesn't have a core display. pMARS has also been reported to compile on Amigas. ____________________ Language support All strings are contained in the file str_eng.c for easy translation into languages other than english. If you would like to see pMARS speak your native tongue, translate the strings and send the file to us. We will then include the new str_???.c in the next release and might even release the foreign language binaries. $Id: README,v 1.1.1.1 2000/08/31 10:22:56 iltzu Exp $ pmars-0.9.2/config/000077500000000000000000000000001345164315400141175ustar00rootroot00000000000000pmars-0.9.2/config/94x.opt000066400000000000000000000003201345164315400152620ustar00rootroot00000000000000;redcode-94x ;options for KotH ;use pmars -@ 94x.opt file1 [files...] -s 55440 ;coresize -p 10000 ;max. proc. -c 500000 ;cycles -l 200 ;warrior length ;-v 13 ;coreview modepmars-0.9.2/config/icws.opt000066400000000000000000000004411345164315400156070ustar00rootroot00000000000000;redcode-icws ;ICWS Annual Tournament Hill Specs (stormking only) ;use pmars -@ icws.opt file1 [files...] -s 8192 ;coresize -p 8000 ;max. processes -c 100000 ;cycles -l 300 ;warrior length -8 ;ICWS '88 instruction set ;-v 13 ;coreview modepmars-0.9.2/config/mw.mac000066400000000000000000000012041345164315400152210ustar00rootroot00000000000000Useful macros for multiwarrior games _alive counts the number of warriors currently alive and stores the result in n. alive calls _alive and echos the result. alive=m _alive~ca n _alive=@wq c=.,w=n=0~@ca t=$+1~!!~@pq w=w+1~@ca n=n+($>=0)~!t~@pq of~@l c alt-a=m alive _tproc totals the number of processes of all warriors in n. tproc calls _tproc and echos the result. tproc=m _tproc~ca n _tproc=@wq c=.,w=n=0~@ca t=$+1~!!~@pq w=w+1~@ca n=n+($+1)*~!t~@pq of~@l c alt-b=m tproc Execute until warrior "x" is dead. until_dead=@go~@pq x~if $>=0~!~@pq off Execute until there are "x" warriors left until_left=!!~@go~m _alive~if n>x~!~@wq of pmars-0.9.2/config/pmars.mac000066400000000000000000000137111345164315400157260ustar00rootroot00000000000000version= echo $Id: pmars.mac,v 1.1.1.1 2000/08/18 14:34:50 iltzu Exp $ pmars.mac: default macro file for pmars (version 0.5+) The macros below include bindings for DOS extended keys; e.g. pressing the "F10" function key executes the "shell" command (the space before "sh" prevents it from being repeated by ). To change the key bindings, simply edit the command chain after the equal sign. Additional macros (up to 100) can be added. Recognized "hot-key" names apart from those below are "alt-a" thru "alt-z" and "ctrl-a" thru "ctrl-z". You can also invoke these macros "manually" as you would any other macro, e.g. "macro f1". This works also for non-PCs. The cdb macro language supports macro nesting, loops, conditional (if-) statements. For a complicated macro, see "check" below. key-x macros: issued from the coreviewer Displays info and continues: key-p= progress~registers~go key-l= m f5~go PC function keys f1= close~cls~help f2= write pmars.log f3= write f4= @skip 1000~m f5~! f5= switch 2~@step~cls~l pc2-6,pc2+6~switch~@step~cls~l pc1-6,pc1+6 f6= switch 1~m f7~swi~cls~echo @a~m @a_f~l-1,+1~echo @b~m @b_f~l-1,+1 f7= @s~cls~l-5,+5~ech a~m a_f~l-1,+1~ech b~m b_f~l-1,+1~@l pc f8= m f7~swi~m f7~swi f9= progress~go f10= sh The mouse click executes this macro mousel= cls~l ,+lines-4 mousem= m mousel mouser= cls~l ,+lines-4~@l -lines+4 mouse= m mousel Replacements for "step", "go", .., using the two-panel display alt-g= sw 2~@go~m d_env alt-s= sw 2~@step~m d_env alt-c= sw 2~@con~m d_env alt-t= sw 2~@thread~m d_env d_env=cls~-5,+5~echo A,B:~m a_f~.~m b_f~.~echo @A,@B:~m d_env2 d_env2= m @a_f~.~m @b_f~.~echo *A,*B:~m *a_f~.~m *b_f~.~sw 1~l pc Accessories, set the current address to A/B-pointer a_f= @l pc~@l .+a b_f= @l pc~@l .+b @a_f= m a_f~@l .+b @b_f= m b_f~@l .+b j~reset~if d<30~ca i,j%c~@ca i=i+1 -------------------------------------- pcur - count number of processes pointing to the current address pcur= m _pstep~if.==z~@ca n=n+1~m _pend These two (sub)macros are shared code: _pstep=@ca z=.,c=n=0~!!~@pq~@l c=(c+1)%($+1)~@pq off _pend=if c!=0~!~ca n~@l z -------------------------------------- pseg - calculates how many processes are operating inside segment [x,y] pseg= m _pstep~m _ptest~m _pend _ptest= if y>=x && x<=. && y>=. || y=.)~@ca n=n+1 -------------------------------------- stone-debug executes until code is executed that has been modified by the stone's MOV instruction. This may be a self-modification in which case this macro is useful for optimizing the stone's constants. stone-debug= @$~if !o~@ca o=-1~se mov.i<*t~if .==$~m _sde~mov on~@ca m=.~m _sd Message: MOV is not traced _sde= echo Trace the stone "MOV <" instruction before calling stone-debug~res Main loop: executes until the next trace. If this isn't the MOV address, we have modified ourselves. Else, if the MOV instruction points to itself, we are about to modify ourselves. Else, trace the addresses referenced by the MOV and continue. _sd=!!~@go~t o~if(n=.)!=m,x=+a~!!~u.~m _sdf~!1~m _sds~t c~@ca o=n+x~m _sdt~! Test whether MOV points to itself. Remove the d comparison if B-mode is direct _sdt= @l n~if A==0||B==0||c==n||d==n~m _sdf Save indirect A and B address in c and d. Change: A-mode B-mode < @a_f >$ @b_f _sds= m $*.man .man.doc: @echo Building $*.doc - printable manual @cp $*.man $*.doc @ex $*.doc < makedoc.ex > /dev/null pmars-0.9.2/doc/corewar-faq.html000066400000000000000000001741171345164315400165270ustar00rootroot00000000000000 Core War Frequently Asked Questions (rec.games.corewar FAQ)

Core War Frequently Asked Questions (rec.games.corewar FAQ)

These are the Frequently Asked Questions (and answers) from the Usenet newsgroup rec.games.corewar. A plain text version of this document is posted every two weeks. The latest hypertext version is available at http://homepages.paradise.net.nz/~anton/cw/corewar-faq.html and the latest plain text version is available at http://homepages.paradise.net.nz/~anton/cw/corewar-faq.txt.

This document is currently being maintained by Anton Marsden (anton@paradise.net.nz).

Last modified: Mon Aug 21 22:22:27 NZST 2000

To Do

  • Change "silk" definition - it is possible to write a silk in ICWS '88. Get some example code
  • Make question 17 easier to understand. Add a state diagram?
  • Add info about infinite hills, related games (C-Robots, Tierra?, ...)
  • New question: How do I know if my warrior is any good? Refer to beginners' benchmarks, etc.
  • Would very much like someone to compile a collection of the "revolutionary" warriors so that beginners can see how the game has developed over the years. Mail me if interested.

What's New

  • Updated silk definition.
  • Minor URL changes.
  • Added the online location of Dewdney's articles
  • Changed ftp://www.koth.org/corewar/ to ftp://www.koth.org/pub/corewar/
  • Changed primary location of FAQ (again!)
  • Changed Philip Kendall's home page address.
  • Updated list server information

Table of Contents

  1. What is Core War
  2. Is it "Core War" or "Core Wars"?
  3. Where can I find more information about Core War?
  4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set?
  5. What is ICWS'94? Which simulators support ICWS'94?
  6. What is the ICWS?
  7. What is Core Warrior?
  8. Where are the Core War archives?
  9. Where can I find a Core War system for ...?
  10. Where can I find warrior code?
  11. I do not have FTP. How do I get all this great stuff?
  12. I do not have access to Usenet. How do I post and receive news?
  13. Are there any Core War related WWW sites?
  14. What is KotH? How do I enter?
  15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core?
  16. How does SLT (Skip if Less Than) work?
  17. What is the difference between in-register and in-memory evaluation?
  18. What is P-space?
  19. What does "Missing ;assert .." in my message from KotH mean?
  20. How should I format my code?
  21. Are there any other Core War related resources I should know about?
  22. What does (expression or term of your choice) mean?
  23. Other questions?

1. What is Core War?

Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all processes of the opposing program to terminate, leaving your program in sole posession of the machine.

There are Core War systems available for most computer platforms. Redcode has been standardised by the ICWS, and is therefore transportable between all standard Core War systems.

The system in which the programs run is quite simple. The core (the memory of the simulated computer) is a continuous array of instructions, empty except for the competing programs. The core wraps around, so that after the last instruction comes the first one again.

There are no absolute addresses in Core War. That is, the address 0 doesn't mean the first instruction in the memory, but the instruction that contains the address 0. The next instruction is 1, and the previous one obviously -1. However, all numbers are treated as positive, and are in the range 0 to CORESIZE-1 where CORESIZE is the amount of memory locations in the core - this means that -1 would be treated as CORESIZE-1 in any arithmetic operations, eg. 3218 + 7856 = (3218 + 7856) mod CORESIZE. Many people get confused by this, and it is particularly important when using the SLT instruction. Note that the source code of a program can still contain negative numbers, but if you start using instructions like DIV #-2, #5 it is important to know what effect they will have when executed.

The basic unit of memory in Core War is one instruction. Each Redcode instruction contains three parts:

  • the opcode
  • the source address (a.k.a. the A-field)
  • the destination address (a.k.a. the B-field)

The execution of the programs is equally simple. The MARS executes one instruction at a time, and then proceeds to the next one in the memory, unless the instruction explicitly tells it to jump to another address. If there is more than one program running, (as is usual) the programs execute alternately, one instruction at a time. The execution of each instruction takes the same time, one cycle, whether it is MOV, DIV or even DAT (which kills the process).

Each program may have several processes running. These processes are stored in a task queue. When it is the program's turn to execute an instruction it dequeues a process and executes the corresponding instruction. Processes that are not killed during the execution of the instruction are put back into the task queue. Processes created by a SPL instruction are added to the task queue after the creating process is put back into the task queue.

[ToC]

2. Is it "Core War" or "Core Wars"?

Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle.

[ToC]

3. Where can I find more information about Core War?

Core War was first described in the Core War Guidelines of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in Scientific American which discussed Core War, starting with the May 1984 article. Those articles are contained in two anthologies:

Author Title Published ISBN Library of Congress Call Number
Dewdney, A. K. The Armchair Universe: An Exploration of Computer Worlds New York: W. H. Freeman © 1988 0-7167-1939-8 QA76.6 .D517 1988
Dewdney, A. K. The Magic Machine: A Handbook of Computer Sorcery New York: W. H. Freeman © 1990 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback) QA76.6 .D5173 1990

A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current. You can view a scanned version of the articles at http://www.koth.org/info/sciam/. For those who are interested, Dewdney has a home page at http://www.csd.uwo.ca/faculty/akd/.

[ToC]

4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set?

A draft of the official standard (ICWS'88) is available as ftp://www.koth.org/pub/corewar/documents/standards/redcode-icws-88.Z. This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at Mark Durham's tutorials, ftp://www.koth.org/pub/corewar/documents/tutorial.1.Z and ftp://www.koth.org/pub/corewar/documents/tutorial.2.Z.

Steven Morrell has prepared a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. This and various other tutorials can be found at http://www.koth.org/info.html.

Even though ICWS'88 is still the "official" standard, you will find that most people are playing by ICWS'94 draft rules and extensions.

[ToC]

5. What is ICWS'94? Which simulators support ICWS'94?

There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a new addressing modes and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft at ftp://www.koth.org/pub/corewar/documents/icws94.0202.Z for more information. There is a HTML version of this document available at http://www.koth.org/info/icws94.html. You can try out the new standard by submitting warriors to the '94 hills of the KotH servers. Two corewar systems currently support ICWS'94, pMARS (many platforms) and Redcoder (Mac), both available at ftp://www.koth.org/pub/corewar. Note that Redcoder only supports a subset of ICWS'94.

[ToC]

6. What is the ICWS?

About one year after Core War first appeared in Scientific American, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). The ICWS is no longer active.

[ToC]

7. What is Core Warrior?

Following in the tradition of the Core War News Letter, Push Off, and The 94 Warrior, Core Warrior is a newsletter about strategies and current standings in Core War. Started in October 1995, back issues of Core Warrior (and the other newsletters) are available at http://para.inria.fr/~doligez/corewar/. There is also a Core Warrior index page at http://www.kendalls.demon.co.uk/pak21/corewar/warrior.html which has a summary of the contents of each issue of Core Warrior. Many of the earlier issues contain useful information for beginners.

[ToC]

8. Where are the Core War archives?

Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from ftp://ftp.csua.berkeley.edu/pub/corewar. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@csua.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net.

This site is mirrored at:

The plain text version of this FAQ is automatically archived by news.answers (but this version is probably out-of-date).

[ToC]

9. Where can I find a Core War system for . . . ?

Core War systems are available via anonymous FTP from www.koth.org in the corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. It is a good idea to check ftp://www.koth.org/pub/corewar/incoming for program updates first.

CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than www.koth.org. Generally, the older the program - the less likely it will be ICWS compatible.

If you are looking for an ICWS'94 simulator, get pMARS, which is available for many platforms and can be downloaded from:

Notes:

Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter.

Below is a not necessarily complete or up-to-date list of what's available at www.koth.org:

MADgic41.lzh corewar for the Amiga, v4.1
MAD4041.lzh older version?
MAD50B.lha corewar for the Amiga, beta version 5.0
Redcoder-21.hqx corewar for the Mac, supports ICWS'88 and '94 (without extensions)
core-11.hqx corewar for the Mac
core-wars-simulator.hqx same as core-11.hqx?
corewar_unix_x11.tar.Z corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible
koth31.tar.Z corewar for UNIX/X-windows. This program ran the former KotH server at intel.com
koth.shar.Z older version
kothpc.zip port of older version of KotH to the PC
deluxe20c.tar.Z corewar for UNIX (broken X-windows or curses) and PC
mars.tar.Z corewar for UNIX, likely not ICWS'88 compatible
icons.zip corewar icons for MS-Windows
macrored.zip a redcode macro-preprocessor (PC)
c88v49.zip PC corewar, textmode display
mars88.zip PC corewar, graphics mode display
corwp302.zip PC corewar, textmode display, slowish
mercury2.zip PC corewar written in assembly, fast!
mtourn11.zip tournament scheduler for mercury (req. 4DOS)
pmars08s.zip portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive
pmars08s.tar.Z same as above
pmars08.zip PC executables with graphics display, req 386+
macpmars02.sit.hqx pMARS executable for Mac (port of version 0.2) buggy, no display
MacpMARS1.99a.cpt.hqx port of v0.8 for the Mac, with display and debugger
MacpMARS1.0s.cpt.hqx C source (MPW, ThinkC) for Mac frontend
pvms08.zip pMARS v0.8 for VMS build files/help (req. pmars08s.zip)
ApMARS03.lha pMARS executable for Amiga (port of version 0.3.1)
wincor11.zip MS-Windows system, shareware ($15)

[ToC]

10. Where can I find warrior code?

To learn the game, it is a good idea to study previously posted warrior code. The FTP archives have code in the ftp://www.koth.org/pub/corewar/redcode directory. A clearly organized on-line warrior collection is available at the Core War web sites (see below).

[ToC]

11. I do not have FTP. How do I get all this great stuff?

There is an FTP email server at bitftp@pucc.princeton.edu. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. Note that many FTP email gateways are shutting down due to abuse. To get a current list of FTP email servers, look at the Accessing the Internet by E-mail FAQ posted to news.answers. If you don't have access to Usenet, you can retrieve this FAQ one of the following ways:

[ToC]

12. I do not have access to Usenet. How do I post and receive news?

To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Koth.Org list processor. To join, send the message

SUB COREWAR-L FirstName LastName

to listproc@koth.org. You can send mail to corewar-l@koth.org to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (ttsg@ttsg.com).

Servers that allow you to post (but not receive) articles are available. Refer to the Accessing the Internet by E-Mail FAQ for more information.

[ToC]

13. Are there any Core War related WWW sites?

You bet. Each of the two KotH sites sport a world-wide web server. Stormking's Core War page is http://www.koth.org; pizza's is http://www.ecst.csuchico.edu/~pizza/koth . Damien Doligez (a.k.a. Planar) has a web page that features convenient access to regular newsletters (Push Off, The '94 Warrior, Core Warrior) and a well organized library of warriors: http://para.inria.fr/~doligez/corewar/. Convenient for U.S. users, this site is also mirrored at koth.org.

[ToC]

14. What is KotH? How do I enter?

King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program (warrior) with special comment lines. You will receive a reply indicating how well your program did against the current top programs "on the hill".

There are two styles of KotH tournaments, "classical" and "multi-warrior". The "classical" KotH is a one-on-one tournament, that is your warrior will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off.

In "multi-warrior" KotH, all warriors on the hill fight each other at the same time. Score calculation is a bit more complex than for the one-on-one tournament. Briefly, points are awarded based on how many warriors survive until the end of a round. A warrior that survives by itself gets more points than a warrior that survives together with other warriors. Points are calculated from the formula (W*W-1)/S, where W is the total number of warriors and S the number of surviving warriors. The pMARS documentation has more information on multi-warrior scoring.

The idea for an email-based Core War server came from David Lee. The original KotH was developed and run by William Shubert at Intel starting in 1991, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: koth@koth.org is maintained by Scott J. Ellentuch (tuc@ttsg.com) and pizza@ecst.csuchico.edu by Thomas H. Davies (sd@ecst.csuchico.edu). Up until May '95, the two sites provided overlapping services, i.e. the some of the hill types were offered by both "pizza" and "stormking". To conserve resources, the different hill types are now divided up among the sites. The way you submit warriors to both KotHs is pretty much the same. Therefore, the entry rules described below apply to both "pizza" and "stormking" unless otherwise noted.

Entry Rules for King of the Hill Corewar

  • Write a corewar program. KotH is fully ICWS '94 compatible, EXCEPT that a comma (",") is required between two arguments.
  • Put a line starting with ";redcode" (or ";redcode-94", etc., see below) at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill.

    Additionally, adding ";name <program name>" and ";author <your name>" will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. Using ";name" is mandatory on the Pizza hills.

    In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use.

    There are currently seven separate hills you can select by starting your program with ;redcode-94, ;redcode-b, ;redcode-lp, ;redcode-x, ;redcode, ;redcode-94x or ;redcode-94m. The former four run at "pizza", the latter three at "stormking". More information on these hills is listed below.
  • Mail this file to koth@koth.org or pizza@ecst.csuchico.edu. "Pizza" requires a subject of "koth" (use the -s flag on most mailers).
  • Within a few minutes you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit.
  • In an hour or so you should get more mail telling you how your program performed against the current top 20 (or 10) programs. If no news arrives during that time, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient.

If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode[-??] quiet" when you first mail in your program; then you will only get mail when you make it on the top 25 list or when you are knocked off. Using ";redcode[-??] verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 25 list.

Often programmers want to try out slight variations in their programs. If you already have a program named "foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill.

Sample Entry

;redcode
;name Dwarf
;author A. K. Dewdney
;strategy Throw DAT bombs around memory, hitting every 4th memory cell.
;strategy This program was presented in the first Corewar article.
bomb  DAT   #0
dwarf ADD   #4,    bomb
      MOV   bomb, @bomb
      JMP   dwarf
      END   dwarf          ; Programs start at the first line unless
                           ; an "END start" pseudo-op appears to indicate
                           ; the first logical instruction.  Also, nothing
                           ; after the END instruction will be assembled.

Hill Name Hill Size Core Size Max. Processes Duration Before Tie Max. Entry Length Min. Distance Rounds Fought Instr. Set
Pizza's ICWS '94 Draft Hill (Accessed with ";redcode-94") 25 8000 8000 80000 100 100 200 Extended ICWS '94 Draft
Pizza's Beginner's Hill (Accessed with ";redcode-b") 25 8000 8000 80000 100 100 200 Extended ICWS '94 Draft
Pizza's Experimental (Small) Hill (Accessed with ";redcode-x") 25 800 800 8000 20 20 200 Extended ICWS '94 Draft
Pizza's Limited Process (LP) Hill (Accessed with ";redcode-lp") 25 8000 8 80000 200 200 200 Extended ICWS '94 Draft
Stormking's ICWS '88 Standard Hill (Accessed with ";redcode") 20 8000 8000 80000 100 100 250 ICWS '88
Stormking's ICWS '94 No Pspace Hill (Accessed with ";redcode-94nop") 20 8000 8000 80000 100 100 250 ICWS '94
Stormking's ICWS '94 Experimental (Big) Hill (Accessed with ";redcode-94x") 20 55440 55440 500000 200 200 250 Extended ICWS '94 Draft
Stormking's ICWS '94 Multi-Warrior Hill (Accessed with ";redcode-94m") 10 8000 8000 80000 100 100 200 Extended ICWS '94 Draft

Note: Warriors on the beginner's hill are retired at age 100.

If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document.

At "stormking", a message body with ";help" will return brief instructions. If you submit code containing a ";test" line, your warrior will be assembled but not actually pitted against the warriors on the hill.

At "pizza", you can use ";redcode[-??] test" to do a test challenge of the Hill without affecting the status of the Hill. These challenges can be used to see how well your warrior does against the current Hill warriors.

All hills run portable MARS (pMARS) version 0.8, a platform-independent Core War system available at www.koth.org.

The '94 and '94x hills allow five experimental opcodes and three experimental addressing modes currently not covered in the ICWS'94 draft document:

  • LDP - Load P-Space
  • STP - Store P-Space
  • SEQ - Skip if EQual (synonym for CMP)
  • SNE - Skip if Not Equal
  • NOP - (No OPeration)
  • * - indirect using A-field as pointer
  • { - predecrement indirect using A-field
  • } - postincrement indirect using A-field

[ToC]

15. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core?

Core is initialized to DAT 0, 0. This is an illegal instruction (in source code) under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you have a DAT 0, 0 instruction in your source code - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction.

[ToC]

16. How does SLT (Skip if Less Than) work?

SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: -1 becomes M-1 where M is the memory size (core size).

Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero.

[ToC]

17. What is the difference between in-register and in-memory evaluation?

These terms refer to the way instruction operands are evaluated. The '88 Redcode standard ICWS'88 is unclear about whether a simulator should "buffer" the result of A-operand evaluation before the B-operand is evaluated. Simulators that do buffer are said to use in-register evaluation, those that don't, in-memory evaluation. ICWS'94 clears this confusion by mandating in-register evaluation. Instructions that execute differently under these two forms of evaluation are MOV, ADD, SUB, MUL, DIV and MOD where the effective address of the A-operand is modified by evaluation of the B-operand. This is best illustrated by an example:

   L1  mov L2, <L2
   L2  dat #0, #1

Under in-register evaluation, the L2 instruction is saved in a buffer before the L2 memory location is decremented by evaluation of the B-operand of L1. The saved DAT #0,#1 instruction is then written to L2, leaving it unchanged.

Under in-memory evaluation, the L2 instruction is not buffered and thus decremented by evaluation of the B-operand. After execution of L1, L2 changes to DAT #0,#0.

[ToC]

18. What is P-space?

P-space is an area of memory which only your program's processes can access. The contents of each memory location are preserved between rounds in a multi-round match.

P-space is in many ways different from the core. First of all, each P-space location can only store one number, not a whole instruction. Also, the addressing in P-space is absolute, ie. the P-space address 1 is always 1 regardless of where in the core the instruction containing it is. And last but not least, P-space can only be accessed by two special instructions, LDP and STP.

The syntax of these two instructions is a bit unusual. STP, for example, has an ordinary value in the core as its source, which is put into the P-space field pointed to by the destination. So the P-space location isn't determined by the destination address, but by its value, ie. the value that would be overwritten if this were a MOV. So STP.AB #Q, #R would put the value Q into the P-space field R mod PSPACESIZE. Similarly,

        stp.b  2, 3
        dat    0, 0
        dat    0, 9
        dat    0, 7

would put the value 9 into the P-space field 7. LDP works the same way, except that now the source is a P-space field and the destination a core instruction. The P-space location 0 is a special location. It is initialised to a special value before each round. This value is:

  • -1 (or CORESIZE-1) at the beginning of the first round
  • 0 if the program died in the previous round
  • The number of surviving programs if the program did not die in the previous round

This means that for one-on-one matches, loss=0, win=1 and tie=2.

The default size of P-space is 1/16 of the core size. This size is the value of the predefined variable PSPACESIZE. The addresses in the P-space wrap around just like in the core, ie. you can store a value from 0 to CORESIZE-1 in each P-space location. All P-space values (except for location 0) are 0 initially.

[ToC]

19. What does "Missing ;assert .." in my message from KotH mean?

This means you have omitted an ";assert" line in your submission. ";assert" is used to specify which environments your code will work under or was designed for. For example, if your warrior was written for the '94 draft hill then you can put:

;assert CORESIZE==8000
in your code, meaning that an error will occur if you attempt you compile the code for a different core size. If you don't want to use the features of ";assert" and you want to get rid of the annoying warning just put: 
;assert 1

in your code, which means it will compile unconditionally.

[ToC]

20. How should I format my code?

The way you format your code is really your own choice in the end. If you are new to the game then use the style you feel most comfortable with. However, using a common format helps others to understand your code quicker. Most players tend to use the following conventions when writing code:

  • use lower case for location names and opcode names
  • don't add opcode modifiers if you don't need to, eg. add.ab #1, #2 is the same as add #1, #2
  • use whitespace after every comma
  • use tabs to align the opcodes, the instruction field(s) and any comments
  • do not use $ (direct addressing mode) or : (suffix of some labels)

[ToC]

21. Are there any other Core War related resources I should know about?

Using genetic algorithms to generate warriors has been attempted by a number of people. There are a number of resources available for people who are interested in doing some experimentation:

[ToC]

22. What does (expression or term of your choice) mean?

Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me.

(References to an X-like program mean that the term X is derived from the specific program X and has become a generic term).

Binary launch
One of several means to start an imp-spiral running. The fastest launch technique, but requires the most code. See also JMP/ADD Launch and Vector Launch. 
    impsize   equ 2667
    example   spl 4               ; extend by adding spl 8, spl 16, etc.
              spl 2
              jmp imp+(0*impsize) ; jmp's execute in order
              jmp imp+(1*impsize)
              spl 2
              jmp imp+(2*impsize)
              jmp imp+(3*impsize)
    imp       mov 0, impsize      ; in '94 use -> mov.i #0, impsize
Bootstrapping
Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible.
B-Scanners
Scanners which only recognize non-zero B-fields. 
    example   add #10, scan
    scan      jmz example, 10
c
Measure of speed, equal to one location per cycle. Speed of light.
CMP-Scanner
A Scanner which uses a CMP instruction to look for opponents. 
    example   add step, scan
    scan      cmp 10, 30
              jmp attack
              jmp example
    step      dat #20, #20
Colour
Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. 
    example   dat #100
Core-Clear
Code that sequentially overwrites core with DAT instructions; usually the last part of a program.
Decoys
Bogus or unused instructions meant to slow down scanners. Typically, DATs with non-zero B-fields.
Decrement Resistant
Property of warriors making them functional (or at least partially functional) when overrun by a DJN-stream.
DJN-Stream (also DJN-Train)
Using a DJN command to rapidly decrement core locations. 
    example   ...
              ...
              djn example, <4000
Dwarf
The prototypical small bomber.
Gate-busting (also gate-crashing)
technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates.
Hybrids
warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone).
Imp
Program which only uses the MOV instruction. 
    example   mov 0, 1
or 
    example   mov 0, 2
              mov 0, 2
Imp-Gate
A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. 
    example   ...
              ...
              spl 0, <example
              dat <example, #0
Imp-Ring
A minimal Imp-Spiral. 
    D         EQU (CORESIZE+1)/3
    a         mov 0, D   ; copy self to b
    b         mov 0, D   ; copy self to c
    c         mov 0, D   ; copy self to a+1
Imp-Spiral
An Imp-like program with two or more processes supporting each other. A three-point spiral, with six processes running in this sequence: 
    D         EQU (CORESIZE+1)/3
    a         mov 0, D   ; copy self to b
    b         mov 0, D   ; copy self to c
    c         mov 0, D   ; copy self to a+1
    a+1       mov 0, D   ; copy self to b+1
    b+1       mov 0, D   ; copy self to c+1
    c+1       mov 0, D   ; copy self to a+2
Incendiary Bomb
A type of Stun bomb which creates a SPL 0 carpet. 
    example   spl 0, 8
              mov -1, <-1
JMP/ADD Launch
one of several means to start an imp-spiral running. The slowest launch technique, but requires the least code. See also Binary Launch and Vector Launch. 
    IMPSIZE   EQU 2667
    example   spl 1               ; extend by adding more spl 1's
              spl 1
              spl 2
              jmp @0, imp
              add #IMPSIZE, -1    ; bump address by impsize after each jmp
              dat #0, #0          ; excess processes must die!
    imp       mov 0, IMPSIZE      ; in '94 use -> mov.i #0,IMPSIZE
Mirror
see reflection.
On-axis/off-axis
On-axis scanners compare two locations M/2 apart, where M is the memory size. Off-axis scanners use some other separation.
Optimal Constants
(also optima-type constants) Bomb or scan increments chosen to cover core most effectively, i.e. leaving gaps of uniform size. Programs to calculate optimal constants and lists of optimal numbers are available at www.koth.org.
Paper
A Paper-like program is one which replicates itself many times. Part of the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy.
P-Warrior
A warrior which uses the results of previous round(s) in order to determine which strategy it will use.
Pit-Trapper
(also Slaver, Vampire). A program which enslaves another. Usually accomplished by bombing with JMPs to a SPL 0 pit with an optional core-clear routine.
Q^2 Scan
A modern version of the Quick Scan where anything found is attacked almost immediately.
Quick Scan
2c scan of a set group of core locations with bombing if anything is found. Both of the following codes snips scan 16 locations and check for a find. If anything is found, it is attacked, otherwise 16 more locations are scanned.

Example:

     start
     s1 for 8    ;'88 scan
            cmp  start+100*s1, start+100*s1+4000 ;check two locations
            mov  #start+100*s1-found, found      ;they differ so set pointer
     rof
            jmn  attack,   found    ;if we have something, get it
     s2 for 8
            cmp  start+100*(s2+6), start+100*(s2+6)+4000
            mov  #start+100*(s2+6)-found, found
     rof
     found  jmz  moveme,  #0        ;skip attack if qscan found nothing
     attack cmp  @found,  start-1   ;does found points to empty space?
            add  #4000,   found     ;no, so point to correct location
            mov  start-1, @found    ;move a bomb
     moveme jmp  0,       0
In ICWS'94, the quick scan code is more compact because of the SNE opcode: 
     start       ;'94 scan
     s1 for 4
            sne  start+400*s1, start+400*s1+100     ;check two locations
            seq  start+400*s1+200, start+400*s1+300 ;check two locations
            mov  #start+400*s1-found, found       ;they differ so set pointer
     rof
            jmn  which,   found     ;if we have something, get it
     s2 for 4
            sne  start+400*(s2+4), start+400*(s2+4)+100
            seq  start+400*(s2+4)+200, start+400*(s2+4)+300
            mov  #start+400*(s2+4)-found-100, found
     rof
     found  jmz  moveme,  #0        ;skip attack if qscan found nothing
            add  #100,    -1        ;increment pointer till we get the
     which  jmn  -1,      @found    ;right place
            mov  start-1, @found    ;move a bomb
     moveme jmp  0,       0
Reflection
Copy of a program or program part, positioned to make the active program invisible to a CMP-scanner.
Replicator
Generic for Paper. A program which makes many copies of itself, each copy also making copies.
Self-Splitting
Strategy of amplifying the number of processes executing a piece of code. 
    example    spl 0
    loop       add #10, example
               mov example, @example
               jmp loop
Scanner
A program which searches through core for an opponent rather than bombing blindly.
Scissors
A program designed to beat replicators, usually a (B-field scanning) vampire. Part of the Paper-Scissors-Stone analogy.
Self-Repair
Ability of a program to fix it's own code after attack.
Silk
A replicator which splits off a process to each new copy before actually copying the code. This allows it to replicate extremely quickly. Example: 
            spl   1
            mov   -1, 0
            spl   1                ;generate 6 consecutive processes
    silk    spl   3620,   #0       ;split to new copy
            mov   >-1, }-1      ;copy self to new location
            mov   bomb,   >2000 ;linear bombing
            mov   bomb,   }2042    ;A-indirect bombing for anti-vamp
            jmp   silk,   {silk    ;reset source pointer, make new copy
    bomb    dat   >2667,  >5334  ;anti-imp bomb
Slaver
see Pit-Trapper.
Stealth
Property of programs, or program parts, which are invisible to scanners, accomplished by using zero B-fields and reflections.
Stone
A Stone-like program designed to be a small bomber. Part of the Paper-Scissors-Stone analogy.
Stun
A type of bomb which makes the opponent multiply useless processes, thus slowing it down. Example is referred to as a SPL-JMP bomb. 
    example    spl   0
               jmp   -1
Two-Pass Core-Clear (also SPL/DAT Core-Clear)
core clear that fills core first with SPL instructions, then with DATs. This is very effective in killing paper and certain imp-spiral variations.
Vampire
see Pit-Trapper.
Vector Launch
one of several means to start an imp-spiral running. As fast as Binary Launch, but requiring much less code. See also JMP/ADD Launch and Binary Launch. This example is one form of a Vector Launch: 
    sz      EQU   2667

            spl   1
            spl   1
            jmp   @vt, }0
    vt      dat   #0, imp+0*sz ; start of vector table
            dat   #0, imp+1*sz
            dat   #0, imp+2*sz
            dat   #0, imp+3*sz ; end of vector table
    imp     mov.i #0, sz

[ToC]

23. Other questions?

Just ask in the rec.games.corewar newsgroup or contact me. If you are shy, check out the Core War archives first to see if your question has been answered before.

[ToC]

Credits

Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document:
  • Mark Durham (wrote the original version of the FAQ)
  • Paul Kline
  • Randy Graham
  • Stefan Strack (maintained a recent version of the FAQ)

Copyright © 2000 Anton Marsden.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Valid HTML 4.0! Valid CSS! pmars-0.9.2/doc/makedoc.ex000066400000000000000000000001651345164315400153620ustar00rootroot000000000000001,$s/_//g g/GAMES AND DEMOS/-2,-1d g/GAMES AND DEMOS/+1d g/Last change:/-1d g/Last change:/+1,+2d 1,$s/^/ / wq pmars-0.9.2/doc/pmars.6000066400000000000000000001357021345164315400146400ustar00rootroot00000000000000.\" portable MARS is .\" Copyright (c) by Albert Ma, Na'ndor Sieben, Stefan Strack, Mintardjo Wangsaw and Ilmari Karonen .\" .\" pmars.6 by Stefan Strack .\" $Id: pmars.6,v 1.4 2000/12/25 00:49:07 iltzu Exp $ .\" .\" to create a printable manual with proper pagination do .\" nroff -man -e pmars.6 > pmars.doc .\" ex pmars.doc .\" :%s/_\^H//g .\" :g/PMARS(6)/-2,-1d .\" :g/PMARS(6)/+1d .\" :g/Last change:/-1d .\" :g/Last change:/+1,+2d .\" :wq .de EX \"Begin example .ne 5 .if n .sp 1 .if t .sp .5 .nf .in +5n .. .de EE \"End example .fi .in -5n .if n .sp 1 .if t .sp .5 .. .TH PMARS 6 "December 25, 2000" "PMARS v0.9.2" .ad b .SH NAME pmars \- portable corewar system with ICWS'94 extensions .SH SYNOPSIS .I pmars [ .I option \fP...\fI ] file1 [ .I file(s) ] .SH DESCRIPTION .I pMARS (portable Memory Array Redcode Simulator) is a corewar interpreter with multi-platform support. .I pMARS currently runs on UNIX systems, PC/DOS, VMS, Amiga (AmigaDOS command line), and the Mac. .I pMARS implements the ICWS'94 draft standard, but can also be used in ICWS'88 mode. The base system includes a graphical core display for UNIX (curses, X-windows), PC/linux (svgalib), PC/DOS and the Mac (see APPENDIX). A line-oriented debugger is included to help in writing warriors for the ICWS'94 draft standard. .PP .I pMARS runs one or more warriors written in .I Redcode that are provided as .I file(s) on the command line. Running a single warrior is supported for debugging. Two warriors are pitted against each other for standard play, but up to 36 warriors can be named for "multi-warrior" core war. If the warrior(s) assemble without error they are loaded into the core array and executed in round-robin mode starting with the first warrior. Warrior 1 is loaded starting at core position 0, warrior 2, 3, etc., at either a random or fixed position. For fairness the starting order is rotated after each round. .SH SCORE The score is reported after all rounds have been played. A round ends when either a single surviving warrior remains or when a maximum number of cycles has elapsed. For each round, every surviving warrior is awarded points calculated from a score formula (F). By default, this is (W*W-1)/S, where W is the total number of warriors participating, S is the number of of survivors, and "/" is integer division. Alternative score formulas can be specified with the .I = option (see below). .PP When two warriors battle, the results are reported as wins1, wins2, and ties, where wins1 and wins2 are the numbers of rounds that each warrior won, and ties are the number of rounds in which both warriors lasted until time-out. The score is then: .PP .nf warrior 1: points = wins1 * F + ties * F warrior 2: points = wins2 * F + ties * F .fi .PP F is a score formula containing the W and S parameters. When more than two warriors (W) participate in a game, results are reported as wins[1], wins[2], .., wins[W], losses for each warrior, where the index indicates the number of warriors that survived until the end (S parameter in the score formula). The total number of points for each warrior is then calculated as: .PP .nf points = sum (S=1..W) (wins[S] * F) .fi .PP A few alternative score formulas: .EX 10 (W+1)/S (x=W-S+1)*(x+1)/2 (S==3)*5 + (S==2)*3 + (S==1) (S == 1)*W + (S != 1) .EE .SH OPTIONS Command line options may occur anywhere on the command line. Single-letter options without a parameter can be combined as in \-fbe. The special argument .I - (dash) stands for standard input (stdin). It can be combined with the .I -@ option (see below) to signify reading options from stdin, or the .I - can take the place of a warrior filename, in which case warrior code starting with a .I ;redcode line and ending with an .I END statement is extracted from stdin. The .I END statement can be omitted if the next .I ;redcode line immediately follows the last instruction. Several warriors, each specified by a separate dash on the command line and bracketed by .I ;redcode/END can be piped into .I pMARS. .I "#-" (where # is a positive number) is a shorthand for writing this number of dashes on the command line. .TP .BI \-r\ # This options sets the number of rounds to play. The default is 1. \-r 0 produces assembly output (unless -b is specified), but does not execute the warrior(s). A maximum of 32787 rounds can be specified. .TP .BI \-s\ # The \-s option specifies the size of core memory in number of instructions. It defaults to 8000. Maximum core size is platform-dependent, but usually at least 65535. .TP .BI \-c\ # \-c sets the maximum number of cycles per round. A cycle consists of one execution of each warrior. A round ends when either a single warrior remains executing or when the maximum number of cycles has elapsed. .TP .BI \-p\ # This option sets the maximum number of processes a warrior can run. The default is 8000. .TP .BI \-l\ # This sets the maximum length of a warrior source file in instructions. It defaults to 100 and can be up to 500. .TP .BI \-d\ # This option specifies the minimum distance between the first instruction of each warrior. It cannot be smaller than the maximum length (-l option) and defaults to 100 instructions. .TP .BI \-S\ # The -S option sets the size of the P-space to # cells. The default is 1/16th of core size if core size is evenly divisible by sixteen, or the next larger divisible fraction. See also the P-SPACE section below. .TP .BI \-f The \-f option instructs the loader to use a fixed series of addresses for positioning warriors. This is done by initializing the pseudo random number generator with a checksum value derived from the source of all warriors. Thus, initial placements will still be "random" from round to round, but will be the same if the same warriors are run again. As a consequence, the result of battles run with the \-f option will show no statistical fluctuations. This options is useful for validating ports of .I pMARS to new platforms and for providing an absolute, albeit arbitrary performance measure for warriors. .TP .BI \-F\ # This option server two purposes. It sets the seed value of the pseudo random number generator, and also tells the loader to install warrior 2 at the given address # for round 1. If the number is larger than the core size minus the minimum warrior distance, it will be wrapped around to the range of available starting positions. This option is useful for testing different versions of a warrior with constant initial placement. Warrior 1 is always installed at address 0. The \-F and \-f options are mutually exclusive. If neither option is specified, the pseudo random number generator is initialized with the system time. .TP .BI \-P This option makes .I pMARS use an alternative algorithm for positioning warriors. This algorithm uses all possible combinations of starting order and position in a random sequence, and will not use the same combination twice unless all the combinations have already been used. If the \-r option is not given, the number of rounds fought will be the number of all possible combinations. Trying to use this option with more (or less) than two warriors causes an error. .TP .BI \-e If this option is specified, the .I cdb debugger is entered immediately after loading warriors into core. .TP .BI \-b This options runs .I pMARS in brief output mode. \-b suppresses warrior listings after assembly. .TP .BI \-k With the \-k option, .I pMARS uses the same output format as the KotH program. This option enables .I pMARS to work with scripts written for the KotH server. .TP .BI \-8 This options enforces strict compliance with the ICWS'88 standard and disables all ICWS'94 language extensions, which are flagged as syntax errors by the assembler. Since ICWS'94 is a superset of ICWS'88, this options is not necessary to run ICWS'88 warriors. .TP .BI \-o When this option is given, .I pMARS reports scores in decreasing order rather than in the order warriors were named on the command line. This is mostly useful for multi-warrior play. .TP .BI \-V The assembler generates verbose output with this option. This is only useful for debugging. .TP .BI \-v This option sets the display mode for UNIX and DOS display versions (see APPENDIX). .TP .BI \-@\ .I pMARS continues reading options and filenames from the parameter file .I . If .I is a - (dash) standard input is parsed. Comments in the parameter file start with a semicolon. .TP .BI -=\ The = (equal) option allows you to specify a custom score formula (see SCORE). The formula may contain the standard arithmetic and logical operators (as in the C language), as well as the parameters W (number of warriors participating) and S (number of warriors surviving this round). You need to enclose the formula string with quotes if it contains spaces or characters interpreted by the operating system. .TP .BI \-Q\ # The "query" option is intended for use in scripts that run .I pMARS in batch mode. Depending on the number code following .I -Q, the program returns an informative number as the exit status. "pmars -Q 1000" e.g. will cause .I pMARS to exit with a code that spells out the program version. More on .I -Q arguments and exit codes can be found in the ADDENDUM. .TP .BI $ The $ (dollar) parameter is not preceded by a dash and cannot be grouped with other options. It terminates reading command line parameters and is used in parameter files or input streams .I (-@ fn). The .I $ is necessary if you want to combine two or more of command line parameters, warrior code and cdb commands in the same input stream or file. Below an example of such a combined input file: .EX ;Below the command line parameters: -r 10 -beF 1000 2- $ ;redcode ;name Imp 1 ;assert 1 mov 0,1 end ;redcode ;name Imp 2 ;assert 1 mov 0,2 mov 0,2 end !! cdb commands follow: sk 1000 reg quit .EE .SH X-WINDOWS OPTIONS The X-Windows display version of pMARS has these additional command line options: .PP .TP .BI \-display\ Expects a string specifying the display where the window should appear. Following X standards, this display specification has a format of hostname.domain:display.screen where the part before the colon is the standard internet host specification and display and screen are integers. The screen specification can be omitted. For an example, consider you are working at an X terminal named ncd13.complang.tuwien.ac.at and remotely logged in at host stud1.tuwien.ac.at where the binary of pmars lies, you can use the following command line .PP .nf stud1$ pmars -display ncd13.complang.tuwien.ac.at:0 -b aeka.red aeka.red .fi and the window will appear at you local screen. .TP .BI \-geometry\ Lets you specify the initial size and position of the window. The format is widthxheight+x+y where width, height, x, y are integers and + may be replaced by -. Either of the two parts (widthxheight or +x+y) may be omitted. This overrides the -v switch concerning the window geometry. As an example, pmars -geometry 600x400+30+100 .... will open a window of 600 by 400 pixels at the screen position (30,100). pmars -geometry 1024x768 ... creates a window of 1024x768 pixels and pmars -geometry -20+300 ... creates a window with standard size with its left upper corner at position (-20,300), i.e. out of the left side of the screen. .TP .BI \-fn\ The string following this argument specifies the X font to use. By default, a terminal font is used. If this font can't be found, "fixed" is used for a font ("fixed" should be present at every X installation). Use the command 'xlsfonts' to get a listing of fonts that can be used at your X server. 'xfontsel' provides a comfortable way to select a font. "fixed" is the fallback if the specified font can't be found. It is strongly recommended to use a fixed pitch font. .PP The argument of the .I -v display option has an additional fourth digit in the X-Windows version: 0 (the default) enables the color display, 1 the grayscale, and 2 the black and white display (e.g. -v 1033 for the grayscale display). .SH REDCODE .I pMARS implements an extension of the proposed ICWS'94 standard. The new instruction modifiers .I .A,.B,.AB,.F,.X, and .I .I, the arithmetic instructions .I MUL, DIV and .I MOD, as well as post-increment indirect (>) are supported. .I pMARS currently does not implement read/write ranges, although they may be added in future versions. .LP Version 0.5 of .I pMARS adds support for three experimental opcodes that are currently not included in the ICWS'94 draft: .LP SEQ (Skip if EQual): this is a synonym for CMP and is included mainly for clarity (future versions of .I pMARS may implement SEQ as a "predefined EQU" rather than a true opcode). .LP SNE (Skip if Not Equal): the opposite of SEQ. .LP NOP (No OPerations): do nothing. .LP Version 0.6 adds three new indirect addressing modes that use the A-field instead of the B-field as the pointer for indirection: .LP * - indirect using A-field .LP { - predrecement indirect using A-field .LP } - postincrement indirect using A-field .PP The new P-space instructions of version 0.8 are discussed under separate heading below. .PP The assembler also supports multi\-line .I EQU statements, a feature not included in the current ICWS'94 draft. The format for multi-line EQUates is .EX