From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: MNCT Lives! Message-ID: <1994Feb1.032132.14279@news.vanderbilt.edu> Date: Tue, 1 Feb 1994 03:21:32 GMT In article <2ijsa2$rqg@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: >Due to popular request (3 letters!), MNCT has returned! Round 3 was where I >left off, I think. Just to refresh your memory, the rules for round 3 are: > > Style: Standard round-robin (each entry fights each other entry) > Standard: 94 > Coresize: unknown (that is, your program must function in a variety of > coresizes) but always < 64K What about max. warrior length, max. processes, and, most importantly cycles-until-tie? Is cycles-until-tie going to scale with coresize (e.g. 10*coresize) or remain fixed? Remember that the fastest complete core-clear takes 2*coresize cycles. Also, are you going to run round-robins for more than one coresize? >BTW, since this round will incorporate large coresizes, this might be a good >time for me to mention, once again, my optima calculator which handles >coresize up to 64K. [....] Yes, but how is this going to do us any good if we don't know the coresize beforehand :-) (this might be a good time for me to mention that you need the 32-bit pMARS executables (pmars04g.zip) for the large coresize) Things a warrior in a core of unknown dimensions might like to know are what divisors coresize has (to calculate imp-steps, self-avoiding bomb/scan patterns, etc.) and perhaps the approximate size of core (to determine, e.g, the best number of mini-bombers to launch). To find out whether the current coresize is divisible by a certain number is very straightforward in redcode'94: DIVISOR equ 5 org test a dat #-DIVISOR ; if coresize is divisible, so is this test mod #DIVISOR,a jmz divisible,a jmp not_divisible The code below tries to get an idea of how large the core is by binary subdivision. This is a reasonable compromise between speed (40 cycles in a core of 8000) and accuracy (within a power of 2): ;redcode-94 ;name sizer ;strategy Get an idea how large core is (within a power of 2) org sizer cs dat #-1 ;This is coresize-1 sizer div #2,cs add #1,case jmn sizer,cs case jmp @case ;jump somewhere depending on coresize ;trace on ge1 jmp 0 ;core= 1-2 (we would jump to somewhere useful here) ge3 jmp 0 ; 3-4 ge5 jmp 0 ; 5-8 ge9 jmp 0 ; 9-16 ge17 jmp 0 ; 17-32 ge33 jmp 0 ; 33-64 ge65 jmp 0 ; 65-128 ge129 jmp 0 ; 129-256 ge257 jmp 0 ; 257-512 ge513 jmp 0 ; 513-1024 ge1025 jmp 0 ; 1025-2048 ge2049 jmp 0 ; 2049-4096 ge4097 jmp 0 ; 4097-8192 ge8193 jmp 0 ; 8193-16384 ge16385 jmp 0 ; 16385-32768 ge32769 jmp 0 ; 32769-65536 (actually, this is the first time I find mul/div/mod really useful) > - Michael Constant Looking forward, Michael! -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: MNCT Lives! Date: 1 Feb 1994 20:15:34 GMT Message-ID: <2imd96$k9b@agate.berkeley.edu> In article <1994Feb1.032132.14279@news.vanderbilt.edu>, Stefan Strack wrote: >What about max. warrior length, max. processes, and, most importantly >cycles-until-tie? Is cycles-until-tie going to scale with coresize (e.g. >10*coresize) or remain fixed? Remember that the fastest complete core-clear >takes 2*coresize cycles. Max warrior length: 200 Max processes: 8000 Cycles to tie: 50000 + 5*coresize (this seems reasonable to me. opinions?) *Min* coresize: 1000 >Also, are you going to run round-robins for more than one coresize? Yes. Probably for 3 different coresizes; more if time permits. -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- h f+(++) g+ w+ t++(+++) r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: MNCT Cumulative Scores Date: 1 Feb 1994 20:54:56 GMT Message-ID: <2imfj0$l39@agate.berkeley.edu> Here are the cumulative scores for MNCT to date. Lower is better. Rank Name Score -------------------------------------- 1 Anders Ivner 27 2 Stefan Strack 28 3 Alex MacAulay 63 4 Na'ndor Sieben 100 5 J. Layland 132 6 P. Kline 133 7 Wayne Sheppard 150 8 P. Baillargeon 160 9 Bill Shubert 167 10 Timothy Laswell 170 11 Campbell Fraser 180 12 Marcus Williams 183 13 Fredrik Ohrstrom 190 14 Jonathan Wolf 200 14 Mintardjo W. 200 They were calculated to make each round, regardless of the number of entrants, worth the same amount: for each round, I divided the number of participants into 100 to get the "base score" for that round. Then, for each person, I multiplied this base score by their ranking for that round. If a person did not enter a round, they got 100 points (the worst possible). Thus, since the base score for round 1 was 8.3, and for round 2 was 10, the best possible score for rounds 1 and 2 would be 18 (I rounded enerything to the nearest integer). The worst possible is of course 200. I probably made many mistakes calculating this; let me know if you disagree with your score (or with the scoring system in general). -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- h f+(++) g+ w+ t++(+++) r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: ICWS'94 draft revision: call for last minute comments Message-ID: <1994Feb2.010023.4384@news.vanderbilt.edu> Date: Wed, 2 Feb 1994 01:00:23 GMT I am finally going to update the ICWS'94 draft document, correcting a number of typos and ambiguities that were spotted and posted to rec.games.corewar by: Planar Ander Ivner Albert Ma Steven Morrel Sorry if I missed somebody; please send me your changes again. There will also be some changes to the sample simulator code in the draft. These address problems that surfaced while implementing the pMARS simulator: - DIV/MOD: behavior upon division by zero is undefined - DJN.{F|I|X}: jump if *both* A and B are non-zero - JM{Z|N}.{AB|BA}: work like {I|F|X} (not intuitive) If you don't know what I am talking about, grab soda.berkeley.edu:/pub/corewar/documents/icws94.draft and post your corrections (by the end of the week please, or they won't make it into this revision). Cheers, Stefan (stst@vuse.vanderbilt.edu) From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: SJ-4a Date: 2 Feb 1994 17:34:50 GMT Message-ID: <2ioo7q$h2@elroy.jpl.nasa.gov> Here is the code for SJ-4a, a SPL-JMP bomber inspired by Leprechaun 1b. The two-pass clear and gate are not quite good enough to kill short imp spirals-- it is most annoying to see them get stunned up to the process limit, then revive during the second pass and hit me before the gate kicks in. Something to work on in my copious spare time. The big change from Leprechaun or other fighters using this B-scanning/ bombing strategy is that I bomb with JMP instructions, rather than conventional bombs like SPLs or DATs. The program checks the B-field of the instruction pointed to by the JMP instruction. If it is zero, the program loops to bomb another address; otherwise it drops a SPL-JMP bomb at the targeted location. Against scanners, the JMP instructions are probably lethal, so I act like a 2/3-c bomber. Against paper, I am almost as effective as dropping two SPL-JMP bombs per 7-instruction loop, which is slightly faster than a straightforward SPL-JMP bomber, which uses 4 instructions per bomb. Battles with Winter Werewolf and Imprimis are roughly even; but I lose to conventional bombers (too fast) and most imp-spirals (bombers too fast, plus the reincarnating spirals mentioned above). My original idea in developing this was to create a Leprechaun-style vampire, but I could not figure out how to do what I wanted (I needed double-indirect addressing @@). I did not put much effort into optimizing the constants (beyond debugging the 2-pass core clear), and I have a few ideas on modifying the core clear, but this is the version on KotH for the last two months. ;redcode ;name SJ-4a ;author J.Layland ;strategy Leprechaun-like SPL-JMP bomber, 2-pass clear, gate inc equ -16*7 ; mod 16 bomb offset equ 24 ; mod 8 overall b equ scan-offset loc equ b+1+48 bomb dat <-49, #0 start add #inc, scan mov j1, @scan scan jmz -2, @test+offset ;xbreak mov scan, @2 ; dec protected test mov j2, @b mov s, __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| February 2, 1994 Issue #1 This is the first edition of _The '94 Warrior_, a new bi-weekly (twice a month) newsletter that will discuss the ICWS '94 Draft hills on Stormking -- in much the same way as Paul Kline's _PUSH OFF_ newsletter covers the '88 Standard hill on KOTH. The 1994 redcode (draft) standard offers some exciting advantages and challenges not available in the current (1988) standard. It is my hope that this newsletter will help to increase enthusiasm for the new standard among the newsgroup readers, and will ease its transition. (After all, if you're going to live with it, you might as well enjoy it! ;^) If you are unfamiliar with the '94 draft standard, you can learn more about it by reading the FAQ for this newsgroup. In addition, the program pMARS includes a highly recommended tutorial on the new standard. Feel free to send me e-mail if you have any difficulty finding either of them, or if you have any other questions. First off, let's start with an introduction to the hills: ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instrucitons Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions This hill is exactly like the standard for the KOTH hill, except that it also allows you to use instrutions from the '94 standard. Any programs you have written for KOTH will work exactly the same on this hill. In fact, a recent article in the rec.games.corewar newsgroup recommended that everyone automatically submit their program to the '94 draft hill whenever they send it to the standard KOTH hill. This sounds like a good idea to me! The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 42/ 24/ 35 NC II Wayne Sheppard 160 55 2 48/ 42/ 10 Rave Stefan Strack 155 38 3 47/ 42/ 11 Rave 3 Stefan Strack 153 27 4 45/ 36/ 19 Fast Food v2.1 Brant D. Thomsen 153 13 5 46/ 39/ 15 SJ-4 J.Layland 152 4 6 47/ 43/ 9 Medusa's v6 Mintardjo & Strack 151 60 7 37/ 23/ 40 Snake Wayne Sheppard 151 10 8 38/ 26/ 35 Sphinx v5.1 W. Mintardjo 151 58 9 36/ 23/ 41 ttti nandor sieben 149 11 10 45/ 40/ 15 Sylvester v1.0 Brant D. Thomsen 149 37 11 36/ 24/ 40 ttti94 nandor sieben 148 6 12 45/ 42/ 13 Fire Storm v1.1 W. Mintardjo 148 61 13 37/ 28/ 35 JustTakingALookSee J.Layland 145 54 14 43/ 41/ 16 Ntttgtstitd Simon Hovell 145 1 15 42/ 41/ 18 Beholder's Eye v1.7 W. Mintardjo 143 67 16 40/ 40/ 19 tiny J.Layland 141 35 17 42/ 46/ 12 infraRed nandor sieben 137 7 18 37/ 37/ 27 RotLD TNG 2 nandor sieben 136 21 19 40/ 54/ 6 Testdec 0.8 Jonathan Wolf 127 2 20 31/ 38/ 31 Plasma Wayne Sheppard 125 9 I have found the code for many of these programs on SODA, and several others have been posted to the newsgroup. It may be revealing that the program holding strong in the #1 position is written in the '88 standard. (Correct me if I'm wrong, Wayne. :^) ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The size 55,440 was chosen for the core because this number has so many divisors. (The values 2 - 12 are all possible.) In addition, since the number 55,441 is prime, imp-spirals are not as effective. Because of the increased size of the core, it is still uncertain what the best strategies will be for this hill. (CG-X, by the way, is a group of modified stones.) One big advantage of this hill is that you are _guaranteed_ to get on it. In other words, WE NEED MORE PROGRAMS! The current ICWS '94 Experimental hill: # %W/ %L/ %T Name Author Score Age 1 79/ 7/ 14 CG-X IV Brant D. Thomsen 250 6 2 79/ 17/ 4 Rave 3 (55440) Stefan Strack 241 7 3 76/ 21/ 3 No Ties Allowed Wayne Sheppard 231 12 4 69/ 21/ 10 BS J.Layland 217 14 5 67/ 22/ 11 testing testing Fredrik Ohrstrom 213 2 6 63/ 18/ 19 BigImps James Layland 208 15 7 62/ 18/ 20 Frantic 0.9 A Lee 205 16 8 59/ 26/ 16 Road Hammer 0.3 Simon Hovell 192 13 9 59/ 32/ 8 bunker t3 P.Kline 186 3 10 54/ 24/ 22 Iron Gate Wayne Sheppard 183 11 11 41/ 53/ 6 Tiny Ring J.Layland 128 9 12 36/ 64/ 0 test 94X Anonymous 107 5 13-20 No entries ______________________________________________________________________________ HINTS and HELPS: Some of the recent discussion in rec.games.corewar has suggested that the new standard will not result in any new forms of programs -- only shorter ones. Whether or not this is true, programming redcode using the new standard is an interesting challenge because there are so many more ways to do these same things. One of the things I would like to do with this newsletter is to share with you some of the hints, quirks, tricks and trivia I have found and discovered that relate to the new standard. With the '94 standard, it is possible to allow every mode for both the A and B values of any instruction. One of the interesting possibilities this allows is to have an instruction use the "#" addressing mode to refer to itself. I first saw this used by W. Mintardjo in his program Lemming v1.0, although I believe it was possible to use this trick back in the '86 standard. (Again, please correct me if I'm mistaken. The '86 standard was before my time. ;-) Take a look a the following redcode instructions: MOV #100, 1 This is the '94 equivalent of the common imp (MOV 0, 1). By choosing the first value for this instruction at random, and using it as an imp-spiral instead of a common imp, you make it impossible for imp-spiral scanners like Iron Trap to function effectively. SPL #732, <-17 This instruction functions exactly like SPL 0. It can be used very effectively in a SPL/JMP bomber, or to make your core clearing code more robust. JMP #201, <-10 Anyone who has seen my source code to Distance or Fast Food should recoginize this statement. It is the '94 equivalent to a "wimp". If you have a program that generates a lot of processes, you can put this statement (with one process) somewhere else in the code as a defense in case your main code stops running. In addition, if this instruction is the only one you have left, it will stop any "standard" imp-spirals your opponent still may have. Since it is possible, using the 94 standard, to manipulate the A value of instructions so effectively, having the value of the A field's instructions be irrelevant can be a big advantage. For example, in some of my earlier programs I used a DJN.A stream. By using the above technique, my recent programs are much more robust -- and the DJN.A streams much less dangerous. Another advantage of using this trick is that I have also been able to reduce the size of some of my programs by using this a value to store data -- instead of DAT statements. As any veteran corewar programmer can tell you, one line can make a big difference! Of course, one disadvantage with this technique is that it can make your code visible to any A-Field scanners. ("Enigma" by Stefan Strack is the only one I've seen so far, but ...) ______________________________________________________________________________ I NEED YOUR HELP: if you have any comments or questions about the '94 hills or the '94 standard that you think might be of general interest, please let me know. Without your assistance, these newsletters could start to get very dry -- and nobody wants that to happen. (Right?) Also, please submit your programs to the '94 hills. We'd love to have your best KOTH warrior on the standard '94 hill, and I've found that the best way to learn the '94 standard is to take an '88 standard program and try to improve it. Not only will you get the additional challenge and enjoyment of learning the new standard, but you will be better able to correct and critique the latest drafts of the new standard when they arrive. Good luck, and happy computing! ______________________________________________________________________________ Brant D. Thomsen, Editor Snail mail: 1197 E. 6290 S. (bdthomse@peruvian.cs.utah.edu) Salt Lake City, UT 84121 University of Utah U.S.A. -- Brant D. Thomsen The teaching of BASIC in schools bdthomse@peruvian.cs.utah.edu should be considered a criminal act. (University of Utah) - Dijkstra From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Redcode Tutorial Date: 3 Feb 1994 20:20:02 GMT Message-ID: <2irm9i$6tb@agate.berkeley.edu> In article <2ir8un$q21@ionews.io.org>, wrote: >The tutorial.2 mentions the various places that arguments for SPL can be, >but not what they do!! for example, if I have SPL #6 in my code, what >does that do for me? The #6, specifically. Same thing for a JMP having two >operands. The instruction SPL #6 is illegal in ICWS'88. In the '94 standard, however, it is treated just like a SPL 0 instruction. In fact, as a general rule, in the '94 standard, any time you use immediate (#) addressing when it doesn't make sense, it is treated like a 0. There are two general reasons you might want to do this: it saves space by putting data into an instruction where a 0 would have been, and it make the 0 invulnerable to decrements and increments (i.e. your SPL #6 would continue to function as a SPL 0 even if it was decremented to SPL #5). The JMP with two operands ignores the seond. >PS: do you all think I should use ICWS '88 or '94? '94, definitely. You might want to hold off on writing a tutorial, however, until you are sure on what all the instructions do - it wouldn't be nice to distribute misinformation, however well-written. -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- h f+(++) g+ w+ t++(+++) r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: The '94 Warrior (Newsletter) Message-ID: <1994Feb3.221857.16483@news.vanderbilt.edu> Date: Thu, 3 Feb 1994 22:18:57 GMT In article <1994Feb2.223028.20642@hellgate.utah.edu> bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) writes: >This is the first edition of _The '94 Warrior_, a new bi-weekly (twice a >month) newsletter that will discuss the ICWS '94 Draft hills on Stormking -- >in much the same way as Paul Kline's _PUSH OFF_ newsletter covers the '88 >Standard hill on KOTH. Nice job, Brant. Looking forward to the next issue. For those without a FAQ list at hand, the stormking address is koth@stormking.com, and ;redcode-94 selects the "regular" '94 hill, ;redcode-94x selects the "big core" '94 hill. > MOV #100, 1 > > This is the '94 equivalent of the common imp (MOV 0, 1). > By choosing the first value for this instruction at random, > and using it as an imp-spiral instead of a common imp, > you make it impossible for imp-spiral scanners like Iron Trap > to function effectively. I am sure this is just a typo, but before a hord of suicidal would-be imps is launched towards the stormking hills ... This doesn't quite work: the default modifier for this opcode/mode combination is .AB to emulate the behavior of this instruction under ICWS'88. So MOV.AB #100,1 simply writes #100 to the B-value of the next address, and the process dies on the next cycle. MOV.I #100,1 is what you want, because the instruction pointed to by an immediate operand is the same instruction. Exercise for the reader: What does MOV.BA #99,#100 do? -Stefan (stst@vuse.vanderbilt.edu) From: wsheppar@sct.edu (Wayne Sheppard) Subject: Re: MNCT Lives! Date: 3 Feb 1994 22:23:29 -0500 Message-ID: <2isf3h$130c@st6000.sct.edu> In article <1994Feb1.032132.14279@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: > >What about max. warrior length, max. processes, and, most importantly >cycles-until-tie? Is cycles-until-tie going to scale with coresize (e.g. >10*coresize) or remain fixed? Remember that the fastest complete core-clear >takes 2*coresize cycles. Don't take this too seriously, but I can write complete core-clears that take less time than 2*coresize. mov bomb,<-1 mov bomb,<-2 jmp -2 This would take 1.5*coresize. ;-) Wayne -- Wayne Sheppard wsheppar@st6000.sct.edu Date: Fri, 4 Feb 1994 15:10:24 MST From: Message-ID: <94035.151024AHNAS@ASUACAD.BITNET> Subject: pMARS questioner Please fill out the questioners included with the last release of pMARS. We are very much in need of this to decide which way to go. Nandor. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: revised ICWS'94 draft at soda Message-ID: <1994Feb5.003959.11424@news.vanderbilt.edu> Date: Sat, 5 Feb 1994 00:39:59 GMT soda.berkeley.edu:/pub/corewar/incoming/icws94.0202.Z Revision 3.2, dated Feb. 2, ca. 32K compressed. If you can't ftp, I'd be glad to email it to you. I applied all changes suggested here; see the introduction for details. Please comment/correct as much as you can. I am sure I introduced some errors trying to fix old ones. Especially look at the formal grammar and the new section on default modifiers (ICWS'86/88 emulation, A2.1.1/2). Also, there are still a lot of blanks, esp. in the appendix that need filling in. Thanks. I am not quite happy with read/write limits and how they're anchored into the standard; should we keep them in the present form (i.e. wrap-around, mini cores), then I think we also need a "jump/split" limit. Perhaps we should keep the *concept* of read/write/(jump) limits in the draft, but allow for different implementations (mini-core, x-hill, ..). Ideas? -Stefan (stst@vuse.vanderbilt.edu) From: d92-foh@dront.nada.kth.se (Fredrik Öhrström) Subject: Impurge source Date: 5 Feb 1994 13:54:46 GMT Message-ID: <2j08f6$1ck@news.kth.se> I posted this a year ago, but here it is again.... ;redcode ;name Impurge ;author Fredrik Ohrstrom ;kill Impurge bomber mov #26, counter add #26, comper boom mov bomb, Date: Sat, 5 Feb 1994 17:50:36 GMT Don't remember if I posted this, so here it is (again?): It is the only one of my programs lately without antivamp. The ability to override gates kills most (not Christopher?!) vampires very well. ;redcode ;name Cannonade ;kill Cannonade ;author P.Kline ;strategy break gates, score points ;strategy stone and gate-busting imp-spiral(s) impsize2 equ 2667 impsize1 equ 2668 offset1 equ 1833-impsize2 offset2 equ offset1+15 offset3 equ offset1+15+2 decst equ 400-(start*57) stinc equ 190 start mov imp1,imp1+offset2+5 mov imp1, I have recieved 2 submissions already, but both of them are purely '88 programs! Does everyone know that round 3 accepts '94 code? I think this applies especially to the author of LS v1.0 (you know who you are). You could improve your program a little by using '94 extensions... -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: daffyd@ionews.io.org (Daffyd) Subject: Re: Redcode Tutorial Date: 6 Feb 1994 00:39:23 -0500 Message-ID: <2j1vqb$1o6@ionews.io.org> mconst@soda.berkeley.edu (Michael Constant) writes: >In article <2ir8un$q21@ionews.io.org>, wrote: >>The tutorial.2 mentions the various places that arguments for SPL can be, >>but not what they do!! for example, if I have SPL #6 in my code, what >>does that do for me? The #6, specifically. Same thing for a JMP having two >>operands. >The instruction SPL #6 is illegal in ICWS'88. In the '94 standard, however, it >is treated just like a SPL 0 instruction. In fact, as a general rule, in the >'94 standard, any time you use immediate (#) addressing when it doesn't make >sense, it is treated like a 0. There are two general reasons you might want to >do this: it saves space by putting data into an instruction where a 0 would >have been, and it make the 0 invulnerable to decrements and increments (i.e. >your SPL #6 would continue to function as a SPL 0 even if it was decremented to >SPL #5). [material deleted] >-- > - Michael Constant > mconst@soda.berkeley.edu >GM/CS d? p c++(++++) l u(++) e(*) m++ s--/- h f+(++) g+ w+ t++(+++) r+@ !y So, what if it was SPL 6? or SPL @6? Do you all think that ICWS '94 is going to become THE standard? The docs now always say "proposed" '94 standard... From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Redcode Tutorial Date: 6 Feb 1994 21:58:22 GMT Message-ID: <2j3p5u$6lj@agate.berkeley.edu> In article <2j1vqb$1o6@ionews.io.org>, Daffyd wrote: >So, what if it was SPL 6? or SPL @6? Do you want a general answer, or just for this specific case? Specifically, SPL 6 will add the instruction 6 core locations forward of itself to the process queue; SPL @6 will look at the B-field of the instruction 6 locations ahead of itself and go that many more locations forward and add *that* location to the process queue. For a general answer, try looking at tutorial.2 again, as well as any of the example programs you will find on soda.berkeley.edu in /pub/corewar/redcode. >Do you all think that ICWS '94 is going to become THE standard? The docs >now always say "proposed" '94 standard... Personally, I think that it will. Perhaps there will be a few minor changes, but I believe that corewar needs a new standard and the ICWS would find it difficult to refuse a complete and tested standard like the one we (readers of rec.games.corewar, that is) are proposing. -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: boeren@vsl.ist.ucf.edu (David Boeren) Subject: Revised ICWS'94 source Date: 7 Feb 1994 05:47:03 GMT Message-ID: <2j4kkn$k16@pegasus.cc.ucf.edu> Just a quick note. I tried to compile the sample source code for ICWS94 and it says "Multiple declaration for 'noqueue'". I'm using Borland 3.1. I see the problem, and it's easy to fix, but I don't see the advantage of implementing this extremely long and unwieldy macro. It doesn't save any code size, after all. Why not do it as a real function? This should not be too hard to do, and would be a little less grotesque to read. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Revised ICWS'94 source Message-ID: <1994Feb7.073140.26149@news.vanderbilt.edu> Date: Mon, 7 Feb 1994 07:31:40 GMT In article <2j4kkn$k16@pegasus.cc.ucf.edu> boeren@vsl.ist.ucf.edu (David Boeren) writes: > >Just a quick note. I tried to compile the sample source code for ICWS94 and >it says "Multiple declaration for 'noqueue'". I'm using Borland 3.1. > So it actually compiles (or almost)? I didn't think anyone would try :-) I'll fix the multiple label and get rid of that insiduous goto. >I see the problem, and it's easy to fix, but I don't see the advantage of >implementing this extremely long and unwieldy macro. It doesn't save any >code size, after all. The original draft had the code simply repeated 5 times; point of Planar's macro was to increase readability and decrease *document* size. > Why not do it as a real function? This should not be >too hard to do, and would be a little less grotesque to read. > Wouldn't work, at least not without greatly complicating the code. The 'op' in ARITH(op) is an arithmetic operator that can't simply be passed to a function. -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: MTS and curses version of pMARS Message-ID: <1994Feb7.182155.2511@news.vanderbilt.edu> Date: Mon, 7 Feb 1994 18:21:55 GMT James Ojaste wrote a while ago: >recommend pmars3g - pmars4 is out, but I've encountered situations where >programs can get negative scores... Turns out James used the Curses-display version of pMARS with the tournament scheduler MTS, and this one was reporting bogus results. Sorry I forgot to put this in the documentation: Do not use MTS with the curses-display version of pMARS, or if you have to, specify "-v 0" on the command line to turn the display off. Not only is the curses display way too slow for any serious tournament, it also seriously confuses MTS which is trying to parse pMARS's output for the win/loss/tie triplet. -Stefan (stst@vuse.vanderbilt.edu) From: kisrael@jade.tufts.edu (Kirk Israel) Subject: New RedCode Paradigm (flamebait?) Message-ID: Date: Tue, 8 Feb 1994 16:31:13 GMT I'm kind of a lurker, and really haven't had a chance to build my own CoreWarriors, (like, well, any I would dare submit to a hill) but this thought occured to me: RedCode is alot like assembly..part of the pleasure is getting back into the guts of the machine to produce elegant, haiku-like warriors...but has any one ever thought of a whole new paradigm for RedCode (it would probably need a whole new name) that was more based on C or some other structured language? C has the ability to dive into memory like RedCode does, although this new paradigm might try to find a different form of abstraction for the battles, because so much tends to be hidden by the compiler nowadays, unlike assembly... I realize there would be thousands of difficulties with this, like forming a new standard, difficulties in making compilers that'll run exactly the same in different implementations, and maybe a lack of interest in general...but I think it might be an interesting thing to argue about for a while... Flame if you must, I'm wearing my asbestos underwear. -KIRK -- _____ -O\O Kirk Israel \\ "Life is so peculiah don't let anybody fool ya!" ( = ) kisrael@jade.tufts.edu \\ --Five Guys Named Moe From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: New RedCode Paradigm (flamebait?) Date: 8 Feb 1994 23:55:08 GMT Message-ID: <2j98os$8ql@agate.berkeley.edu> Kirk Israel wrote: > [...] but has any one ever thought >of a whole new paradigm for RedCode (it would probably need a whole new >name) that was more based on C or some other structured language? This might be interesting, but it seems to me that if the paradigm stayed close to the current corewar standard (i.e. two programs in memory, each tries to get the other to execute an invalid instruction) that we would have some major problems. First of all, many of the low-level memory-manipulating functions would be pretty much lethal to an enemy. We could eliminate this threat, however, by restricting memory access to, say, blocks of 8 bytes or less. A deeper problem would be the lack of any sort of SPL instruction. Without SPL, stone-type programs would easily beat any others: paper could not exist (or indeed any paper-like program which tries to find safety in numbers), and stone beats scissors. I believe that this would hold true even in the new, structured language. However, if we abandon the current corewar paradigm, we will discover an interesting game called C-robots where you write code for a robot in C and it fights aginst other C-robots. Note that there is a fundamental difference from corewar in that it is the *robots* that are fighting, not the programs themselves. If you would like more info on C-robots, ask someone else because I don't know much about it except where you can get a copy, and (I assume) you can use archie yourself :-) -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: wisej@acf4.nyu.edu (wisej) Subject: Re: New RedCode Paradigm (flamebait?) Date: 9 Feb 1994 04:29:07 GMT Message-ID: <2j9oqj$ckk@cmcl2.NYU.EDU> mconst@soda.berkeley.edu (Michael Constant) writes: >Kirk Israel wrote: >> [...] but has any one ever thought >>of a whole new paradigm for RedCode (it would probably need a whole new >>name) that was more based on C or some other structured language? Or, possibly, has anyone considered writing a translator for any other language that would compile into redcode? This would produce valid redcoed programs, which could be run on standard redcode simulators, but would be different from the programmer's viewpoint. it would be interesting to see if ICWS '94 provides a versatile enough instruction set for the implementation of any high level languages... From: trodrigu@kirk.ecs.umass.edu (Tao Rodriguez-Seeger) Subject: Re: New RedCode Paradigm (flamebait?) Date: 9 Feb 1994 06:11:38 GMT Message-ID: <2j9uqq$bq1@risky.ecs.umass.edu> For folks with Macintosh, there's Robowar in which you program a mid-level language to control robot combatants. - Stephen Linhart From: jayhan@cs.washington.edu (Jay Han) Subject: Re: New RedCode Paradigm (flamebait?) Message-ID: Date: 09 Feb 1994 10:51:41 GMT In article <2j9oqj$ckk@cmcl2.NYU.EDU> wisej@acf4.nyu.edu (wisej) writes: > Or, possibly, has anyone considered writing a translator for any other language > that would compile into redcode? This would produce valid redcoed programs, > which could be run on standard redcode simulators, but would be different from > the programmer's viewpoint. it would be interesting to see if ICWS '94 > provides a versatile enough instruction set for the implementation of any high > level languages... No way. Redcode lacks registers, stacks, and subroutines. That means there is no easy way to implement a procedure call. The closest you can get is to store the return address inside the procedure itself. But then the procedure is not re-entrant. Moreover, it lacks index registers, so it takes a huge amount of arythmetics to have arrays. However, I think Redcode is complete, i.e. you *can* program pretty much anything, if you're willing to spare the convoluted constructs. It doesn't mean that making a compiler is an interesting thing. If we want to have machine language powerful enough for high-level languages, we might consider MIX, the imaginary computer in Knuth's books. How about taking MIX and add the addressing modes, DAT, SPL, and see what comes out? It won't be a simple language anymore, for sure, but who said mastering Redcode was simple? -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: Michael N Nonemacher Subject: Re: New RedCode Paradigm (flamebait?) Date: Wed, 9 Feb 1994 11:13:37 -0500 Message-ID: Excerpts from netnews.rec.games.corewar: 9-Feb-94 Re: New RedCode Paradigm (f.. by wisej@acf4.nyu.edu > Or, possibly, has anyone considered writing a translator for any other languag > e > that would compile into redcode? This would produce valid redcoed programs, > which could be run on standard redcode simulators, but would be different from > > the programmer's viewpoint. it would be interesting to see if ICWS '94 > provides a versatile enough instruction set for the implementation of any high > > level languages... While writing in a high-level language may be simpler, there are lots of people who will write their programs in redcode to get better performance. Even the best redcode compiler couldn't match some of the redcode I've seen lately, so I think any "compiled" warrior wouldn't stand a chance. Of course, if warriors get complex enough that writing in redcode is just too complex and time-consuming (with a huge core and 1,000 line warriors, for example), a compiler might be useful. But I think there will still be people who will gladly program their warriors in redcode for the added performance. But, that's just my opinion... ;----------------------------------------------- ; "I wanna talk today about Smug people ; They think they're so good, they ain't good! ; No, they ain't good at all, I'll tell you why ; You wanna be a good man, you look at me ; I'm gonna talk to you about humility, cause I GOT IT! ; I'm gonna talk to you about righteousness, cause I GOT IT! ; I'm good, I'm humble, I'm BETTER THAN YOU! ; You wanna be a humble man, you look at me ; You say Brother, how can I be humble? ; I DON'T KNOW how you can be humble! ; It took me a long time to get this way, ; But thank God, I've arrived!" ; - Steve Taylor, "Smug," Squint ; ; Michael N. Nonemacher ; Carnegie Mellon University ; mn2f+@ andrew.cmu.edu ;----------------------------------------------- From: jayhan@cs.washington.edu (Jay Han) Subject: Re: New RedCode Paradigm (flamebait?) Message-ID: Date: 09 Feb 1994 16:06:10 GMT In article kisrael@jade.tufts.edu (Kirk Israel) writes: > Maybe as a base for the language we could start with simple > commands that group current commands: like say a one-line > imp or vampire or gate generator. This would just be a start, > though. Now *that* is an interesting idea, and I think it has more or less been proposed earlier here. The idea was to have a "high-level" Redcode macro-language with simple building blocks (loop, imp, bootstrap, scanner, etc.) and being able to mix-and-match them to produce a complete program which would later be hand-tuned. Personally, that's not the way I design a warrior, though. > > A deeper problem would be the lack of any sort of SPL instruction. > > Without SPL, stone-type programs would easily beat any others: paper could not > > exist (or indeed any paper-like program which tries to find safety in numbers), > > and stone beats scissors. I believe that this would hold true even in the > > new, structured language. > > But why couldn't a new higher-level program have a command like SPL, > that'll split execution among two subroutines 'simultaneously'- > almost like an emulation of a parallel processor... > (Hmmm- now there's a thought- how 'bout Core War hardwired > into a massively parallel computer- and maybe with hundreds > of programs loaded at once- Welcome to the Jungle- or has > this been thought of before?) SPL is not the major problem. After all, we do fork() all the time. However, one problem is the re-entrance of the routines. I don't see how you could implement re-entrance with the current Redcode. And yes, there *are* processors that support multiple hardware threads in one processor. About massively parallel stuff. The idea has crept up every now and then, but nobody submitted a draft rule for a system having more than two warriors at the same time in the core. There was some talk about cooperative warriors. I also remember reading about a system where you'd have a group of 3 warriors, say A B C, and B would be launched when A died, and C when B died, allowing you to have three totally different strategies in separate stages. > And also, could some kind soul take a minute to explain the > paper beats rock beats scissors beats paper metaphor? > I take it 'paper' is a program that proliferates like mad... > (Would this be in some sort of FAQ?) That must be in the FAQ. The idea is that paper = replicators, scissors = scanners, and stone = bombers, and they are vulnerable in a circular way. However, most warriors these days have at least two parts, e.g. stone+paper. Also, the equation doesn't count imp spirals and gates, which are still a subject of ongoing debate (about 2668 imp spirals and Iron Trap). > > However, if we abandon the current corewar paradigm, we will discover an > > interesting game called C-robots where you write code for a robot in C and it > > fights aginst other C-robots. Note that there is a fundamental difference > > from corewar in that it is the *robots* that are fighting, not the programs > > themselves. > > I've seen it, though never taken the time to use it... > Is there any newsgroup that ever talks about it? > (Sounds like the old Origin game Omega, where you > programmed cybertanks and set them out to battle- > I was distressed how well by tank that just sat at > the bottom and waited for the computer to come to it > did....) I think the first incarnation of this game was on Apple II, a game called RobotWar, back in 1981 or so. It was very neat, with a simple language (move, sense, aim, shoot!) and a sophisticated tourney manager (you could make it run overnight). -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: daffyd@io.org Subject: Pits, Vampires, and the new Tutorial Date: 9 Feb 1994 17:07:17 -0500 Message-ID: <2jbmql$2vr@r-node.io.org> Hi, all. As most of you know, I am in the process of writing a corewar tutorial. To this end, I would like some help since I am pretty bad at it myself! No.1: I don't understand the concept of pits. Could someone please explain them to me (prefferably along with some example code)? No.2: What is a vampire? How do they work? What is an antivamp? How do they work? No.3: Could someone send me the simplest examples you have of each of the following: A vampire. An antivamp. An imp. A paper. A scissors. Thank you for your time. I will post the first draft of the tutorial here. daffyd@io.org From: kisrael@jade.tufts.edu (Kirk Israel) Subject: Re: New RedCode Paradigm (flamebait?) Message-ID: Date: Wed, 9 Feb 1994 19:58:11 GMT In article <2j98os$8ql@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: Kirk Israel wrote: > > [...] but has any one ever thought > >of a whole new paradigm for RedCode (it would probably need a whole new > >name) that was more based on C or some other structured language? I'm gonna say some things in this post that will betray my newbie nature: please forgive. > This might be interesting, but it seems to me that if the paradigm stayed close > to the current corewar standard (i.e. two programs in memory, each tries to get > the other to execute an invalid instruction) that we would have some major > problems. First of all, many of the low-level memory-manipulating > functions would be pretty much lethal to an enemy. We could eliminate this > threat, however, by restricting memory access to, say, blocks of 8 bytes or > less. Sorry, I don't know enough about theoretical C to see what commands you are talking about here, except for things like memset that could blanket an indeterminately-large area with 0s...but I was thinking more of a new language, structured but not neccesarily with C commands.... Actually, C might be too powerful: maybe a "sub-C", like the kind of code a compiler generates halfway through a compile... Maybe as a base for the language we could start with simple commands that group current commands: like say a one-line imp or vampire or gate generator. This would just be a start, though. > A deeper problem would be the lack of any sort of SPL instruction. > Without SPL, stone-type programs would easily beat any others: paper could not > exist (or indeed any paper-like program which tries to find safety in numbers), > and stone beats scissors. I believe that this would hold true even in the > new, structured language. But why couldn't a new higher-level program have a command like SPL, that'll split execution among two subroutines 'simultaneously'- almost like an emulation of a parallel processor... (Hmmm- now there's a thought- how 'bout Core War hardwired into a massively parallel computer- and maybe with hundreds of programs loaded at once- Welcome to the Jungle- or has this been thought of before?) And also, could some kind soul take a minute to explain the paper beats rock beats scissors beats paper metaphor? I take it 'paper' is a program that proliferates like mad... (Would this be in some sort of FAQ?) > However, if we abandon the current corewar paradigm, we will discover an > interesting game called C-robots where you write code for a robot in C and it > fights aginst other C-robots. Note that there is a fundamental difference > from corewar in that it is the *robots* that are fighting, not the programs > themselves. I've seen it, though never taken the time to use it... Is there any newsgroup that ever talks about it? (Sounds like the old Origin game Omega, where you programmed cybertanks and set them out to battle- I was distressed how well by tank that just sat at the bottom and waited for the computer to come to it did....) > -- > - Michael Constant > mconst@soda.berkeley.edu -KIRK -- _____ -O\O Kirk Israel \\ "Life is so peculiah don't let anybody fool ya!" ( = ) kisrael@jade.tufts.edu \\ --Five Guys Named Moe From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: New RedCode Paradigm (flamebait?) Date: 9 Feb 1994 20:36:29 GMT Message-ID: <2jbhgd$1ki@agate.berkeley.edu> >For folks with Macintosh, there's Robowar in which you program >a mid-level language to control robot combatants. Great game, highly recommended. It's sort of like corewar except it has some much higher-level commands, most notably trig functions and if-then-else. But what's really neat about it, compared to corewar, is that a long program is not a disadvantage, and the length limit is essentially infinite. This ends up producing *very* smart robots... the level of sophistication is quite amazing compared to corewar. Now if I only had a Mac to play it on... I spend altogether too much time at friends' houses, writing and debugging RoboWar programs... -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: New RedCode Paradigm (flamebait?) Date: 9 Feb 1994 20:56:24 GMT Message-ID: <2jbilo$21q@agate.berkeley.edu> Kirk Israel wrote: >And also, could some kind soul take a minute to explain the >paper beats rock beats scissors beats paper metaphor? Paper is a program which tries to produce many copies of itself, so that it will not be killed by a single attack. Scissors is a program designed to beat paper by (usually) scanning through core until it finds one copy of the paper, and then causing it to execute an inordinate number of SPL instructions, so that the paper will slow down. Then scissors sequentially overwrites every core location with DAT instructions to kill the stunned paper. Stone is a short fast DAT bomber designed to beat scissors. It works because scissors programs are typically 2-3 times as long as stones, and thus will likely be hit by the bombing before they can scan for and deactivate the stone. Of course, modern programs tend to be a mixture of several strategies instead of employing a single strategy like stone, paper or scissors. Typically large programs, especially paper, will start with a stone and then drop into their normal code. This helps to get rid of scissors-type programs which would easily disable the large program. Also many programs will drop into an imp-spiral after (or sometimes before) they are finished their main code. There is a corewar FAQ which explains all this a lot better than I can. It's available by anon ftp to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z and it is also posted to this newsgroup sporadically (or is there a pattern to the posting dates, Stefan? ;-) -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: pk6811s@acad.drake.edu Subject: _Push Off_ Message-ID: <1994Feb9.152844.1@acad.drake.edu> Date: Wed, 9 Feb 1994 21:28:44 GMT _PUSH OFF_ A midweek review of Corewar February 9, 1994 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 46/ 37/ 17 SJ-4a J.Layland 154 108 2 37/ 26/ 37 Match Stick c w blue 149 86 3 46/ 44/ 10 Iron Gate 1.1 Wayne Sheppard 148 71 4 44/ 40/ 16 Blitzkrieg Mike Nonemacher 148 101 5 41/ 35/ 24 Winter Werewolf 3 W. Mintardjo 148 917 6 42/ 37/ 22 Christopher Steven Morrell 147 11 7 45/ 44/ 10 Medusa's v5.1 W. Mintardjo 146 111 8 34/ 27/ 39 NC decoy Wayne Sheppard 141 192 9 33/ 26/ 41 Killer instinct Anders Ivner 140 171 10 38/ 36/ 27 Genocide Mike Nonemacher 140 3 11 30/ 20/ 50 Cannonade P.Kline 140 180 12 28/ 17/ 54 test t6 P.Kline 140 1 13 41/ 44/ 14 test-tw Fredrik Ohrstrom 139 75 14 37/ 38/ 25 Clown v8.1 P.E.M & E.C 136 190 15 30/ 24/ 46 Imprimis 7 P.Kline 136 839 16 27/ 19/ 54 ttti nandor sieben 136 187 17 36/ 36/ 28 Double V1.1 P.E.M & E.C 135 8 18 27/ 19/ 54 Walk Between the Raindrop Mike Nonemacher 134 44 19 34/ 37/ 30 Keystone t13 P.Kline 131 446 20 25/ 22/ 53 test Mike Nonemacher 128 2 21 2/ 98/ 0 looking P.Kline 7 0 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives, including many helpful articles, warrior source code, and reliable emulators, are available via anonymous FTP at soda.berkeley.edu in pub/corewar. -FAQ for this newsgroup is available via anonymous FTP at rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.z ------------------------------------------------------------------------------- III. The Scoop: This week's standings show J. Layland's remarkable SJ-4a program on top of the Hill. Layland has combined a 3-line bomber and b-scanner into a very strong competitor. That and a 2-pass spl/dat core clear are putting the heat on some excellent warriors. S. Morrell has challenged us with a new vampire (the only one on KotH to my knowledge). "Throw your best anti-vamp against it" he says :-) Thought we killed those guys off for good, but no, they just wait for a full moon and rise up again. Then there is the mysterious Match Stick which when last published was a paper designed to overtake other paper as well as imps and stones. Somewhere in the last weeks Match Stick took a big jump toward the top of KotH and has stayed in the top 5 or so ever since. Any suggestions for the rest of us, CW? ------------------------------------------------------------------------------- IV. The Outlook: 4 35/ 28/ 37 Match Stick c w blue 141 1 5 39/ 34/ 27 Double V1.1 P.E.M & E.C 143 1 6 39/ 38/ 23 Christopher Steven Morrell 139 1 6 40/ 37/ 22 Six Counts of Genocide v2 Mike Nonemacher 144 1 7 38/ 39/ 24 Genocide Mike Nonemacher 136 1 9 27/ 20/ 53 Walk Between the Raindrop Mike Nonemacher 134 1 12 38/ 41/ 21 My wife is pregnant! Steven Morrell 136 1 ------------------------------------------------------------------------------- V. The Quick Look: 19 14/ 39/ 47 Chaos v2! Gil Richard 89 1 20 17/ 45/ 38 Multibom Gil Richard 90 1 20 23/ 59/ 18 Smartbomb 4.1 Devin Kilminster 87 1 21 0/ 45/ 55 wipe-me Richard 55 0 21 5/ 61/ 34 ImpBuster Gil Richard 50 0 21 5/ 80/ 15 Smartbomber Gil Richard 29 0 21 7/ 88/ 5 The Full-Auto Hopsplat Gu Gil Richard 26 0 21 8/ 75/ 17 Clamp Gil Richard 40 0 21 12/ 81/ 7 Tank Mark Tuempfel 43 0 21 13/ 73/ 14 A Dwarf Gil Richard 53 0 21 13/ 85/ 2 xxx AMP 42 0 21 13/ 86/ 1 NO3 AMP 40 0 21 14/ 78/ 9 cascade 1 Steve Gunnell 49 0 21 29/ 33/ 38 Yop La Boum v2.2 P.E.M & E.C 124 0 21 30/ 52/ 18 Looks Like Lines to Me Steven Morrell 107 0 ------------------------------------------------------------------------------- VI. The Hint: More and more fighters are going to a 2-pass spl/dat core-clear, filling the entire core with spl-zero then wiping it with dat's. Of the warriors on KotH: SJ-4a, Winter Werewolf 3, and Blitzkrieg all claim to be using a double core-clear (tho' maybe that's what S. Morrell means by "my sister-in-law is having twins" :-). And these are proving to be some very tough hombres. Here is one way to set up a spl/dat core-clear: db dat Subject: Re: 2-pass coreclears Date: Wed, 9 Feb 1994 23:41:37 -0500 Message-ID: To: netnews.rec.games.corewar Subject: Re: _Push Off_ CC: Excerpts from netnews.rec.games.corewar: 9-Feb-94 _Push Off_ by pk6811s@acad.d rake.edu > The spl-dat core-clear is very effective against replicators, and the > resulting gate deters the standard imp-spiral. There is also an insidious : -) > > affect on Cannonade-style gate-busting spirals. The 2-pass clear seems > to gum up the works on putting the gate-passing code beyond the gate. > Yuck! In playing around with Paradox (my newest warrior to date - gate-crashing imp-spiral + anti-imp paper), I've found that a well structured spiral can survive a 2-pass coreclear and the resulting gate, if done this way. A slightly more complex 2-pass coreclear can defeat this, though (just got done installing it in Genocide...): g dat <-18-2668, <-18 . . . ptr1 dat #split clear spl 0, <-17 mov @ptr1, <19 jmp -1, <-19 ;partial gate split spl 0, #-20 ;can be anywhere in code This should be set up so when "ptr1" is hit with "split", it points at "g". When finishing the DAT coreclear, the -18 in "g" will put "g" at clear+1, making a complete gate at clear-17, and half a gate at clear-17-2668. It might be possible for *some* gate-crashing spiral to get thru, I'm not sure, but I know Paradox's spiral gets stopped. I expect to be posting the Genocide source sometime soon (whenever I have time to make it understandable :-), so you'll see it in action. ;----------------------------------------------- ; "I wanna talk today about Smug people ; They think they're so good, they ain't good! ; No, they ain't good at all, I'll tell you why ; You wanna be a good man, you look at me ; I'm gonna talk to you about humility, cause I GOT IT! ; I'm gonna talk to you about righteousness, cause I GOT IT! ; I'm good, I'm humble, I'm BETTER THAN YOU! ; You wanna be a humble man, you look at me ; You say Brother, how can I be humble? ; I DON'T KNOW how you can be humble! ; It took me a long time to get this way, ; But thank God, I've arrived!" ; - Steve Taylor, "Smug," Squint ; ; Michael N. Nonemacher ; Carnegie Mellon University ; mn2f+@ andrew.cmu.edu ;----------------------------------------------- From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: New RedCode Paradigm (flamebait?) Message-ID: <1994Feb10.001226.13206@news.vanderbilt.edu> Date: Thu, 10 Feb 1994 00:12:26 GMT In article <2j98os$8ql@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: >However, if we abandon the current corewar paradigm, we will discover an >interesting game called C-robots where you write code for a robot in C and it >fights aginst other C-robots. [...] > - Michael Constant > According to the charter, this newsgroup is about "discussion of Core War and related games". However, our FAQ doesn't even mention "related games". I'd like to add a section on C-robots et al.. I came across P(ascal)-robots and seem to remember a few more. If you happen to have any information about corewar-related games (description, FTP site (or commercial), pointer to further info) please send them to me for inclusion in the next FAQ. Thanks, Stefan (stst@vuse.vanderbilt.edu) From: wisej@acf4.nyu.edu (wisej) Subject: Re: New RedCode Paradigm (flamebait?) Date: 10 Feb 1994 01:42:33 GMT Message-ID: <2jc3e9$gs0@cmcl2.NYU.EDU> -----BEGIN PGP SIGNED MESSAGE----- jayhan@cs.washington.edu (Jay Han) writes: >No way. Redcode lacks registers, stacks, and subroutines. That means there is >no easy way to implement a procedure call. The closest you can get is to store >the return address inside the procedure itself. But then the procedure is not >re-entrant. Moreover, it lacks index registers, so it takes a huge amount of >arythmetics to have arrays. It would take a well-written compiler, but I don't think it would be as difficult as you think..After all C compilers have been written for computers with a wide variety of architectures, including single-accumulator and stack-only machines. Much work would have to be done in memory that would traditionally be done in registers, it is true, but this can be done. As far as arrays are concerned, it is true that they would be much easier in a machine with an index register, but this is not required. After all, in C, an array is merely a different pointer notation, and pointers _are_ provided for, in the form of the indirect addressing mode. Stack pointers could also be provided for in memory, although they would pretty clearly be a very vulnerable point in the processes defenses... Stack use could be avoided for any program not using recursion, however, and flat (single-procedure) code would be stronger, anyhow. The basic constructs of a high level choice would allow a good high-level view of what the program was doing which might make writing easier, at least for relative beginners, such as myself. >-=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Jim Wise wisej@acf4.nyu.edu jaw7254@acfcluster.nyu.edu -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVmRYjS8O1DgkhNpAQGtwwQAjngCJKY4sq6E9pjZKwg0iATKkkBd+Zwe yVqAm56/VMgpwCu1i+ZV/akavhDpJi70ISk8Ypjgp03HoFQuxIiczTUiadH6Gp85 k3lJXGXblhllMss96FbPWYB+WRFGX8UaJLRJvFymwX0gePq5g6dln45A3+d810nn b7uBbrL1Rrg= =HSX5 -----END PGP SIGNATURE----- From: kisrael@jade.tufts.edu (Kirk Israel) Subject: Re: New RedCode Paradigm (flamebait?) Message-ID: Date: Thu, 10 Feb 1994 02:25:04 GMT In article Michael N Nonemacher writes: > > Or, possibly, has anyone considered writing a translator for any other > languag > > e > > that would compile into redcode? This would produce valid redcoed programs, > > which could be run on standard redcode simulators, but would be > different from > > > > the programmer's viewpoint. it would be interesting to see if ICWS '94 > > provides a versatile enough instruction set for the implementation of > any high > > > > level languages... > > While writing in a high-level language may be simpler, there are lots of > people who will write their programs in redcode to get better > performance. Even the best redcode compiler couldn't match some of the > redcode I've seen lately, so I think any "compiled" warrior wouldn't > stand a chance. Of course, if warriors get complex enough that writing > in redcode is just too complex and time-consuming (with a huge core and > 1,000 line warriors, for example), a compiler might be useful. But I > think there will still be people who will gladly program their warriors > in redcode for the added performance. But, that's just my opinion... My newsfeed here is acting a little crazy: I'm not seeing the message that the message *I'm* now following up to followed up to... I agree, well-written low level warriors will probably always have a big advantage: sorta like finely-hand-tuned assembly code vs. big clunky C...It might be an interesting idea to try to implement, though, even if it wouldn't win many battles. Well, guess I'll just have to wait and see if any other threads on this are around and about, just out of my view... KIRK -- _____ -O\O Kirk Israel \\ "Life is so peculiah don't let anybody fool ya!" ( = ) kisrael@jade.tufts.edu \\ --Five Guys Named Moe From: pk6811s@acad.drake.edu Subject: Re: Pits, Vampires, and the new Tutorial Message-ID: <1994Feb10.094851.1@acad.drake.edu> Date: Thu, 10 Feb 1994 15:48:51 GMT In article <2jbmql$2vr@r-node.io.org>, daffyd@io.org writes: > As most of you know, I am in the process of writing a corewar tutorial. Great! Much needed. > No.2: > What is a vampire? How do they work? What is an antivamp? How do they work? > Here is some recycled _Push Off_ stuff that may be helpful: Basically a pit-trapper works by making your processes jump into a rapid-splitting, core-clearing, self-destroying, nasty bit of code. You are forced to split many many processes, thereby robbing your healthy processes of time. You are forced to erase the core, destroying any surviving components. And you finally erase the pit itself, killing your remaining processes. Vampire strategy goes back to one of the standard battle programs, 'Vampire', and was used successfully by Eugene P. Lilitko's Cowboy program to win the 1988 ICWS tournament. Here's a modern version of Vampire: inc dat #3364,#-3364 fang jmp trap,4 ; <- the fang start spl 0 add inc,fang mov fang,@fang ; <- the fang-bomber jmp -2 trap mov 10,<-10 ; <- the pit spl -1 jmp -2 All vampires eventually cause their own processes to jump into the trap to speed up the core clear (and to guarantee one). Vampire's strengths include small size, rapid bombing (with fangs), and complete core-clear. Their most important feature, however is enslaving the opponent's processes to do their dirty work. Variations include substituting the 'trap' line for 'inc', booting the code to separate the bomber from the trap, putting the fang in different locations, multiple spl's to more rapidly overpower the opponent, and 'gates' to stop imps (see Sucker 5). --------------------------------------------------------------------------- Vampires - deadly opponents or patsies? The Achille's heel of Vampires is their 'fang'. What other warrior puts pointers to itself all over core? (well, imps okay, but that's another topic :-) Here's what a typical fang in core looks like: jmp a,b In reality, here's what it represents: jmp pitlocation,-fangsource Now if we could turn either of those pointers to advantage, we could zero in on the vamp and squelch him. Since several of the better vampires (Sucker, Twilight Pits, and Grimm's Vampyre) locate the fang just after their bombing code, they are easily attacked by this code: spl 0 avamp mov bomb,<-100 sub @avamp, Date: Thu, 10 Feb 1994 16:05:12 GMT In article <2jbmql$2vr@r-node.io.org>, daffyd@io.org writes: > Hi, all. > As most of you know, I am in the process of writing a corewar tutorial. Great! Much needed. > > No.2: > What is a vampire? How do they work? What is an antivamp? How do they work? > Here is some recycled _Push Off_ stuff that may be helpful: Basically a pit-trapper works by making your processes jump into a rapid-splitting, core-clearing, self-destroying, nasty bit of code. You are forced to split many many processes, thereby robbing your healthy processes of time. You are forced to erase the core, destroying any surviving components. And you finally erase the pit itself, killing your remaining processes. Vampire strategy goes back to one of the standard battle programs, 'Vampire', and was used successfully by Eugene P. Lilitko's Cowboy program to win the 1988 ICWS tournament. Here's a modern version of Vampire: inc dat #3364,#-3364 fang jmp trap,4 start spl 0 add inc,fang mov fang,@fang jmp -2 trap mov 10,<-10 spl -1 jmp -2 All vampires eventually cause some of their own processes to jump into the trap to speed up the core clear (and to guarantee one). Vampire's strengths include small size, rapid bombing (with fangs), and complete core-clear. Their most important feature, however is enslaving the opponent's processes to do their dirty work. Variations include substituting the 'trap' line for 'inc', booting the code to separate the bomber from the trap, putting the fang in different locations, multiple spl's to more rapidly overpower the opponent, and 'gates' to stop imps (see Sucker 5). --------------------------------------------------------------------------- Vampires - deadly opponents or patsies? The Achille's heel of Vampires is their 'fang'. What other warrior puts pointers to itself all over core? (well, imps okay, but that's another topic :-) Here's what a typical fang in core looks like: jmp a,b In reality, here's what it represents: jmp pitlocation,-fangsource Now if we could turn either of those pointers to advantage, we could zero in on the vamp and squelch him. Since several of the better vampires (Sucker, Twilight Pits, and Grimm's Vampyre) locate the fang just after their bombing code, they are easily attacked by this code: spl 0 avamp mov bomb,<-100 sub @avamp, Date: Thu, 10 Feb 1994 19:26:28 GMT Hi Is there an ICWS94 hill anywhere, and what is its address and help etc.. Is there an interpreter for the new ICWS94 standard, and can I get one for X and the PC? Thanks J-D -- | J-D Mountjoy -- Rhodes University -- csjm@alpha.ru.ac.za -- My Views Only | From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: ICWS94, a hill and an interpreter Date: 10 Feb 1994 21:47:52 GMT Message-ID: <2jea28$10g@agate.berkeley.edu> >Is there an ICWS94 hill anywhere, and what is its address and help etc.. Yes. Include the line ";redcode-94" at the top of your program (as well as the standard ;name, ;author, and ;strategy lines, of course) and mail it to koth@stormking.com. This is a UUCP site. They tell me that I should get results in a few hours, but *I've* never gotten anything back before three or four days... be patient. :-) >Is there an interpreter for the new ICWS94 standard, and can I get >one for X and the PC? Yes again. It's called pMARS, short for Portable MARS, (which itself is short for Memory Array Redcode Simulator...) and it runs on just about anything except X. (They're working on it though.) You can get a copy by anon ftp to soda.berkeley.edu, in the /pub/corewar/incoming (within a few weeks it will be /pub/corewar/systems instead) directory as "pmars04.zip" (this is for the PC.) If you have a 386 or better you should also get "pmars04g.zip" which is a 32- bit upgrade (it requires the original pmars04.zip) and runs faster. When you unzip it, though, make sure to keep a copy of the "pmarsv" program included with the standard pmars04.zip. You can let it overwrite pmars and mts with the 32-bit versions, but make sure to have both versions of pmarsv available, because the 32-bit pmarsv doesn't work in graphics mode (?!). As a service to the pMARS people, who are going to follow up to this article if I don't say this myself... :-) pMARS is a portable program. If you have a Mac (god forbid :-) then get the file macpmars.something, which is currently in /pub/corewar/systems (on soda.berkeley.edu). I think I described the PC files in detail about a paragraph ago. If you have anything else, get the file pmars04s.tar.Z and compile it yourself (the make-file is pretty good, though). -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: MNCT Round 3 Date: 10 Feb 1994 21:55:56 GMT Message-ID: <2jeahc$182@agate.berkeley.edu> This is a reminder that round 3 entries are due very very soon... February 13 to be exact. However, I know that many of you won't even be reading this message until then, so you won't be able to do anything about it... So, I'm going to be nice and extend the deadline another week, until February 20. I'm very forgiving about late entries *if* you let me know beforehand. So, if you plan to enter round 3, send me either your program or an excuse by February 20. Sorry to the people who have already submitted their programs, this is going to take an extra week, but after all I only have two entries so far! Keep them coming! -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: ojastej@sdh7531.ice.ncr.ca (James Ojaste) Subject: Re: ICWS94, a hill and an interpreter Message-ID: Date: Fri, 11 Feb 1994 13:22:12 GMT In article <2jea28$10g@agate.berkeley.edu>, mconst@soda.berkeley.edu (Michael Constant) writes: |> >Is there an ICWS94 hill anywhere, and what is its address and help etc.. |> |> Yes. Include the line ";redcode-94" at the top of your program (as well as |> the standard ;name, ;author, and ;strategy lines, of course) and mail it to |> koth@stormking.com. This is a UUCP site. They tell me that I should get |> results in a few hours, but *I've* never gotten anything back before three |> or four days... be patient. :-) I was wondering why it was taking so long... In the summer, I used to send in my warriors, update them and resubmit them about 3, 4 times a day... It's kinda slowing down my development... :-) -- main(){char n[]="James Ojaste\r";int x,y=12;while(y--,x=y)while(x--)putc(' ',0);printf("%s",n+y);} From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: New RedCode Paradigm (flamebait?) Message-ID: <1994Feb11.190305.16935@news.vanderbilt.edu> Date: Fri, 11 Feb 1994 19:03:05 GMT In article jayhan@cs.washington.edu (Jay Han) writes: >In article kisrael@jade.tufts.edu (Kirk Israel) writes: > >> Maybe as a base for the language we could start with simple >> commands that group current commands: like say a one-line >> imp or vampire or gate generator. This would just be a start, >> though. > >Now *that* is an interesting idea, and I think it has more or less been >proposed earlier here. The idea was to have a "high-level" Redcode >macro-language with simple building blocks (loop, imp, bootstrap, scanner, >etc.) and being able to mix-and-match them to produce a complete program which >would later be hand-tuned. Personally, that's not the way I design a warrior, >though. > >-=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Two "higher-level" extensions are already implemented in pMARS, namely multi-line EQUs and for/rof loops. You can use multi-line EQUs for code modules: dwarf equ add #4,1 equ mov -2,-2 equ jmp -3 spacer equ mov 0,2667 And for/rof for repetitive code: ;macro num for 10 a&num spl a&num ;"num" is expanded to 01, 02, .. 10 and appended to "a" jmp a&num for 5 dwarf for 10 spacer rof rof rof Not that the above does anything useful :-) -Stefan (stst@vuse.vanderbilt.edu) From: cbarilleaux@delphi.com Subject: How do I get Starteed Date: Sat, 12 Feb 94 11:07:14 -0500 Message-ID: Hi! I'm new to this group, and would like to get started on CoreWars. I have tried FTPing to the archive, but can't figure out how to get started. Any advice on what I should download? Charles From: jstewart@fox.nstn.ns.ca (Elio Dolente ) Subject: Re: MNCT Lives! Date: 12 Feb 1994 20:58:30 -0400 Message-ID: In article <94036.000800AHNAS@ASUACAD.BITNET> writes: >Path: nstn.ns.ca!coranto.ucs.mun.ca!csd.unb.ca!torn!spool.mu.edu!howland.reston.ans.net!cs.utexas.edu!asuvax!asuacad!ahnas >Organization: Arizona State University >Date: Sat, 5 Feb 1994 00:08:00 MST >From: >Message-ID: <94036.000800AHNAS@ASUACAD.BITNET> >Newsgroups: rec.games.corewar >Subject: Re: MNCT Lives! >References: <2ijsa2$rqg@agate.berkeley.edu> >Lines: 2 >It would be nice to have the summarized scores after the two rounds. >Nandor. "Ada: Enchantress of numbers" E-mail: adatoole@well.sf.ca.us September 1993 is the 150th anniversary of Ada Byron's, (Lady Lovelace's), description of Charles Babbage's concept of the first computer, the "Analytical Engine". Ada was remarkable for being one of the most picturesque characters in the history of computing as well as the most prescient about the computer revolution. As Howard Rheingold wrote in his review in Whole Earth: "Her letters are some of the classic founding documents of . . .computer science written a century before ENIAC. " William Gibson and Bruce Sterling used Ada in their science fiction novel, "The Difference Engine" as the "queen of the engines." Ada's story and her letters are a hologram, a journey through cyberspace. Her vision of the Analytical Engine has stood the test of time: she predicted its use for sound, vision, as well as its use as a practical and scientific machine. Speaking of the programming system she develped for the mechanical computer, Ada teased in a letter to Babbage: "No one knows what power lies yet undevelopped in that wiry system of mine." All the excerpts that follow are from "Ada, The Enchantress of Numbers: A Selection from the Letters of Lord Byron's Daughter and Her Description of the First Computer" by Betty A. Toole Ed.D. published by Strawberry Press, Mill Valley, California From Part 10 - Working Like the Devil A Fairy in Your Service What a General I Would Make An Analyst and a Metaphysician (All from 1843) Ada gave Wheatstone, who was working with Richard Taylor, the publisher of a scientific journal, her translation of L. F. Menabrea's description of Babbage's Analytical Engine, which was published in French in a Swiss Journal in October, 1842. According to Babbage's recollection in his autobiography, Passages, many years after Ada's death, he wrote: "Some time after the appearance of his memoir [article] on the subject in the "Bibliothque Universelle de Gnve," the Countess of Lovelace informed me that she had translated the memoir of Menabrea. I asked why she had not herself written an original paper on the subject with which she was so intimately acquainted? To this Lady Lovelace replied that the thought had not occurred to her. I then suggested that she should add notes to Menabrea's memoir: an idea which was immediately adopted.". . . 1. To Charles Babbage Thursday Morning [1843] Ockham My Dear Babbage. I have read your papers over with great attention; but I want you to answer me the following question by return of post. The day I called on you, you wrote off on a scrap of paper (which I have unluckily lost), that the Difference Engine would do. . . Analytical Engine would do . . . (something else which is absolutely general). Be kind enough to write this out properly for me; & then I think I can make some very good Notes. . . A.A.L. Ada started making headway with the Notes and sent some off for Babbage's inspection. As for her Note A, Babbage replied the next day: "If you are as fastidious about the acts of your friendship as you are about those of your pen, I much fear I shall equally lose your friendship and your Notes. I am very reluctant to return your admirable & philosophic Note A. Pray do not alter it . . . All this was impossible for you to know by intuition and the more I read your notes the more surprised I am at them and regret not having earlier explored so rich a vein of the noblest metal."1 Babbage continued his compliments and wrote her that Note D was in her usual "clear style." . . . 2. To Charles Babbage Monday [10 July 1843]1 Ockham My Dear Babbage. I am working very hard for you; like the Devil in fact; (which perhaps I am). I think you will be pleased. I have made what appear to me some very important extensions & improvements. . . .It appears to me that I am working up the Notes with much success; & that even if the book be delayed in it's [sic] publication, a week or two, in consequence, it would be worth Mr Taylor's while to wait. I will have it well & fully done; or not at all. I want to put in something about Bernoulli's Numbers, in one of my Notes, as an example of how an implicit function, may be worked out by the engine, without having been worked out by human head & hands first. Give me the necessary data & formulae. Yours ever A.A.L. 6. To Charles Babbage Tuesday Morning [4 July 1843] Ockham My Dear Babbage. . . In Note D, it is very well & lucidly demonstrated that every single Operation, demands the use of at least three Variable-Cards. It does not signify whether the operations be in cycles or not. . . .I enclose what I believe it ought to be. . . Think of my having to walk, (or rather run), to the Station, in half an hour last evening; while I suppose you were feasting & flirting in luxury & ease at your dinner. It must be a very pleasant merry sort of thing to have a Fairy in one's service, mind & limbs! I envy you! I, poor little Fairy, can only get dull heavy mortals, to wait on me! Ever Yours A.L. 8. To Charles Babbage Wednesday, 5 July [1843] Ockham Park My Dear Babbage. I am much obliged by the contents of your letter, in all respects. . ., "Why does my friend prefer imaginary roots for our friendship?" Just because she happens to have some of that very imagination which you would deny her to possess; & therefore she enjoys a little play & scope for it now & then. Besides this, I deny the Fairyism to be entirely imaginary; (& it is to the fairy similes that I suppose you allude). That brain of mine is something more than merely mortal; as time will show; (if only my breathing & some other et-ceteras do not make too rapid a progress towards instead of from mortality). Before ten years are over, the Devil's in it if I have not sucked out some of the life-blood from the mysteries of this universe, in a way that no purely mortal lips or brains could do. No one knows what almost awful energy & power lie yet undevelopped in that wiry little system of mine. I say awful, because you may imagine what it might be under certain circumstances. Lord L, sometimes says "what a General1 you would make!" Fancy me in times of social & political trouble, (had worldly power, rule, & ambition been my line, which now it never could be). A desperate spirit truly; & with a degree of deep & fathomless prudence, which is strangely at variance with the daring & the enterprise of the character, a union that would give me unlimited sway & success, in all probability. My kingdom however is not to be a temporal one, thank Heaven! . . . "Labor ipse voluptas"2 is in very deed my motto! And, (as I hinted just now), it is perhaps well for the world that my line & ambition is over the spiritual; & that I have not taken it into my head, or lived in times & circumstances calculated to put it into my head, to deal with the sword, poison, & intrigue, in the place of x, y, & z. . . Your Fairy for ever A.A.L. . . 1 Ada's humorous reference to a General is prescient. The software language "Ada" was named in her honour. It was developed and is used as a standard by the U.S. Department of Defense. 2 "Labour is its own reward," was the Lovelace family motto. 3 Ohm was a German physicist (1787-1854). Ohm's law states that for any circuit the electric current is directly proportional to the voltage and inversely proportional to the resistance. 22. To Charles Babbage Sunday, 30 July [1843] Ockham I am beyond measure vexed to find that instead of inserting my corrected Table in the Revise . . . they have left it exactly as it was before. Pray see about it immediately. It is exceedingly careless & annoying. . . I do not think you possess half my forethought, & power of foreseeing all possible contingencies (probable & improbable, just alike). . . .. How very careless of you to forget that Note; & how much waiting on & service you owe me, to compensate. I am in good spirits; for I hope another year will make me really something of an Analyst. The more I study, the more irresistible do I feel my genius for it to be. I do not believe that my father was (or ever could have been) such a Poet as I shall be an Analyst; (& Metaphysician); for with me the two go together indissolubly. Yours A.L. From Ada's description of the first computer found in part 12 of "Ada, The Enchantress of Numbers": Supposing, for instance, that the fundamental relations of pitched sounds in the science of harmony and of musical composition were susceptible of such expression and adaptations, the engine might compose elaborate and scientific pieces of music of any degree of complexity or extent. We may say most aptly that the Analytical Engine weaves algebraical patterns just as the Jacquard-loom weaves flowers and leaves. It is desirable to guard against the possibility of exaggerated ideas that might arise as to the powers of the Analytical Engine. In considering any new subject, there is frequently a tendency, first, to overrate what we find to be already interesting or remarkable; and, secondly, by a sort of natural reaction, to undervalue the true state of the case, when we do discover that our notions have surpassed those that were really tenable. The Analytical Engine has no pretensions whatever to originate any thing. It can do whatever we know how to order it to perform. In part 11, towards the end of Ada writing this description, she and Babbage quarrelled. The reason is found in a letter on the inside of the bookcover of "Ada, The Enchantress of Numbers." After the publication of the Notes, the arguments were resolved and Ada invited Babbage to Ashley Combe, her home in Somerset. Babbage's reply to Ada's invitation was: 9 September 1843 My Dear Lady Lovelace. I find it quite in vain to wait until I have leisure so I have resolved that I will leave all other things undone and set out for Ashley taking with me papers enough to enable me to forget this world and all its' troubles and if possible its' multitudinous Charlatans every thing in short but the Enchantress of Numbers. . . Farewell my dear and much admired Interpretess. Evermost Truly Yours C Babbage The rest of her short life Ada was ill. She spent a great deal of time under the influence of laudanum, in cyberspace. She saw the need for nanotechnology: "What we need is a Newton of the molecular universe," and orbiting in cyberspace Ada saw planetary visions, and her eerie prediction of her personal destiny. The current review of "Ada, The Enchantress of Numbers," just out in the "Annals of the History of Computing" rate the book as "excellent and thoughtful" and for the reader it is a source book not only of the birth of the computer revolution, but for the imagination. Ada The Enchantress of Numbers is published by Strawberry Press. It is a 452 page hardback with over 80 illustrations, and can be obtained for $29.95 prepaid post paid ($42 to ship air outside U.S.) from: Critical Connection P.O. Box 452 Sausalito, Ca 94966. Credit cards call 1-800-544-4565. In the U.K. distributed by Computer Bookshops, Birmingham to bookstores and Pickering and Chatto, to libraries. The author can be reached via Internet e-mail at: adatoole@well.sf.us.ca From: g88m0396@hippo.ru.ac.za (J-D Mountjoy) Subject: 94 Std and Bombers Message-ID: Date: Sun, 13 Feb 1994 11:27:54 GMT Hi Reading the documentation for the 94 standard, I see that there is a read/write distance limit. I suppose that this then precludes the standard bombers/searches etc. who just sit in one place and look through core? This would surely lead to more programs being written which 'move' through core or copy themselves all over the place? J-D -- | J-D Mountjoy -- Rhodes University -- csjm@alpha.ru.ac.za -- My Views Only | Date: Sun, 13 Feb 1994 16:48:06 MST From: Message-ID: <94044.164806AHNAS@ASUACAD.BITNET> Subject: Re: New RedCode Paradigm (flamebait?) I never had a chance to try it but I think crobots is es exactly what you want. I think you find it at oak.okland.edu . There is a pascal version too called probots ( I guess ). Nandor. From: jmorris@ace.com (Cuthalion) Subject: Re: New RedCode Paradigm Message-ID: <2455.UUL1.3#25274@ace.com> Date: Mon, 14 Feb 94 07:33:47 EST . Mbbs@argnews {kisrael@jad said to ** All **: / M{> elegant, haiku-like warriors...but has any one ever thought M{> of a whole new paradigm for RedCode (it would probably need a whole M{> new name) that was more based on C or some other structured language? M{> C has the ability to dive into memory like RedCode does, although M{> this new paradigm might try to find a different form of abstraction M{> for the battles, because so much tends to be hidden by the compiler M{> nowadays, unlike assembly... Just as interesting would be a c to redcode compiler. (sounds interesting, yes?) Maybe i'll write one! :) ... Tag line thievery ... On the next Geraldo! ___ Blue Wave/QWK v2.12 From: Michael N Nonemacher Subject: Genocide Date: Mon, 14 Feb 1994 11:33:19 -0500 Message-ID: This is a classic case of overdoing a good thing. My initial strategy was to make a few changes to Killer Instinct (Anders Ivner), to make it able to kill spl/jmp bombers & paper. Unfortunately, it got too complex. The basic strategy is the same: start a small bomber which scans through core linearly, hoping to find anything the other warrior is throwing out there. The bomber will not find anything against scanners, and it should be quick enough to kill them before it is found (most of the time). When I find something, I subtract it from itself, and compare to core. If it's equal to core, I either found a decrement (probably from some type of stone), or the end of a paper. To decide if I found paper, I just check if FOUND-3 is zero. Since there aren't any mod-3 bombers out there, this is pretty safe. If it's zero, I launch anti-imp paper. If not, I start a 2-pass coreclear. On the other hand, if what I found doesn't compare to core, I first check to see if it's an imp, by comparing to "mov 0, 0". If it is, I start a 2667-spiral stun, and start paper. If not, I assume spl/jmp bomber or vampire. I copy another small bomber (mod-4, with coreclear) to what I found, and start it. This will take care of any spl/jmp bombers. Then, if FOUND-1 is zero, I start a quick anti-vamp. This scans linearly (again) till it finds a fang, then bombs 11 locations on either side of the vampire's trap. At worst, this will wipe out the trap, leaving my bomber to take care of the vamp. But, against most vampires, this also kills the fang-bomber. The bomber eventually clears core, and ends up in a gate, to kill any vamp-spirals. The problems with this strategy are: 1. Against paper, it often finds a paper in the process of being copied, or that has not been started yet. In this case, I launch a small bomber, which doesn't have a chance. 2. It takes too many lines of code to correctly analyze FOUND. Against many imp-spirals, especially Night Crawler, I've been bombed too much to do anything by the time I find something. 3. Against a vampire that positions its trap far away from the rest of its code, I have to rely on my bomber. If my bomber gets hit, I'm finished. 4. For some reason, I suffer 70-90% losses against Match Stick. Against the published version, it's something like 30-40-30, but as for the one on the hill... Incidentally, the current version of Genocide doesn't detect paper, and contains a slight delay before the paper if it finds an imp. This should give the spiral-stun a little better chance... Anyway, without further BS... ;redcode ;name Genocide ;author Mike Nonemacher ;strategy Simpler is better. ;kill Genocide STEP EQU -3510 ;Initial bomber is mod-10 SBOOT EQU 1562 ;Distance to boot bomber FOUND EQU start+SBOOT-1+STEP ;Points to what my Bscan found SJINC EQU 3044 ;increment for anti-SPL/JMPer TIMER EQU 790 ;When Bscan finds this, launch paper CORE EQU ksj2-1 ksj2 mov @-2, 1 ksj3 djn -2, #1999 ksj5 mov @20, <-2 start mov s4, SBOOT mov s3, wel... as the title indicates.. what is CoreWar? Tass From: mconst@soda.berkeley.edu (Michael Constant) Subject: koth@stormking Date: 14 Feb 1994 21:03:51 GMT Message-ID: <2joovn$r3k@agate.berkeley.edu> I've been having problems with the ;kill command on koth@stormking - as in, it doesn't work :-) It seems not to work for anyone else, either, as evidenced by the large numbers of identical programs (or the same program with different version numbers) floating around the various stormking hills. Could the perso in charge of this (Scott, I think) look into this problem? Or do the pMARS people have a good explanation for this? I guess I just don't like having to fight Snake twice, it always beats me :-) -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: 94 Std and Bombers Date: 14 Feb 1994 22:20:55 GMT Message-ID: <2jotg7$t9d@agate.berkeley.edu> J-D Mountjoy wrote: >Reading the documentation for the 94 standard, I see that there >is a read/write distance limit. I suppose that this then precludes the >standard bombers/searches etc. who just sit in one place and look >through core? This would surely lead to more programs being written >which 'move' through core or copy themselves all over the place? It certainly would, which is why the only actual implementation of the '94 standard (pMARS) doesn't support r/w limits. OK, this is personal opinion, and I think everyone already knows *my* feelings about r/w limits. However, this has all been discussed before so there's no need to flame me even if you feel differently. -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: bardosy@ludens.elte.hu Subject: Re: ICWS94, a hill and an interpreter Message-ID: <1994Feb15.134906.1846@ludens> Date: 15 Feb 94 13:49:06 +0100 In article , g88m0396@hippo.ru.ac.za (J-D Mountjoy) writes: > Hi > > Is there an ICWS94 hill anywhere, and what is its address and help etc.. > Is there an interpreter for the new ICWS94 standard, and can I get > one for X and the PC? > > Thanks > > J-D > -- > | J-D Mountjoy -- Rhodes University -- csjm@alpha.ru.ac.za -- My Views Only | if you got the pc-form,can you send it to us:pixie@ludens.elte.hu (or the site,where can it found)? rookies of the Corewar From: zcacygr@ucl.ac.uk (Yoram Grahame) Subject: Newbie Date: 15 Feb 1994 17:41:45 -0600 Message-ID: <1994Feb15.172437.78574@ucl.ac.uk> Okay, complete newbie here. Always wanted to find out about corewar but never got the chance. Unix / Sun4 version, please? Also manuals? Much obliged. -- o---------------------------------------------------------o | Yoram "| |,,-.---." Grahame Y.Grahame@cs.ucl.ac.uk | | `--1 `-' ==; | | ,-'| ; "The crackers, Gromit! | | `--' ,----' We've forgotten the crackers!" | o---------------------------------------------------------o From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: What is Corewar? Date: 15 Feb 1994 20:06:08 GMT Message-ID: <2jr9vg$m7b@agate.berkeley.edu> >wel... as the title indicates.. what is CoreWar? It's a really neat game and you should start playing it :-) The FAQ is available by anon ftp to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z. If you have any questions, you can post them here or mail me. -- - Michael Constant mconst@soda.berkeley.edu GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Answers to Frequently Asked Questions (FAQ) for rec.games.corewar Message-ID: <1994Feb15.212923.11214@news.vanderbilt.edu> Date: Tue, 15 Feb 1994 21:29:23 GMT [rtfm.mit.edu seems to have stopped automatic posting of the FAQ, that's why you haven't seen this in a while. I will post this manually until I figured out what's going on with the server. -stst] From: stst@vuse.vanderbilt.edu (Stefan Strack) Organization: The Core War Newsletter Newsgroups: rec.games.corewar,rec.answers,news.answers Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Followup-To: rec.games.corewar Reply-To: stst@vuse.vanderbilt.edu (Stefan Strack) Summary: This posting contains a list of Frequently Asked Questions (and their answers) about the game Core War. It should be read by anyone interested in posting to the rec.games.corewar newsgroup or submitting warriors to the ongoing Core War tournament - KotH. Approved: news-answers-request@MIT.Edu Archive-name: games/corewar-faq Last-modified: 1994/01/03 Version: 2.1.5 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 122 6. What is the ICWS? 138 7. What is TCWN? 148 8. How do I join? 156 9. Are back issues of TCWNs available? 173 10. What is the EBS? 180 11. Where are the Core War archives? 196 12. Where can I find a Core War system for . . . ? 214 13. I do not have ftp. How do I get all of this great stuff? 262 14. I do not have access to Usenet. How do I post and receive news? 269 15. When is the next tournament? 287 16. What is KOTH? How do I enter? 296 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 440 18. How does SLT (Skip if Less Than) work? 452 19. What does (expression or term of your choice) mean? 464 20. Other questions? 592 --------------------------------------------------------------------- Q 1: What is Core War? A 1: 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 posession 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. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: 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. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: 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 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.draft.Z). You can try out the new standard by submitting warriors to the experimental '94 KotH server (see Q16). pMARS, a corewar system that implements ICWS'94 is available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: 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). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: 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 as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please 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 annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: 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 are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar 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 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A11: Where is the Core War archive? Q11: 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.149.19) 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. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. 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. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: 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. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-10.hqx - corewar for the Mac core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program runs the KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars03s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars03s.tar.Z - same as above pmars03.zip - PC executables, graphics display version macpmars02.sit.hqx - pMARS executable for Mac ApMARS03.lha - pMARS executable for Amiga ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: 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. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. ---------------------------------------------------------------------- Q16: What is KOTH? How do I enter? A16: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with email provided by William Shubert (wms@iwarp.intel.com). 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". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. 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 daemon 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 assembled correctly or not. If it did assemble 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: 8000 instructions Max processes: 8000 per program Duration: After 80,000 cycles, 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 ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. 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 (wms@iwarp.intel.com) for a copy or get it by anonymous FTP from soda.berkeley.edu in the pub/corewar/systems directory (see Q12). STORMKING.COM KOTH: A second KotH server is installed at stormking.com. Send your warrior to koth@stormking.com. Since this is an UUCP site, it may take a day before you get results back. There are currently five separate hills that you can select by starting your program with ;redcode, ;redcode-x ;redcode-icws, ;redcode-94, or ;redcode-94x. ;redcode and ;redcode-x select hills with rules of the regular and experimental hills at intel.com (see above). ;redcode-icws sends your warrior to the ICWS-hill. Rules here follow that of the annual ICWS tournament, in short: Core size: 8192 instructions Max processes: 64 per program Duration: After 100,000 cycles, a tie is declared. Max entry length: 300 instructions ;redcode-94 selects the experimental ICWS'94 (see Q 5 for more on this proposed new standard). Core size, Max processes, etc. are identical to the regular hills at stormking and intel.com. ;redcode-94x selects the experimental '94 or simply "Big Hill". Here the core size is 55440, a number with many small factors, that might lead to more complex warriors. Like the '94 hill, the '94x hill supports the ICWS'94 dialect. Here all parameters: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions All hills at stormking.com except for the x-hill run portable MARS, a platform-independent corewar system available at soda (see Q12). The contact person is for this server is Scott J. Ellentuch (tuc@stormking.com). Please send all bug reports, inquiries, etc. to him and me (stst@vuse.vanderbilt.edu). ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Date: Wed, 16 Feb 1994 06:48:23 GMT In <2jotg7$t9d@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: >J-D Mountjoy wrote: >>is a read/write distance limit. I suppose that this then precludes the >>standard bombers/searches etc. who just sit in one place and look >>through core? This would surely lead to more programs being written >It certainly would, which is why the only actual implementation of the '94 >standard (pMARS) doesn't support r/w limits. Well I don't have any objection to the limits being there, but if the standard has the limits in it, why are they not implemented? What's the point? J-D -- | J-D Mountjoy -- Rhodes University -- csjm@alpha.ru.ac.za -- My Views Only | From: pk6811s@acad.drake.edu Subject: Keystone t21 Message-ID: <1994Feb16.084131.1@acad.drake.edu> Date: Wed, 16 Feb 1994 14:41:31 GMT This is going to be a tough one for newbies, but here is the latest code for Keystone. Darn thing is so complicated _I'm_ not sure what everything is doing anymore. Sort of taken on a life of its own :-) Basically Keystone is a standard MOV very important 5. pre-loads part of the imp-ring into core, in case original is corrupted 6. imp-ring launcher creates a decrement stream (one pre-dec decrementing another) 7. imp-ring launcher lays down a spl-carpet for more tying power Some results: Keystone t21 wins: 65 Medusa's v5.1 wins: 29 Keystone t21 wins: 65 Iron Trap wins: 30 Keystone t21 wins: 63 Christopher wins: 18 Keystone t21 wins: 63 Blitzkrieg wins: 24 Keystone t21 wins: 62 SJ-4a wins: 19 Keystone t21 wins: 52 Iron Gate 1.1 wins: 39 Keystone t21 wins: 48 Dragon Spear III wins: 44 Keystone t21 wins: 42 test-tw wins: 25 Keystone t21 wins: 31 NC decoy wins: 37 Keystone t21 wins: 30 Walk Between the Raindrops wins: 30 Keystone t21 wins: 29 Incrimination v1.0 wins: 19 Keystone t21 wins: 23 Winter Werewolf 3 wins: 16 Keystone t21 wins: 23 ttti wins: 37 Keystone t21 wins: 23 Cannonade wins: 47 Keystone t21 wins: 21 Imprimis 7 wins: 43 Keystone t21 wins: 18 Genocide wins: 40 Keystone t21 wins: 15 Killer instinct wins: 29 Keystone t21 wins: 1 Paradox wins: 25 Keystone t21 wins: 1 Match Stick wins: 42 There's room for another stone on Koth, ideally it would do a fast mod-8 bomb/decrement followed by a spl/dat core-clear and a solid gate. Paper will destroy it, but there are plenty of scanners out there to munch on. ;redcode quiet ;name Keystone t21 ;kill Keystone ;author P.Kline ;strategy stone + anti-vamp ;strategy antivamp is converted by stone into core-clear/gate ;strategy if antivamp is dead, stone converts self into gate (djn 0,<-12) ;strategy if stone detects paper -> launch long 3-point imps & spl-carpet ;strategy t21: faster, more compact launch; added redundancy; better gate spacing equ 2517 ; mod-1, approximates a mod-4 step dat #-start,#1 ; long decoy to delay scanners dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 dat #-start,#1 hptr2 dat #hide6+2512+527+1 m0 spl mimp+5334, Subject: Paradox Date: Wed, 16 Feb 1994 19:31:41 -0500 Message-ID: Paradox is a gate-crashing spiral, combined with anti-imp and anti-vamp paper. The spiral is the key element. It had to be able to survive a coreclear, or else I would have no way to beat scanners, so I wove 4 2668-spirals together. If you take out the spiral part, and just run it against a gate, it will always lose. But something happens to it when a coreclear goes thru it, that makes it able to crash gates. Weaving gate-crashing spirals only works if the spiral that is furthest ahead of the others executes first, then the next furthest, etc., but this takes 4 "twitches" to get thru a coreclear. Paradox's spiral starts out with the spiral that's behind the others executing, then so on moving forward (4-3-2-1). A coreclear changes it so the second executes, then the farthest ahead, then the last, then the third (2-1-4-3). This can sometimes crash gates. I'm still not sure exactly how or why this happens. This spiral will crash gates like spl 0, <-16 dat <-17, #0 but will never cross gates like spl 0, <-16 dat <-17-2668, <-17 or spl 0, <-16 dat <-17, <-17+2667 Apparently, Dragon Spear III uses one of these... :) ;redcode ;name Paradox ;author Mike Nonemacher ;strategy Vampiric anti-imp paper + anti-vamp paper ;strategy + gate-crashing imp-spiral ;strategy You can always kill one... ;kill Paradox ;anti-imp paper, anti-vamp paper, and gate-crashing spiral PC1 EQU -2395 ;normal (anti-imp) paper's constant PC2 EQU 1067 ;anti-vamp paper's constant PC3 EQU -2995 IMPC EQU 232 ;offset of start of imp-spiral IMPOFF EQU 1 ;difference between 2667 & 2668 imps (-) D1 EQU 2667 D2 EQU 2668 i1off EQU 0 ;start as 4-3-2-1, coreclear changes it to i2off EQU 2667 ;2-1-4-3 i3off EQU 5334 i4off EQU 1 imp1 mov 0, 2667 imp2 mov 0, 2668 start spl p1 spl i2b i2a mov imp2, imp2+IMPC+i1off mov imp2, imp2+IMPC+i1off+1 mov imp2, imp2+IMPC+i1off+2 spl 1 spl 1 mov -1, 0 spl 2 jmp @0, imp2+IMPC+i1off add #D2, -1 dat #0 i2b spl i2c mov imp2, imp2+IMPC+i2off mov imp2, imp2+IMPC+i2off+1 spl 1 spl 1 mov -1, 0 spl 2 jmp @0, imp2+IMPC+i2off add #D2, -1 dat #0 i2c spl i2d mov imp2, imp2+IMPC+i3off spl 1 spl 1 mov -1, 0 spl 2 jmp @0, imp2+IMPC+i3off add #D2, -1 dat #0 i2d spl i1a spl 1 spl 1 mov -1, 0 spl 2 jmp @0, imp2+IMPC+i4off add #D2, -1 dat #0 i1a mov imp1, imp1+IMPC-IMPOFF spl 1 spl 1 mov -1, 0 spl 2 jmp @0, imp1+IMPC-IMPOFF add #D1, -1 dat #0 p1 spl 1 spl 1 spl 1 spl p3 spl p2 spl 1 mov #16, 16 ;Vampiric paper p001 mov <-1, <1 spl @0, #PC1 mov b1, <-1 mov b2, <-2 mov b3, <-3 jmz @0, -6 b1 dat <2667, <5334 b2 mov 0, <1 b3 jmp 50, <2667 mov b1, <-60 spl -1, <-60 jmp -2, <-61 jmp -3, <2667 jmp -4, <2667 jmp -5, <2667 spacer dat #0 mov #8, 8 p2 mov <-1, <1 spl @0, #PC2 mov #8, av-100 sub Date: Thu, 17 Feb 1994 00:12:04 GMT In article g88m0396@hippo.ru.ac.za (J-D Mountjoy) writes: >Well I don't have any objection to the limits being there, but if the >standard has the limits in it, why are they not implemented? What's the >point? > >J-D >-- >| J-D Mountjoy -- Rhodes University -- csjm@alpha.ru.ac.za -- My Views Only | (a) even if they are not used (read=writelimit=coresize) they slow down the simulator considerably (b) last time this discussion came up, there was no clear consensus how to implement limits and whether they should be included at all I am including a few recent posts on this topic; perhaps we can use this as a starting point. -Stefan (stst@vuse.vanderbilt.edu) -------begin posts on read/write limits------------------------------ From: ama@athena.mit.edu (Albert Ma) Newsgroups: rec.games.corewar Subject: ranges Date: 2 Nov 1993 22:28:07 GMT Organization: Massachusetts Institute of Technology Lines: 24 Distribution: world Message-ID: <2b6mto$mjj@senator-bedfellow.MIT.EDU> NNTP-Posting-Host: w20-575-111.mit.edu Realistically speaking, how smart can a warrior get given our current instructio n set, even with ranges? Ranges give a warrior time to do stuff, but what could a warrior possibly do? What kinds of things have been done with KotH-X? I understand ranges in KotH-X behave differently than they do in the proposed 94 standard. How would this affect things? what becomes possible/impossible? Also, we in the pMARS group are discussing various implementations of ranges. What do you guys think of a unified read/write/jmp range instead of separate ranges? Advantages of unified ranges o easier and more efficient to implement o separate r/w ranges have no real machine equivalent o weird things happen when ranges are different What would we lose if we went this way? One person advocates limited write and unlimited read. Supposing this were the case, what would a program do? You can't really tell what kind of program you're facing and what it's doing. Albert Article 2215 of rec.games.corewar: Newsgroups: rec.games.corewar Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!sol.ctr.colu mbia.edu!news.kei.com!ssd.intel.com!wms From: wms@ssd.intel.com (William Shubert) Subject: Re: ranges Message-ID: Sender: usenet@SSD.intel.com Nntp-Posting-Host: e26 Organization: Supercomputer Systems Division (SSD), Intel References: <2b6mto$mjj@senator-bedfellow.MIT.EDU> Date: Wed, 3 Nov 1993 02:24:40 GMT Lines: 46 ama@athena.mit.edu (Albert Ma) made some comments about ranges, some of which I would like to address. >Also, we in the pMARS group are discussing various implementations of ranges. >What do you guys think of a unified read/write/jmp range instead of >separate ranges? > >Advantages of unified ranges > >o easier and more efficient to implement Not true. >o separate r/w ranges have no real machine equivalent Not true. Many machines have areas of memory than can be read but not written to. >o weird things happen when ranges are different Depends on what you mean by "weird". Many would consider ALL corewar programs to be weird. >What would we lose if we went this way? The only way to know it for sure is to try it. >One person advocates limited write and unlimited read. That is exactly how KotH-X worked. > Supposing this were >the case, what would a program do? You can't really tell what kind of >program you're facing and what it's doing. That isn't correct. For a while, a program of mine (Spider) was doing very well on that hill; it would scan all of memory, looking for an opponent, then when it found an opponent moving in with a very fast attack right at the opponent. It was finally knocked off (opponents that moved too fast would slip right by), but it showed that options WERE available. Perhaps some tweaking would have revived it, but I got involved in other things. I don't mean to be argumentative, but you made a lot of statements about range limits that simply weren't correct. I believe that before ANY range limits are put into the standard, they should be tried out. Maybe other people would agree/disagree with me, but I'd say that KotH-X was a mixed success; some different appreaches to programming were made, but all the programs on the hill are (as far as I know) just regular-complexity programs that happen to travel through memory fast. Is there anybody else who tried KotH-X still around? What did you think of those access limits? -Bill (wms@ssd.intel.com) Article 2216 of rec.games.corewar: Path: hellgate.utah.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!umn.e du!gaia.ucs.orst.edu!news.reed.edu!jhopson From: jhopson@reed.edu (John Hopson) Newsgroups: rec.games.corewar Subject: Re: ranges Date: 3 Nov 1993 03:06:13 GMT Organization: Reed College, Portland, OR Lines: 16 Distribution: world Message-ID: <2b7775$m2t@scratchy.reed.edu> References: <2b6mto$mjj@senator-bedfellow.MIT.EDU> NNTP-Posting-Host: shiva.reed.edu >One person advocates limited write and unlimited read. Supposing this were >the case, what would a program do? You can't really tell what kind of >program you're facing and what it's doing. But it would create a new, hybrid class of scanners. These would act like a scanner until they found an enemy, then send out a smaller program that would replicate out to the enemy's location. Repeat until enemy is whipped. But as with all schemes involving write ranges, it makes replicating programs supreme. Bombers are obsolete, and scanners can only exist in conjuction with a replicating attack portion. I believe that such limits can only hurt the game. The entire point of corewars is that it is such a wide open battlefield. Any change involving limit s on reading or writing can only encourage small, stupid replicators. Article 2222 of rec.games.corewar: Newsgroups: rec.games.corewar Path: hellgate.utah.edu!caen!math.ohio-state.edu!cs.utexas.edu!asuvax!chnews!ssd .intel.com!wms From: wms@ssd.intel.com (William Shubert) Subject: Re: ranges Message-ID: Sender: usenet@SSD.intel.com Nntp-Posting-Host: e26 Organization: Supercomputer Systems Division (SSD), Intel References: <2b6mto$mjj@senator-bedfellow.MIT.EDU> <1993Nov3.184113.21579@news.v anderbilt.edu> Date: Wed, 3 Nov 1993 21:45:00 GMT Lines: 34 >In article <2b6mto$mjj@senator-bedfellow.MIT.EDU> ama@athena.mit.edu (Albert Ma ) > writes: >>o weird things happen when ranges are different >> > >This may need some explanation. Suppose >read range=2000 >write range=1000 > >0000 mov.i <700, blah > >Both read and write occur during A-operand evaluation, but the write access >(decrement) is wrapped, the read access isn't. Consequently, location 7700 >is decremented and 0700 is used for indirection. Weird, huh? Yes, this IS weird. That is why if you wrap when you go "out of range", I think that you HAVE to have a unified address space. I in general think that wrapping out-of-range addresses is dumb. Then, if you have a maximum range of 100, "mov x,100" and "mv x,101" puts "x" in widely separated locations. And the sequence: mov x,-100 mov y,-101 puts "x" and "y" in different locations. The model I prefer is to have out-of-range acceses fail in some way (by either killing the process, or not modifying the core during a write and returning "DAT 0,0" for any read). >The "unified read/write/jump range" Albert is mentioning is essentially the >same as Jon Newman's "address space" (TCWN, Winter 1990). This is implemented >by normalizing all numbers first to [-range/2..range/2-1] and then to >[0..coresize-1]. Yuck. If there is to be some sort of read/write limit (which I am not sure of), I really, really don't like this double-normalizing scheme for the reasons I explained above. -Bill (wms@ssd.intel.com) From: bdthomse%peruvian.cs.utah.edu@cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 17 Feb 94 12:02:47 MST Message-ID: <1994Feb17.120248.6541@hellgate.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| February 17, 1994 Issue #2 ______________________________________________________________________________ First off, I would like to thank everyone for the interest and comments I have received so far. There was a large increase in the number of programs submitted to both of the experimental hills on Stormking, as well as to the ICWS hill. (If anyone wants to cover that hill, it's still available! ;-) I also wanted to inform the masses about the program I used to create the title for this newsletter. It's called figlet, and you can get it by anonymous FTP to ftp.isu.edu:/pub/figlet. It is also being discussed in the alt.ascii-art newsgroup. If you are unfamiliar with the '94 draft standard, you can learn more about it by reading the FAQ for this newsgroup. In addition, the program pMARS includes a highly recommended tutorial on the new standard. Feel free to send me e-mail if you have any difficulty finding either of them, if you need to have a corewar item mailed to you, or if you have any other questions. The FAQ is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instrucitons Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current ICWS '94 Draft hill: # %W/ %L/ %T Name Author Score Age 1 42/ 30/ 28 Killer instinct Anders Ivner 155 5 2 38/ 25/ 37 NC II Wayne Sheppard 152 60 3 37/ 25/ 38 Sphinx v5.1 W. Mintardjo 148 63 4 35/ 25/ 39 Snake Wayne Sheppard 145 15 5 43/ 43/ 14 Fire Storm v1.1 W. Mintardjo 143 66 6 32/ 21/ 48 ttti nandor sieben 143 16 7 42/ 42/ 16 Sylvester v1.0 Brant D. Thomsen 142 42 8 32/ 23/ 45 ttti94 nandor sieben 142 11 9 35/ 28/ 38 JustTakingALookSee J.Layland 141 59 10 43/ 45/ 12 Rave 3 Stefan Strack 140 32 11 41/ 42/ 17 SJ-4 J.Layland 139 9 12 39/ 39/ 22 Christopher Steven Morrell 139 4 13 42/ 46/ 11 Rave Stefan Strack 138 43 14 39/ 41/ 20 Fast Food v2.1 Brant D. Thomsen 138 18 15 40/ 43/ 17 Beholder's Eye v1.7 W. Mintardjo 138 72 16 40/ 43/ 17 Ntttgtstitd Simon Hovell 136 6 17 38/ 42/ 20 tiny J.Layland 134 40 18 39/ 47/ 14 Impurge 94 Fredrik Ohrstrom 132 2 19 40/ 49/ 10 Medusa's v6 Mintardjo & Strack 132 65 20 31/ 31/ 37 CG IV Brant D. Thomsen 131 1 New programs on the hill include two warriors from the KOTH hill: "Killer instinct" and "Christopher"; as well as two new '94 warriors: "Impurge 94" and "CG IV". Despite the small number of new programs, the hill is really quite different. Killer instict jumped right to the top of the hill ... probably due to all the vampires it was able to prey upon. It's also interesting that the programs at the top of the hill tend to be those written in the '88 standard. Again, this is a good reflection of the intensity of competition on the KOTH hill. ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The current ICWS '94 Experimental hill: # %W/ %L/ %T Name Author Score Age 1 79/ 17/ 4 Rave 3 (55440) Stefan Strack 240 8 2 75/ 11/ 14 CG-X IV Brant D. Thomsen 239 7 3 74/ 23/ 3 No Ties Allowed Wayne Sheppard 226 13 4 68/ 22/ 10 BS J.Layland 213 15 5 65/ 23/ 12 testing testing Fredrik Ohrstrom 208 3 6 62/ 18/ 20 BigImps James Layland 206 16 7 57/ 19/ 24 Frantic 0.9 A Lee 195 17 8 59/ 33/ 9 bunker t3 P.Kline 184 4 9 56/ 28/ 16 Road Hammer 0.3 Simon Hovell 184 14 10 53/ 25/ 23 Iron Gate Wayne Sheppard 181 12 11 52/ 36/ 12 VJX-2 James Ojaste 169 1 12 36/ 53/ 11 Tiny Ring J.Layland 119 10 13 31/ 69/ 0 test 94X Anonymous 93 6 14-20 No entries A big thanks to James Ojaste for his entry: "VJX-2". Once again, this is an ideal hill for beginners -- you are _guaranteed_ to get on it! ______________________________________________________________________________ HINTS and HELPS: Before I begin with this week's hint, I need to thank Stefan Strack for pointing out a mistake in the last issue of _The 94 Warrior_. A MOV #a, B command is converted to MOV.AB #a, B in the '94 draft, which will only move the "a" value of the instruction -- instead of the entire instruction. You will need to explicitly specify that the instruction be MOV.I #a, B if you want an imp. The following is an excerpt from the latest draft of the '94 redcode proposal. I was actually planning to create a table similar to this for this issue's hint, but since one already exists, I'll just pass it along instead. A.2.1.2 ICWS'88 to ICWS'94 Conversion The default modifier for ICWS'88 emulation is determined according to the table below. Opcode A-mode B-mode modifier ------------------------------------------------ DAT #$@<> #$@<> F MOV,CMP # #$@<> AB $@<> # B $@<> $@<> I ADD,SUB,MUL,DIV,MOD # #$@<> AB $@<> # B $@<> $@<> F SLT # #$@<> AB $@<> #$@<> B JMP,JMZ,JMN,DJN,SPL #$@<> #$@<> B ------------------------------------------------ From now on, I will explicitly be specifying the moderator for all the instructions I supply in this newsletter -- which is probably a good idea when writing '94 warriors as well. I have found that forcing yourself to explicitly think about what modifier each instruction needs not only eases the development of '94 warriors, but can also be useful for generating ideas as well. * * * Since I'm already on the subject, this issue's hint will be on imp-rings and spirals. For those of you that are unfamiliar with exactly what imps, imp-rings, or imp-spirals are, here is a copy of the explanation in the FAQ: Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, " operand to continuously increment the B-field of a given location in the core. This causes the imp-spiral to move an instruction past the point where it is supposed to, thus leaving a gap in the imp-spiral. For an example of this technique, take a look at the following imp-gate: start SPL.B 0, >-20 DAT.B <-11, >-21 The location twenty instructions before "start" is continually being incremented, so any "standard" imp-spirals will be killed here. However, if a gate-crashing imp-spiral gets past this location, it will also need to get past the location ten instructions before "start", which is being decremented every other turn. Since the gate-crashing imp-spiral will tend to be quite fragile when it reaches the second location, the decrementing will usually be enough to finish it off. While this gate will stop the three special imp-spirals mentioned above, it is still possible to create a series of imp-spirals that can (at least occasion- ally) over-write it. However, this gate does have an advantage over the '88 method in its ability to work independently of the step-size of the imp- spiral -- as well as forcing the opponent to use more complex and less dependable imp-spiral combinations in order to over-write it. On a final note: you can easily create a '94 imp-gate that will stop any imp- spirals -- if the imp-spiral uses a "MOV.I 0, b" instruction instead of a "MOV.I #a, b" instruction. Simply have an imp-gate that continually increments the A-field at a given location. "Sylvester" uses this technique quite effectively! ______________________________________________________________________________ Looking to the Future: The lastest draft of the standard has been on soda.berkeley.edu for a couple of weeks now (as /pub/corewar/incoming/icws94.0202.Z). Take a look at it and let the newsgroup know what you think. There are some interesting additions to the former '94 draft standard. Also, please submit your programs to the '94 hills. We'd love to have your best KOTH warrior on the standard '94 hill, and I've found that the best way to learn the '94 standard is to take an '88 standard program and try to improve it. Not only will you get the additional challenge and enjoyment of learning the new standard, but you will be better able to correct and critique the latest drafts of the new standard when they arrive. If you have any comments or questions about the '94 hills or the '94 standard that you think might be of general interest, please let me know. Good luck, and happy computing! ______________________________________________________________________________ Brant D. Thomsen, Editor Snail mail: 1197 E. 6290 S. (bdthomse@peruvian.cs.utah.edu) Salt Lake City, UT 84121 University of Utah U.S.A. -- Brant D. Thomsen The teaching of BASIC in schools bdthomse@peruvian.cs.utah.edu should be considered a criminal act. (University of Utah) - Dijkstra From: clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) Subject: Kind of newbie... Message-ID: Date: Fri, 18 Feb 1994 03:57:48 GMT As the subject line suggests, I'm "sort of" a newbie. I've actually written a simple CoreWar MARS program for the Amiga (called GCW). It's based on the two original Scientific American articles on CoreWar, so it does not conform to any of the ICWS standards (yet). I just found out about this group a couple of days ago, and I promptly went and read the FAQ as well as the ICWS'94 proposal. I noticed a few odd things about the ICWS'94 proposal: First, it says the default behaviour for ORG is 0. If the first line of the program is a DAT won't this kill it? GCW currently always executes the first non-DAT instruction. Also, no mention is made as to whether labels are case-sensitive. Would it be safe to assume they are not? Oh, and what would a line like this: foo bar EQU 6 do? ie: is foo a label, or an equate? Also, the grammar is screwed up regarding EQU. According to the grammar, an expression involving EQU would be set up like: [label *] EQU[.modifier] [mode][field] [, [mode][field] ] [comment] while it looks like these are special instructions that should only be treated as: