旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴캠 � 旼캠旼캠旼� 旼캠敏쨌旼캠旼� 旼캠旼� 旼캠 旼캠 旼캠 붜� � 냥暠냥맏낳獺� 攷납낳넌故낳獺 넌故낳獺냥맏 쳐 � 냥맏 붜� � 넛캠넛暮냥맏� 攷� 볐�맏냥맏 냥暠냥맏넛暮 쳐 붚럼螳� 붜� � 突暠突暠獨獨突暠突暠獨獨獨獨 獨 獨獨突暠 突暠獨突暠 붜� � 米米旼캠旼캠旼� 旼캠旼캠旼쨌米米旼캠米 붜� � 낳낳� 攷� 攷낳獺 � 볐袴볐 낳낳낳넌故낳 붜� � 넛暮쳐 볐 攷냥맏 낳볶냥맏낳 볐螳볐�맏넛캠 붜� � 突暠突暠突暠獨獨 豚迦獨獨豚暠突暠獨獨突暠 붜� 突袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴暠栢 栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢栢 Copyright (c) 1992 Stefan Strack All rights reserved Email: stracks@ctrvax.vanderbilt.edu (Internet) stracks@vuctrvax (Bitnet) Mail: Dept. Pharmacology, 406 MRB Vanderbilt Univ. Medical School Nashville, TN 37232-6600 Phone: +615-322-4890, Fax: +615-343-6532 旼컴컴컴컴컴컴컴컴컴캠 � Table of Contents � 突袴袴袴袴袴袴袴袴袴暠 Line 1. Files .............................................. 59 2. Introduction ....................................... 72 3. Hardware requirements .............................. 93 4. Configuration ...................................... 105 5. Menu options........................................ 268 5.1. Function keys ............................ 286 5.2. Top level menu ........................... 319 5.3. The Loader menu .......................... 340 5.4. The Monitor menu ......................... 399 6. Redcode ............................................ 432 6.1. Instruction set .......................... 471 6.2. Addressing modes ......................... 641 6.3. Preprocessor syntax ...................... 663 7. ICWS'88 extensions ................................. 834 7.1. Process limit ............................ 856 7.2. Address space ............................ 872 7.3. Descendant count ......................... 886 8. The Core Editor .................................... 910 9. Run control switches ............................... 996 10. Bugs ............................................... 1096 11. Version history .................................... 1115 This document contains graphics characters; make sure your printer is set up properly before printing. New features or changes are indicated by V3.XX=> at the left margin. 旼컴컴컴컴컴캠 � 1. Files � 突袴袴袴袴袴暠 CORE.DOC - Quick intro, what's new COREMAN.DOC - Manual for CoreWar Pro CORE.EXE - CoreWar Pro executable CORE.SYS - Configuration file for CORE.EXE CORESTD.SYS - Configuration file for ICWS'88 compatible battles COREMUS.DEF - optional mouse driver *.RED - sample Redcode programs 旼컴컴컴컴컴컴컴컴컴� � 2. Introduction � 突袴袴袴袴袴袴袴袴袴� Core War is a simulation game for program battles in a small virtual memory space. The rules are detailed in the original articles by the creator of Core War, A.K.Dewdney (Computer recreations column, Scientific American, May 84, March 85, December(?) 86; compiled in his book "The Armchair Universe"). CoreWar Pro is a MARS (Memory Array Redcode Simulator), a Core War supervisory program that schedules the execution of battle programs written in the assembly-style language Redcode. CoreWar Pro is an integrated environment for writing and debugging Redcode programs and for running battles between two or more programs. The Redcode interpreter supports a superset of the ICWS'88 (International Core War Standard of 1988) instruction set (see 6.) and implements Jon Newman's Three Proposals for Future Redcode Standards (see 7.). V3.0=> The program is written in PDC Prolog 3.21. 旼컴컴컴컴컴컴컴컴컴컴컴컴컴캠 � 3. Hardware Requirements � 突袴袴袴袴袴袴袴袴袴袴袴袴袴暠 CoreWar Pro runs under DOS on IBM compatible computers with floppy or hard drive and DOS. A graphics card is not required, since the program operates fully in text mode. Memory requirement depends on the size of the Core (specified in CORE.SYS, default 8000) and on the number of Redcode programs loaded. With a Core size of 8000 the program will need less than 300K. The maximum Core size is 32757. 旼컴컴컴컴컴컴컴컴컴캠 � 4. Configuration � 突袴袴袴袴袴袴袴袴袴暠 The program is started with CORE [filename] where the optional parameter "filename" specifies a configuration file. If omitted, the file defaults to CORE.SYS. The configuration file controls appearance and behavior of CoreWar Pro. It consists of Prolog predicates that are consulted upon program start. You can change the setup by modifying the file with a text editor. All predicates are on a separate line, no blank lines are permitted. Commenting text following the closing parenthesis of a predicate is ignored. The CORE.SYS supplied with this release is a sample configuration for a color display; there you can find examples for most predicates described in the following. If CoreWar Pro cannot find the configuration file, or predicates are omitted from the file, the program will initialize from defaults. predicate: coresize(CS) occurs: 0..1 argument: CS = 0..32757, default = 8000 example: coresize(32000) Coresize/1 determines the size of the virtual memory array (Core) in number of addresses; the original rules refer to CS=8000, but for Redcode debugging and test runs the Core can be much smaller. The Core may contain up to 32757 addresses. The larger the Core array, the longer before a battle concludes by extinction of a contestant. V3.0=> address_space(AS) occurs: 0..1 argument: AS = 0..CoreSize, default = CoreSize example: address_space(2000) Address_space/1 specifies the range of Core that is addressable from a given instruction (see 7.2.). Numeric fields of instructions are normalized to a range of -(AS/2) .. (AS/2)-1 (-1000 .. 999 in the example). The entire Core is addressable by default (AS=CoreSize). V3.0=> process_limit(PL) occurs: 0..1 argument: PL = 1..32767, default = 1000 example: process_limit(64) Process_limit/1 restricts the maximum number of processes allocated to each program (see 7.1.). When the process number reaches this limit, SPL or SPC will have the same effect as a "JMP 1" instruction. V3.0=> predicate: screensize(Rows,Columns) occurs: 0..1 arguments: Rows: 25, 43, 50, 60 .. Columns: 80, 132, .. example: screensize(50,80) By default, CoreWar Pro starts up using the current text mode for displaying the Core arena (most commonly 25 rows by 80 columns). The screensize/2 predicate is used to set the screen size to the specified values. You need to have the appropriate graphics card to use extended text modes (EGA for 43x80, VGA for 50x80, etc.). predicate: windowcolors(WindowName,InsideColor,FrameColor) occurs: 0..7 arguments: WindowName = main ; menu ; statusline ; dialog ; message ; editor ; error InsideColor = 0..255, default = 7 (statusline 122) FrameColor = 0..255, default = 15 example: windowcolors(message,36,47) This predicate specifies the appearance of several windows (main, menu, ..) in the game environment. InsideColor and FrameColor are integers in the range from 0 to 255 specifying the color of the window inside and its frame respectively. If you have a monochrome monitor and the Core War display is illegible using the provided CORE.SYS, try color values 7 or 15. You can also delete all windowcolors/3 predicates, since colors default to black and white. V3.0=> predicate: controlmode(M1,M2,M3,M4,M5,M6,M7,M8,M9) occurs: 0..1 arguments: M1,M2,..M8 = on ; off defaults: (on,off,on,off,on,on,on,off,off) example: controlmode(off,on,off,off,off,off,off,off,off) Controlmode/9 describes the initial setting of run control and run display parameters (see 9.). The order of arguments is the same as in the "Run control" window. predicate: prodisplay(ProcessNo,ExeColor,ExeChar, WriteColor,WriteChar, BreakColor,BreakChar) occurs: 0..? arguments: ProgramNo = 1..? ExeColor = 0..255, default = MainWindowForeground ExeChar = ASCII(32)..ASCII(255), default = ASCII(48 + ProgramNo) WriteColor = 0..255, default = MainWindowForeground WriteChar = ASCII(32)..ASCII(255), default = ASCII(249) ('�') BreakColor = 0..255, default = MainWindowForeground + 128, BreakChar = ASCII(32)..ASCII(255), default = ASCII(48 + ProgramNo) example: prodisplay(1,32,'1',2,'�',175,'1') Prodisplay/7 controls the appearance of processes when run in "visual mode" (see 9.). Argument ExeColor is the color attribute for the display of ExeChar, the character indicating the execution of program ProgramNo. When ProgramNo writes to Core, it is shown by displaying WriteChar with color WriteColor. When visual mode is interrupted because a program faulted, a key was pressed, etc., the address last executed is highlighted by BreakChar displayed with color BreakColor. predicate: exclude(ExStr) occurs: 0..? argument: ExStr = "DAT" ; "MOV" ; "ADD" ; "SUB" ; "JMP" ; "JMZ" ; "JMN" ; "JMG" ; "DJZ" ; "DJN" ; "CMP" ; "SPL" ; "SLT" ; "PCT" ; "HLT" ; "SPC" ; "RND" ; "EXC" ; "SLC" "$" ; "@" ; "<" ; ">" example: exclude("EXC") The exclude/1 predicate forces programs to use a subset of the Redcode language - e.g. to enforce the ICWS'88 instruction set. ExStr is a quoted opcode in all capitals or an addressing mode symbol. predicate: editor(CommandString) occurs: 0..1 argument: CommandString = DOS command string example: editor("qed") Use the editor/1 predicate to specify the file editor invoked by the "Editor" selection from the main menu. predicate: path(DosPathName) occurs: 0..1 argument: DosPathName = valid drive:\pathname, default = "" example: path("D:\GAMES\COREWAR") Path/1 specifies where CoreWar Pro looks for files when displaying a directory listing. Files that the program expects in DosPathName are programs (*.RED), and saved game states (*.DMP). If the path/1 predicate is omitted, CoreWar Pro will look for all files in the current directory. E.g. path("b:") sets the directory path to drive B:. Note: you must omit the trailing back-slash in the directory name. predicate: cycles(N) occurs: 0..1 argument: N = Real default: 100000 example: cycles(2500) Cycles/1 sets the starting value for the count-down execution timer (see also 9.). 旼컴컴컴컴컴컴컴컴컴� � 5. Menu options � 突袴袴袴袴袴袴袴袴袴� CoreWar Pro is a windowing environment driven by menus and dialog windows. Menu items are selected with arrow keys and the key or highlighted hot-keys; the escape key returns to the previous menu V3.02=> on top and also cancels input in dialog windows. recalls the last string in input prompts. The main window displays the progress of the Core battle and the message window receives most text output (run information, status reports etc.). The status line on the bottom of the screen informs if and what kind of input the program will accept. From the top level menu the two central modules Loader and Monitor can be selected, each represented with its own submenu. Briefly, the Loader loads and installs Redcode programs and the Monitor executes them. 旼컴컴컴컴컴컴컴컴컴컴캠 � 5.1. Function keys � 突袴袴袴袴袴袴袴袴袴袴暠 You can use the function keys F1 to F6 to execute frequently used commands. F2, F3 and F4 (RunV, Step, Watch) first set the appropriate interrupt/view modes of the control panel, then start the interpreter and finally reset the control panel to its previous state. F1 (Load) Lets you select Redcode programs from a directory listing until you press . You are then prompted for one of three ways to install the selected programs in Core (see 5.3., Install programs). This is equivalent to repeatedly selecting "Load program" and then "Install programs" from the Loader submenu. F2 (RunV) Starts the interpreter in visual mode using the default settings for controlmode/9. F3 (Step) Starts the interpreter in single-step (debugging) mode. F4 (Watch) Starts the interpreter in watch/single-step mode. Watchpoints are set from within the Core Editor. F5 (New) Clears the Core and unloads programs (= "Reset"/"Unload programs" from the Loader submenu). F6 (Cls) Clears the main window. 旼컴컴컴컴� 쿗oader굇>� 쿘onitor >� 쿏OS � 旼컴컴컴컴컴컴컴컴컴컴컴� 쿐ditor � � 5.2. Top level menu � 쿜uit � 突袴袴袴袴袴袴袴袴袴袴袴� 읕컴컴컴컴� The top level menu provides access to the Loader and Monitor submenus and exits the environment (Quit). In addition the following commands are available from the main menu: 5.2.1 DOS. This selection starts up a DOS shell. "EXIT" returns to the top level. 5.2.2 Editor. Invokes the editor specified in the editor/1 setup predicate (see 4.) for editing Redcode programs etc.. 旼컴컴컴컴� 쿗oader굇>� 旼컴컴컴컴컴컴컴컴컴컴커 쿗oad켙edcode켺rogram굇� 쿔nstall programs >� 쿗oad Core � 旼컴컴컴컴컴컴컴컴컴컴컴캠 쿏ump Core � � 5.3. The Loader menu � 쿝eset >� 突袴袴袴袴袴袴袴袴袴袴袴暠 읕컴컴컴컴컴컴컴컴컴컴켸 The Loader submenu is used to make the preparations for a Core battle such as loading programs from disk, installing them in Core, etc.. These are the items on the menu: 5.3.1 Load Redcode program. Reads a Recode source file from disk, selected from a directory listing of files matching *.RED and assembles the program into an internal representation of Redcode. You V3.0=> can change the default file path or extension by pressing F4 (Mask) in the directory window. A program is selected using cursor-control keys or the first letter of the file name. Syntax errors are reported in an error window, and the assembly status is reported after completion. "Load Redcode program" can be repeated ad lib.; for each successful assembly a new program image is stored in memory. A description of Redcode syntax can be found in section 6. 5.3.2 Install programs. After all Redcode battle contestants have been loaded from disk and successfully assembled, they need to be installed in the circular memory array (Core). "Install programs" offers three installation modes in a submenu: (1) At random. Programs are installed with randomly scattered start addresses while maintaining a minimum distance that can be specified. (2) Maximum distance. Programs are installed into Core such that they keep a maximum distance from one another. (3) Manually. The user is prompted for the start address of each program. 5.3.3 Load Core. The Core War simulator allows to dump the current state of execution (Core contents, programs, process control blocks, process queue, stacks) to disk in order to resume with a battle in progress at a later time. "Load Core" lets the user select a core file (*.DMP) from a current directory listing and consults (=reads) it. Load/Install programs and Load Core are mutually exclusive options for preparing for execution. 5.3.4 Dump Core. See above item; dumps the current state of execution to disk (default extension .DMP). This option is also useful for making "back-ups" during a long-running battle. A .DMP file is a plain ASCII-file that you can look at or modify with an editor. 5.3.5 Reset. Allows to reset (clear) Core and/or program images in order to start fresh. (a) "Uninstall programs" clears all Core addresses and resets process control blocks, stacks, and the process queue, (b) "Unload programs" does the same as (a) and also clears all programs from memory (this corresponds to pressing F5). (c) "Reset counter" resets the count-down execution timer to its start value (specified in the configuration file, see 4). "Install programs" will not work unless the Core is clear. 旼컴컴컴컴� 쿗oader >� 쿘onitor�>� 旼컴컴컴컴컴� 쿝un굇굇굇굇� 旼컴컴컴컴컴컴컴컴컴컴컴컴� 쿎ontrol >� � 5.4. The Monitor menu � 쿐dit Core � 突袴袴袴袴袴袴袴袴袴袴袴袴� 읕컴컴컴컴컴� The Monitor is the program scheduler and Redcode interpreter; from the Monitor menu you can start execution, control execution, inspect or edit the Core contents. The menu entries are: 5.4.1 Run. This starts the round-robin scheduler executing instructions of Redcode programs installed in Core. Execution is interrupted when one of the interrupt conditions enabled on the control panel (see 9.) applies. An interrupt window displays the source of interrupt, the current process' program counter and the instruction interrupted. You are then returned to the Monitor menu from which execution can be restarted after the point of interrupt. The "Run" command uses the current settings on the control panel (see below and 9.). The F2-4 keys start execution with predefined control settings (see 5.1.). 5.4.2 Control. Opens the "control panel" of the scheduler. Several controls pertaining to execution interrupts (single step, break on error etc.) and representation of the running processes (visual, watch, etc.) can be enabled or disabled by toggling on or off. The initial setting of the control parameters are defined by the setup predicate controlmode/9 (see 4.). The effect of each control parameter on execution is described in section 9. 5.4.3 Edit Core. This option starts the full-screen memory editor in its own window. The Core Editor allows you to scroll through the memory array and to modify the contents of addresses. Core Editor commands are described in section 8. 旼컴컴컴컴컴컴캠 � 6. Redcode � 突袴袴袴袴袴袴暠 CoreWar Pro deals with three forms of Redcode as shown in this schema: "Full Redcode" (program on disk) � � Preprocessor v "Plain Redcode" ^ � Assembler/Disassembler v "Machine code" The Redcode programmer writes programs in "Full Redcode" using a text editor. Full Redcode is Redcode with "syntactic sugar" (see 6.3.). In pre-3.0 versions of CoreWar Pro, the preprocessor was a separate program (RPP.EXE) that converted Full Redcode files to "Plain Redcode" files, ie Redcode with all labels, EQUates and expressions resolved to numbers. Starting with version 3.0, the preprocessor is integrated into the program loader and feeds Plain Redcode directly into the assembler. The assembler in turn produces a space-efficient internal representation of the code ("machine code"). Machine code is not visible to the user; in fact, the Core Editor (see 8.) includes a disassembler that translates machine code back into human-readable Plain Redcode for display. Each Redcode instruction occupies one line. Plain Redcode instructions consist of a three-letter opcode followed by zero, one or two operands. Each operand is made up of an optional addressing mode character (see 6.2.) followed by an integer. Each file V3.0=> contains exactly one program. Execution starts at the first executable (ie non-DAT) instruction unless a specific start instruction is defined by an "END " statement. 旼컴컴컴컴컴컴컴컴컴컴컴캠 � 6.1. Instruction set � 突袴袴袴袴袴袴袴袴袴袴袴暠 CoreWar Pro supports a superset of the International Core War Standard of 1988 (ICWS'88) Redcode instruction set. Twelve of the 25 opcodes supported belong to the ICWS'88 (this includes DAT and the END pseudo-opcode). The 13 non-standard opcodes fall into five classes: (1) Opcodes listed by A.K.Dewdney that were never incorporated into the standard (JMG, DJZ); (2) the proposed opcode PCT; (3) the widely implemented, but non-standard RND; (4) additional process-control opcodes (HLT: Halt, and SPC: Split with descendant count); and (5) the meta-interpreter opcode EXC. The SLT opcode was introduced in the ICWS'88. Redcode warriors written for official tournaments must obviously restrict themselves to the ICWS'88 instruction set and addressing modes (see 6.2.). The alternate configuration file CORESTD.SYS contains the appropriate exclude/1 statements to enforce ICWS'88 compatibility (see 4.). In the listing below, non-standard opcodes are indicated by a �. �袴袴袴袴袴袴袴袴袴佶袴袴佶袴袴佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 � Instruction � Mnem� Args� Description � 勁袴袴袴袴袴袴袴袴曲袴袴曲袴袴曲袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � Data statement � DAT � B � Non-executable; B is data value � � � � � � 훤袴袴袴袴袴袴袴袴賈袴袴賈袴袴賈袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� Store-Instructions �袴袴袴袴袴袴袴袴袴佶袴袴佶袴袴佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 � Instruction � Mnem� Args� Description � 勁袴袴袴袴袴袴袴袴曲袴袴曲袴袴曲袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � Move � MOV � A B � Move contents of A to B � � � � � � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Add � ADD � A B � Add the A- and B-fields of A to � � � � � the A- and B-fields of B � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Sub � SUB � A B � Subtract the A- and B-fields of A � � � � � from the A- and B-fields of B � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Random� � RND � A B � Generate random number (range 0 .. � � � � � A-1) and store it in B � 훤袴袴袴袴袴袴袴袴賈袴袴賈袴袴賈袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� ADD and SUB will add and subtract integers in the range from -32768 to 32767. The result is normalized to the current address space. Branch-Instructions �袴袴袴袴袴袴袴袴袴佶袴袴佶袴袴佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 � Instruction � Mnem� Args� Description � 勁袴袴袴袴袴袴袴袴曲袴袴曲袴袴曲袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � Jump � JMP � A � Transfer control to A � � � � � (unconditional) � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Jump if zero � JMZ � A B � Transfer control to A if contents � � � � � of B is zero � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Jump if not zero � JMN � A B � Transfer control to A if contents � � � � � of B is not zero � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Jump if greater � JMG � A B � Transfer control to A if contents � � than zero� � � � of B is greater than zero � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Compare � CMP � A B � If contents of A is equal to B � � � � � then skip one instruction � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Skip if less � SLT � A B � If contents of A is less than B � � than � � � then skip one instruction � 훤袴袴袴袴袴袴袴袴賈袴袴賈袴袴賈袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� Counter-Instructions �袴袴袴袴袴袴袴袴袴佶袴袴佶袴袴佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 � Instruction � Mnem� Args� Description � 勁袴袴袴袴袴袴袴袴曲袴袴曲袴袴曲袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � Decrement, jump � DJZ � A B � Subtract 1 from B and jump to A � � if zero� � � � if contents of B is 0 � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Decrement, jump � DJN � A B � Subtract 1 from B and jump to A � � if not zero � � � if contents of B is not 0 � 훤袴袴袴袴袴袴袴袴賈袴袴賈袴袴賈袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� Process-Instructions �袴袴袴袴袴袴袴袴袴佶袴袴佶袴袴佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 � Instruction � Mnem� Args� Description � 勁袴袴袴袴袴袴袴袴曲袴袴曲袴袴曲袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � Split � SPL � A � Split execution into next � � � � � instruction and A � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Split/descendant � SPC � A B � Split, B is descendant count � � count� � � � � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Halt� � HLT � - � Terminate execution of � � � � � (sub)process � 훤袴袴袴袴袴袴袴袴賈袴袴賈袴袴賈袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� Remarks: SPC implements the descendant count modification introduced by Jon Newman (see 7.3.). Execution of the HLT (Halt) instruction has the same effect as attempted execution of a data statement, except that HLT will not trigger an error message. Processes spawned by a program are identified by process numbers. The V3.02=> initial "root" process is called "process 0". All processes created by the root process using SPL (Split) are refered to as process 1, processes spawned by these "first level processes" are called process 2, a.s.o.. In contrast, processes created by the experimental SPC (Split/descendant count) instruction are given unique negative numbers that are unrelated to the level of process spawning. Special Instructions �袴袴袴袴袴袴袴袴袴佶袴袴佶袴袴佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 � Instruction � Mnem� Args� Description � 勁袴袴袴袴袴袴袴袴曲袴袴曲袴袴曲袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � Protect� � PCT � A � Write-protect address A against � � � � � next write attempt � 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Execute� � EXC � A B � Execute instruction at B, update B � � � � � & transfer control to A if no error� 픔컴컴컴컴컴컴컴컴컵컴컴컵컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � End � END � A � Loader directive: end-of-program, � � � �(Opt)� optionally begin execution at A � 훤袴袴袴袴袴袴袴袴賈袴袴賈袴袴賈袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� Remarks: The END pseudo-opcode is optional and marks the end of the program. If a program file does not contain an END statement, EOF is assumed. The optional operand of END points to the first instruction to be executed (e.g. END -15, if the program execution starts 15 instructions before). The default start is the first executable instruction. The EXC instruction is a single-thread meta-interpreter. It provides Redcode programs with internal exception handling, since EXC traps errors by conditional branching: if the instruction pointed to by B fails or is a HLT instruction, then the next instruction following EXC is executed. If the instruction at B succeeds, then B is updated with the new "local" program counter (the address B transfers control to), and execution resumes at A. B is therefore usually an indirect address. Since only one local program counter is maintained in B, only one execution thread can be trapped by EXC. Consequently, when EXC executes a SPL or SPC instruction, the newly created process is not under EXC's control. The code fragment below demonstrates a single-instruction meta-interpreter executing a 3-instruction program. exc 0 @pc ;single instruction loop jmp continue ;an error was trapped pc: dat 1 ;local PC loop: mov #0 @target ;"DWARF-like" sub #10 2 jmp loop target: dat 4 Since code executed by EXC is under control of the executing program, it is "invisible" to the interpreter: e.g. single-step mode will not trace the instructions under control of EXC, nor will breakpoints trigger an interrupt. You can still debug code under the control of EXC by placing a watchpoint on the data statement that serves as the local program counter. EXCs can be nested, i.e. an EXC instruction can execute another EXC instruction. The interpreter can catch EXC "loops", i.e. it will signal failure if an EXC tries to execute itself in an infinite loop. 旼컴컴컴컴컴컴컴컴컴컴컴컴� � 6.2. Addressing modes � 突袴袴袴袴袴袴袴袴袴袴袴袴� Non-ICWS'88 modes are indicated with a �. �袴袴袴袴袴袴袴袴袴袴袴袴袴佶袴佶袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴敲 � Mode 쿞ym� Description � 勁袴袴袴袴袴袴袴袴袴袴袴袴曲袴曲袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� � immediate � # � is data value � � � � � � direct � $ � is effective address � � � � ($ can be omitted) � � indirect � @ � is address of effective address � � � � � � pre-decrement indirect � < � decrement, is then address of � � � � effective address � � post-increment indirect� � > � is address of effective address, � � � � then increment � 훤袴袴袴袴袴袴袴袴袴袴袴袴賈袴賈袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴� 旼컴컴컴컴컴컴컴컴컴컴컴컴컴캠 � 6.3. Preprocessor syntax � 突袴袴袴袴袴袴袴袴袴袴袴袴袴暠 V3.0=> CoreWar Pro includes a powerful, built-in Redcode preprocessor that facilitates writing of programs. Preprocessor features include label-based references, constant definitions (EQUates), evaluation of integer expressions and access to system variables. 旼컴컴컴컴컴컴컴컴컴컴컴컴� � 6.3.1. General format � 突袴袴袴袴袴袴袴袴袴袴袴袴� Redcode program files are relatively free-format, but you should establish and adhere to your own format conventions for clarity. The preprocessor is case-insensitive; empty lines are permitted. Opcodes, labels, numbers, etc. can be separated by space(s), tab(s) or comma(ta). Separators are not required before and after non-alphanumeric characters. E.g.: "Choice: DJN @Start to the program counter as in Plain Redcode. Labels are names that consist of letters, numerals and the underscore and that start with a letter or underscore. V3.01=> Before an instruction, a colon can be appended to labels, but the colon is ommitted when the label is referenced by an instruction. Labels can be on a separate line or on the same line before an instruction. Multiple labels per instruction are allowed. E.g.: LastInstr:Endless: jmp endless is equivalent to Endless LastInstr jmp ENDLESS 旼컴컴컴컴컴컴컴캠 � 6.3. EQUates � 突袴袴袴袴袴袴袴暠 The EQU (Equate) statement defines a name for a list of symbols used in the following code. RPP will replace every occurence of the first argument of EQU in the code with what follows after the first argument. EQU is similar to the #define preprocessor directive in C. EQUates may be nested, that is the list of symbols to be substituted may contain other EQUated names. EQUates have the format Name EQU Symbol [..] or EQU Name Symbol [..] E.g.: numberlines equ (last-first+1) equ bombzero mov #0 The first format is part of the ICWS'88 Redcode definition; the second format is supported for compatibility with CoreWar Pro V2.0 and earlier. It is good practice to surround EQUated expressions with parentheses to enforce evaluation precedence. 旼컴컴컴컴컴컴컴컴컴컴컴컴컴� � 6.3.4. System variables � 突袴袴袴袴袴袴袴袴袴袴袴袴袴� By refering to system variables you can write Redcode programs that adapt to the current system configuration. There are four system variables: CORESIZE. The CORESIZE variable is instantiated to the current size of the Core as determined by the coresize/1 predicate in the configuration file (see 4.). The following fragment defines the Coresize-dependent constant process_spacing: equ n_processes 4 equ process_spacing (CORESIZE / n_processes) V3.0=> RANDOM_ADDRESS. At load-time, the system variable RANDOM_ADDRESS is instantiated to a random number between 0 and Coresize-1, which is the same for each reference to RANDOM_ADDRESS within a program, but different between programs. RANDOM_ADDRESS can be used to create unique "program IDs" or to add some unpredictable behavior. In the example below, n_processes can range from 2 to 5. equ n_processes (RANDOM_ADDRESS % 4 + 2) V3.0=> ADDRESS_SPACE. The value of ADDRESS_SPACE corresponds to the value of the address_space/1 configuration predicate (see 4., 7.2.). V3.0=> PROCESS_LIMIT. This variable is set to the value of the process_limit/1 configuration predicate (see 4., 7.1.). System variables are implemented as predefined EQUate statements and can therefore be overridden by EQUates in the program code. 旼컴컴컴컴컴컴컴컴컴컴캠 � 6.3.5. Expressions � 突袴袴袴袴袴袴袴袴袴袴暠 Numerical expressions can be embedded anywhere in the program text. The preprocessor evaluates an expression and substitutes it with the integer result. Expressions consist of operators and operands. Operators are: + addition - subtraction * multiplication / integer division % modulo Operands can be integers, labels, expressions or symbols representing integers, labels or expressions. Two notations are supported: standard infix (A + B) and reverse-polish (A B +). You can mix infix and reverse-polish notation in the same expression, although this would not exactly add to the readability of your code. V3.0=> In infix notation, the order of evaluation is left to right; operator precedence (*,/,% before +,-) is not supported, but parentheses can be used to control evaluation order. Reverse-polish expressions must be enclosed in parentheses to avoid ambiguities such as the following: 1) ADD 2 2 - 3 => ADD (2 2 -) 3 => ADD 0 3 (reverse-polish) 2) ADD 2 2 - 3 => ADD 2 (2 - 3) => ADD 2 -1 (infix) Examples: MOV #last-first+1 numlines ; infix ADD @2 * (CORESIZE + 2) counter ; infix with parentheses spacing EQU (CORESIZE 4 /) ; reverse-polish jmp (spacing first + - choicepoint) ; reverse-polish, then infix 旼컴컴컴컴컴컴컴컴컴� � 6.3.6. Comments � 突袴袴袴袴袴袴袴袴袴� Two comment symbols are implemented: the ; (semi-colon), which is ICWS'88 compatible, and the REM word. REM is supported for backward compatibility with earlier CoreWar Pro versions and may not be supported in future versions. The comment extends from the comment symbol to the end of the line. 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴캠 � 6.3.6. Order of processing � 突袴袴袴袴袴袴袴袴袴袴袴袴袴袴暠 The preprocessor first substitutes all EQUated names, goes on to replace label-references by numbers, and lastly evaluates expressions. This means that it is possible to EQUate labels. 旼컴컴컴컴컴컴컴컴컴컴컴컴� � 7. ICWS'88 extensions � 突袴袴袴袴袴袴袴袴袴袴袴袴� Under the current Core War standard "DWARF-like" warriors that remain stationary and bomb the Core systematically are favored over more "intelligent" programs that copy themselves, spawn sub-processes and are capable of self-repair. This is evidenced by the fact that the last freely self-replicating warrior to win the annual tournament was MICE in 1987. Most effective warriors currently try to disable their opponent by "process explosion", for example by planting the devastating "SPL 0" instruction into the opponent's code. While this is perfectly legal, it might be considered unfair, since the entire program grinds to a halt, and not just the process whose code segment that was hit. To promote more interesting warriors, Jon Newman has suggested extensions to the current Core War standard ("Three Proposals for future Core War standards" published in the Winter 1991 issue of The Core War Newsletter). CoreWar Pro implements these changes while maintaining compatibility with ICWS'88. 旼컴컴컴컴컴컴컴컴컴컴캠 � 7.1. Process limit � 突袴袴袴袴袴袴袴袴袴袴暠 V3.0=> ICWS'88 does not specify a limit to the number of processes a warrior can spawn off. This is why "SPL 0" bombs are so effective; the affected warrior will stall by spawning off processes until the memory allocated to the interpreter is filled. CoreWar Pro allows defining an upper limit to the process count through the process_limit/1 predicate in the configuration file (see 4.). If the process limit is reached, SPL or SPC will not create a new process but will merely transfer control to the following instruction. A low process limit will effectively defang warriors that use "process explosion". 旼컴컴컴컴컴컴컴컴컴컴캠 � 7.2. Address space � 突袴袴袴袴袴袴袴袴袴袴暠 V3.0=> The address space extension is used to restrict the addressable range of Core memory. With e.g. address_space(2000) in the configuration file, CoreWar Pro normalizes operand values to a range of -1000 to 999. All direct Core references are restricted to this range; indirect addressing accesses -2000 to 1999. This extension encourages mobile programs: in order to seek out opponents in non-addressable areas of Core, warriors have to copy themselves or spawn off processes. 旼컴컴컴컴컴컴컴컴컴컴컴컴� � 7.3. Descendant count � 突袴袴袴袴袴袴袴袴袴袴袴袴� V3.0=> The descendant count modification limits the number of processes that a newly created process can spawn off. With descendant_count enabled (see 4.), the B-operand of the SPC instruction specifies the maximum number of processes that the new process can create. This limit includes children processes, children's children processes and so on. E.g. "SPC X #0" creates a processes that cannot create sub-processes and is therefore immune to "SPL 0" bombs (a SPLit instruction would simply transfer control to the next instruction). The "root" process has a descendant_count of ProcessLimit-1 (the global processes-per-program limit set by the process_limit/1 configuration predicate). A process can change its own descendant count by splitting off a sub-process with the desired descendant count and committing suicide. You could thus write a largely "SPL 0" resistant program by starting the code with spc start #some_low_number hlt start: 旼컴컴컴컴컴컴컴컴컴컴캠 � 8. The Core Editor � 突袴袴袴袴袴袴袴袴袴袴暠 The Core Editor is a debugging tool for inspecting and modifying the contents of the Core array. Invoked from the Monitor menu, the Core Editor opens a window centered on the Core address that was executed last. Each address is displayed as one line with the format: Address Attr Instruction 3017 1W CMP #513 @-12 "Address" is in the range from 0 to CoreSize-1. The attribute V3.0=> consists of a number which may be followed by a "W", "B", or "P". The number is the "owner" attribute of this address and corresponds to the number of the program that wrote to it last. The "W" indicates that this address is marked as a watchpoint to be displayed when the watchpoint switch is enabled on the control panel (see 9.). Similarly, the "B" marks an address as a breakpoint. An address is protected against the next write access if the "W" symbol is displayed. The contents of the instruction field is displayed as "Plain Redcode", i.e. with labels, expressions and symbols resolved to numbers. "Empty" addresses are shown with blank attribute and instruction fields. A selection bar highlights the current address. You can move around the Core using cursor-control keys and issue single-character commands displayed on the status line: Up-, Down-Arrow move selection bar up or down by one address Left-, Right-Arrow scroll screen up or down by one address , display next or previous screen (22 addresses) <^PgDn>, <^PgUp> (Control-PgUp, -PgDn) jump 1/8th of the Core size ahead or back go to the top of the page go to the bottom of the page Erase contents of current address oto go to specified address (default is the current address offset by the B-field of the current address, i.e. a JMP @0 #Goto) V3.02=> , dit edit current address ind find contents of address

