From: durham@cup.portal.com (Mark Allen Durham) Subject: rec.games.corewar Answers to Frequently Asked Questions Message-ID: <66977@cup.portal.com> Date: Thu, 1 Oct 92 03:50:22 PDT These are the Frequently Asked Questions (and answers) from rec.games.corewar as compiled by Mark A. Durham (durham@cup.portal.com). Last Update: September 25, 1992 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. What is the ICWS? 5. What is TCWN? 6. How do I join? 7. Are back issues of TCWNs available? 8. What is the EBS? 9. Where are the Core War archives? 10. Where can I find a Core War system for . . . ? 11. I do not have ftp. How do I get all of this great stuff? 12. I do not have access to Usenet. How do I post and receive news? 13. When is the next tournament? 14. What is KOTH? How do I enter? 15. Other questions? --------------------------------------------------------------------- Q1: What is Core War? A1: 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 of the opposing programs to terminate, leaving your program in sole possesion of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q2: Is it "Core War" or "Core Wars"? A2: 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. ---------------------------------------------------------------------- Q3: Where can I find more information about Core War? A3: 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 an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 --------------------------------------------------------------------- Q4: What is the ICWS? A4: About one year after Core War first appeared in Sci-Am, 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). --------------------------------------------------------------------- Q5: What is TCWN? A5: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q6: How do I join? A6: For more information about joining the ICWS (which includes a subscription to TCWN), contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current dues are $15.00 in US currency. If you wish to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please send it to me at Mark A. Durham 18 Honeysuckle Terrace Spartanburg, SC 29307-3760 email: durham@cup.portal.com ---------------------------------------------------------------------- Q7: Are back issues of TCWN available? A7: Back issues of the TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 or contact William R. Buckley at xwbuckley@fullerton.edu. Prices are unknown at this time, but should be around $5.00 (the original cover price). More recent issues can be found on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q8: What is the EBS? A8: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament will be entered into the annual ICWS tournament. Now that rec.games.corewar has been created, the EBS has moved its business to the newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. Contact me if you are interested in helping serve the EBS. ---------------------------------------------------------------------- A9: Where is the Core War archive? Q9: 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 soda.berkeley.edu (128.32.131.179) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. ---------------------------------------------------------------------- Q10: Where can I find a Core War system for . . . ? A10: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are Unix X-Window, IBM PC-compatible (sorry, no systems specifically designed for MS-Windows yet), Macintosh, and Amiga Core War systems available there. 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 soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Please post or email to me any review of any Core War system you have tried out so that others may learn from your experience. ---------------------------------------------------------------------- Q11: I do not have ftp. How do I get all of this great stuff? A11: There is an ftp email server at FTPMAIL@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q12: I do not have access to Usenet. How do I post and receive news? A12: There is a Usenet email server. To subscribe to rec.games.corewar, send a message with a subject and body text consisting solely of "subscribe" (without the quotes) to rec-games-corewar-request@ucbvax.berkeley.edu. To unsubscribe, simply change the message to "unsubscribe". You can post to rec.games.corewar by sending your message to rec-games-corewar@ucbvax.berkeley.edu. You can subscribe and post to other Usenet groups in the same manner as described here for rec.games.corewar. Just remember to substitute "-" for "." in the newsgroup names. ---------------------------------------------------------------------- Q13: When is the next tournament? A13: The 1992 Annual ICWS tournament will be held December 15th, 1992. The rules are currently ICWS'88, core size of 8192, maximum number of processes per warrior of 8000, and ties declared after 100 000 cycles. To enter you must be a member of the International Core War Society or successfully participate in one of the Branch Section preliminary tournaments ("successfully" meaning finish in the top five/ten [see below]). Valid entries should be sent to Jon Newman either via email to jonn@microsoft.com of via mail on 3.5" disk (800K Mac or 720K IBM), 5.25" disk (720K IBM or 1.2MB IBM), or printed. Disk entries should be in a simple ASCII text format and on virus-free disks. ICWS Members may submit one entry or two entries if in electronic form. Branch Sections may submit five entries, or ten if in electronic form. Entries are limited to 50 instructions, 300 if in electronic form. No scatter loading will be supported (instructions must be contiguous). All entries become public domain on submission. The ICWS will keep them confidential until after the tournament has been completed. The EBS will hold its preliminary tournament November 15th, 1992. The EBS is open to all persons with access to electronic mail. Please limit submissions to two unique entries. Send submissions to durham@cup.portal.com and clearly indicate their purpose (i.e. ;For November 15th, 1992 EBS preliminary tournament) as well as author and name. ---------------------------------------------------------------------- Q14: What is KOTH? How do I enter? A14: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email provided by William Shubert . You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". If your program finished in the top twenty, it will remain on the hill until such time as it finishes twenty-first against another challenger, at which time it "falls off" the hill. Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" 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. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, 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 20 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 20 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. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. Max entry length: 100 instructions Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. 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 Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. - A tie is not declared until 150,000 cycles per program have elapsed. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by email from William Shubert. Write to him at for a copy or get it by anonymous FTP from soda.berkeley.edu in the pub/corewar/systems directory. ---------------------------------------------------------------------- Q15: Other questions? A15: Just ask. Either ask in the newsgroup or send your question to me at durham@cup.portal.com. I will do my best to answer your question or put you in touch with someone who can. Mark A. Durham MAD From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: DAT 0, how? Message-ID: Date: Thu, 1 Oct 1992 11:56:27 GMT I have a problem with the DAT 0 instruction: In MARS 4.0 the default memory contents are DAT 0,0 's. However, DAT 0,0 will compile to DAT #0,0 making it impossible for my CMP-scanner to avoid hitting itself. (CMP differs between the two intructions.) What is the default memory contents in KoTH? It can't be DAT 0,0 since this is not a valid instruction according to the KoTH daemon. Both MARS and KoTH claim to be fully ICWS'88 compatible, so this smells like a ompatibility problem to me... Anders Ivner. From: durham@cup.portal.com (Mark Allen Durham) Subject: EBS Tournament Message-ID: <67050@cup.portal.com> Date: Fri, 2 Oct 92 03:29:12 PDT This meeting of the EBS will come to order: The EBS is the Electronic Branch Section of the International Core War Society. Basically, if you have access to email, then you are a member of the EBS. Our immediate order of business is to determine how to run our tournament to determine the warriors we will be sending to the annual ICWS tournament. Our current options include: 1. Run an isolated tournament specifically for choosing finalists. Warriors would be submitted via email to the tournament coordinator on or before November 15, 1992. This is what we have done in the past. 2. Use the top ten warriors on the KotH hill as of midnight, November 15, 1992. I would like to hear which of these two options you support and suggestions for other ways to run the tournament. Other business: The EBS standards committee is continuing to work on a draft of a new standard for possible adoption by the ICWS in 1994. The EBS needs to establish a less ad-hoc way of conducting its business. To that end, volunteers with relatively permanent email addresses and an idea of what it is they can do for the EBS are encouraged to contact me. The ultimate goal is to write a constitution and have a vote as to whether to adopt it or not. Upcoming dates of interest: November 1, 1992: The first anniversary of rec.games.corewar. November 15, 1992: The EBS tournament. December 15, 1992: The ICWS tournament. Mark A. Durham MAD From: durham@cup.portal.com (Mark Allen Durham) Subject: RE: DAT 0, 0 vs DAT #0, #0 Message-ID: <67052@cup.portal.com> Date: Fri, 2 Oct 92 04:00:40 PDT RE: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? Under ICWS'88 rules, core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 and strictly compliant assemblers (such as KotH) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. The MADgic Core assembler - ASR - is not strictly compliant in that it allows all grammatically-correct instructions and does not flag any so called "illegal" instructions. It is left up to the programmer not to use illegal instructions when developing code for KotH or ICWS tournaments. On the other hand, if you want to experiment with MOV #a, #b you can do so. This feature merely reflects my bias against illegal instructions. So the question is "How to compare instructions to see if one is empty core?". The answer is, most likely the instruction before your first instruction and/or the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparisons. In fact, in KotH, if the number of instructions in your program is N, all of the instructions from N to 99 (relative to your first instruction at location 0) are guaranteed to be DAT 0, 0 at the beginning of the battle. This is because KotH allots 100 instructions to your warrior, whether you use all 100 or not, and guarantees warriors will not overlap. Mark A. Durham MAD From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: EBS Tournament Message-ID: <1992Oct2.122007.6645@oucsace.cs.ohiou.edu> Date: 2 Oct 92 12:20:07 GMT In article <67050@cup.portal.com> durham@cup.portal.com (Mark Allen Durham) writes: > >1. Run an isolated tournament specifically for choosing finalists. > Warriors would be submitted via email to the tournament coordinator on > or before November 15, 1992. This is what we have done in the past. > >2. Use the top ten warriors on the KotH hill as of midnight, November 15, > 1992. I am in favor of the first choice. I see the problem with the second choice is that there are some people who are on KotH more than once, and in many cases, more than twice... I think a tournament where everybody has a fair shot at the top ten would be idea. I just know that people who have more than 2 warriors in KotH just doesn't give anybody else a fair chance at it as well. Scott Adkins sadkins@ohiou.edu -- Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: pk6811s@acad.drake.edu Subject: Re: EBS Tournament Message-ID: <1992Oct2.110213.1@acad.drake.edu> Date: Fri, 2 Oct 1992 17:02:13 GMT >> >>1. Run an isolated tournament specifically for choosing finalists. >> Warriors would be submitted via email to the tournament coordinator on >> or before November 15, 1992. This is what we have done in the past. >> >>2. Use the top ten warriors on the KotH hill as of midnight, November 15, >> 1992. > > I suggest we take suggestion #2, only move the date back to November 10. > That way I have time to submit any warriors that didn't make it, but > which might perform better in a larger tournament. > >Paul Kline From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: EBS Tournament Message-ID: Date: Fri, 2 Oct 1992 20:23:22 GMT I don't know how reliable the result is if you run an internal tournament, but the KotH results are far too arbitrary to be reliable for any but maybe the top five warriors. My 'X-ray 2.0' has been bouncing up and down between positions 8 to 20 the last days. You can actually gain 10 positions if a warrior that you beat pushes one that beats you off the hill. Just my personsal opinion, ofcourse. Anders Ivner d91andiv@und.ida.lui.se From: wms@ssd.intel.com (William Shubert) Subject: Re: EBS Tournament Message-ID: <1992Oct2.213330.28851@iWarp.intel.com> Date: Fri, 2 Oct 1992 21:33:30 GMT I think that it was MAD who suggested: >1. Run an isolated tournament specifically for choosing finalists. > Warriors would be submitted via email to the tournament coordinator on > or before November 15, 1992. This is what we have done in the past. > >2. Use the top ten warriors on the KotH hill as of midnight, November 15, > 1992. Option (2) only makes sense if KotH is modified to a core size of 8192. I'd be willing to do this temporarily (or maybe set up a third hill for this purpose). It'd be easy since core size can be specified at the command line of KotH. -Bill (wms@iwarp.intel.com) From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) Subject: Re: EBS Tournament Message-ID: <69775@hydra.gatech.EDU> Date: 2 Oct 92 21:34:07 GMT In article <67050@cup.portal.com> durham@cup.portal.com (Mark Allen Durham) writes: >1. Run an isolated tournament specifically for choosing finalists. > Warriors would be submitted via email to the tournament coordinator on > or before November 15, 1992. This is what we have done in the past. > >2. Use the top ten warriors on the KotH hill as of midnight, November 15, > 1992. I vote in favor of the first choice. The problem with #2 is that you can see who is on the hill before you submit your entry. You could enter a program designed to make your program score well and other programs score lower. I also agree that you sould be limited to two programs. -- Wayne Edward Sheppard Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b Internet: gt7804b@prism.gatech.edu Subject: Re: KOTH Message-ID: <1992Oct4.185036.2197@drycas.club.cc.cmu.edu> From: KENT@dirac.physics.jmu.edu (Kent Peterson) Date: 4 Oct 92 18:50:35 -0500 In <1992Oct4.194532.25228@athena.mit.edu> ama@athena.mit.edu writes: > Hi everybody! I just got started on corewar. > > Is it okay to use SPL 0 commands, and other similar tactics, in KOTH? The 8000 > process limit per program makes this tactic very powerful. How about in ICWS > tourneys? Darn right. In CoreWar, "no holds barred" is the only rule applicable to these things. SPL 0,0; JMP 0,0; JMP @0,x; etc. are all common bombs used by programs on the hill. The only "forbidden" instructions are those the assembler can't handle. Kent Peterson From: ama@athena.mit.edu (Albert Ma) Subject: KOTH Message-ID: <1992Oct4.194532.25228@athena.mit.edu> Date: Sun, 4 Oct 1992 19:45:32 GMT Hi everybody! I just got started on corewar. Is it okay to use SPL 0 commands, and other similar tactics, in KOTH? The 8000 process limit per program makes this tactic very powerful. How about in ICWS tourneys? From: t-jcisek@microsoft.com (Julius Cisek) Subject: Re: EBS Tournament Message-ID: <1992Oct05.062254.10223@microsoft.com> Date: 05 Oct 92 06:22:54 GMT In article <67050@cup.portal.com> durham@cup.portal.com (Mark Allen Durham) writes: >This meeting of the EBS will come to order: > >The EBS is the Electronic Branch Section of the International Core War >Society. Basically, if you have access to email, then you are a member of >the EBS. > >Our immediate order of business is to determine how to run our tournament >to determine the warriors we will be sending to the annual ICWS tournament. > >Our current options include: > >1. Run an isolated tournament specifically for choosing finalists. > Warriors would be submitted via email to the tournament coordinator on > or before November 15, 1992. This is what we have done in the past. > >2. Use the top ten warriors on the KotH hill as of midnight, November 15, > 1992. It really ought to be 1. We all know that Koth standings mean very little. The current trend, not the quality of the warrior, would decide the winners. What kind of tournament would you be thinking of running? A KotH type thing with unlimited players? Or something more like the old ICWS tournaments (which in my opinion were way too random)? Jules -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: ubacw00@ucl.ac.uk (Mick Farmer) Subject: Rules and Memory Sizes Message-ID: <1992Oct05.135140.27571@bas-a.bcc.ac.uk> Date: 5 Oct 92 13:51:40 GMT Hi, We use core wars to teach our postgraduate students about machine code programming. This year, we're thinking of setting the memory bound to 10000, so that arithmetic is easier. Has anyone any views on this? Finally, could someone let me have a copy of the latest rules, especially what instruction set to use. Regards, Mick From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: Rules and Memory Sizes Message-ID: Date: Mon, 5 Oct 1992 16:53:18 GMT In article <1992Oct05.135140.27571@bas-a.bcc.ac.uk> ubacw00@ucl.ac.uk (Mick Farmer) writes: We use core wars to teach our postgraduate students about machine code programming. This year, we're thinking of setting the memory bound to 10000, so that arithmetic is easier. Has anyone any views on this? Wouldn't an even power of two, like 8192, make more sense? Not that CW supports any bitwise boolean operations, but just to relate it to standard memory sizes in computers. Anders Ivner (I wish I had scheduled time for core wars! :-) From: AZNXS@ASUACAD.BITNET Subject: Re: EBS Tournament Message-ID: <92279.132548AZNXS@ASUACAD.BITNET> Date: 5 Oct 92 20:25:48 GMT I would like to recommend the last eliminating system for the tournament. I think it's very usefull if there are many warrior in the tournament. The system is the following: Suppose we have n warrior. Depending on n every warrior battles with let say n/3 to n-1 other warriors. This gives us an order. In the next step the worst (could be more) warrior is eliminated. And so on. Of course in the next step we can use the results from the previus step but the scores against the eliminated warriors does not count. In this way the k-th warrior is always wors than the avarage first k-1 warrior especially #1 beats #2. Nandor. From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: EBS Tournament Message-ID: <1992Oct5.170908@IASTATE.EDU> Date: Mon, 5 Oct 1992 22:09:08 GMT In article <92279.132548AZNXS@ASUACAD.BITNET>, writes: > I would like to recommend the last eliminating system for the tournament. > I think it's very usefull if there are many warrior in the tournament. > The system is the following: Ideally, after competition between all pars of programs is done, the score matrix should be constructed, and then added to weighted powers of itself. This way, if program A beats B, and B beats C, then A gets some indirect points for beating C, even if it didn't do well against C directly. Of course you need near unlimited computer resources to run a tournament that size. :) | __L__ ******************************* -|- ___ * Warren Kurt vonRoeschlaub * | | o | * kv07@iastate.edu * |/ `---' * Iowa State University * /| ___ * Math Department * | |___| * 400 Carver Hall * | |___| * Ames, IA 50011 * J _____ ******************************* From: jonn@microsoft.com (Jon Newman) Subject: Re: Rules and Memory Sizes Message-ID: <1992Oct06.015709.7866@microsoft.com> Date: 06 Oct 92 01:57:09 GMT In article <1992Oct05.135140.27571@bas-a.bcc.ac.uk> you write: >Hi, > >We use core wars to teach our postgraduate students about >machine code programming. This year, we're thinking of >setting the memory bound to 10000, so that arithmetic is >easier. Has anyone any views on this? > >Finally, could someone let me have a copy of the latest >rules, especially what instruction set to use. > >Regards, > >Mick Clearly, decimal arithmetic is easier for the writer of fighter programs, but more difficult and slower for the writer of Core War simulators. The old 8000 standard did have some advantages, not least a wide variety of divisors, but I don't see us moving off 2^^N standard coresizes. You can get the latest rules via FTP from the Core War Archive, read the FAQ. For a printed copy, send US$4 to me (check made out to Jon Newman) at Jon Newman Director, ICWS 13824 NE 87th Street Redmond, WA 98052-1959 -- jonn@microsoft.com This is not the official opinion of Microsoft Corporation. Bill Rules! From: durham@cup.portal.com (Mark Allen Durham) Subject: RE: EBS Tournament Message-ID: <67306@cup.portal.com> Date: Wed, 7 Oct 92 03:50:44 PDT The poll of "new tournament vs KotH" is running 2 to 1 in favor of running a new tournament specifically for choosing EBS finalists to advance to the ICWS annual tournament. There is a little variance in specific suggestions for how to handle the tournament, but nothing severe. So, here is how the tournament will be run. Entries should be sent to "durham@cup.portal.com" before November 15, 1992. I recommend that you write very verbose comments so that there can be no mistaking your intentions for the program. Example: ; Program Name ; EBS 1992 Qualifying Tournament Entry ; ; Program's Author ; Program's Author's Email address ; I am (or am not) an ICWS member ; ; Detailed description of program etc. Remember, your program can only be up to 300 contiguous instructions in length. (Instructions, not lines. You can have as many comments as you wish.) My assembler can handle any instruction format you throw at it, but I prefer that you seperate operands by a comma. I will accept up to two entries per person. I will give preference to advancing those entries from people who are NOT members of the ICWS or its branch sections (other than the EBS). Members of the ICWS can submit their progams directly to Jon Newman before December 15th to enter them in the ICWS tournament. Reasons for entering the EBS tournament even though you are a member of the ICWS include seeing how you stack up to the competition prior to the tournament. Last year we had fewer than the allowed ten entries. I know we can do much better this year. The winner of the EBS tournament last year went on to win the ICWS tournament. I know we can repeat that success. The format for the tournament will be a round-robin of several rounds, each round with a randomly chosen separation. The separation will be no smaller than the largest submission in order to guarantee programs do not overlap. The scoring will be the standard 3 points per win, 1 point per tie, and 0 points for a loss. Some people have suggested weighting the results. I doubt that will be necessary or have any noticable effect. In any case, I am certain that all will consider the results of the tournament "fair". Mark A. Durham MAD From: durham@cup.portal.com (Mark Allen Durham) Subject: Best bombing step sizes Message-ID: <67307@cup.portal.com> Date: Wed, 7 Oct 92 03:52:50 PDT I am posting some source code which may help some people determine "good" step-sizes for bombing. This is only my second iteration on this program. I plan to continue to improve its performance and expand its scope so that it can handle multiple step-size scenarios too. My first thought is to improve the search-for-the-appropriate-block-of-free-memory routine. Until then, I need someone with some "heavy iron" (aka a fast computer) to run this program with arguments of 8000 and 8000 for me, and then post or email the results back to me. Otherwise, it could be 1993 before the program finishes! Thanks, and enjoy the program. Mark A. Durham MAD -------------------------------------------------------------------------- /***************************************/ /* */ /* Modula Bomber */ /* */ /* Determines the step-size which will */ /* produce the minimum sum maximum */ /* contiguous bomb-free space. Helps */ /* determine optimum bombing strategy. */ /* */ /* Directions for use: */ /* After compiling and linking */ /* (ANSI C), enter: */ /* */ /* progname coresize bombs */ /* */ /* on the command line. "progname" */ /* is the name you give to the */ /* executable (example: mb), */ /* "coresize" is a number */ /* representing the size of the */ /* core (example: 8000), and */ /* "bombs" is the number of bombs */ /* to drop for each step-size */ /* (example: 100). */ /* */ /* Mark A. Durham */ /* October 4, 1992 */ /***************************************/ /***************************************/ /* */ /* Include Files */ /* */ /***************************************/ #include #include /***************************************/ /* */ /* Structures */ /* */ /***************************************/ struct list { /* Excuse the mangling of terminology. */ int from; /* The idea is to keep a table of bomb */ int to; /* free areas linked together by both */ int size; /* starting location and size. The */ int last; /* "next" field doubles as a link for */ int next; /* unused elements of the table. */ int lastsize; int nextsize; }; /***************************************/ /* */ /* Global Variables */ /* */ /***************************************/ int FirstFree; /* Largest unbombed block of memory. */ /***************************************/ /* */ /* Functions */ /* */ /***************************************/ void delete( /* Deletes an element from the table. */ struct list *core, int i ) { core[core[i].lastsize].nextsize = core[i].nextsize; core[core[i].last].next = core[i].next; core[core[i].nextsize].lastsize = core[i].lastsize; core[core[i].next].last = core[i].last; core[i].next = FirstFree; FirstFree = i; } void insert( /* Inserts a new element into the */ struct list *core, /* table. */ struct list *node ) { int i; int j; i = FirstFree; FirstFree = core[i].next; core[i].from = node->from; core[i].to = node->to; core[i].size = node->size; for (j = 0; core[i].from > core[j].from; j = core[j].next); core[i].next = j; core[i].last = core[j].last; core[j].last = i; core[core[i].last].next = i; for (j = 2; core[i].size < core[j].size; j = core[j].nextsize); core[i].nextsize = j; core[i].lastsize = core[j].lastsize; core[j].lastsize = i; core[core[i].lastsize].nextsize = i; } void hit( /* Bomb core. */ struct list *core, int bomb ) { int i; struct list left; struct list right; for (i = 0; bomb > core[i].to; i = core[i].next); /* Find node. */ if (bomb >= core[i].from) { left.from = core[i].from; /* node exists */ left.to = bomb - 1; left.size = bomb - core[i].from; right.from = bomb + 1; right.to = core[i].to; right.size = core[i].to - bomb; delete(core,i); if (left.size > 0) { insert(core,&left); }; if (right.size > 0) { insert(core,&right); }; }; } void InitList( /* Initialize table for empty core. */ struct list *core, int maxsize ) { int i; core[0].from = -1; /* core[0] is guaranteed to be smaller */ core[0].to = -1; /* than any other element and first in */ core[0].size = 0; /* the list. */ core[0].last = -1; core[0].next = 1; core[0].lastsize = 1; core[0].nextsize = -1; core[1].from = 0; /* core[1] is the initially empty core */ core[1].to = (maxsize-1); core[1].size = maxsize; core[1].last = 0; core[1].next = 2; core[1].lastsize = 2; core[1].nextsize = 0; core[2].from = maxsize; /* core[2] is guaranteed to be larger */ core[2].to = 2*maxsize + 1;/* than any other element and last in */ core[2].size = maxsize + 1;/* the list. core[0] and core[2] both */ core[2].last = 1; /* greatly simplify deletion and */ core[2].next = -1; /* insertion by eliminating special */ core[2].lastsize = -1; /* cases. */ core[2].nextsize = 1; for (i=3; i<(maxsize+1); i++) { core[i].next = i+1; /* This initializes the free element */ }; /* list. */ core[(maxsize+1)].next = -1; FirstFree = 3; /* FirstFree always indicates the */ } /* largest block of unbombed core. */ void main( /* Main program code. */ int argc, char *argv[] ) { int bomb; /* Location to bomb. */ struct list *core; /* Table of unbombed blocks of core. */ int done; /* Largest unbombed block of core when done. */ int i; /* Bomb counter. */ int freespacesum; /* Sum of largest unbombed core blocks.*/ int maxsize; /* core size. */ int mindone; /* "done" for minimum "freespacesum". */ int minfree; /* minimum "freespacesum". */ int minstep; /* step-size fo mimimum "freespacesum".*/ int stepsize; /* step-size for bombing counter. */ int totalbombs; /* total number of bombs for each step.*/ if (argc > 1) { maxsize = atoi(argv[1]); } else { printf("Enter core size: "); scanf("%d",&maxsize); }; if (argc > 2) { totalbombs = atoi(argv[2]); } else { totalbombs = maxsize; }; core = (struct list *)calloc((maxsize+2),sizeof(struct list)); minfree = maxsize * maxsize; minstep = 0; for (stepsize = 1; stepsize < (maxsize/2); stepsize++) { InitList(core,maxsize); bomb = 0; freespacesum = 0; for (i = 0; i < totalbombs; i++) { hit(core,bomb); freespacesum += core[core[2].nextsize].size; bomb = (bomb + stepsize) % maxsize; }; done = core[core[2].nextsize].size; if (freespacesum < minfree) { minfree = freespacesum; minstep = stepsize; mindone = done; }; printf("%d\t%d\t%d\n",stepsize,done,freespacesum); }; printf("\nMinimum free space = %d for step size %d\n",minfree,minstep); printf("\tFree space remaining = %d\n\n",mindone); free(core); } From: PEPPER@stl550.span.nasa.gov Subject: subscribe Message-ID: <9210071649.AA23778@mx.nsi.nasa.gov> Date: 7 Oct 92 16:49:38 GMT subscribe From: pk6811s@acad.drake.edu Subject: Scanner Ideas Message-ID: <1992Oct7.164836.1@acad.drake.edu> Date: Wed, 7 Oct 1992 22:48:36 GMT Well, looks like my prediction about multiple-tactic programs is coming true with a vengeance. Both my high-tech bombers, Emerald and ExtraExtra, were driven off the hill, and Twill also. More people are writing stone-paper combinations successfully and venerable Flash Paper is showing definite signs of age. The unfortunate side effect of stone-paper combos is they have driven off their friends the stones, thus allowing scanners to rule the hill. I would be curious to know if anyone is using bombers modeled after Emerald or ExtraExtra as described in my article 'stone.better.txt' on soda.berkely. Much as I hate to encourage scanners, they do seem to be in the limelight, and there are three ideas I would like to share. First Idea: ---------- To make a cmp-scanner that does not use a fixed separation between the a- and b-fields, ala Charon and No Mucking About (and all the others I've seen). This would look like: next add inc,scan scan cmp 0,0 slt #11, scan jmp next attack mov bomb,@scan mov #scan2-scan,scan2 sub scan,scan2 mov bomb, @scan2 jmp next scan2 dat #0 inc dat #1003,#0-1003 bomb spl 0 If you follow this, you will see that the a and b operands of 'scan' will always total 8000 (or zero), so subtracting b from zero gives a. Actually you subtract b from #scan2-scan to allow for the relative positions of scan and scan2. Unfortunately, Core 1.1 for the Mac does not check for negative operands with the SUB command (at least not for both operands), so I can't get this to work reliably. Second Idea: ------------ A multi-processing scanner, with a large number of syncronized processes. One requirement for a scanner-replicator combo is that the scanner must grow processes, or it will effectively cease to function as the replicators multiply. Here's part of one that I have: ptr1 dat #-100 ptr2 dat #-100 bomb spl 0 start spl 1, Date: 8 Oct 92 12:26:10 GMT Here is my program SNAKE. All of my vampiric bombers kept taking a beating from this new class of bombers that claim to bomb the core at 150% of c. But a decrement doesn't kill a program. I designed all of the B-fields so that if any one is decremented, the bombing routine keeps functioning. I would really be interested in any other programs that use this tactic. ;redcode verbose ;name SNAKE ;author WAYNE SHEPPARD ;strategy PITBOMBER ;strategy now with decrement protection ;strategy and extra redundancy spl start ;hit here start2 spl 0,pitbomb2 ;One of these three statments mov @0,@pitbomb2 ;can be decremented and the sub offset2,@-1 ;bombing goes on jmp -2 dat #0,#0 ;hit here dat #0,#0 pbdup2 jmp pit-3,3 ;duplicate pitbomb pitbomb2 jmp pit-2,2 offset2 dat #-115,#115 ;If this is decremented, we are out of action dat #0,#0 ;hit here start spl 0,pitbomb ;making myself larger for scanners mov @0,@pitbomb ;but helps against bombers sub offset,@-1 jmp -2 dat #0,#0 ;hit here offset dat #115,#-115 dat #0,#start2 ;duplicate bomb bomb dat #0,#start2 dat #0,#0 dat #0,#0 ;hit here pbdup jmp pit+11,-11 ;duplicate pitbomb pitbomb jmp pit+12,-12 pit mov @0, Date: 8 Oct 92 18:29:34 GMT subscribe From: pk6811s@acad.drake.edu Subject: Re: Decrement Protection Message-ID: <1992Oct8.141307.1@acad.drake.edu> Date: Thu, 8 Oct 1992 20:13:07 GMT > > Here is my program SNAKE. All of my vampiric bombers kept taking > a beating from this new class of bombers that claim to bomb > the core at 150% of c. But a decrement doesn't kill a program. > I designed all of the B-fields so that if any one is decremented, > the bombing routine keeps functioning. > > I would really be interested in any other programs that use > this tactic. AhHa! So that's why Snake does so well against my bombers. I wondered if people would catch on to this. It's easy to protect against single decrements on b-fields. Here's how I do it in Eclipse: Lines marked ** function normally when decremented (once). ;redcode ;name Eclipse V2.0 ;kill Eclipse ;author P.Kline ;strategy bscan, 2-dwarf, 1-dwarf bomb2 mov -1,<0 ptr mov bomb1,<1-131 next add #121,@2 ; ** jmz next,@ptr mov bomb2,@ptr jmn ptr,@-1 ; ** bomb1 spl 0,10 ; ** mov cnt+1, Date: Thu, 8 Oct 92 21:12:21 PDT The Summer 1992 edition of The Core War Newsletter has been restored on soda.berkeley.edu. Honest! Thanks to those who pointed out the previous file was of zero length. It's not my fault. Honest! Mark (Honest!) A. Durham MAD durham@cup.portal.com From: durham@cup.portal.com (Mark Allen Durham) Subject: RE: Best Bombing Step Sizes Message-ID: <67408@cup.portal.com> Date: Thu, 8 Oct 92 22:59:46 PDT Much thanks to Bas de Bakker and Pete Orelup for running my program and sending back the results. For the curious among you, the "best" step size for bombing a core of 8000 elements 8000 times is: 3039 or 3359 The sum of maximum bomb-free space is 101410 for each. Unfortunately, 3039 and 8000 have no common divisors and 3359 is prime, therefore a bomber using either of these step-sizes would necessarily bomb itself eventually. Here are the best finishers for the next ten sizes of free space: End Freespace Step-size Sum of Max Freespace ------------- ---------- -------------------- 0 3039/3359 101410 1 2234/3094 101856 2 none 3 3044/3364 111160 4 2365/3315 114390 5 none 6 none 7 2376/2936 133360 8 none 9 2430/2930 147380 10 none Mark A. Durham MAD durham@cup.portal.com Date: Thursday, 8 Oct 1992 23:22:15 MST From: Message-ID: <92282.232215ASMQK@ASUACAD.BITNET> Subject: Re: Best bombing step sizes Asking for the parameter 8000 8000 suggest that the coresize on the tournament is going to be 8000. Am I right? I'm posting the "optima-type" constants. (just in case the de. is: the constans 'a' that gives maximum average distans s(a) from the previously bombed locations. For example s(4)=4. coresize 8000: a s(a) mod 1 3039 5.17 mod 2 2234 9.45 mod 4 3044 17.11 mod 5 2365 21.13 In the less than 100 interval 73 3.36 98 6.50 76 10.07 95 12.57 Coresize 8192 mod 1 3455 5.10 mod 2 3438 9.51 mod 4 3164 10.07 less than 100 71 3.44 46 4.77 76 10.07 Na'ndor Sieben From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: Scanner Ideas Message-ID: <1992Oct9.030336.399@vlsi.polymtl.ca> Date: Fri, 9 Oct 1992 03:03:36 GMT pk6811s@acad.drake.edu writes: : I would be curious to know if anyone is using bombers modeled after : Emerald or ExtraExtra as described in my article 'stone.better.txt' on : soda.berkely. : Here's some program I wrote that used multiple bombs: ;redcode verbose ;name Confetti ;author Pierre Baillargeon ;strategy v0.99: Leave stuff everywhere. ;strategy v1.00: Fastest clear core. ;strategy v1.10: Copy ourselves away. ;strategy v1.20: Change step and kill method. ;strategy v1.22: One instruction smaller. ;strategy v1.30: Now affect 3 locations / 4 cycles. ;strategy v2.00: Start mod-5, decrement, end core-clear. ;strategy v2.10: Smaller. ;strategy v2.20: Self-splitting, mod-random, mutagenizing. ;kill Confetti dist1 equ -15 ; mod-5 but not 10 dist2 equ -70+1 ; mod-10 but not 20 many spl 0, Date: Fri, 9 Oct 92 05:46:29 GMT What is "stone" ? Nowadays everybody keeps talking about it, but I've never seen the code for it, even though it seems to be quite basic... Is it just another name for "Dwarf" or what ? Code would be nice, but plain description is also OK. Thank YOU for helping me out on this one. ;-) snh. From: gt6525c@prism.gatech.EDU (Damon Gallaty) Subject: Types of bombs Message-ID: <70624@hydra.gatech.EDU> Date: 9 Oct 92 14:38:32 GMT I was just curious about people's ideas on bombing. If you're going to bomb someone, why use decrementing, jmp's to slave pits, and such? WHy not just bomb a typical DAT and destroy them right there? It seems to me that keeping them alive longer just prolongs the battle and gives them a slightly better chance to survive. The only use I see for using anything but DAT's is perhaps for bombing someone's data area with decrements, to try to make them destroy themselves. Perhaps I am missing something. Anybody have any helpful insight on this? - Damon Gallaty -- "Have you ever danced with the Devil by the pale moonlight? I ask that of all my prey. I just like the sound of it..." - the Joker ************************************************************************ Damon Gallaty E-mail: gt6525c@prism.gatech.edu From: pk6811s@acad.drake.edu Subject: Re: Types of bombs Message-ID: <1992Oct9.132426.1@acad.drake.edu> Date: Fri, 9 Oct 1992 19:24:26 GMT In article <70624@hydra.gatech.EDU>, gt6525c@prism.gatech.EDU (Damon Gallaty) writes: (Parts of this note are taken from my article "stone.better.txt" on soda.berkely.) > I was just curious about people's ideas on bombing. If you're going to > bomb someone, why use decrementing, jmp's to slave pits, and such? WHy > not just bomb a typical DAT and destroy them right there? It seems > . . . > > - Damon Gallaty > Ok Damon, good question that many new players ask. First, jmps to slave pits or stun-bombs are needed to overcome replicating opponents, like mice or 'paper'. If you only bomb with dat-zero, you'll lose 80 or 90% of your battles against replicators, you just can't catch them all (at the same time). Example stun bombs: ------- spl 0 ------- spl -1 ------- spl 0 <- recommend this one jmp -1 ------- spl 0,8 <- sometimes fought off by paper mov -1,<-1 ------- spl -1,0 <- sometimes reaches out and grabs you mov -1,<-1 <- but good against paper-colonies ------- (Another term is 'carpet bombing' where you lay down a series of spl 0's) Second, decrements are a free extension of the bombing process, they cost you nothing and hopefully give your opponent fits. Here's an example of an old 'stone' type bomber: ;name Twill ;author Andy Pierce offset dat #-5138,#5138 start spl 0,0 add offset,1 mov <0,0 jmp -2,0 end start Now, just because it's old-fashioned, doesn't mean it's not effective. Twill used to hang around the top of the hill most of the time, because it beat up on all the scanners out there. Anyway, you'll note that Twill bombs one location with a three-instruction loop - a real honest bomb that will probably kill whatever is there. Also, by using the predecrement form on the a-operand, Twill decrements another location. Thus Twill 'trashes' two locations with three instructions. (If you didn't know before, the add instruction adds both the a- and b-operands.) The two important considerations for bombers are pattern and throw-weight. Twill has a excellent pattern, checkering core rapidly then filling in the blanks. Twill also has good throw weight, bombing one location and decrementing one every three instructions, or 66% of c. Now consider this fighter: ;redcode ;name Emerald ;author P.Kline inc dat #-2045,#2045 emerald spl 0,100 stone mov Message-ID: <92283.225235AZNXS@ASUACAD.BITNET> Subject: Re: Best bombing step sizes It's very interesting. The minimal maximum bomb free constans are exactly the same as the "optima-type" constans. The question is why? Is there any algebrist out there to give a proof that this is true for any coresize? This result can be used inthe problem: How to display a fractal? More precisely in which order calculate the point of a fractal to get an idea of the picture as fast as possible. , Nandor Sieben From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Types of bombs Message-ID: <1992Oct10.005417.3404@oucsace.cs.ohiou.edu> Date: 10 Oct 92 00:54:17 GMT In article <70624@hydra.gatech.EDU> gt6525c@prism.gatech.EDU (Damon Gallaty) writes: >I was just curious about people's ideas on bombing. If you're going to >bomb someone, why use decrementing, jmp's to slave pits, and such? WHy >not just bomb a typical DAT and destroy them right there? It seems >to me that keeping them alive longer just prolongs the battle and >gives them a slightly better chance to survive. The only use I see >for using anything but DAT's is perhaps for bombing someone's data >area with decrements, to try to make them destroy themselves. Perhaps >I am missing something. Anybody have any helpful insight on this? I can think of a couple of reasons right off the bat... It is easy enough to bomb somebody, and hope they die... but keep in mind, they are also trying to survive. What the enemy programs do is split off a bunch of processes that search for the enemy and also watch each other's back. If one of them gets bomb, patch it up and maybe try to find out where that bomb came from... So, what you want to do as a programmer is to out-smart this strategy. One way to do it is to bomb using SPL statements instead of DAT's and then after a period of time of this type of bombing, switch over to the DAT type bombs. If the enemy executes the SPL instruction, then all of their processes, not just that one, will slow down... This means that the processes can't watch each other's backs as easily and as fast, and if they do detect a bomb, they can't react to it as fast. This will give you time to bomb the rest of the core and maybe squash all of the slow processes. Another type of program is the vampire slave bombers. You would bomb with JMP statements in hopes that the enemy will execute it and jump to one of your home-made bombing routines. Since the enemy will probably have lots of processes watching each others back, what would be the perfect weapon but to have one of its own processes searching and destroying its own brethren? And just as a safe guard, you would put a SPL 0 or something in the bombing routine to slow the enemy program down, the bombing process would pick up more speed as more processes get captured, and the other processes would get slower and slower, reacting very slowly to any pending attack. Yet another type of stategy is the decrement type attack. The basic idea here is to merely confuse the enemy program, and all of its processes so that it cannot see an oncoming attack, or to throw off the enemy attacks since you probably changed its bombing step and bombing destinations... You would attempt to modify the enemy program enough that it would just curl up and die on its own, without much work on your side. Unfortunately, this style of attack doesn't work very well, since you can confuse the enemy, but you could also by chance make it easier for the enemy to find you... Now-a-days, people are using decrements for other reasons as part of an attack strategy, and not as *the* attack strategy. Well, hope this helps. There are lots of reasons why a simple DAT type bombing program will not do the job. The basic idea is that the enemy knows you are looking for it. It may be looking for you, but it will be watching its own back as well. You must find a way to stop the whole enemy program at one time. Killing just one process is just like stirring up a hornets nest. What would happen if you got them angry... Stepping on one isn't the answer, but spraying them with Raid might be in the long run... ;-) Catch you later! Scott Adkins sadkins@ohiou.edu -- Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: schei@ph.und.ac.za Subject: Interested in Corewars but ClueLess Date: Mon, 12 Oct 1992 10:04:43 GMT Message-ID: Hello There, I find the concept of Corewars very interesting and would love to fiddle with a program of that nature. Can anyone point me in the direction of where I can get a copy of the core corewars program? And a FAQ (If it exists) as to how the rules can get implemeneted. Much Appreciated -Carl. From: wms@ssd.intel.com (William Shubert) Subject: KotH Standings Message-ID: <1992Oct12.203445.3991@iWarp.intel.com> Date: Mon, 12 Oct 1992 20:34:45 GMT Here they are: ICWS '88 hill: # %W/ %L/ %T Name Author Score Age 1 49/ 40/ 11 No Mucking About Campbell Fraser 159 576 2 48/ 42/ 11 Charon v7.0 J.Cisek & S.Strack 154 224 3 46/ 44/ 9 nandor sieben 148 363 4 38/ 28/ 34 Atomic Sheep c w blue 148 34 5 42/ 37/ 20 Pale Shears Matt Hastings 147 365 6 43/ 40/ 16 B-scanners live in vain Matt Hastings 146 558 7 43/ 40/ 17 Eclipse V3.0 P.Kline 146 47 8 31/ 21/ 47 Army 42 Anders Ivner 141 21 9 34/ 28/ 38 Flash Paper3.7 Matt Hastings 141 628 10 36/ 31/ 33 Chaff v2.8 Patrick Hunt 140 87 11 42/ 45/ 13 Sucker 4 Stefan Strack 140 829 12 42/ 44/ 15 Falling Leaf 1.21 Matt Hastings 139 714 13 38/ 36/ 26 Smooth Noodle Map 6 Matt Hastings 139 380 14 40/ 44/ 15 Twilight Pits 3 W. Mintardjo 136 66 15 39/ 42/ 19 SNAKE Wayne Sheppard 136 6 16 38/ 40/ 23 Icicles 2+ W. Mintardjo 135 7 17 41/ 46/ 13 testing RoadRunner S. Halvorsen 135 420 18 41/ 52/ 7 Orc c w blue 131 97 19 35/ 47/ 18 Emerald P.Kline 124 5 20 30/ 43/ 27 test (16) Unknown 116 1 X-Hill: # %W/ %L/ %T Name Author Score Age 1 54/ 22/ 24 Sonic Boom 1.0 Eric J. Schwertfeger 186 97 2 50/ 17/ 33 Sledge 1.3 Alex MacAulay 183 24 3 50/ 23/ 27 Scorpion 3.3 Alex MacAulay 176 77 4 32/ 16/ 52 El Papel Unknown 147 2 5 42/ 42/ 16 Loki 2.30 Eric J. Schwertfeger 143 135 6 40/ 39/ 21 Scylla and Charybdis V1.0 Jeff Berry 140 49 7 26/ 21/ 53 Edge 1.1 Alex MacAulay 131 78 8 22/ 14/ 64 Sigil Matt Hastings 130 150 9 34/ 41/ 25 Deep Green Sea Pierre Baillargeon 127 48 10 20/ 14/ 66 Time Machine 3.20 Pierre Baillargeon 127 20 11 34/ 45/ 21 Halberd 1.70 Eric J. Schwertfeger 124 26 12 22/ 21/ 58 LongWorm 1.2 Dan Nabutovsky 122 19 13 18/ 18/ 64 oozing mass Campbell Fraser 118 59 14 18/ 21/ 62 seething mass Campbell Fraser 115 170 15 16/ 19/ 65 Blind Leap1.1 Jonathan Wolf 112 236 16 17/ 22/ 60 Troll 2.1 Dan Nabutovsky 112 16 17 33/ 54/ 13 Fence Leaper-X 1.0 Jeff Raven 111 58 18 16/ 25/ 59 Skipsplit V1.2 Jeff Berry 106 66 19 12/ 21/ 67 Trap 3 Kent Peterson 103 9 20 12/ 33/ 55 Rats 3 Kent Peterson 92 1 As usual, then entry instructions are in the FAQ and available by mail from me. C Source code to KotH is available via anonymous FTP from soda.berkeley.edu. -Bill (wms@ssd.intel.com) From: tkimball@foghat.rutgers.edu (Timothy Kimball) Subject: WinCore project Message-ID: Date: 12 Oct 92 23:27:56 GMT Now that I am soon to find a C compiler, I am restarting my efforts to port CoreWar to Microsoft Windows. This project was originally (sp?) to be done in Pascal, but I needed something to learn C anyway. Until I get the compiler and start tinkering, it would be appreciated if I could get pseudocode for all the commands (new and old) and for the forms of number handling (preferably new). This would speed up the programming/debugging time as I would have an idea of what to write. Thanks, T. S. Kimball no .sig, but will soon . . . . From: bas@phys.uva.nl (Bas de Bakker) Subject: Re: Interested in Corewars but ClueLess Message-ID: Date: Tue, 13 Oct 1992 15:20:27 GMT >>>>> On Mon, 12 Oct 1992 10:04:43 GMT, schei@ph.und.ac.za said: s> I find the concept of Corewars very interesting and would love to s> fiddle with a program of that nature. Can anyone point me in the s> direction of where I can get a copy of the core corewars program? s> And a FAQ (If it exists) as to how the rules can get implemeneted. You should ftp to soda.berkeley.edu and browse in the /pub/corewar directory. If you cannot ftp, the standard advice is to send email to ftpmail@decwrl.dec.com with a message body of help, but the one time I tried this it was very slooooooow. Nevertheless, if it's the only way... Bas de Bakker. From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) Subject: WARNING :: Bug in CoreWarsDeluxe Message-ID: <71121@hydra.gatech.EDU> Date: 13 Oct 92 21:45:08 GMT I have just found a bug in CoreWarsDeluxe for the PC. It involves the MOV ADD and SUB commands when using predecrement in the B-field. Here's how I found it: mov 2,<2 jmp -1 dat #1 What happens is when CWD reads the A field, it goes ahead and grabs a copy of what it is going to move. Then if the B field decrements that same instruction, the mov works as normal except that it uses the copy of the instruction that has not been decremented. The same goes for the ADD and SUB commands. Has anyone ran the test programs on CorewarsDeluxe or on KoTHPC? -- Wayne Edward Sheppard Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b Internet: gt7804b@prism.gatech.edu From: ag625@yfn.ysu.edu (George M. Gruschow) Subject: Re: Interested in Corewars but ClueLess Message-ID: <1992Oct13.215048.11418@news.ysu.edu> Date: Tue, 13 Oct 1992 21:50:48 GMT What system are you running off of??? If a common PC system then call any local BBS up, ask the public where to get a corewars program for your system, and they will either point you to someone that might now, or tell you where to get one direct. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* George Gruschow | ag625@yfn.ysu.edu| The genius without a clue... *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From: wms@ssd.intel.com (William Shubert) Subject: Re: WARNING :: Bug in CoreWarsDeluxe Message-ID: <1992Oct13.225240.22358@iWarp.intel.com> Date: Tue, 13 Oct 1992 22:52:40 GMT gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) noticed: >I have just found a bug in CoreWarsDeluxe for the PC. It involves >the MOV ADD and SUB commands when using predecrement in the B-field. >Here's how I found it: > > mov 2,<2 > jmp -1 > dat #1 > >What happens is when CWD reads the A field, it goes ahead and grabs >a copy of what it is going to move. Then if the B field decrements >that same instruction, the mov works as normal except that it uses >the copy of the instruction that has not been decremented. This is not a bug. The specification for corewar is very vague; it simply states that the a-field is interpreted first, then the b-field. However, it does NOT say whether "interpreted" means that the address is calculated, that the value is actually read in, or what. Both CoreWarsDeluxe and KotH use "in-register" evaluation; that is, when the a-field is interpreted, the value is read into an internal register of the MARS and stored. Then the b-field is read in. The result is calculated and written back. I think I remember Mark Durham saying that the latest version of MADgic corewar has a switch where you can select between "in-register" evaluation (such as above) and "in-memory" evaluation (which you apparently expected to see). -Bill (wms@iwarp.intel.com) From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: WARNING :: Bug in CoreWarsDeluxe Message-ID: <1992Oct14.005356.29478@oucsace.cs.ohiou.edu> Date: 14 Oct 92 00:53:56 GMT In article <71121@hydra.gatech.EDU> gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) writes: >I have just found a bug in CoreWarsDeluxe for the PC. It involves >the MOV ADD and SUB commands when using predecrement in the B-field. > Since Bill already explained that this is not a bug, then I will leave that alone. :-) This "feature" just comes from one of the many ambigious rules that came from the standards... maybe all of this will be cleared up in the next release of standards. :-) Now, what I am curious about is the fact that you have Core Wars Deluxe for the PC??? This is something I haven't heard about yet! :-) Would you mind telling me where you got it (so I can get it), or if you did it yourself, I would be happy to hear more about it! The next version of Core Wars Deluxe is still currently only half done (I have rewritten all of the assembler parts, but haven't touched the MARS yet). One of the things that I am doing is developing the next version on both the IBM PC (in fact, using an XT for one, and a 486sx for another copy) and the Unix system... So far everything is working perfectly and exactly the same (including with memory usage)! :-) If anyone else is runnig any PC versions of the Core Wars Deluxe, please let me know, I would be happy to hear about it... :-) Scott Adkins sadkins@ohiou.edu (You know, I bet you that my sig will appear after this, so, why did I provide my name and address? Hmm....) -- Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) Subject: Re: WARNING :: Bug in CoreWarsDeluxe Message-ID: <71143@hydra.gatech.EDU> Date: 14 Oct 92 01:57:55 GMT >Now, what I am curious about is the fact that you have Core Wars Deluxe >for the PC??? This is something I haven't heard about yet! :-) Would >you mind telling me where you got it (so I can get it), or if you did >it yourself, I would be happy to hear more about it! The next version >........ >Scott Adkins >sadkins@ohiou.edu (You know, I bet you that my sig will appear after this, Sorry, I meant CoreWarPro. I didn't mean to confuse anyone. -- Wayne Edward Sheppard Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b Internet: gt7804b@prism.gatech.edu From: c9036991@wombat.newcastle.edu.au (THE TIME HAS COME, THE WALRUS SAID, TO TALK OF MANY THINGS. OF SAILING BOATS AND SEALING WAX, OF CABBAGES AND KINGS) Subject: Beginner Message-ID: <1992Oct14.210329.1@wombat.newcastle.edu.au> Date: Wed, 14 Oct 1992 11:03:29 GMT Hi all ... Being a beginner at these things i was wondering if somone willing enough could tell me some books I could read so I actually understand the redcode language. I think this would be a great help to me! I would also like to know which is the better to learn corewar on, I have koth from soda, and also core (also from soda). Thanks in advance, Mathew -- Wayne's World, Wayne's World, Party Time, Excellent! Party on Dudes! - Bill and Ted C9036991@wombat.newcastle.edu.au OR C9036991@idiot.at.home Just call me Mathew or BG From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: The IMProved imp. Message-ID: Date: 14 Oct 92 17:41:22 GMT As some of you have seen, my program "The IMPire strikes back" now holds the first place on the KotH list in a firm grip. 170 pts gives it an 18 pt margin to the 2nd place. (ok, so I needed to boast a bit :-) And, yes it IS imp-based... I call it 'Cyclic imps'. The following little example should give you an idea of what I mean: ;redcode ;name trident ;author Anders Ivner ;strategy Three imps are better than one :-) start mov imp, imp-2667 spl imp-2667 spl imp+2667 imp mov 0, 2667 end start (Note that 2667*3 = 8001) The effect is a program that is only ONE instruction long, like the imp AND it kills anything it runs into that has less than three processes. Like this, however, it will only score something like 90-100 pts. The secret is to put several layers of processes executing the same instructions. Like this, the different "rings" support each other, making it close to impossible to stop. It will recover completely from any decrement hit, it may break loose from spl hits, and the remaining rings will survive a dat hit undamaged. The best setup I have found so far is using seven layers with nine processes in each layer ( 9*889 also equals 8001 ): ;redcode ;name The IMPire strikes back ;author Anders Ivner ;strategy ...and 9*7 imps are even better... start spl 1 spl 1 spl 1 spl 1 spl 1 mov -1, 0 jpt jmp Date: 15 Oct 92 17:01:59 GMT I've got another question about the evaluations. Is the A-mode treated just like the B-mode? EX: MOV <1,4 DAT #1 If it is treated the same way, shouldn't DAT #1 be moved forward 4? Or will DAT #0 be moved forward? -- Wayne Edward Sheppard Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b Internet: gt7804b@prism.gatech.edu From: wms@ssd.intel.com (William Shubert) Subject: Re: More BUGS ??? Message-ID: <1992Oct15.174256.22282@iWarp.intel.com> Date: Thu, 15 Oct 1992 17:42:56 GMT gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) asked: >I've got another question about the evaluations. Is the A-mode treated >just like the B-mode? > >EX: > >MOV <1,4 >DAT #1 > >If it is treated the same way, shouldn't DAT #1 be moved forward 4? > >Or will DAT #0 be moved forward? The A-mode is treated just like the B-mode. So here is what happens: 1: Read in current instruction. Instruction = "MOV <1,4". 2: Evaluate A operand. - Decrement address pointed to by A operand. "DAT #1" -> "DAT #0". - Read in address pointed to by this decremented register. "DAT #0". 3: Evaluate B operand. - No action necessary since a MOV needs no input from the B operand. 4: Perform Calculation. - Result = "DAT #0" 5: Write result back to memory location referenced by B operand. - Write "DAT #0" to address 4. You see, when the A operand has a predecrement, the value gets decremented before it is read in. If the B operand had had the predecrement, the value would have gotten decremented in step 3. Since the value was read in during step 2, it would have gotten written back as it was BEFORE being decremented. This is really pretty simple once you just write out the five steps of MARS evaluation and figure out what happens at each step. -Bill (wms@ssd.intel.com) From: info301a4@cc.newcastle.edu.au (Your Average Ordinary Everyday Dude) Subject: A Question of Copyright Message-ID: <1992Oct16.084951.1@cc.newcastle.edu.au> Date: Thu, 15 Oct 1992 22:49:51 GMT Hello, \ I have a warrior that i call BUGGER because basically its a BUGGERised version of about 3 or 4 other warriors that I have seen the code for. I was just wondering what the rules concerning copyright (if any) there is about my warrior. It just basically takes the best (and most usefull) bits of the 4 programs, and combines them into one. I was most surprised when it managed to kill off XTC five times out of ten on KothPC (I think thats the correct program I was running) Also, I was wondering if there are any books that I could read to learn more about the programming side of things. Being a Psychology student, we dont have much to do with programming, and to be honest most of the code used in the warrior goes right over the top of my head. Thanks, Mathew. From: bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) Subject: New Digests Date: 16 Oct 92 11:28:34 MDT Message-ID: <1992Oct16.112834.8351@hellgate.utah.edu> Are there any plans to make the more recent postings to this newsgroup available on Soda? I'd like to catch up on everything I missed during summer vacation. ---------------------------------------------------------------------- Brant D. Thomsen Practice random acts of bdthomse%peruvian@cs.utah.edu kindness and senseless beauty. (University of Utah) Date: Friday, 16 Oct 1992 21:25:50 MST From: Message-ID: <92290.212550AZNXS@ASUACAD.BITNET> Subject: EBS tournament question What will be the scoring system on the EBS tournament on Nov. 15 ? How many opponents, how many battle per opponents ? Or the system used on the Valentine tournament? Another question: How can I delete something from soda? I's like to upload the new version of Mars88 and delete the old one. Na'ndor Sieben From: pk6811s@acad.drake.edu Subject: Re: The IMProved imp. Message-ID: <1992Oct17.102630.1@acad.drake.edu> Date: Sat, 17 Oct 1992 16:26:30 GMT > > As some of you have seen, my program "The IMPire strikes back" now > holds the first place on the KotH list in a firm grip. 170 pts gives > it an 18 pt margin to the 2nd place. (ok, so I needed to boast a bit :-) > And, yes it IS imp-based... I call it 'Cyclic imps'. > The following little example should give you an idea of what I mean: > Kudos Anders! This is great stuff. For a while there IMPire had a 30-pt lead. Hope you don't mind if I share a few things about this new ring technology. Here's what we're up against with rings. Take a ring running at three points: A copies itself to B B copies itself to C C copies itself to A+1 A+1 copies itself to B+1 B+1 copies itself to C+1 C+1 copies itself to A+2 etc. If you drop a bomb on B you have a one-in-three chance of killing the ring. If it is B's turn to execute he's dead, but if A's or C's then he repairs himself and keeps on going. If it's a seven-point ring, you have a one-in- seven chance, and one-in-nine for a nine-point ring. Rings are made much stronger by running multiple processes at each point. Now if you drop a bomb on B when it's his turn to execute, you kill that process, but only that one because the points take turns and A will repair B before the next B-process executes. Single process programs, like scanners and some bombers, are vulnerable in this way. A three-point ring running eight processes at each point is 24 processes. When it walks through your code, you will execute the mov 0,x instruction too, but because you are only one process you will run ahead of the ring and out of safe code. You would have to be running at least 24 instructions to avoid outrunning the ring. So one line of attack is to use a spl-0 to constantly increase the number of processes in your fighter, then you can get a tie by following the ring around and around and ... I'm not sure if Anders' 9*8 configuration is just one nine-point ring with eight processes each (72 processes) or if he is running multiple rings. I can't get IMPire to run using Core! 1.01 on the Mac. It just devolves into several jmp @0,0 instructions. Random Thoughts: A ring's weakness is that he can only tie a fighter running more processes than himself, unless he actually forces self-destructive behavior as he creeps up on the opponent's position. So we need to design fighters that don't self-destruct under those conditions. Replicators need not fear destruction, but they are going to tie a lot more. Scores will be generally depressed if all we can do is force a tie. Rings are actually worms - multiple imps running in trains. Worms also repair themselves and were very tough opponents early on. Really random thoughts: Possible names for sequels to "The IMPire Strikes Back" Return of the Gemini - for multi-instruction units ReWORM of the Jedi - got to keep those guys healty Fellowship of the RingWORM - we'll all get it sooner or later I'm enclosing my dwarf-ring combo, Earnest. It is a seven-point ring running eight processes at each point, with a one-dwarf running the other eight processes (64 total). ;redcode ;name Earnest ;kill Earnest ;author P.Kline ;strategy dwarf/ring combo spacing equ 1143 start spl 1 spl 1 spl 1 spl a2 a1 spl a1b2 a1b1 spl a1b1c2 a1b1c1 mov imp1,imp1+(spacing*1) jmp @-1 a1b1c2 mov imp1,imp1+(spacing*2) jmp @-1 a1b2 spl a1b2c2 a1b2c1 mov imp1,imp1+(spacing*3) jmp @-1 a1b2c2 mov imp1,imp1+(spacing*4) jmp @-1 a2 spl a2b2 a2b1 spl a2b1c2 a2b1c1 mov imp1,imp1+(spacing*5) jmp @-1 a2b1c2 mov imp1,imp1+(spacing*6) jmp @-1 a2b2 spl a2b2c2 a2b2c1 mov imp1,imp1+(spacing*0) jmp @-1 a2b2c2 spl 0 mov bomb, From: Dan Nabutovsky Date: Sun, 18 Oct 1992 09:59:53 GMT Here is Impressive, currently no.1 at the hill (195 points). This is an Impire-like program with 2 important enchancements: 1. Process ring was replaced by a process spiral, which decreases number of looses from 9% to 1% . 2. Dwarf added at the end, allowing to win self-splitting programs. ;redcode ;name Impressive ;author Dan Nabutovsky ;strategy Impossible + self-splitting dwarf d EQU 2667 i EQU imp-1000 imp: mov 0,d start: mov imp, i spl 32 spl 16 spl 8 spl 4 spl 2 jmp i+d*0 jmp i+d*1 spl 2 jmp i+d*2 jmp i+d*3 spl 4 spl 2 jmp i+d*4 jmp i+d*5 spl 2 jmp i+d*6 jmp i+d*7 spl 8 spl 4 spl 2 jmp i+d*8 jmp i+d*0 spl 2 jmp i+d*1 jmp i+d*2 spl 4 spl 2 jmp i+d*3 jmp i+d*4 spl 2 jmp i+d*5 jmp i+d*6 spl 16 spl 8 spl 4 spl 2 jmp i+d*7 jmp i+d*8 spl 2 jmp i+d*0 jmp i+d*1 spl 4 spl 2 jmp i+d*2 jmp i+d*3 spl 2 jmp i+d*4 jmp i+d*5 spl 8 spl 4 spl 2 jmp i+d*6 jmp i+d*7 spl 2 jmp i+d*8 jmp i+d*0 spl 4 spl 2 jmp i+d*1 jmp i+d*2 spl 2 jmp i+d*3 jmp dwarf DAT #0 DAT #0 DAT #0 DAT #0 DAT #0 DAT #0 DAT #0 MOV 7, <-7 incr: MOV 7, <-7 dwarf: SPL 0 loop: MOV <75, -74 ADD incr, loop DJN loop, <4400 JMP -1 END start ---------------------------------------------- Dan Nabutovsky fedimit@wiscon.weizmann.ac.il From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: ring killers Message-ID: Date: 19 Oct 92 10:08:36 GMT "xtc" is a good ring killer. Campbell -- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. Campbell Fraser: fraserc@dcs.glasgow.ac.uk Computing Science Department, University of Glasgow, Glasgow G12 8QQ From: ford@rho.uleth.ca (Roger Ford) Subject: Flash Paper 3.7 Message-ID: Date: 20 Oct 92 00:10:24 GMT Well, it finally happened....Flash Paper got pushed off the hill. Almost sad to see it go. When I started playing this game FP was allways #1 on the hill, and I made it my goal to someday beat it. Now it's gone. Thank you Matt Hastings for a worthy opponent. c w blue From: durham@cup.portal.com (Mark Allen Durham) Subject: Some Answers Message-ID: <68058@cup.portal.com> Date: Tue, 20 Oct 92 00:12:26 PDT This is in reply to Matthew's and Na'ndor's queries. Their questions are quoted. The answers are taken from the FAQ, revised and posted to rec.games.corewar (and news.answers someday) the first of each month. " Also, I was wondering if there are any books that I could read" " to learn more about the programming side of things." Q3: Where can I find more information about Core War? A3: 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 an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 A9: Where is the Core War archive? Q9: 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 soda.berkeley.edu (128.32.131.179) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. " What will be the scoring system on the EBS tournament on Nov. 15 ?" Q13: When is the next tournament? A13: The 1992 Annual ICWS tournament will be held December 15th, 1992. The rules are currently ICWS'88, core size of 8192, maximum number of processes per warrior of 8000, and ties declared after 100 000 cycles. The format is round-robin. Scoring is three points per win, one point per tie, and no points for losses. To enter you must be a member of the International Core War Society or successfully participate in one of the Branch Section preliminary tournaments ("successfully" meaning finish in the top five/ten [see below]). Valid entries should be sent to Jon Newman either via email to jonn@microsoft.com of via mail on 3.5" disk (800K Mac or 720K IBM), 5.25" disk (720K IBM or 1.2MB IBM), or printed. Disk entries should be in a simple ASCII text format and on virus-free disks. ICWS Members may submit one entry or two entries if in electronic form. Branch Sections may submit five entries, or ten if in electronic form. Entries are limited to 50 instructions, 300 if in electronic form. No scatter loading will be supported (instructions must be contiguous). All entries become public domain on submission. The ICWS will keep them confidential until after the tournament has been completed. The EBS will hold its preliminary tournament November 15th, 1992. The EBS is open to all persons with access to electronic mail. Please limit submissions to two unique entries. Send submissions to durham@cup.portal.com and clearly indicate their purpose (i.e. ;For November 15th, 1992 EBS preliminary tournament) as well as author and name. The EBS rules are necessarily the same as the ICWS rules. " How many opponents, how many battle per opponents ?" The number of opponents is determined by the number of entries I receive by November 15th. So far I have zero (0). The number of rounds (each warrior battles every warrior [including itself] once per round in a round-robin tournament) will be determined at the time of the tournament. My goal is to be fair, so I will run rounds until the average results are stable. That assumes I have more than 10 entries. If I have 10 or fewer entries, I will run just one round since the results will have no bearing on which warriors are submitted to the ICWS tournament. " Another question: How can I delete something from soda? I's like to" " upload the new version of Mars88 and delete the old one." Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. He will gladly help replace old versions with new versions. Mark A. Durham MAD durham@cup.portal.com From: hastings-matthew@yale.edu (Matthew Hastings) Subject: New progs-fighting the IMP Message-ID: <1c1qvsINN964@MINERVA.CIS.YALE.EDU> Date: Tue, 20 Oct 1992 20:42:36 GMT Wow! I was really surprised by the success of the IMP programs, and in fact they got me to write a few new programs. I had sworn off redocde authorship until I got a bit mad at the success of the IMPs. I dunno, it was a bit annoying to me. Of course, I must state that it is a truly original idea, the sort of thing we haven't had for a while. Unfortunately, due to time, the recent upheavel and so on, my old one's are now all off. The new programs (which are kind of just thrown togethor and I which I don't like as much as my older one's) are:A B-Scanner Darkly, A CMP-Scanner Darkly, Pale Shears2 and The Sender of Eight. The Sender of Eight is another Paper/Stone program, which could use some improvs. Due to it's unfinished nature I'm not yet ready to give the source-but I will after a bit more time-even if I don't change anything. It's just I don't want to admit to writing such a sloppy piece of code. BTW, the name not only refers to a being in a novel, but has much to do with how my program works. To the real new stuff:I worked for a while on an IMP-killing method that was not highly specific. First tried adding SPL 0 to end so that when hit by IMP it would walk onto SPLs, make lots of procs., and live. This was not good enough-especially since many of the programs would core-clear the SPLs. It was possible to make an infinte core clear which missed the SPL 0 at the end but then against IMP/dwarves the program would be way too long. So:I realized that you could modify the core-clear of a lot of programs to split off more processes. A B-Scanner Darkly and Pale Shears2 use the same trick spl 0 mov @{some location which isnt bombed},<-1 jmp @-1. This acts to make lots of processes, but when it is dropped elsewhere, it turnes into spl jmp @-1 whihc is like spl jmp -1. Agony 2.4b was the best base program for close mod-I just added a JMP -2 to the end. Briefly it was on the hill as A CMP-scanner darkly. However, it is soon going to be on there as Agony 2.5 (almost every single line was written by S. Strack, I just resurrected it for use in aslightly different role). Finally, the new A CMP-scanner Darkly is a test program of a different type of CMP scanner, which builds IMP protection in-the clear has a JMP -2 instead of a JMP -1 and it drops 2 SPLs instead of 1. This is like No Mucking About in the bomb length (course NMA's len is 4 not 3), but the constants are blatantly stolen from Andy Pierce's Crimp 2, which I always saw as the standard basic CMP scanner. The last mod to A B-Scanner Darkly is one which I've had for a long time in my own version of B-Scanners live in vain, but hadnt bothered to put in the hill version-decoys!! Since it is a B-scanner I can set up a field of decoys, half with non-zero B-fields and have CMP scanner see them all and it see none. There is actually one further mod. I should make to the decoys- there not as effective as they might be, but they help some. Well, this anti-IMP mod can be implemented in a lot of programs. Just Agony 2.4b looks like on of the best to use it on-it goes to a 16-8-76 edge or so on average (I ran a lot of battles beyond those run by wms on hill), before mod it loses 76+% of the time. And it is real good against all those replicators out there. Of course, Stefan deserves all the credit for that end of it. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: R.I.P. Sucker 4 Message-ID: Date: Wed, 21 Oct 1992 01:06:32 GMT Cruely killed off at the, admittedly, ripe old age of 949, what follows is the code to "Sucker 4". It's been so long since I wrote it that I barely remember how it works :-). It is a simple self-splitting vampire; changed constants at some launch code/decoy are the differences to "Sucker 3", which (I believe) I posted a while back. Cheers, Stefan ;redcode ;name Sucker 4 ;author Stefan Strack ;strategy Self-splitting, pattern-bombing vampire ;strategy 2: with confusion ;strategy 3: much denser, mod-2 bomb-pattern; no spacer ;strategy 3.1: avoids prematurely dropping into clear-mode ;strategy 4: spacer/bootstrap; changed bomb increment; tracer-proof ;strategy Submitted: @date@ AWAY equ 4000 ;mirrors boot template mark equ start+39 ;------ bootstrap main bombing loop and slave pit without spacers boot mov loop+2,@ptr1 mov loop+1, Date: 21 Oct 92 09:11:54 GMT Some of you probably have already noticed that two programs I submitted: Beholder's Eye & Winter Werewolf suddenly entered KotH and competed with IMPire programs for the #1 and #2 place. And YES, they are normal vampire programs that defend themselves against IMPs. By average, they score something like 70-15-15 against multi-layered IMPs. The idea behind their success is quite simple: - Since multi-layered IMPs advanced slowly, scanners/vampires would have sufficient time to finish their own routines before dealing with IMPs. So to say: 1. Normal routine 2. Core clear 3. IMPs gate First and two are clear. Third: IMPs gate. Ok, there might be a better word for this. What I mean is to stop the IMPs while you are hopeless. And the secret? To use an instruction which has been looong forgotten: Pre-Decremental DAT. Does it ring a bell? So, here we go: First: Winter Werewolf. ;redcode ;name Winter Werewolf ;author W. Mintardjo ;strategy SPL/JMP bomber with 2 pass core-clear (SPL/DAT) + self-defense ;strategy against IMPs step EQU 153 init EQU 152 n EQU (12*8)-2 DAT <-4-n, #0 m MOV -1, 0-n JMP 2 snow SPL 0, <-3-step-n main MOV hold, @3 MOV snow, <2 ADD #step, 1 JMP main, init ; Hit here MOV @-4, /* Sender: W. Mintardjo (wangsawm@prism.cs.orst.edu) */ main() { printf(".sig? what's .sig?\n"); } From: hrobi@namu01.gwdg.de (Helge Robitzsch) Subject: predecrement evaluation Message-ID: Date: Wed, 21 Oct 1992 09:22:41 GMT >gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) noticed: >>I have just found a bug in CoreWarsDeluxe for the PC. It involves >>the MOV ADD and SUB commands when using predecrement in the B-field. >>Here's how I found it: >> >> mov 2,<2 >> jmp -1 >> dat #1 >> >>What happens is when CWD reads the A field, it goes ahead and grabs >>a copy of what it is going to move. Then if the B field decrements >>that same instruction, the mov works as normal except that it uses >>the copy of the instruction that has not been decremented. > wms@ssd.intel.com (William Shubert) answered: > This is not a bug. The specification for corewar is very vague; it simply >states that the a-field is interpreted first, then the b-field. However, it >does NOT say whether "interpreted" means that the address is calculated, >that the value is actually read in, or what. Indeed, the ICWS '88 Standard has some ambiguities. However, concerning predecrement(<) evaluation the standard leaves no room for an interpretation as "in-register" evaluation or suchlike. The evaluation is as follows (see the section "Effective Address Calculation" in the standard): 1. Normalise the a-operand (this includes decrementing the b-field of the specified memory location in case of predecrement). 2. Perform the same procedure to normalise the b-operand. 3. With both operands now normalised, the operation code is examined and the specified operation performed. In the concrete, performing the mov-instruction in the example above the b-field of the dat has to be decremented BEFORE the dat is moved. In my opinion other results are not in conformity with the standard and indicate bugs. Wayne E. Sheppard is right: he found a bug. Sorry, Bill :-( -- Helge Robitzsch, NAM Goettingen, Tel: 0551-394528 From: pk6811s@acad.drake.edu Subject: ring killers - and more Message-ID: <1992Oct21.102041.1@acad.drake.edu> Date: Wed, 21 Oct 1992 16:20:41 GMT Looks like everyone has a solution to the imp-ring problem. Here's mine: ;redcode ;name Eclipse ;author P.Kline ;strategy bscan, ringkiller, clear ;strategy demo-only version hold dat #0 ptr dat #stun next add #2234,ptr scan jmz next,@ptr ; scan for non-zero slt #14,ptr ; check for me jmp next,hold inc mov @ptr,hold ; save whatever is pointed to stun mov bomb,@ptr ; drop a stunner add hold,ptr ; bump pointer up the trail cmp #-1,hold ; don't follow djn streams jmn stun,@ptr ; follow the trail djn next,#4 ; check for enough bomb spl 0 mov 2,<-1 jmp -1 end next Eclipse is based on a program I wrote a couple of years ago to destroy pit-trappers, the kind that dropped 'jmp @0,trap' bombs. All you had to do was add the b-field (trap) to your pointer and you had the location of the trap, which also happened to be the location of the pit-trapper. Unfortunately that style of snare was changed to jmp trap,coresize-trap, and my Hunter program became useless. First time I tried Hunter, it demolished IMPire with no problem, so I streamlined it as above. The current version of Eclipse (not shown) is also effective against modern pit-trappers as well as RotlD2, and probably any other programs that drop pointers to their position all over core. Unfortunately it is a little too big in its present form, but it will be back Real Soon Now. Eclipse is also effective against the kind of paper replicators that form colonies - a result of not bumping the 'next' location after each copy is made. Once it finds a small-number b-field, say '4' or '8', it works its way through the colony, dropping stunners along the way. Unfortunately Note Paper, Flash Paper, etc. aren't around anymore to beat up on. Paul Kline pk6811s@acad.drake.edu From: wms@ssd.intel.com (William Shubert) Subject: Re: predecrement evaluation Message-ID: <1992Oct21.175948.24638@iWarp.intel.com> Date: 21 Oct 92 17:59:48 GMT hrobi@namu01.gwdg.de (Helge Robitzsch) accused: >In my opinion other results are not in conformity with >the standard and indicate bugs. Wayne E. Sheppard >is right: he found a bug. Sorry, Bill :-( Well, I went back to my ICWS '88 specs, and guess what? He's right! Oops. Alas, I only got ICWS '88 specs about a month ago or else this problem would probably never have happened. Originally KotH was a weird mix of in-register and in-memory evaluation, but I shifted it to all in-register to match with other programs available at the time. I have a new release of KotH (it will be 3.1) coming out within a month or two that will have much nicer debugging facilities; I'll probably switch over to in-memory evaluation at that time. At least one ambiguity is still left. The line "After the instruction to be executed has been fetched, the operands must be `normalized' before the opcode is processed." Does this mean that mov <0,5 will decrement the "5" before evaluating the B-operand, or fetch the whole thing at once and decrement a version of the "5" that is in memory but keep using the "5" as the destination address? Grrrr. Well maybe the next spec will be better. For now I'll assume "instruction to be executed has been fetched" will mean ONLY the "mov" part is fetched, the "0" and "5" are left in memory until it is time to evaluate them. -Bill (wms@ssd.intel.com) From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Sonic Boom update (2.0 and up) Message-ID: <1992Oct21.213015.28754@unlv.edu> Date: Wed, 21 Oct 92 21:30:15 GMT For those of you that have noticed (and are interested), I've been trying very hard the last day or so to improve Sonic Boom. I've tried better bombing patterns, a smarter monitor, a better dumb monitor, and yet nothing comes close to the original. Kinda frustrating, really :-) Expect the next version to be 1.2, which will be 1.X bombing and 2.2 monitor. For those of you that don't know, Sonic boom sends two core clears through memory, one in each direction. There's a monitor process that waits for enough time for it to be killed, then starts two more core clears, on the assumption that if neither of the last two core clears have killed it, then both are dead and need to be restarted. Now, the 2.1 monitor would watch both of them, and relaunch the one that failed, almost as soon as it failed. This worked, but it was somehow getting out of sync, so that the new core-clear wouldn't kill the old one, but would fall into it. The 2.2 monitor would watch both of them, and relaunch both of them once both have failed. Same as before, but it does it faster now. Also on the horizon, Shotgun (might become Loki 3.0, similar idea but different mechanics) -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: More Interesting X-Hill Discoveries (I'm Baaaack:-) Message-ID: <1992Oct22.194125.9255@unlv.edu> Date: Thu, 22 Oct 92 19:41:25 GMT Well, I tried two new interesting ideas in Shotgun, and I plan on doing a littl more work on it, but it doesn't seem to be the champion that I thought it might be. So, I'm going to describe the new ideas, and probably knock myself out of first again by giving one of you a truly great idea (or at least a better use for these ideas :-) Since the ideas only apply to the jumper, and everyone has seen my core-clear routines several times, I'll only detail the jumper here. STEP EQU 240 OFFS EQU 10 INC EQU 30 JLAUNCH MOV CSRC,CSRC-STEP MOV CDST,CDST-STEP SPL 1 SPL 1 SPL 1 JMP LOOP BOMBS JMP -OFFS,TRAP+OFFS+STEP JMP -OFFS-INC*1,TRAP+OFFS+INC*1 JMP -OFFS-INC*2,TRAP+OFFS+INC*2 JMP -OFFS-INC*3,TRAP+OFFS+INC*3 JMP -OFFS-INC*4,TRAP+OFFS+INC*4 JMP -OFFS-INC*5,TRAP+OFFS+INC*5 JMP -OFFS-INC*6,TRAP+OFFS+INC*6 JMP -OFFS-INC*7,TRAP+OFFS+INC*7 CSRC DAT 0,LAST+1+STEP CDST DAT 0,LAST+1+STEP*2 LOOP MOV 0,@BOMBS JMP LOOP+STEP TRAP SPL 0,2 MOV -1,>-1 LAST DAT 0,0 The first and most evident idea was the use of a table of bombs, and the MOV >0,@BOMBS instruction to deposit them. Since I like multi-process programs, I've been looking for a way to use interval bombing rather than carpet bombing when I have several processes executing the same code. It is possible to do this by having two routines running in parallel, but this was an interesting and more flexible idea. Basically, the MOV >0,@BOMBS instruction moves whatever is at bombs to whatever it points to, then increments the B field. In parallel, this means that in 8 cycles, it will take a table of 8 instructions, and blast them all into memory wherever they belong. The second idea, this one being quite applicable to (SPL 0;JMP) -1 bombers, is the (SPL 0,2;MOV-1,>-1) trap. this trap will grow, and multiply MUCH faster. I did a test on both, and after 2500 cycles, the standard trap had trapped just over 1500 processes. My trap, on the other hand, had trapped 2490 processes! It had only failed to split on 11 cycles. The disadvantages are twofold. It relies on the B field, so you can't use it for anything else, and it will grow, whereas the standard trap stays in the same place. Also, for most programs, the difference in splitting speed is only a minor issue. Against sigil or another fast replicator, however, this speed difference makes a noticeable impact. Last time I announced an X-hill discovery, I went from having 1st, 3rd, and 4th, to having 2nd, 5th, and 8th. I really hope this makes life on the hill tougher again :-) -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: No more IMPire. Message-ID: Date: Thu, 22 Oct 1992 19:53:57 GMT Good work! It only took you guys one week to push IMPire off the hill, once you knew what you were up against! Now I'll have to come up with something better... Anders Ivner From: maniac@hubert.cs.unlv.edu (Eric J. Schwertfeger) Subject: Re: More Interesting X-Hill Discoveries (I'm Baaaack:-) Message-ID: <1992Oct23.023304.24016@unlv.edu> Date: Fri, 23 Oct 92 02:33:04 GMT In article <1992Oct22.194125.9255@unlv.edu>, maniac@unlv.edu (Eric J. Schwertfeger) writes: ) Well, I tried two new interesting ideas in Shotgun, and I plan on doing a ) littl more work on it, but it doesn't seem to be the champion that ) I thought it might be. So, I'm going to describe the new ideas, OK, so I was wrong :-) Shotgun 1.0 is at third, and 1.1 is under development. -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: alfa@csource.oz.au (glenn durden) Subject: Crobots Message-ID: Date: Fri, 23 Oct 92 11:30:02 +1000 I'm new to this newsgroup, so I first start off with a question. Do you run Crobots competitions here? ......................................................... glenn durden alfa@csource.oz.au Unique Computing Pty Ltd, Melbourne, Australia The opinions expressed above are that of the author only. From: pk6811s@acad.drake.edu Subject: No more IMPire - Lots more Rings Message-ID: <1992Oct23.102715.1@acad.drake.edu> Date: Fri, 23 Oct 1992 16:27:15 GMT Yeah, Anders, we are learning to overcome rings, but only by making our fighters a little bit longer, a little bit more complex, a little bit less efficient, and therefore a good deal more vulnerable to attack. :-( But rings are here to stay, and they can't be ignored as the last few days on the Hill have proven. IMPire suffered from too many ties, especially against replicators. The problem was that as it rode over a replicator, it advanced faster than the imp'd opponent, and created a trail of safe instructions to follow. The simple addition of a dwarf or stone disturbs the trail, causing the opponent to die. -------------------------------------- Ring Sizes: I first thought ring sizes were limited to a handful of numbers - 3,7,9,18,21 - basically the small factors of 8001. But factors of 16001, 24001, 32001, etc. should also work, the leading point just has to end up one instruction in front of itself each go-around. Here's a short program to find these: for i=1 to 19 j=(8000*i)+1 print the factors of j i and here are the results: #points dist ------ ------ 3 2667 7 1143 9 889 11 5091 13 3077 17 2353 19 7579 21 381 27 2963 31 3871 33 1697 49 2449 53 2717 63 127 Only the smaller factors/points are shown, it would be a challenge to successfully launch a 63+ point ring against a very fast opponent. This kind of ring is equivalent to the imp-form: mov 0,1 Another form is: (Dan pointed this out to me) mov 0,2 mov 0,2 For this kind we need factors of 8002, 16002, etc., so here are some: #points dist ------ ------ 2 4001 3 5334 6 2667 6 6667 7 2286 9 1778 11 2182 13 6154 14 1143 14 5143 17 4706 18 889 18 4889 19 7158 21 762 22 1091 22 5091 23 4174 26 3077 29 4138 33 3394 34 2353 37 1946 38 3579 42 381 46 2087 57 2386 58 2069 59 678 63 254 Actually there are lots of other factors, but they have separations greater than 8000, making them unusable. I publish these, not knowing just what they are good for, but to encourage others to find some anomaly in launching; cooperation with stone, dwarf, scanner, etc.; or bombing/searcing pattern that would make them attractive. For example, a 2-point ring carries a reflection at 4000, making it impervious to attack by an on-axis scanner. Paul Kline pk6811s@acad.drake.edu From: macaulay@ecr.mu.oz.au (Alex MacAulay) Subject: Rings on the X-Hill Message-ID: <9229922.4368@mulga.cs.mu.OZ.AU> Date: 25 Oct 92 11:56:04 GMT Although IMPire is no longer on the regular Hill, it lives on in the X-Hill. A few days after IMPire was posted, I sent off Impirex which was just a copy of IMPire with a step size of 127, the only step I could find that was suited to the 250 write limit, and 3 processes at each point. I was hoping that the results would be even more spectacular than IMPire due to the fact that to beat it, you not only need to hit a point immediately before it executes, but you also needed to be within 250 locations of it at the same time. Unfortunately it only made it about half-way up the hill. :-( Although it had the lowest loss percentage (less than 20%) on the hill, it tied almost every time with replicators. Unfortunately, you can't write a simple stone for the X-Hill, so it may be difficult to convert these ties into wins. I recently replaced Impirex with Springer 1.0 which creates more and more ring processes and has a different method of starting the rings up. Although this method is slower, it does not need a massive, vulnerable jump table. Has anyone found an even better way of doing this? The other thing to note is that the 'top' imp in the ring is helped along by the main program (so, strictly, it's not really a ring). Here is Springer 1.1, which I have just sent off: ;redcode-x verbose ;name Springer 1.1 ;author Alex MacAulay ;strategy A ring "replicator". ;strategy 1.1 - smaller step equ 247 offset equ -126 start spl 0,>spread helpimp mov imp,imp+offset+3 spl 1,>helpimp spl 1 spl 1 spl 1 spl inc spread jmp @spread,#imp+offset inc add #step,spread dat 0,0 imp mov 0,step end start If you would like to test this out but don't have post-increment, it still works if you replace the three instructions from 'start' with: start spl 0 add #1,spread helpimp mov imp,imp+offset+3 add #1,helpimp spl 1 -- Alex MacAulay (macaulay@ecr.mu.oz.au) From: s903040@minyos.xx.rmit.oz.au (Christopher Francis Anderson) Subject: Newbie needs help! Date: 26 Oct 92 01:48:21 GMT Message-ID: Hi. I'm just a newbie at this thing. I have the PC versions of KOTH and also CoreWar Pro 3.something, plus about 60 warriors. What I don't have (as far as I know - I haven't looked at all the docs I have, yet) is good explanations about what rings, imps, scanners, etc. etc. ad nauseum actually ARE, and how they work. So could you folks please give me a hand? Thanx in advance (and Email is preferred, as my news server is just a little bit touchy at the moment :-( ) -- Thunderchild (a.k.a. Chris Anderson) s903040@minyos.xx.rmit.oz.au "Where's the kaboom? There was supposed to be an earth-shattering kaboom!" From: hrobi@namu01.gwdg.de (Helge Robitzsch) Subject: predecrement evaluation Message-ID: Date: Mon, 26 Oct 1992 10:10:58 GMT wms@ssd.intel.com (William Shubert) writes: >... For now I'll assume "instruction to be executed has been >fetched" will mean ONLY the "mov" part is fetched, the "0" and "5" are left >in memory until it is time to evaluate them. IMHO it would be better to fetch the whole instruction at once. Two reasons: 1st Following the ICWS '88 specs an INSTRUCTION has three FIELDS, the opcode field and two operand fields (section "Instruction Format"). "After the instruction to be executed has been fetched..." therefore means that the whole thing has to be fetched before the operands are normalised. Suppose the authors of the specs intended by the term "instruction" that one has to fetch the FIELDS one after another, why didn't they use the term FIELDS instead of INSTRUCTION? 2nd For example, let's execute the instruction mov <0, b ; First both of the methods decrement the B-field of the mov instruction in memory. Next the "fetch-by-parts" method moves the contents of the relative memory location b-1 to the relative memory location b-1, which has no effect. The "fetch-the-whole" method moves the contents of the relative memory location b-1 to the relative memory location b. I would prefer the second alternative since an instruction of the type mov *, b generally should take the location b for destination. This is the natural behavior, why should we deviate from it without necessity? Is there an accepted interpretation of the ICWS '88 specs concerning this problem? Seemingly ambiguities in standards are a destiny. :-) -- Helge Robitzsch | _ Institut fuer Numerische hrobi@namu01.gwdg.de |_|_| und Angewandte Mathematik Germany | |\_ - Universitaet Goettingen - :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) From: wms@ssd.intel.com (William Shubert) Subject: KotH standings Message-ID: <1992Oct26.210714.14270@iWarp.intel.com> Date: 26 Oct 92 21:07:14 GMT Well, the Imps came, for a while they filled the top quarter of the ICWS '88 hill, but their numbers have thinned some. #1 is still an imp/worm ring/ whatever you want to call it. Rather sad, though; all the oldest programs got wiped off. Does anybody know if any program made it to age 1000 before falling off? # %W/ %L/ %T Name Author Score Age 1 34/ 11/ 55 Impression 1 Dan Nabutovsky 157 95 2 47/ 39/ 14 No More Mucking About Campbell Fraser 155 4 3 41/ 35/ 25 Agony 2.5 M. Hastings & S. Str 147 76 4 26/ 11/ 63 Tarrasque c w blue 141 62 5 39/ 39/ 22 B-scanners live in vain Hastings&Mintardjo 140 52 6 39/ 40/ 21 Emerald P.Kline 138 9 7 37/ 37/ 26 Pale Shears3 Matt Hastings 138 56 8 29/ 21/ 50 The Sender of Eight Matt Hastings 138 123 9 29/ 21/ 49 Atomic Sheep c w blue 137 251 10 38/ 38/ 24 A CMP-Scanner Darkly Matt Hastings 137 63 11 23/ 13/ 64 Dwimp nandor sieben 133 12 12 33/ 34/ 33 Winter Werewolf W. Mintardjo 132 101 13 36/ 45/ 19 Charon v7.0 J.Cisek & S.Strack 127 441 14 33/ 42/ 25 Dain Dan Nabutovsky 125 92 15 16/ 7/ 77 repimp nandor sieben 125 106 16 31/ 39/ 30 ExtraExtra 3.0 P.Kline 122 3 17 25/ 30/ 45 Patients 1a ECP 121 13 18 20/ 23/ 56 dead end 1.1 nandor sieben 118 37 19 30/ 44/ 26 tut ECP 116 1 20 30/ 45/ 25 Gorgon 2 Anders Ivner 116 10 On the experimental hill, some upgrades for old programs are doing pretty well. # %W/ %L/ %T Name Author Score Age 1 38/ 13/ 48 Corona Alex MacAulay 163 1 2 42/ 22/ 36 Sledge 1.3 Alex MacAulay 161 53 3 46/ 32/ 22 Sonic Boom 2.40 Eric J. Schwertfeger 161 11 4 42/ 29/ 30 Shotgun 1.00 Eric J. Schwertfeger 155 13 5 45/ 35/ 20 Snare 1.00 Eric J. Schwertfeger 155 12 6 41/ 30/ 29 Scorpion 3.3 Alex MacAulay 152 106 7 42/ 35/ 23 Sonic Boom 3.10 Eric J. Schwertfeger 150 3 8 32/ 24/ 44 Edge 1.1 Alex MacAulay 140 107 9 27/ 15/ 58 Springer 1.1 Alex MacAulay 139 5 10 27/ 26/ 47 El Papel Unknown 128 31 11 35/ 46/ 19 Loki 2.50 Eric J. Schwertfeger 125 20 12 35/ 46/ 18 Halberd 1.70 Eric J. Schwertfeger 124 55 13 34/ 44/ 22 Deep Green Sea Pierre Baillargeon 123 77 14 19/ 23/ 59 Sigil Matt Hastings 114 179 15 22/ 30/ 48 LongWorm 1.2 Dan Nabutovsky 113 48 16 22/ 32/ 46 Trap 6 Kent Peterson 112 2 17 33/ 55/ 11 Fence Leaper-X 1.0 Jeff Raven 111 87 18 17/ 23/ 60 Time Machine 3.20 Pierre Baillargeon 110 49 19 17/ 25/ 58 Troll 2.1 Dan Nabutovsky 110 45 20 30/ 50/ 20 Scylla and Charybdis V1.0 Jeff Berry 109 78 In other news, KotH v3.1 is nearing time to be shipped out. It's got some REALLY nice disassembly/debugging windows added to it. KotH 3.0 is still available via anonymous FTP to soda.berkeley.edu. -Bill (wms@ssd.intel.com) From: durham@cup.portal.com (Mark Allen Durham) Subject: RE: predecrement evaluation Message-ID: <68470@cup.portal.com> Date: Tue, 27 Oct 92 03:33:02 PDT As regards the discussion of "in-register" vs "in-memory" interpretations of ICWS'88: This topic comes up every three months or so. It is NOT A BUG! It is an ambiguity in the standard. The problem will not go away until a new standard is established. A new standard is being worked on. Helge Robitzsch did not fully understand the example presented and the explanation of behaviour given. Part of "normalization" of the A-operand is reading in parts of core and STORING THEM for later use in instruction execution because they may be altered by the B-operand (predecrement) or the instruction execution itself ("DJN @x, x" for example). From ICWS'88: MOV A, B: [Immediate mode omitted] The contents of the entire memory location specified by the A-operand is (sic) moved to the memory location specified by the B-operand. "The contents of the entire memory location specified by the A-operand" are precisely those contents in core AFTER A-operand "normalization" but BEFORE B-operand "normalization". It is therefore necessary to store those contents as part of A-operand evaluation! After B-operand "normalization" (which may alter core but not the stored A-operand contents) the stored A-operand contents are moved from storage into the core memory specified by the B-operand. This interpretation is consistent with the "Effective Address Evaluation" section of ICWS'88 (See below). Examine MARS88.c on soda.berkeley.edu for one implementation which follows the evaluation order to the letter. With respect to Bill Shubert's question about "instruction to be executed has been fetched", "instruction" refers to not just the opcode but also the operands. Therefore, you must fetch the ENTIRE instruction. "MOV <0, 1" is a good example instruction. Here is how it would execute: (PC is the current pointer counter -- the address of "MOV <0, 1"). 1. "MOV <0, 1" is fetched and stored in the instruction register. 2. The A-operand is evaluated. a. The B-field of the instruction located at PCA = PC+0 is decremented. The instruction in the instruction register is still "MOV <0, 1" but the instruction in CORE[PC] is now "MOV <0, 0". b. The instruction at PCAI = PCA+0 ("MOV <0, 0") is stored in the A instruction register for later use. 3. The B-operand is evaluated. The effective address is PCB = PC+1. 4. The contents of the entire memory location specified by the A-operand ("MOV <0, 0" stored in the A instruction register) are moved to the memory location specified by the B-operand (PCB = PC+1). So the contents of core after execution are: MOV <0, 0 ; Our original instruction MOV <0, 0 ; The copy Note that "in-memory" execution (but with an instruction register) would have produced the same results. This is always the case for B-modes other than predecrement. The two interpretations deviate only when the A-operand and B-operand reference the same location and the B-operand is predecrement. Here is Wayne Sheppard's example: PC MOV 2,<2 JMP -1 DAT #1 1. "MOV 2, <2" is fetched and stored in the instruction register. 2. The A-operand is evaluated. The instruction at PCA = PC+2 ("DAT #1") is stored in the A instruction register for later use. 3. The B-operand is evaluated. a. The B-field of the instruction located at PCB = PC+2 is decremented. CORE[PC+2] is now "DAT #0". b. The memory location specified by the B-operand is PCBI = PCB+0. 4. The contents of the entire memory location specified by the A-operand ("DAT #1" stored in the A instruction register) are moved to the memory location specified by the B-operand (PCBI = PCB+0 = PC+2). So the contents of core after execution are: PC MOV 2,<2 JMP -1 DAT #1 The same as before execution, except PC+2 was decremented and then overwritten with a copy of its undecremented self during execution. If you have not done so, you MUST read the ICWS'86 standard. In particular, you need to read the discussion of DJN on page 11. This is where the role of registers is explicitly described. The gist of the discussion is that the values BEFORE execution are the appropriate values to use DURING execution. The only way for this to be so is to store the values in registers during the "normalization of operands" phase of instruction execution. This includes entire instructions where MOV and CMP are concerned. It is inconsistent to do one but not the other. ICWS'88 does not exist in a vacuum. Much of what is left out of ICWS'88 is in ICWS'86, and it is this historical perspective (along with some aesthetic arguments and some heavy campaigning) which has led to the de facto adoption of "in-register" as the interpretation of choice. Mark A. Durham MAD durham@cup.portal.com From: pk6811s@acad.drake.edu Subject: overcoming mintardjo gates Message-ID: <1992Oct27.142931.1@acad.drake.edu> Date: Tue, 27 Oct 1992 20:29:31 GMT The 'mintardjo gate' is a very clever piece of programming designed to destroy imps and imp-rings. It seems to be adaptable to a number of otherwise successful programs - scanners and bombers - to give some number of wins against the new ring programs, wins that otherwise would likely be losses. This article is to discuss the greatest weakness of the mintardjo gate - its lack of aggressiveness. The early implementations, as in Winter WereWolf, are to use a strong strategy like scanning, followed by a complete core clear, winding up with a standing gate. Most likely the first two phases will not be successful in destroying a well-designed ring or spiral, so it is up to the gate to finish the job. In fact some programs would be better off to skip the first two phases and go right to the gate, that would prevent them being overrun before the gate could be completed. Of course that would be useless against any other opponent, or against a ring-dwarf combo. Once the gate is operating, it is only a matter of time before the ring encounters it and is destroyed. Unfortunately time is not always available, there are only 80000 cycles for the whole battle, including the pre-gate phases. In fact a well designed ring system can almost guarantee that it will not be destroyed by the gate. Take the case of a three-point ring running one process at each point, facing a standing gate. How far will the ring advance in 80000 cycles? 80000 / 3 = 26666, which gives 3.3 laps around the core, ensuring that the ring will encounter the gate. A ring with 10 processes at each point will advance (80000 / 30) = 2666 locations. Since the points are separated by 2667 locations, this ring will also encounter the gate. But a ring with more than 10 processes at each point will not cover the distance from each point to the next before time expires, making it less probable that the gate will be encountered. Also note that all processes do not have to be in the ring, some could be operating a scanner, stone, or dwarf. It is the total number of processes that is important. The magic number of processes-per-point is given by the ratio of total cycles to core size (80000 / 8000) = 10. So that a ring with more than 10 processes per point (average) will not cover the whole core, while a ring with less than 10 will. To take advantage of this anomaly, use multiple rings. For example, two rings of three points, times ten processes equals 60 processes. 60 processes will walk 1333 locations in 80000 cycles. (again, some of the processes could be in a dwarf). If the two rings are spaced 1333 locations apart, each ring will cover half the core. The whole core will be covered, but not by both rings. A standing gate will destroy one ring, but not both, unless it gets lucky and kills the first one very early. Using three rings and allowing some overlap of coverage might also be useful. The main thing is to make sure the entire core is covered, so as to overrun any standing opponent. I'm speculating that the reason several ring implementations on the hill tie so much, is that they have so many processes that they do not actually cover the whole core. They may actually be missing opportunities to destroy non-gated opponents. My upgraded version of Eclipse is an aggressive ring-killer, some results: Opponent Eclipse Wins ----------- -------------- Impression 1 67 Impression 3 40 Silver Bullet 68 repimp 36 is this a ring? Red Dragon 50 "" Tarrasque 50 "" It is also seems to be effective against some of the other participants, though I can't explain some of them. Paul Kline pk6811s@acad.drake.edu From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: Re: overcoming mintardjo gates Message-ID: Date: 28 Oct 92 10:13:58 GMT In article <1992Oct27.142931.1@acad.drake.edu>, pk6811s@acad.drake.edu writes: > The 'mintardjo gate' is a very clever piece of programming designed to > destroy imps and imp-rings. It seems to be adaptable to a number of ... Did you not see my post describing the very same technique as used in "No More Mucking About". Anyway Paul your comments are appreciated. However, there is more than one way to skin a cat. Campbell -- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. Campbell Fraser: fraserc@dcs.glasgow.ac.uk Computing Science Department, University of Glasgow, Glasgow G12 8QQ From: jampel@cs.city.ac.uk (Michael Jampel) Subject: FAQ (Request for Frequently Asked Questions file) Message-ID: <1992Oct28.132751.2845@city.cs> Date: 28 Oct 92 13:27:51 GMT Dear corewar newsgroup, Is there a FAQ file for this group, or some kind of standard reading list online? If so, could it please be posted to the group, or mailed directly to jampel@cs.city.ac.uk Thanks Michael Jampel From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Re: overcoming mintardjo gates Message-ID: <1992Oct28.175143.7814@unlv.edu> Date: Wed, 28 Oct 92 17:51:43 GMT Could someone mail me source to x-hill Imp Ring programs? I'm getting clobbered by them, and want to test a few ideas of my own, but have nothing but the x-hill itself to test them on, since I don't want to take the time designing my own Imp Ring, especially because Mine would probably be far from the norm. -- Eric J. Schwertfeger, maniac@cs.unlv.edu From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) Subject: Mintardjo Gates ??? Message-ID: <72884@hydra.gatech.EDU> Date: 28 Oct 92 22:49:27 GMT I am a little confused about these Mintardjo gates. Could someone explain how they work. I tried to make a gate of my own, but for some reason it doesn't work jmp pit start jmp 0,<-2 bomb dat #-1 pit mov bomb, Date: 29 Oct 92 04:05:58 GMT In my previous posting, I was suggesting to use pre-decrement DAT as part of core-clear's bomb so that scanner/bomber could end up its routine in a form of IMPs gate. Something like: SPL 0, <-n DAT <-n-1 Now, since I believe that such this method is not uncommon. What's if I suggest to just give a common name to identify this method? Like: SPL/DAT gate or waiting gate --- W. Mintardjo -- #include /* Sender: W. Mintardjo (wangsawm@prism.cs.orst.edu) */ main() { printf(".sig? what's .sig?\n"); } From: macaulay@ecr.mu.oz.au (Alex MacAulay) Subject: Re: overcoming mintardjo gates Message-ID: <9230318.16607@mulga.cs.mu.OZ.AU> Date: Thu, 29 Oct 1992 07:54:34 GMT In article <1992Oct28.175143.7814@unlv.edu>, maniac@unlv.edu (Eric J. Schwertfeger) requests: > Could someone mail me source to x-hill Imp Ring programs? > I'm getting clobbered by them, and want to test a few ideas > of my own, but have nothing but the x-hill itself > to test them on, since I don't want to take the time > designing my own Imp Ring, especially because Mine would > probably be far from the norm. Well, the only x-rings I know of are Corona and Springer. I have already posted Springer, so here is Corona. I've also modified Corona for the standard hill (renamed as Nimbus) so I've included that as well. Corona 1.1 is currently KotXH by about 30 points and does very well against leapers. The fighters which it has most problems against are replicators and fighters using standard imps as part of their attack (ie. Edge 1.1, Longworm 1.2 and Trap 6). Against both of these types, Corona tends to tie very often. It loses *very* rarely with W/L/T percentages of about 46/ 7/47! ;redcode-x verbose ;name Corona 1.1 ;author Alex MacAulay ;strategy Creates a 63-point 2-process ring, waits, then sends out a ;strategy core-clear which kills off the ring and the subverted enemy. ;strategy 1.1 - Uses core-clear instead of jumper - better vs replicators. ;kill Corona step equ 127 runup spl 1 spl 1 spl 1 spl 1 spl 1 mov -1,0 spl 1 spl inc spread jmp @spread,#imp inc add #step,spread ; need a dat after this instruction dat 0,0 jstep equ step+4 jprocs equ 48 jbomb equ jptr jfirst equ jptr jlast equ jfrom start spl runup wait djn 0,#104 spl 1 mov -1,0 spl 1 mov From: fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky) Date: Thu, 29 Oct 1992 17:21:22 GMT A standard process ring looks like this: d EQU 2667 imp MOV 0,d SPL 1 SPL 1 SPL 1 SPL 1 JMP <16 JMP imp+2*d JMP imp+d JMP imp JMP imp+2*d JMP imp+d JMP imp ... If we replace it by a spiral: ... JMP imp+2*d+1 JMP imp+d+1 JMP imp+1 JMP imp+2*d JMP imp+d JMP imp JMP imp+2*d+1 JMP imp+d+1 JMP imp+1 JMP imp+2*d JMP imp+d JMP imp ... it cannot be killed by any single bomb. This technique (used by Impression) makes imp MUCH less vulnerable to any kind of attack. ------------------------------------------------------- Dan Nabutovsky fedimit@wisipc.weizmann.ac.il ------------------------------------------------------- From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) Subject: PLASMA scanner->replicator Message-ID: <73060@hydra.gatech.EDU> Date: 29 Oct 92 22:33:33 GMT Hello everyone. I bet you all are wondering how a scanner-replicator works. First of all, it is not doing both at the same time. It scans until it finds something. That gets bombed thoroughly. Now it switches to a replicator. This allows me to have a small target area for other scanners. But against bombers and imps, it doesn't take too long before I turn into a replicator. Yhis allows me to kill most bombers and tie the imps. There is a lot of room for improvement. For example you could use CMP scanning in the main scanning loop to find something quicker. Here's the code: ;redcode verbose ;name PLASMA 4 ;author Wayne Sheppard ;strategy Scanner-Replicator ;strategy Better killing Process ;kill PLASMA bomb equ start-1 ;this should point to dat 0 , 0 start add #3039,loc ;best increment size loc jmz start,-1 cmp #-1,@loc ;don't look at DJN trails slt #100,loc ;program length jmp start mov bomb,@loc ;bomb whatever I found cmp Date: Thu, 29 Oct 1992 22:58:35 GMT It's been 2 years since I first heard about Corewars. It fascinated me from the first moment. Unfortunately though, I did not have an appropriate program, and the version that was on the VM-system then, didn't work. Now, at a time where the word Corewars was somewhere in the outmost corner of my memory =), I notice this group. Moreover, I realize that Corewars is still very alive ! So, my question(s) now. Where can I get a RedCode simulator/interpreter/ compiler for PC ? Has the RedCode undergone any changes since ? Is MARS still 8000 addresses long ? etc...etc... Concretely : Where do I find all the necessary stuff to join the fun ??? I would be VERY grateful !!! Henk. ---------------------------------------------------------------------------- Henk Van Wulpen | Mai laif is bjutifull Engineering and Computer Science | Mai Bet is soft end worm senior at the K.U.Leuven | Wejk ap mai lidl lembs vwulpen@cs.kuleuven.ac.be | Sun yt uyl bi daun. (D.Byrne) ---------------------------------------------------------------------------- From: ronr@ateami2.EBay.Sun.COM (RON RICHARDSON - SUN MICROSYSTEMS) Subject: Re: Wow ! + Help ! Date: 29 Oct 1992 23:41:57 GMT Message-ID: <1cpss5INNaoj@male.EBay.Sun.COM> Me too. Please forward. Ron Richardson In article 19449@cs.kuleuven.ac.be, vwulpen@cs.kuleuven.ac.be (Henk Van Wulpen) writes: | It's been 2 years since I first heard about Corewars. It fascinated me |from the first moment. Unfortunately though, I did not have an appropriate |program, and the version that was on the VM-system then, didn't work. | Now, at a time where the word Corewars was somewhere in the outmost corner |of my memory =), I notice this group. Moreover, I realize that Corewars is |still very alive ! | So, my question(s) now. Where can I get a RedCode simulator/interpreter/ |compiler for PC ? Has the RedCode undergone any changes since ? Is MARS still |8000 addresses long ? etc...etc... Concretely : Where do I find all the |necessary stuff to join the fun ??? | I would be VERY grateful !!! | | |Henk. | |---------------------------------------------------------------------------- |Henk Van Wulpen | Mai laif is bjutifull |Engineering and Computer Science | Mai Bet is soft end worm | senior at the K.U.Leuven | Wejk ap mai lidl lembs |vwulpen@cs.kuleuven.ac.be | Sun yt uyl bi daun. (D.Byrne) |---------------------------------------------------------------------------- From: rdorich@jade.tufts.edu (Rob) Subject: help for newbie Message-ID: <1992Oct30.043854.15061@news.tufts.edu> Date: 30 Oct 92 04:38:54 GMT Hi netters... I'm kind of new to this game and was wondering why the following code doesn't work... to me it seemed to be like a mix between imp and random. DAT #0 RND 3990,-1 SPL @-2 MOV 0,1 It should split once and then we'll have two imps running... I'm assuming that SPL works kind of like C's fork(), it's probably where I'm going wrong.... Can someone help me please? Thanx in advance. Rob -- ------------------------------------------------------------------------------- Roberto Dorich | /~~ \ / ~~/~~ /~~/ /~~ /| / /~~ | SKI /-- X / /__/ /-- / |/ | /-- From: pk6811s@acad.drake.edu Subject: Re: Imp Rings vs Imp Spirals Message-ID: <1992Oct30.085143.1@acad.drake.edu> Date: Fri, 30 Oct 1992 14:51:43 GMT > A standard process ring looks like this: > ... > If we replace it by a spiral: > ... The technique used by Nimbus also creates a spiral: start spl 1 spl 1 spl 1 spl bump go jmp @0,imp bump add #2667,go dat #0 imp mov 0,2667 Fewer lines of code are required to launch the spiral, but it takes a little longer (twice as long?). Also, it only puts one process at each point of the spiral. Perhaps it is most useful when launching a very large spiral (Nimbus = 63 points!), since you double the number of points by adding one line of code - spl 1. Paul Kline pk6811s@acad.drake.edu From: KENT@dirac.physics.jmu.edu (Kent Peterson) Subject: Re: help for newbie Message-ID: <1992Oct30.172039.2403@drycas.club.cc.cmu.edu> Date: 30 Oct 92 22:20:37 GMT In <1992Oct30.043854.15061@news.tufts.edu> rdorich@jade.tufts.edu writes: > Hi netters... > I'm kind of new to this game and was wondering why the > following code doesn't work... to me it seemed to be like a mix > between imp and random. > > DAT #0 > RND 3990,-1 > SPL @-2 > MOV 0,1 This does not work for the very simple reason that RND is not a valid Redcode instruction. Some MARS programs support it, but it is not in the 1988 CoreWar Standard. Also, you have to have execution start on a non-DAT instruction. > It should split once and then we'll have two imps running... Why? Assuming that your version of MARS uses RND and that execution starts at the RND, all that will happen is that a random number gets put in the DAT, a process splits off to the address that number points to, while the other process executes the MOV 0,1. This will produce 1 imp, since the other process executed empty core and probably died, unless it had the good fortune to land in some other program's code. > I'm assuming that SPL works kind of like C's fork(), it's probably > where I'm going wrong.... Can someone help me please? Something like that. You should get a copy of the '88 Standard from somewhere - you could try soda.berkeley.edu, there's a lot of CoreWar stuff there. Also, this newsgroup's FAQ covers the basics of Redcode. > Thanx in advance. You're welcome. Kent Peterson