Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cbmvax!uunet!portal!cup.portal.com!Chad_The-Walrus_Netzer
From: Chad_The-Walrus_Netzer@cup.portal.com
Newsgroups: comp.sys.amiga
Subject: Re: Core Wars for Amiga
Message-ID: <6218@cup.portal.com>
Date: 4 Jun 88 08:51:28 GMT
References: <5605@bloom-beacon.MIT.EDU>
Organization: The Portal System (TM)
Lines: 106
XPortal-User-Id: 1.1001.2959


In a previous article (Rich Carreiro) writes:

>I just downloaded CoreWars 1.1w (Chad_the_Walrus's Amy port of the
>1984 Scientific American version of CoreWars).  However (and
>understandibly), Chad did not include any docs.  Can some kind soul
>describe to me the Redcode command set, required operands, and
>addressing modes.  For what it's worth, I am familiar with assembly
>language programming concepts (having done some SIMPLE things on a
>Radio Shack CoCo II).

	Sorry, but after I wrote the program, I didn't feel up to typing
in all the docs as to the concept of 'CoreWars' (rather than just the
"usage" docs)...  A while later, I started making a summary, but didn't
finish...  I'll see if I can dig it up, and add a little to it.  Of
course, the best solution would be if you could get the original Sci. 
Am.  article (as well as the followups...  I Think the original was in
the November, 1984 issue) You can ask me questions, and I'll try to
answer them (I've personally never written a single original program in
Redcode...  I just found the source, and after I had learned 'C' and was
taking a break from another project, I ported it, and added some nice
enhancements to make the program non-infuriating...  So I actually might
be of limited help :-) Also, I'm in the middle of finals, so that could
slow things down.  We should probably continue our discussion elsewhere,
so you can direct me to the proper newgroup (probably
rec.games.programmers). 
	Anyway, here goes the summary:


"add." = "address"

INSTRUCTION | MNEMONIC | CODE | ARGUMENTS |	 EXPLANATION
------------+----------+------+-----------+-----------------------------------
	    |	       |      | 	  |
MOVE	    |	MOV    |  1   | A	B | Move contents of add. A to add. B
	    |	       |      | 	  |
ADD	    |	ADD    |  2   | A	B | Add contents of add. A to add. B
	    |	       |      | 	  |
SUBTRACT    |	SUB    |  3   | A	B | Subtract contents of add. A from
	    |	       |      | 	  | add. B
	    |	       |      | 	  |
JUMP	    |	JMP    |  4   | A	  | Transfer control to add. A
	    |	       |      | 	  |
JUMP IF ZERO|	JMZ    |  5   | A	B | Transfer control to add. A if
	    |	       |      | 	  | contents of B are zero.
	    |	       |      | 	  |
JUMP IF     |	JMG    |  6   | A	B | Transfer control to add. A if
GREATER     |	       |      | 	  | contents of B are greater than zero
	    |	       |      | 	  |
DECREMENT:  |	DJZ    |  7   | A	B | Subtract 1 from contents of add. B
JUMP IF ZERO|	       |      | 	  | and transfer control to add. A if
	    |	       |      | 	  | contents of add. B are then zero.
	    |	       |      | 	  |
COMPARE	    |	CMP    |  8   | A	B | Compare contents of add. A and B;
	    |	       |      | 	  | if they are unequal, skip the
	    |	       |      | 	  | next instruction.
	    |	       |      | 	  |
DATA        |	DAT    |  0   | 	B | A nonexecutable statement;
STATEMENT   |	       |      | 	  | B is the data value.
	    |	       |      | 	  |

Addressing modes:	IMMEDIATE	#	(Refers to a numerical
						constant.)

			DIRECT			(Refers to a RELATIVE
						memory location at this
						ABSOLUTE offset.)

			INDIRECT	@	(Refers to the address
						contained at the address
						this points to)

Notes:
	Basically, things are PC relative.  Ie. the instruction:
		MOV #0 @-2 takes the value of 2 subtracted from PC counter
(@-2), takes the value stored there (Which I believe has to be stored as
a DAT statement, but I don't know for sure), and uses this as an offset
from THAT location.  It then takes this final location, and stores the
value of zero there (#0). 

	Direct addressing works as follows:
		MOV	0	1
	Takes the value of the address at the PC ( ie. PC + 0, or PC(0))
and stores it at the next memory location (ie PC + 1, or PC(1)).  Since
a single addressable memory location stores an ENTIRE instruction
including arguments (ie.  "MOV	0  1" can be stored completely at memory
location 1, and not spread out over locations 1,2 and 3, etc.), this
effectively makes a "Rogue" program that copies itself to the next
higher address, then transfers control to the next higher address, only
to copy itself again, ad infinitum...  This will go on forever (assuming
another program doesn't stop it), because CoreWar's memory is a 'loop',
ie. the very last location in memory is also equal to the very first
location in memory (0), and therefore has no logical "End".  Memory
location 8000, in a memory bank containg exactly 8000 "cells", becomes
address zero.  Address 8001 becomes address 1, and so on.
	That's the quick summary... ask me (or the Net) about anything
else you might need cleared.  It would be nice to find some more
programs, or organize a contest...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
				Chad 'The_Walrus' Netzer -> AmigaManiac++

"Amiga -- The computer for the BEST of us..."   - Gary Heffelfinger
			       ^^^^
				|_____ Let's put this one outside
Apple's H.Q.'s, huh? :-)