rot write-protect/deprotect current address (equivalent to executing PCT on this address/writing to it) reak toggle breakpoint flag atch toggle watchpoint flag eec execute current address and move selection bar to next PC return to Monitor menu The dit command allows you to change the instruction field of the V3.0=> current address. The full preprocessor syntax is supported at the prompt for a new instruction. This means that labels, expressions and system variables can occur in the instruction. You can even key in an EQUate statement, in which case the old instruction is not overwritten. Labels and EQUated symbols remain valid for the current editing session and are cleared upon exiting the Core Editor. ind prompts for an instruction to search for. Again, this V3.0=> instruction may contain labels, expressions, etc.. If you hit at the prompt, the Editor will search for the next occurrence of the instruction field of the currently selected address. The address attribute is ignored in the search. The search instruction may be specified incompletely using the * wildcard. The * can take the place of the opcode, the A- and the B-field. E.g. "MOV * *" positions the selection bar at the next MOV instruction, irrespective of operands. "* 0 1" searches for any opcode with operands 0 1, "* * *" jumps to the next non-empty address, and "* *" locates the next instruction with an empty B-field. The eecute command will try to execute the instruction currently under the selection bar. If the address is executable, the screen is refreshed to show updated Core addresses, and the selection bar moves to the address that the executed instruction transfers control to. If an executed instruction returns more than one new process counter - as it is the case with SPL and RLS - only the first PC is traced. This command is extremely useful for debugging code segments. In conjunction with the dit command, you can write write entire programs into the Core and watch them execute. 旼컴컴컴컴컴컴컴컴컴컴컴컴컴� � 9. Run control switches � 突袴袴袴袴袴袴袴袴袴袴袴袴袴� The run control panel in the Monitor module has nine on/off switches that control appearance and interrupt behavior of a Core War battle. Three parameters control how the battle is represented on screen (single step, visual, watch), the remaining six control under what circumstances execution is paused. Key interrupt ON: execution can be paused at any time by pressing any key, OFF: execution can only be interrupted by pressing Control-Break (usually ON, except when "single step" is enabled). Default: ON Single step ON: trace mode for debugging, the instruction executed is displayed in the main window in Core Editor format (see $editp$.). Single step ON disables all other switches (except Watch), since in this mode execution is interrupted after each instruction anyway. Default: OFF Visual ON: visual representation of Core War execution is enabled. In visual mode, the Core is mapped to the main window, with each address corresponding to one position on the 22 * 78 character area (increasing address from left to right, top to bottom). If the Core size exceeds 22 * 78 = 1716 then adjacent Core addresses may map to the same cursor position, "condensing" the entire Core onto one screen. Execution of a process is shown by writing its identifying character and color to the main window at coordinates corresponding to the current program counter. Writing to Core addresses is indicated by a different character and color (all program display parameters can be customized by prodisplay/9 in the configuration file, see 4). Default: ON Watch ON: the contents of addresses marked as watchpoints (using in the Core Editor) are displayed while programs are running. The contents of the instruction it points to as an indirect address is also displayed on the same line. Besides watchpoints, the current list of program counters and the contents of the private stack are shown. OFF: no watch-information is displayed. "Watch" is compatible with all other execution views, although it is most commonly used together with "Single step". Default: OFF Breakpoints ON: the scheduler pauses after an instruction at a breakpoint address was executed (Address Mode = 4,5,6,7); OFF: although a breakpoint may have been reached, execution is not interrupted. Breakpoints can be marked from within the Core Editor. Default: ON Break on error ON: interrupt is invoked if an instruction cannot be executed (e.g. a data statement), usually indicating that the faulting process has been corrupted by a contestant destructively modifying its code in Core. OFF: execution continues through errors. The Monitor terminates a faulting process. If a program has only one process running (and no processes were suspended by SSP), an execution error will terminate the program. Default: ON V3.0=> Break on execute opponent Each Core address has an "owner attribute", a 4-bit field indicating which program has last modified it. The contents of this flag is shown in the second column of the Core Editor display (see 8.). ON: the Monitor uses this information to generate an interrupt if a program executes an instruction that was last written to by a different program. This interrupt thus signals imminent program failure. Default: ON V3.0=> Break on overwrite opponent ON: An interrupt is generated if a program writes to an address that has previously been modified by a different program. This tends to signal program failure earlier than "Break on execute opponent", but also pauses at less critical events, such as one program's bombs overwriting another program's bombs. Default: OFF Count-down from ON: the count-down counter is decremented with each excution of an instruction. If zero is reached, execution is interrupted, but may be restarted since the counter is automatically reset. The current count is also displayed on the status line during a battle. Default: OFF 旼컴컴컴컴컴� � 10. Bugs � 突袴袴袴袴袴� The program is very sensitive to format errors in the configuration file, e.g. the SideKick Notepad appends a ^Z character to each file edited, which causes CoreWar Pro to report an error upon start-up. Most other ASCII-editors should work fine. V3.0=> While there is no fixed limit on the number of Redcode programs that can be run concurrently, program numbers greater than 31 will carry from the "owner" field into first the breakpoint- and then the protect status bit of address attributes. Consequently, programs with program numbers greater than 31 will trigger false breakpoint interrupts (unless turned off from the control panel). Programs above 63 will have all their instructions write-protected which is usually undesirable. 旼컴컴컴컴컴컴컴컴컴컴캠 � 11. Version history � 突袴袴袴袴袴袴袴袴袴袴暠 V1.0 to 1.5 (July-September 1988, not released) V1.6 (released April 1989) � representation of Core as dynamic database predicates � color support V1.7 (released November 1990) � Redcode preprocessor � condensed visual display of execution � stack opcodes V2.0 (released March 1991, posted on c.b.i.p April 1) � more opcodes � Core editor � watchpoints � internal representation of instructions hidden V2.1 (released August 1991) � ICWS'88 compliant � larger Core sizes � lower memory requirement V3.0 (released November 1991) � faster execution � integration of preprocessor � EGA/VGA extended textmodes � ICWS'88 extensions End of COREMAN.DOC, date of last change: 1-16-92