From: fesmire@huey.met.fsu.edu (John R. Fesmire) Subject: Re: Help! - New to IRC Date: Wed, 2 Jun 1993 13:41:23 GMT Message-ID: In response to David's request: Unfortunately, I can't help you as far as tutorials go since I am a newcomer also. But as far as the UNIX compressed files go, there is a program called gzip avaliable via anonymous ftp from prep.ai.mit.edu that will decompress .Z files. This program is considered freeware and I believe that there is a version that is supported by the VAX. Good luck! --- Rusty Fesmire From: jlayland@kilroy.Jpl.Nasa.Gov (James Layland) Subject: FlyPaper 2.0 and a (Useful?) Idea Date: 2 Jun 1993 16:47:49 GMT Message-ID: <1uiljl$a7j@elroy.jpl.nasa.gov> First, a potentially useful (I think) idea, that I haven't been terribly successful with. Seems everyone out there has an imp gate, often of the form: spl 0, <-11 dat Paper, ideas from GammaPaper/Plasma/Paratroops ;strategy 2.0-- now uses Agony-based cmp-scanner, added bootstrap routine. ;strategy Imp killing replicator copied from Gamma Paper ; (I tried using dorky imps, etc. in place of mov @-2667,2667 ; without much change) skip equ 200 dist2 equ 3364 init EQU last+skip-1+dist2 dist EQU 13 boot mov Date: Thu, 3 Jun 1993 04:38:55 GMT Scott Ellentuch has set up a new King of the Hill corewar server based on Bill Shubert's program. There's no point in simply duplicating wms-KotH, so we'd like to ask you what the new KotH should look like. A few ideas: -a beginner's hill where people submit who are just getting started, perhaps with automatic exclusion of players represented on wms-KotH and a system where age decreases the score. -an ICWS-hill using the rules for the annual tournament (coresize= 8192, maxtasks=64). All you ICWS members out there should like this! -a new experimental hill with larger coresize, wrap-around read/write limits, possibly new opcodes, etc. Scott is willing to set up more than one hill (i.e. redcode-beginner, redcode- icws, redcode-x, etc.). Tell us what you want. Reply by email or post; I will summarize all email replies. Second, Scott's news-to-email gateway for this newsgroup is still waiting for a kind sysadmin to provide him with a steady newsfeed. Any volunteers? Contact me. -Stefan (stst@vuse.vanderbilt.edu) P.S.: you should be able to try out the new koth by mailing your warrior to koth@stormking.com; it is presently configured like wms-KotH. From: wangsawm@prism.CS.ORST.EDU (W. Mintardjo) Subject: Insight from an old program Message-ID: <1ukenkINNb7t@flop.ENGR.ORST.EDU> Date: 3 Jun 93 09:02:44 GMT Here is a nifty trick I learnt from an old paper program. (Sorry, couldn't remember what the name is). To create N# processes that execute the same piece of code: - subtract N by one - encode the new value to its equivalent binary form - From left to right, replace each '1' with 'SPL 1', and replace each '0' with 'MOV -1, 0' (doesn't have to be -1. Anything that points to SPL 1) For example: - Set up 13 processes for an imp-spiral 13 x 1 step EQU 3077 SPL 1 ;Equivalent to 1100 (binary) or 12 (decimal) which is one less SPL 1 ;than 13 MOV -1, 0 MOV -1, 0 SPL inc ;13 processes fork to the incrementing processes go JMP @0, imp ;go imp!! inc ADD imp, go ;modifier DAT #0 ;suicide after incrementing imp MOV imp, imp+step - And here is a bit of code I borrowed from P.Kline's Eloquent Each Eloquent's paper module looks like this: mov #6,0 add #-31,2 mov <-2,<1 spl @0,7000 jmz -4,-4 mov 0,<0 6 processes are required to run together on it. The equivalent set up: start SPL 1 MOV -1, 0 SPL 1 ;Create 6 processes running together Have fun, Mintardjo W. From: wolfe@bharh94.bnr.co.uk (Ian Woollard) Subject: Re: A new KotH Date: 3 Jun 1993 16:27:03 GMT Message-ID: <1ul8onINNct0@bHARs12c.bnr.co.uk> In article stst@vuse.vanderbilt.edu (Stefan Strack) writes: > >Scott Ellentuch has set up a new King of the Hill corewar server based on >Bill Shubert's program. There's no point in simply duplicating wms-KotH, >so we'd like to ask you what the new KotH should look like. > I think that it is time for a new sort of hill, one that says how good a program really *is*, not just how well it beats the particular variety of stone-paper-scissors that happens to be prevalent today. This means several things: a) a program gets more score for beating a really good program than one that is not so good. (Loses more for losing against a bad program.) b) the hill is large, so that stone and paper and scissors all fit in together. c) new programs don't play every program in sight, just enough to get a reasonable accuracy of score. When you think about it. A hill really plays two players off. Based on this it estimates a 'rating'. This is exactly the same as the way ratings work in chess... I'm currently trying to implement a rating system, like this, to support a speculative project of mine... should take 2-3 weeks. -Ian. From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: On the Tournament... Date: 3 Jun 1993 19:08:17 -0500 Message-ID: <9306040002.AA28049@st6000.sct.edu> P. Kline writes: <.................................................... Every program Can anyone beat Imprimis consistantly :-) This round will be quite interesting. Wayne wsheppar@st6000.sct.edu From: ama@athena.mit.edu (Albert Ma) Subject: Re: A new KotH Date: 3 Jun 1993 21:23:45 GMT Message-ID: <1ulq51INNb8i@senator-bedfellow.MIT.EDU> In article , stst@vuse.vanderbilt.edu (Stefan Strack) writes: |> |> Scott Ellentuch has set up a new King of the Hill corewar server based on |> Bill Shubert's program. There's no point in simply duplicating wms-KotH, |> so we'd like to ask you what the new KotH should look like. My 0 cents worth: Run a larger number of rounds than the standard 100. Variations in score of 10% are common with only 100 rounds. In article <1ul8onINNct0@bHARs12c.bnr.co.uk>, Ian Woollard writes >c) new programs don't play every program in sight, just enough to get >a reasonable accuracy of score. >When you think about it. A hill really plays two players off. Based on >this it estimates a 'rating'. This is exactly the same as the way >ratings work in chess... This wouldn't work in corewars, the score of a program is highly dependent upon the type of opponent it faces. A halfway decent vampire can nuke the most incredible replicator. On a totally unrelated topic: Watch for the new version of Mercury to be released hopefully early next week. Depending on the types of instructions executed, you might see a 30-45% increase in speed. ------------------------------------------------ Great sig huh? Albert Ma ama@athena.mit.edu From: pk6811s@acad.drake.edu Subject: Re: A new KotH Message-ID: <1993Jun3.154527.1@acad.drake.edu> Date: Thu, 3 Jun 1993 21:45:27 GMT > In article stst@vuse.vanderbilt.edu (Stefan Strack) writes: >> >>Scott Ellentuch has set up a new King of the Hill corewar server based on >>Bill Shubert's program. There's no point in simply duplicating wms-KotH, >>so we'd like to ask you what the new KotH should look like. >> How about if the new hill is large, so your program gets to play as many opponents as possible. Then limit players to a single program on the hill at a time. That would prevent someone (or a small number of someone's) from hogging the hill. So every time I submit a new program, it knocks any previous program of mine off. If I don't have anything on, then it might knock the lowest rated program off. This way I can't keep a program on for a long time, unless I give up running other tests. So more of the time gets used by newer players. It was suggested that wins against 'better' programs count more that wins against 'poorer' programs. How do you determine which programs are 'better', unless you use their scores, which are determined by their performance against the current mix of warriors? Every program gets clobbered by some style of opponent even if that style is poorly implemented (except Snake, anybody beating Snake? I need to know right away :-) -Paul pk6811s@acad.drake.edu From: slandrum@ntg.com (Stephen H. Landrum) Subject: Re: Insight from an old program Message-ID: <1993Jun4.031610.471@ntg.com> Date: Fri, 4 Jun 1993 03:16:10 GMT In article <1ukenkINNb7t@flop.ENGR.ORST.EDU> wangsawm@prism.CS.ORST.EDU (W. Mintardjo) writes: > >Here is a nifty trick I learnt from an old paper program. (Sorry, couldn't >remember what the name is). > >To create N# processes that execute the same piece of code: > - subtract N by one > - encode the new value to its equivalent binary form > - From left to right, replace each '1' with 'SPL 1', and > replace each '0' with 'MOV -1, 0' (doesn't have to be -1. Anything that > points to SPL 1) This is probably from Paper, originally by Scott Nelson. Paper was the first program that I know of that used tandem processes executing the same code. -- Stephen H. Landrum VOICE: (415) 813-8909 Domain: slandrum@ntg.com New Technologies Group - a Division of the 3DO Company 2470 Embarcardero Way, Palo Alto CA 94303 From: han@sor.inria.fr (Jay Han) Subject: Re: Re: A new KotH Message-ID: Date: 4 Jun 93 10:33:48 GMT Yes! Make a beginner's Hill! I'm not a total novice myself (got on the Hill twice), but I found it very frustrating to have to work over a month to get >100 score on the regular Hill. Also, when your new warrior gets beaten by 0/98/2 it doesn't tell you much about its weaknesses. There was a discussion here some time back about the rules. If I remember correctly: - All players with a warrior currently on the regular Hill are excluded - A warrior whose age exceeds 100 is automatically taken out and challenges the regular Hill - If a warrior makes it on the beginner's Hill, its code is sent to all the opponents (except if ;redcode-beginner-quiet or somesuch) An ICWS Hill sounds interesting too. I think the experimental Hill should follow the ICWS'94 draft when it's published. Just my opinion. Jay Han -- Jay Han From: stig@pvv.unit.no (Stig Hemmer) Subject: Re: A new KotH Date: 4 Jun 1993 14:38:37 GMT Message-ID: <1unmpdINNifi@flipper.pvv.unit.no> In article <1993Jun3.154527.1@acad.drake.edu>, pk6811s@acad.drake.edu writes: |> How about if the new hill is large, so your program gets to play as many |> opponents as possible. Then limit players to a single program on the hill |> at a time. That would prevent someone (or a small number of someone's) |> from hogging the hill. So every time I submit a new program, it knocks |> any previous program of mine off. This should be very to implement as you simply pretend that every entry contains a ;kill line. However, I think that this would be bad. IMHO, a much better way to limit people to one entry would be to make sure that if the submitter already has an old program on the Hill one of the two programs will be pushed off. Not necessarily the old one, but the one with the lowest score. This way people won't have to resubmit their champion after submitting test programs. This alternative would require more programming though. |> It was suggested that wins against 'better' programs count more that |> wins against 'poorer' programs. How do you determine which programs |> are 'better', unless you use their scores, which are determined by |> their performance against the current mix of warriors? 01234567890123456789012345678901234567890123456789012345678901234567890123456789 One old suggestion from I've-forgot-who was that you first run an ordinary all-vs-all turnament, then kick off the bottom entry, run a new turnament and so on until you have a finale between the two presumably best programs. This sounds like an awful lot of battles but you can use the same battles in each round, you just subtract the scores gained against the kicked-off program. A program that is very one-sided will kick out the programs that earns it points and fall off itself. This means that you need a program with many strong points to win. I feel that this is good. (Although most of my own good programs has been one-sided. :-) On the other hand it would be a very static hill. A program that kicks off the old number 19 and reached number 15 itself will not change the order of the top 14 at all. Stig Hemmer aka stig@pvv.unit.no .no means Norway, a minor kingdom in northern Europe. Date: Fri, 4 Jun 1993 16:02:08 MST From: Message-ID: <93155.160208ASMQK@ASUACAD.BITNET> Subject: Re: A new KotH The methode eliminating the last was my suggestion, and I still think it would be great. At least we should give it a try if there is no other more sophisticated one. A test mode would be usefull, that is, just result without making it onto the hill. Nandor. From: KENT@dirac.physics.jmu.edu (Kent Peterson) Subject: Re: A suggestion for SPL Message-ID: Date: Sun, 6 Jun 1993 12:25:25 GMT In <1us9jd$a2p@tartarus.uwa.edu.au> devink@tartarus.uwa.edu.au writes: > In reading the files digest-? I've seen several suggestions for taking the > 'sting' out of the SPL instruction. All of these methods seemed overly > complex and so I'd like to suggest one of my own. > > Essentially the idea is to give each warrior control over who and where > it's processes may be split. The idea is to implement a password (or > number) protection scheme. In order to split the correct password must be > provided, an instruction to change the password is provided. > > The protection is intentionally not foolproof, a program may still use > strategies that force the opponent to split but in order to do so they > must 'steal' the opponent's password. > > [explanation of interesting idea deleted] > The last time I looked (a few weeks ago), the X-hill had not changed appreciably since last October. Eric Schwertfeger and Alex MacAulay continue to share the burden of kingship there. IMHO, it is high time to try out a new X-hill, and the above idea would be a good way to do it. Opinions? Kent Peterson From: devink@tartarus.uwa.edu.au (Devin Kilminster) Subject: A suggestion for SPL Date: 6 Jun 1993 16:24:13 +0800 Message-ID: <1us9jd$a2p@tartarus.uwa.edu.au> In reading the files digest-? I've seen several suggestions for taking the 'sting' out of the SPL instruction. All of these methods seemed overly complex and so I'd like to suggest one of my own. Essentially the idea is to give each warrior control over who and where it's processes may be split. The idea is to implement a password (or number) protection scheme. In order to split the correct password must be provided, an instruction to change the password is provided. The protection is intentionally not foolproof, a program may still use strategies that force the opponent to split but in order to do so they must 'steal' the opponent's password. The change modifies the SPL instruction and adds the PWD instruction as follows: SPL A B - Place A in the process queue only if B matches the 'Split Password'. Otherwise execution continues normally. PWD A B - Change the 'Split Password' to A only if B matches the current 'Split Password'. Otherwise execution continues normally. The split password is maintained seperately for each program. At the beginning of execution it can be set to a standard value eg 0 and then changed by each program. A useful extension to the preprocessor (not redcode!) would be the addition of a method of generating a random number. eg: EQU MyPassword random start PWD MyPassword 0 . . . SPL somewhere MyPassword This will take most of the effectiveness out of SPL 0 type attacks however there are some interesting strategies along the same lines that may be employed. 1) Scan the opponent's code in order to steal the password, then bomb them with SPL's. This would tend to lead to strategys of hiding the password in various ways. 2) Since the opponent's password will be a number in {0,..,CORESIZE-1} it ought to be possible to adopt a brute force approach to guessing the password. eg: DAT #0 trap PWD 0 <-1 JMP -1 Force your opponent to jump to trap and it will eventually set it's password to zero allowing easy exploitation of SPL 0 0 etc. Obvious defences to this would be to fork off several processes in order to reduce the amount of time spent in the trap routine. (of course forking off more routines is dangerous as it requires exposing the password for a short time) I believe that this change should be relatively easy to implement and would result in a more interesting game. Devin Kilminster. From: wms@ssd.intel.com (William Shubert) Subject: Re: A suggestion for SPL Message-ID: Date: Sun, 6 Jun 1993 20:41:46 GMT KENT@dirac.physics.jmu.edu (Kent Peterson): >In <1us9jd$a2p@tartarus.uwa.edu.au> devink@tartarus.uwa.edu.au writes: > >> In reading the files digest-? I've seen several suggestions for taking the >> 'sting' out of the SPL instruction. All of these methods seemed overly >> complex and so I'd like to suggest one of my own. >> >> Essentially the idea is to give each warrior control over who and where >> it's processes may be split. The idea is to implement a password (or >> number) protection scheme. In order to split the correct password must be >> provided, an instruction to change the password is provided. >> >> The protection is intentionally not foolproof, a program may still use >> strategies that force the opponent to split but in order to do so they >> must 'steal' the opponent's password. >> >> [explanation of interesting idea deleted] >> > >The last time I looked (a few weeks ago), the X-hill had not changed >appreciably since last October. Eric Schwertfeger and Alex MacAulay continue >to share the burden of kingship there. IMHO, it is high time to try out a >new X-hill, and the above idea would be a good way to do it. Opinions? This is already in KotH. Try "koth -splitid" to play around with it. I'd be happy to try it out on the X-hill, but first: does anybody want to submit programs to try it? If I get enough response I'll give it a try. -Bill (wms@ssd.intel.com) PS - I tried to post a letter like this already, but I think that I screwed up. Sorry if you see it twice. From: devink@tartarus.uwa.edu.au (Devin Kilminster) Subject: Re: A suggestion for SPL Date: 7 Jun 1993 15:51:42 +0800 Message-ID: <1uus2e$5do@tartarus.uwa.edu.au> William Shubert (wms@ssd.intel.com) wrote: : This is already in KotH. Try "koth -splitid" to play around with it. : I'd be happy to try it out on the X-hill, but first: does anybody want to : submit programs to try it? If I get enough response I'll give it a try. : -Bill (wms@ssd.intel.com) Well, I'd like to have a shot at it, I'd like to know about the specifics of the implementation though. I also need to find a corewar system that supports it. Devin Kilminster. From: wsheppar@st6000.sct.edu (Wayne Sheppard) Subject: Cleaver.red Date: 7 Jun 1993 18:25:10 -0500 Message-ID: <9306072319.AA67806@st6000.sct.edu> CMP scanners sure have taken a beating lately. And there are 10 (if I counted right) imp warriors on the hill. I am going to have a tough time going up against the latest version of Sphinx in the tournament this week. And I'm going to resubmit Snake with a different trap location so Emerald doesn't beat me up so bad. By the way, does anyone have a coreclear/perfect gate that ends in a perfect gate or will I have to figure it out myself. In an attempt to do away with some of the imps, I am publishing Cleaver. Use it, modify it, destroy it. I don't care. Just give me credit for it. :-) I was inspired by the ;strategy line in Leprichaun 1b. Not knowing how Anders had done it(I missed his post), I set out to design my own version. One main difference is his use of SPL bombs. I opted to go for the DAT bombs. The trick is to throw out a bomb that is a pointer. Then instead of just JMPing back to the first statement of the loop, use a JMZ to see if the pointer is pointing to something. Then you add an offset so you are pointing directly to the item. Now would be a good time to bomb it, but I CMP it against #2667. If I get the imp trail, I back up a bit, then bomb in an impspiral pattern to stun the entire ring. Now just follow up with a coreclear and gate. The problems come from no defence against paper, and no coreclear vs self-splitting bombers/vamps. I haven't been able to do much to correct these problem areas. ;redcode ;name Cleaver ;author Wayne Sheppard ;strategy Bomber/Bscanner/Impscanner dist equ 2376 look equ dist*2 imp equ 2667 start add #look,loc mov bomb,@loc loc jmz -2,@hit add #dist,loc cmp #imp,@loc jmp loc-1,<1000 sub #8,loc hit mov s, It was nice to see Wayne Shepherd's Cleaver back on the hill. (Distance always did well when Cleaver was on the hill! :-) The following is the code for Distance v6.3. It is basically the same as Distance v6.2, except that the boot-straping routine has been changed. Instead of using "MOV -1" statements to abscure the move commands, I moved everything relative to pointers, and then simply obscured the pointers. It got everything off the ground much more quickly. (Why didn't someone point this trick out to me when I posted Wimp?! My forehead hurt for two days after slapping it when I realized what I had done!) The code is pretty straight forward. The stone covers most of the core before hitting itself and starting the core-clear/pit. After the coreclear has killed itself, the only processes left should be two wimps, which will eliminate any imp-spirals still hanging around. "Wimp", by the way, is my nickname for the command "JMP 0, <-x" . By sending one of your processes to the "wimp", and positioning the "wimp" after your main code, you can still get a win if an imp-spiral over-runs your main code. The problems, of course, are that bootstraping is required, your footprint is slightly larger, and the process used by the wimp is "useless" until/unless you are over-run by an imp. ;redcode ;name Distance v6.3 ;author Brant D. Thomsen ;strategy Standard pit-trap/vampire. ;strategy Bombs the core using an "optimal" mod 2 step. ;strategy After using pit to clear the core, degrades into a perfect Imp gate. ;strategy v6 : Added "wimps" to provide protection against imp-spirals ;strategy v6.2 : Mirrors code to hide itself. ;strategy v6.3 : Improved bootstraping, smaller scanner target. ;strategy Submitted: @date@ dist equ 4000 ; Distance for first core from bootstrap step equ 3094 ; Bombing step adist equ 18 ; Distance of JMP bomb from "top" bdist equ -49 ; Distance between "top" and "clear" gdist equ 20 ; Distance between Imp-Gate decrement and "top" sdist equ 23 ; Distance between "top" and adding data. hdist equ -63 ; Distance between "top" and first wimp idist equ -81 ; Distance between "top" and second wimp start mov top+3, Hi There, does anybody here know where I could get c robots for Unix? thx, /HaWee/ {fido: 2:284/102,email: hanwen@stack.urc.tue.nl} From: wms@ssd.intel.com (William Shubert) Subject: Looking for "steveg" Message-ID: Date: Tue, 8 Jun 1993 15:29:16 GMT Sorry to clutter the net... Would whoever has a login of "steveg" something and has been sending mail to KotH please send me mail without the ";redcode" line? Your mail has been confusing KotH so all the responses it tries to send bounce. Thanks. -Bill (wms@ssd.intel.com) From: pk6811s@acad.drake.edu Subject: _Push Off_ Message-ID: <1993Jun8.120052.1@acad.drake.edu> Date: Tue, 8 Jun 1993 18:00:52 GMT _PUSH OFF_ A midweek review of Corewar June 8, 1993 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 44/ 36/ 20 Distance v6.3 Brant D. Thomsen 151 121 2 46/ 45/ 9 Cleaver Wayne Sheppard 147 4 3 34/ 22/ 44 Night Crawler Wayne Sheppard 146 627 4 33/ 22/ 45 Imprimis 6 P.Kline 145 1027 5 37/ 31/ 32 FlyPaper 3.0 J.Layland 144 51 6 43/ 43/ 13 Arghhhh Fredrik Ohrstrom 143 122 7 45/ 46/ 9 Backstabber Anders Ivner 143 178 8 44/ 46/ 10 Dragon Spear c w blue 141 729 9 32/ 23/ 46 Incrimination v1.0 Brant D. Thomsen 141 31 10 40/ 39/ 21 Emerald 5.1011 P.Kline 140 5 11 33/ 26/ 41 Sphinx v2.8 W. Mintardjo 139 1625 12 30/ 23/ 46 Snake Wayne Sheppard 137 387 13 33/ 29/ 38 ImpsAreMyFriend 1.1 J.Layland 136 116 14 42/ 48/ 10 Fire Storm v1.1 W. Mintardjo 136 266 15 30/ 26/ 44 ttt nandor sieben 135 88 16 40/ 46/ 14 Iron Gate 1.01 Wayne Sheppard 134 455 17 28/ 23/ 49 ttest nandor sieben 133 503 18 41/ 50/ 9 Eclipse II P.Kline 132 1 19 40/ 52/ 8 Agony 5.2 Stefan Strack 129 254 20 34/ 57/ 9 Unknown Unknown 112 2 21 2/ 2/ 0 Early Bird c w blue 7 3 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives 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: King of the Hill enthusiasts were successful in knocking off two more long-standing warriors, Leprechaun 1b by A. Ivner, and Sucker 5 by S. Strack. Leprechaun 1b's age of 1453 has been succeeded only by +0 Stormbringer and Sphinx v2.8. His strategy was to dat-bomb and b-scan at the same time, using a spl-jmp stunner to catch replicators. A few weeks ago Sucker 4 was knocked off and now Sucker 5. Is Sucker really dead, or can Strack pull off a Bram Stroker and resurrect this classic vampire? Some drop off, and some rise like good cream to the top. This week Imprimis 6 passed the 1000-challenge barrier. Kudos to - well - me! Speaking of successful imps, W. Mintardjo is faced with this dilemma: 1 40/ 21/ 39 Sphinx v4.9 W. Mintardjo 158 1 8 32/ 26/ 42 Sphinx v2.8 W. Mintardjo 138 1610 So does he kill off Sphinx v2.8 just as it is approaching +0 Stormbringer's record 1778, or does he keep v4.9 under wraps until v2.8 gets pushed off? (which might be a long, long time :-) Strack's summer tournament rolls on with Mintardjo and Sheppard beating Ivner and Kline out of the loser bracket. Yeeesh. NOW I have a version that beats Snake :-( These two will play off later today and the winner will face Nabutovsky for the championship. Good luck! Sorry folks, there was no _Push Off_ last week. I was too busy trying to convince Wayne to NOT use Snake in our tournament match, making him think I was working on a sure-fire anti-vamp routine, and also to make him think I was going to use a replicator so he would use a scanner that Emerald could beat. But he stuck with Snake and won. Hope you enjoyed the hijinks, anyway :-) Now for a bit of nostalgia. Here was the current hill on July 16, 1992: Title Author Score Age ----- ------ ----- --- No Mucking About Cambel Fraser 164 36 Charon v7.0 J. Cisek & S.Strack 162 51 B-scanners live in vain Matt Hastings 161 18 Crimp 2 Andy Pierce 157 360 Flash Paper3.7 Matt Hastings 156 88 Sucker 4 Stefan Strack 150 289 Note Paper Scott Nelson 148 687 Falling Leaf 1.21 Matt Hastings 144 174 Smooth Noodle Map Matt Hastings 144 294 Dynamic Duo 4.01 Stefan Strack 141 39 PitTrap v4.0 J. Cisek 140 193 Quebec Eric Prestemon 139 22 RoadRunner I S. Halvorsen 139 267 Trinity Matt Hastings 138 293 Nikita 1.4 Jarkko Lindblad 136 1 Kobold Stefan Strack 133 148 Miny v.3 Paul S. Kilroy 131 2 Relentless J. Cisek 131 9 RotLD 2 nandor sieben 131 3 teszt nandor sieben 128 16 The scanners were tough last summer! And Flash Paper became the fave target of many challengers, only succumbing in the Fall with the onslaught of imps. And Sucker 4 nearly was the first to go over 1000 challenges before being pushed off for the same reason. ------------------------------------------------------------------------------- IV. The Outlook: 4 29/ 18/ 53 Incrimination v1.0 Brant D. Thomsen 141 1 6 41/ 38/ 20 Emerald 5.1011 P.Kline 144 1 6 32/ 22/ 46 Oak Stake III c w blue 141 1 9 27/ 21/ 52 Oak Stake II c w blue 132 1 3 35/ 25/ 39 FlyPaper 3.0 J.Layland 145 1 3 38/ 29/ 33 FlyPaper 4.0 J.Layland 148 1 5 40/ 39/ 21 sub-type-v2 c w blue 141 1 4 35/ 26/ 39 Passport 7 P.Kline 143 1 9 40/ 41/ 20 Herem IV Anders Ivner 138 1 3 47/ 42/ 11 Cleaver Wayne Sheppard 153 1 5 32/ 25/ 44 ttt nandor sieben 139 1 9 29/ 22/ 49 Snake7 Wayne Sheppard 136 1 9 39/ 41/ 20 Emerald 5 P.Kline 138 1 ------------------------------------------------------------------------------- V. The Quick Look: 21 1/ 84/ 14 RG KE Lewin 18 0 21 10/ 43/ 48 ick KE Lewin 77 0 19 35/ 43/ 22 wwf J.Layland 127 1 21 27/ 59/ 14 Bomb Michael Constant 95 0 20 25/ 68/ 7 Geek Aaron Helleman 82 1 16 36/ 41/ 22 TWW2 W. Mintardjo 132 1 21 23/ 36/ 41 test P.Kline 110 0 21 30/ 53/ 17 test J.Layland 106 0 12 39/ 38/ 23 Twill Andy Pierce 139 1 21 14/ 85/ 1 XPDNC Michael Constant 44 0 21 28/ 71/ 1 A-bomb Michael Constant 85 0 21 25/ 72/ 3 Icebox Fredrik Ohrstrom 78 0 21 24/ 47/ 29 Invest Andre van Dalen 102 0 21 17/ 71/ 12 fester c w blue 62 0 18 29/ 34/ 37 ptest1 Fredrik Ohrstrom 124 1 21 3/ 88/ 9 spil63 Andre van Dalen 19 0 21 24/ 35/ 41 test 2 P.Kline 114 0 20 36/ 53/ 11 CraMPon c w blue 119 1 20 1/ 76/ 22 Unknown KE Lewin 27 1 21 25/ 68/ 7 Icebox 2 Fredrik Ohrstrom 82 0 21 8/ 54/ 38 Impact 2 Jay Han 63 0 19 25/ 31/ 44 Passport P.Kline 119 1 21 19/ 40/ 40 Pipin IV cArno Martin Fuhlend 99 0 19 35/ 47/ 18 Wimp 6.1 Brant D. Thomsen 123 1 20 37/ 52/ 11 a-test-a nandor sieben 122 1 21 3/ 74/ 23 Eight 1.0 Devin Kilminster 32 0 13 40/ 45/ 15 Emerald 4 P.Kline 135 1 21 23/ 74/ 2 Noise 1.0 Devin Kilminster 72 0 21 27/ 72/ 1 Simplex 1 Scriv 81 0 21 16/ 71/ 12 Thrice 10 Steve Gunnell 61 0 20 34/ 43/ 24 Early Bird c w blue 125 1 20 36/ 52/ 13 Eclipse II P.Kline 120 1 21 16/ 78/ 7 Expediency Michael Constant 54 0 18 40/ 51/ 9 Iron Sword Wayne Sheppard 128 1 14 42/ 51/ 8 Irony v1.0 Brant D. Thomsen 133 1 21 19/ 70/ 11 Thrice 10a Steve Gunnell 67 0 20 37/ 50/ 14 newscanner c w blue 124 1 20 35/ 53/ 13 sub-type-c c w blue 117 1 19 25/ 62/ 13 Spare Parts Fredrik Ohrstrom 88 1 21 23/ 67/ 10 Sparrowhawk Michael Constant 79 0 19 28/ 35/ 37 Stoned Ratz c w blue 120 1 21 1/ 88/ 11 Vampire 4PK Wayne Sheppard 14 0 21 22/ 43/ 35 sub-type-av c w blue 102 0 19 35/ 45/ 19 sub-type-bs c w blue 126 1 10 42/ 45/ 13 sub-type-gv c w blue 138 1 11 29/ 22/ 48 sub-type-os c w blue 137 1 21 17/ 61/ 21 Duplicator 1 Bruno Degiovanni 73 0 21 23/ 55/ 22 Just testing c w blue 92 0 21 10/ 83/ 7 Snake Hunter J.Layland 36 0 21 20/ 69/ 11 StunGun v1.3 Han-Wen Nienhuys 71 0 20 27/ 56/ 17 sub-type-aix c w blue 98 1 21 16/ 83/ 0 Ring of Death Michael Constant 49 0 19 33/ 45/ 21 Spare Parts 1 Fredrik Ohrstrom 122 1 20 28/ 37/ 35 Anti-Imp Paper c w blue 118 1 10 28/ 19/ 52 Flash Paper3.7 Matt Hastings 138 1 (W.Sheppard) 21 9/ 46/ 45 Noisey Imp 1.0 Devin Kilminster 73 0 20 27/ 57/ 17 Precision v1.0 Brant D. Thomsen 96 1 21 16/ 81/ 3 Snake Hunter 2 J.Layland 50 0 19 37/ 49/ 14 Glass House 3.0 J.Layland 125 1 21 19/ 52/ 29 Paper Noise 1.0 Devin Kilminster 87 0 19 20/ 24/ 56 Simplicity v3.0 Brant D. Thomsen 117 1 12 37/ 40/ 23 Winter Werewolf W. Mintardjo 135 1 (J.layland) 21 19/ 76/ 5 CheckYourFlyPaper J.Layland 63 0 21 32/ 57/ 11 RoadRunner K (26) S. Halvorsen 107 0 21 18/ 36/ 46 Spare Parts test2 Fredrik Ohrstrom 100 0 20 21/ 39/ 40 Construction Paper c w blue 102 1 17 30/ 31/ 39 Spare Parts (test) Fredrik Ohrstrom 129 1 19 29/ 32/ 39 anti-vampire paper c w blue 125 1 20 31/ 41/ 29 testing Leprechaun Anders Ivner 121 1 13 32/ 30/ 38 ImpsAreMyFriend 1.1 J.Layland 133 1 21 33/ 51/ 15 RoadRunner K (21.1) S. Halvorsen 115 0 ------------------------------------------------------------------------------- VI. The Hint: To boot or not to boot, that is the question. Bootstrapping means to copy some part of your program away from your initial code and start it running there. It is a useful technique that offers several advantages to your fighters. One use of booting is to have your fighter running with the smallest profile possible, combined with a large 'decoy' of non-running code to distract scanners. This is most effective against one-shot scanners like Plasma, Paratroops, Eclipse, Cleaver, FlyPaper, etc. that scan until they find something, bomb or stun it, then start some different process like core-clear or replicators. They will usually target the decoy and go into their second phase very quickly, so you can use a strategy against that phase without worrying about the initial scan part. One variation of this is to leave gaps in your program like Sucker 5 and Agony 5.1 do, which would not be possible without booting. Another use is to do some kind of setup work before starting the main program. This could be to create reflections, do calculations, create multiple processes, etc. This allows you to abandon the setup code and avoid the fallout when it is attacked by a scanner. So for example, in Emerald 5.xxxx, I create multiple processes and jump them all into the bomber, anti-vamp, and core-clear parts which were booted out into core. By having ten or more processes running at each spl-zero, I don't outrun an imp when it overruns my code and don't self-destruct. (Thanks to WM for sharing the multiple-process start code - it was new to me!) The disadvantage of booting is the delay in starting your fighter. If you are up against a fast-starting bomber or scanner, you will sometimes be caught before you are ready. As more and more successful fighters use booting however, this effect diminishes and the advantages become more pronounced. One caution - do NOT leave pointers to your bootstrapped code behind in your decoy :-) Eclipse will eat you alive! ------------------------------------------------------------------------------- VII. The End: Paul Kline pk6811s@acad.drake.edu From: d92-foh@dront.nada.kth.se (Fredrik �hrstr�m) Subject: Perfect gate/coreclear Message-ID: <1993Jun9.175032.18394@kth.se> Date: Wed, 9 Jun 1993 17:50:32 GMT Here is a gate/coreclear that stops imps even while it is still clearing the core. Unfortunately it is big and slower than ordinary clears. The holes in a gate/cc, where the imps slip through, are the moments where the gate/cc switch from jumping to moving. As the number of processes grow in this gate, the holes will become more sparse. I suppose that is the reason why Imprimis spirals makes it a lot better. Imprimis has a lot of heads which reaches the gate earlier than f.ex. NightCrawler. And if the coreclear hasn't had time to build enough processes the chance of slip through is higher. ;redcode ;name Almost perfect gate/coreclear ;author Fredrik Ohrstrom ;strategy Wins 93 1 6 against NightCrawler spirals (bomber disabled) ;strategy 76 0 24 against Imprimis ;strategy 90 0 10 against Stormbringer spl 0, <-30 spl 1, <-31 mov 2, <-31 jmp -2, <-33 dat <-32, <-32 - _ Fredrik Ohrstrom From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 10 Jun 1993 00:00:19 -0400 Message-ID: Archive-name: games/corewar-faq Last-modified: 1993/04/16 Version: 2.0.4 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? 67 2. Is it Core War or Core Wars? 80 3. Where can I find more information about Core War? 88 4. Core War has changed since Dewdney's articles. Where do I get 106 a copy of the current instruction set? 5. What is the ICWS? 120 6. What is TCWN? 130 7. How do I join? 138 8. Are back issues of TCWNs available? 158 9. What is the EBS? 165 10. Where are the Core War archives? 181 11. Where can I find a Core War system for . . . ? 198 12. I do not have ftp. How do I get all of this great stuff? 215 13. I do not have access to Usenet. How do I post and receive news? 222 14. When is the next tournament? 243 15. What is KOTH? How do I enter? 252 16. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 357 17. How does SLT (Skip if Less Than) work? 369 18. What does (expression or term of your choice) mean? 381 19. Other questions? 509 --------------------------------------------------------------------- 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 Q10) --------------------------------------------------------------------- Q 5: What is the ICWS? A 5: 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 6: What is TCWN? A 6: 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 7: How do I join? A 7: For more information about joining the ICWS (which includes a subscription to TCWN), contact: A 7: 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 8: Are back issues of TCWN available? A 8: Recent issues can be found on soda.berkeley.edu (see Q10). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q 9: What is the EBS? A 9: 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. Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A10: Where is the Core War archive? Q10: 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. 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. ---------------------------------------------------------------------- Q11: Where can I find a Core War system for . . . ? A11: 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. ---------------------------------------------------------------------- Q12: I do not have ftp. How do I get all of this great stuff? A12: 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. ---------------------------------------------------------------------- Q13: I do not have access to Usenet. How do I post and receive news? A13: If you have access to telnet, you can read rec.games.corewar (and many more groups) through the gopher information retrieval system. Telnet to consultant.micro.umn.edu (134.84.132.4) or any of the other gopher servers and go through these menus: 1 - Information about Gopher 10 - Gopher+ example server 11 - non-Gopher+ link 7 - News 11 - USENET news 24 - rec 21 - games 6 - corewar If you somehow receive rec.games.corewar but just can't post, you can email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q14: When is the next tournament? A14: 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. ---------------------------------------------------------------------- Q15: What is KOTH? How do I enter? A15: 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: 8 000 instructions Max processes: 8 000 per program Duration: After 80 000 cycles per program, a tie is declared. Max entry length: 100 instructions Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; 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. ---------------------------------------------------------------------- Q16: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A16: 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. ---------------------------------------------------------------------- Q17: How does SLT (Skip if Less Than) work? A17: 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. ---------------------------------------------------------------------- Q18: What does (expression or term of your choice) mean? A18: 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: Thu, 10 Jun 93 12:04:55 GMT G'day all, Could somebody please post a paper type warrior for inspection. I have a number of other types to test my code against but no paper. Also can I assume that code tested on the c88 interpreter will behave the same on KOTH? Ta, -----------------------------------+------------------------------------- Stephen Gunnell -----------------------------> steveg@eldred.dialix.oz.au -----------------------------------+------------------------------------- From: ama@athena.mit.edu (Albert Ma) Subject: Mercury2 is out! Date: 11 Jun 1993 01:34:00 GMT Message-ID: <1v8ne8INN6f1@senator-bedfellow.MIT.EDU> After almost 3 weeks of work, mercury2 is done. I rewrote the entire simulator code from scratch using some innovations I will discuss in a later posting. It can for now be found at soda.berkeley.edu in pub/corewar/incoming/mercury2.zip. Maybe the system administrator will move it to systems this time (the newest mercury never got moved into systems and was still in incoming until I deleted it.) Mercury2 is faster than mercury in every respect. Every single instruction and addressing mode was sped up. The exact speedup will depend on your computer configuration and the instruction/ addressing mode mix. In particular 386 users will gain more because of the decrease in memory read/writes. Most gains, however, come from the short cuts I was able to take by doing operand decoding after dispatching on the instruction code. All users will gain greatly from this. This innovation will be described in my second posting. The greatest thanks go to our beloved leader Stefan Strack :-) who helped me compile and test Mercury2 (I was programming without a PC until the last few days). We also developed together the new debugging features present in the debugging version. It started as a quick hack to find a bug in Mercury2 and has actually become a decent debugger for corewar programs. The excerpt from the mercury.doc file at the end of this post describes the new features. By the way, the nifty doc file and the help screens were rewritten by SS for clarity. Mercury2 is very well tested. Stefan ran a round robin simulation using 32 warriors from the Summer tournament. A total of 51,200 rounds were played in less than 5 hours. The results were compared to the results from the same simulation I ran on Koth (102400 rounds on a DECstation 5000/133 in more than 8 hours) and there was a good correlation. Stefan also tested my random number generator to make sure it was random enough. Enjoy! I'd like to know what you think of Mercury2. Also please report any problems you encounter. Email me at ama@athena.mit.edu Direct all flames to stst@vuse.vanderbilt.edu :-) ------------------------------------------ MERCURY2 by Albert Ma MERCURY2 is an extremely fast and small corewar interpreter without graphical core display. I estimate it to be about 25 times faster than C88v49. It requires a 386 or above and 160K of contiguous free memory. There are two versions of the executable compiled from the same assembly source (see below). MERCURYD.EXE has debugging features; MERCURY2.EXE is optimized for speed. The new -U option (coredump) displays all non-empty cells after the last round has completed. Additional instructions for the debugging version: press 's' to step through trace (if tracing) press 't' to step through trace (force tracing) press return to go back to full speed press 'n' to enable/disable debugging Source-embedded debugging commands (debugging version only): ;debug turn on debugging (MOV copies debug info) ;debug static turn on debugging (MOV does not copy debug info) ;debug off turn off debugging ;trace turn on trace starting with next instruction ;trace off turn off trace ;break pause execution at next instruction ;break once break once and then clear debug status (;debug and ;trace off are defaults) Example: ;name Sucker 3 ;strategy vampire ;debug (copy debug info) ;break once (when opponent executes vampire fang) jump jmp clear-444,444 start spl 0 loop sub clear,jump mov jump,@jump djn loop,<4003 ;trace (the next instruction) clear mov 34,<-34 ;trace off spl clear jmp clear end start Pressing 's' after the breakpoint displays the traced instruction 'clear'; pressing 't' steps through all following instructions as they are executed. Traced instructions are displayed in this format:
From: ama@athena.mit.edu (Albert Ma) Subject: Mercury2 implementation notes Date: 11 Jun 1993 01:36:27 GMT Message-ID: <1v8nirINN6hr@senator-bedfellow.MIT.EDU> The first idea I had was simplify the initial placements of warriors. The standard way is to generate two random numbers as positions and then check for overlap, getting new numbers if they did. Mercury2 places the first warrior at position 0 then generates a random number between 0 and (coresize+1-2*mindist). Warrior two then goes to position 100+random. No range checking needs to be done. The standard way to execute an instruction is to evaluate the operands (the same way for each instruction) copying the cell pointed to by the A operand (for in-register evaluation) in the process and then execute the instruction. I've done away with this. Now the first thing I do is dispatch on the instruction type. Then I evaluate the operands (this means having a different routine for every instruction type). This allows me to take advantage of many shortcuts. For example, operand evaluation for the DAT command merely consists of decrementing the memory locations pointed to by the pre-decrement operands. Non pre-decrement operands are ignored. Then the process count is decremented and the instruction for the other warrior is execution. The B fields of the JMP and SPL commands are done just like the DAT command. I don't bother checking for addressing modes I know don't exist. I only copy exactly what I need to copy for in-register evaluation. For the nonimmediate MOV, CMP I copy the whole cell. For the ADD,SUB I only copy the operands. For nonimmediate SLT I copy only the B operands. For DJN,JMP,SPL,JMZ,JMN,DAT I don't copy anything at all. I hope this is useful to implementators in designing faster programs. I welcome any questions about my implementation. Albert Ma ama@athena.mit.edu From: d92-foh@loire.nada.kth.se (Fredrik �hrstr�m) Subject: Scoring system? Message-ID: <1993Jun11.173305.26950@kth.se> Date: Fri, 11 Jun 1993 17:33:05 GMT How does the scoring system on koth work? I know its three(two?) times the number of wins plus the number of ties. But how are the old results stored, and how do they affect the score? Does koth keep a 20*20 table, with scores for every warrior against every other warrior? - _ // Fredrik Ohrstrom From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: The winner of the EBS summer tournament Message-ID: Date: Sat, 12 Jun 1993 07:46:59 GMT The EBS summer tournament is over. And the winner is ... Tata! oooooooooooooooooooooooooo 8 8 8 Dan Nabutovsky 8 8 8 oooooooooooooooooooooooooo Congratulations to Dan and thanks to everyone who participated. The final match between Dan and Mintardjo was a tough one. Mintardjo released the latest version of his Winter Werewolf (currently #1 on KotH), but Dan's Pergament proved almost impervious. Pergament by Dan Nabutovsky Winter Werewolf 3 by W. Mintardjo Results: 9 2 89 ------- Here's what happened before: In round 6, Mintardjo met Wayne for the chance to confront Dan in the final round. Mintardjo's stone/spiral defeated Wayne's CMP scanner. Iron Gate by Wayne Sheppard Sphinx v5.1 by W. Mintardjo Results: 36 56 8 In round 5, Mintardjo's bomber beat Anders' CMP scanner, and Wayne's vampire/impspiral kicked Paul's bomber out. Backstabber by Anders Ivner versus Fire Storm v1.1 by W. Mintardjo Results: 24 71 5 Fire Storm v1.1 by W. Mintardjo advances in loser bracket Backstabber by Anders Ivner is out of competition ------------------------------------------------- Snake7 by Wayne Sheppard versus Emerald 5 by P.Kline Results: 38 29 33 Snake7 by Wayne Sheppard advances in loser bracket Emerald 5 by P.Kline is out of competition ------------------------------------------------- I will upload the warrior code (some 40 jewels of redcode programming) to soda within the next few days; watch out for an upload announcement. There will also be an archive with 4DOS BTM scripts for various kinds of tournaments using Albert Ma's MERCURY2 interpreter. -Stefan (stst@vuse.vanderbilt.edu) From: wms@ssd.intel.com (William Shubert) Subject: Re: Scoring system? Message-ID: Date: Sun, 13 Jun 1993 22:30:18 GMT d92-foh@loire.nada.kth.se (Fredrik �hrstr�m): >Does koth keep a 20*20 table, with scores >for every warrior against every other warrior? Yes. -Bill (wms@ssd.intel.com) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: warrior code for EBS summer 93 tournament uploaded to soda Message-ID: Date: Mon, 14 Jun 1993 03:31:37 GMT I have uploaded all 41 warriors entered in the EBS summer tournament 93 to soda.berkeley.edu. The file st93warriors.zip resides currently in pub/corewar/incoming; final destination is pub/corewar/redcode. This is an INFO-ZIP 1.9 archive; you need unzip 5.0p1 to extract on UNIX, VMS, DOS, Amiga and Mac, or pkunzip 2.04g on DOS. -Stefan (stst@vuse.vanderbilt.edu) Date: Mon, 14 Jun 1993 16:52:27 MST From: Message-ID: <93165.165227AZNXS@ASUACAD.BITNET> Subject: Re: The winner of the EBS summer tournament Stefan, thanks for the tournament. This was the best double eliminating tournament on the net. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Tournament scripts for mercury2 uploaded to soda Message-ID: Date: Wed, 16 Jun 1993 04:23:55 GMT I have uploaded my collection of 4DOS tournament batch files to soda.berkeley.edu. For now /pub/corewar/incoming/mtourn10.zip; eventually in pub/corewar/systems. Below the readme. -------- MTOURN.DOC -------- This archive contains 4DOS BTM scripts for corewar tournaments using Albert Ma's MERCURY2.EXE interpreter. To use these scripts, it is best to have 4DOS.EXE installed as your command interpreter (shame on you if you're still using COMMAND.COM :-), but you can also load 4DOS.EXE transiently: 4DOS /C scriptname args [..] 4DOS is shareware and available from many FTP sites and BBSs. MERCURY2.EXE is available from soda.berkeley.edu as /pub/corewar/{incoming|systems}/mercury2.zip. RR.BTM RR runs a round-robin tournament of warriors supplied on the command line. If only a single command line argument exists, RR takes this to be a file listing the names of warrior files, one per line. RR calculates the score (3*wins+ties) and prints out a sorted score report (best first, stored as scores.rr!), including percent wins, losses and ties. Scores of individual warriors are stored as warriorname.rr!. All old *.rr! files are deleted before running a new tournament, so rename all score files you want to keep. You can change the number of rounds to play per confrontation from the default of 50 by editing the initialization of the 'rounds' variable in RR.BTM. Examples: rr foo.red bar.red snaz.red =run a rr tournament with these three warriors rr warrior.lst =run tournament with warriors listed in warrior.lst rr *.red =run tourney with all *.red warriors in the current directory CH.BTM CH challenges a warrior against a group of warriors and reports individual and cumulative scores. It is useful for finding out how well your new warrior fares against a set of "standard" warriors. CH.BTM is similar to RR.BTM: if two command line args are supplied, the second is taken to be a list of warrior names. Examples: ch myprog.red foo.red bar.red =pit myprog against foo and then bar ch myprog.red warrior.lst =pit myprog against warriors listed in warrior.lst ch myprog.red *.red =pit myprog against all *.red warriors in the current directory Beware: the command line has a limit of 255 chars (ca. 30 warrior names). The same limit applies to the warrior list file, which is converted internally to a command line. A way around this is to use wildcards on the command line (see third examples above). DEROUND.BTM DEROUND runs one round of a (double) elimination tournament (this is the script I used for the EBS summer tournament 93). The single command line argument specifies a warrior list file (one file per line). DEROUND runs battles between the first and the second, the third and the fourth, a.s.o., warriors. The winner of each battle is written to file winner.$$$, the loser to loser.$$$. These files can then be used as input for the next round of (double) elimination. DEROUND also echos a detailed score report, which can be redirected to a file. Example: deround warrior.lst > round1.rep =run a round of (double) elimination with warriors in warrior.lst and redirect report to round1.rep. SHUFFLE.BTM This is not really a tournament batch, but is used in conjunction with DEROUND.BTM. SHUFFLE randomizes lines in a warrior list file to create a new list file for an unbiased start of a (double) elimination tournament. The single command line argument is the warrior list file to be randomized; output is written to stdout. Example: shuffle warrior.lst > shuffled.lst =shuffle lines in warrior.lst and write to shuffled.lst. All batch files give usage instructions when invoked without arguments. Most variables (rounds, coresize, verbose output, etc.) are parametrized and can be changed by editing the scripts. Bugs: MERCURY2 compilation errors are trapped gracefully, but most user errors (file not found, command line to long, etc.) are not. Use Ctrl-Break to bail out. Please share all improvements you make with me. Comments and suggestions to: Stefan Strack (stst@vuse.vanderbilt.edu) From: EM306965@itesmvf1.rzs.itesm.mx (Gustavo Cavazos) Subject: Re: Koth...docs? Date: Wed, 16 Jun 93 14:23:27 CST Message-ID: <16BEFCA5F.EM306965@itesmvf1.rzs.itesm.mx> I've compiled the program and worked fined. Could someone point me out to where I could get some docs samples programs, anything to get started... Thanks, +Gus Cavazos From: pk6811s@acad.drake.edu Subject: _Push Off_ Message-ID: <1993Jun16.133831.1@acad.drake.edu> Date: Wed, 16 Jun 1993 19:38:31 GMT _PUSH OFF_ A midweek review of Corewar June 16, 1993 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 44/ 35/ 21 Winter Werewolf 3 W. Mintardjo 153 51 2 44/ 41/ 14 Iron Gate 1.01 Wayne Sheppard 148 561 3 35/ 24/ 42 Night Crawler Wayne Sheppard 146 733 4 44/ 44/ 12 Fire Storm v1.1 W. Mintardjo 144 372 5 37/ 30/ 34 FlyPaper 3.0 J.Layland 143 157 6 44/ 44/ 12 Dragon Spear c w blue 143 835 7 44/ 46/ 9 Agony 5.2 Stefan Strack 142 360 8 44/ 47/ 10 Backstabber Anders Ivner 141 284 9 32/ 25/ 43 Sphinx v2.8 W. Mintardjo 140 1731 10 32/ 24/ 43 Incrimination v1.0 Brant D. Thomsen 140 137 11 42/ 45/ 12 Impurge Fredrik Ohrstrom 139 57 12 31/ 25/ 44 Snake Wayne Sheppard 137 493 13 33/ 30/ 37 ImpsAreMyFriend 1.1 J.Layland 136 222 14 42/ 47/ 11 cproba nandor sieben 136 75 15 39/ 42/ 19 Distance v6.3 Brant D. Thomsen 135 227 16 38/ 42/ 19 Emerald 5.1000 P.Kline 135 33 17 30/ 25/ 45 Imprimis 6 P.Kline 135 1133 18 33/ 38/ 30 Passport P.Kline 128 1 19 36/ 48/ 16 Impurge 2.0 Fredrik Ohrstrom 124 3 20 27/ 36/ 37 Sparrowhawk Michael Constant 118 8 21 25/ 37/ 38 Deck of Many Things c w blue 112 2 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives 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: Take a bow, Dan Nabutovsky, winner of the summer tournament. Dan successfully outguessed (or out-lucked :-) every opponent, cruising through the tourney without a lost match. And thanks to Stefan for providing some fun and entertainment the last few weeks. Credit Albert Ma with making the event possible (from Stefan's viewpoint) - his Mercury emulator is clocked at over a thousand battles an hour! W. Mintardjo continues to work on improving Sphinx, just in case Sphinx v2.8 _ever_ gets knocked off: 3 36/ 24/ 40 Sphinx v5.0 W. Mintardjo 147 1 19 27/ 30/ 43 Sphinx v2.8 W. Mintardjo 124 1640 This week may mark the passing of +0 Stormbringer's record age - 1778 as Sphinx v2.8 is already over 1700 as of this writing. And WM's version 3 of Winter Werewolf seems locked in first or second place. Good work! Was that a 'boot' you added WM? :-) CW Blue's 'Dragon Spear' is creeping up on age 1000, might go over this week. On the other hand, Imprimis 6 has been sulking around the bottom of the hill, going under 130 points pretty regularly. Better watch out if it gets knocked off :-( In this week's "Guess we'll never know" department: A challenger has arrived on the hill! Vital statistics: Program "test" (length 48) by "Michael Constant" (contact address "constant@stat.Berkeley.EDU"): ;strategy i'll tell you the strategy if it works F. Ohrstrom continues to prove my theory that the secret is in the name - his 'test -b' program was in first place, but 'Impurge' can't get up that high. And W. Sheppard's 'TEST' scored 155 points, but none of his named warriors are that good. Maybe The Hint should be to give your program a name other than 'test' (or 'sub-type' :-). ------------------------------------------------------------------------------- IV. The Outlook: 1 38/ 21/ 41 TEST Wayne Sheppard 155 1 1 45/ 43/ 12 test - b Fredrik Ohrstrom 148 1 1 46/ 35/ 19 Winter Werewolf 3 W. Mintardjo 157 1 2 36/ 26/ 39 sub-type-b+r c w blue 146 1 2 42/ 38/ 19 Elizabeth Bathory c w blue 147 1 3 36/ 24/ 40 Sphinx v5.0 W. Mintardjo 147 1 3 42/ 38/ 20 sub-type-cmp c w blue 146 1 3 43/ 38/ 19 Winter Werewolf 2 W. Mintardjo 147 1 4 44/ 41/ 15 Twilight Pits 8 W. Mintardjo 146 1 4 45/ 43/ 12 test - a Fredrik Ohrstrom 147 1 6 33/ 24/ 44 sub-type-os c w blue 142 1 6 37/ 34/ 29 FlyPaper 3.01 J.Layland 139 1 6 44/ 42/ 14 Zipp c w blue 147 1 7 33/ 25/ 41 FlyPaper 4.1 J.Layland 141 1 7 45/ 44/ 11 Impurge Fredrik Ohrstrom 145 1 ------------------------------------------------------------------------------- V. The Quick Look: 18 42/ 51/ 8 Medusa's v8.0 W. Mintardjo 132 1 19 17/ 49/ 34 Scroll Paper Arno Fuhlendorf 85 1 19 26/ 37/ 38 Sparrowhawk Michael Constant 114 1 19 26/ 49/ 25 Killer Michael Constant 104 1 19 28/ 41/ 31 anti-vampire paper c w blue 114 1 19 28/ 42/ 30 Eclipse III P.Kline 114 1 19 30/ 38/ 32 mezga nandor sieben 121 1 19 30/ 58/ 12 Thrice 10c Steve Gunnell 103 1 19 32/ 47/ 21 sub-type-v c w blue 118 1 19 36/ 44/ 20 Emerald 5.1000 P.Kline 129 1 20 1/ 75/ 24 BN3 KE Lewin 26 1 20 4/ 33/ 63 Duckula 1 Scriv 75 1 20 4/ 60/ 36 Limps 1.1 Scriv 48 1 20 8/ 51/ 40 Ogre c w blue 65 1 20 18/ 26/ 56 dead end 1.1 nandor sieben 110 1 20 23/ 59/ 18 Duckula 1.1 Scriv 86 1 20 23/ 60/ 17 Dimp Unknown 86 1 20 26/ 37/ 37 Deck of Many Things c w blue 115 1 20 26/ 39/ 35 Anti-Imp Paper c w blue 112 1 20 26/ 41/ 33 flash2 Nandor Sieben 110 1 20 27/ 59/ 14 Bomb Michael Constant 95 1 20 28/ 46/ 26 Spare Parts Fredrik Ohrstrom 109 1 20 34/ 58/ 8 Scan to Bomb 4000 W. Mintardjo 109 1 20 35/ 47/ 18 Emerald 4.1 P.Kline 124 1 21 1/ 71/ 29 ImpSpawn Tim Scheer - Escondi 30 0 21 2/ 47/ 51 test Fredrik Ohrstrom 57 0 21 3/ 55/ 42 Berserk 1.0 Han-Wen Nienhuys 52 0 21 3/ 60/ 38 djntest Han-Wen Nienhuys 45 0 21 6/ 83/ 11 Scared_Stiff 1 Scriv 29 0 21 7/ 64/ 29 Twins Peter van Rossum 50 0 21 9/ 52/ 39 minimum 1 Steve Gunnell 67 0 21 9/ 91/ 0 autex Han-Wen Nienhuys 28 0 21 10/ 43/ 47 weevil 1 Steve Gunnell 76 0 21 10/ 48/ 41 Decoy 1.0 Devin Kilminster 73 0 21 10/ 49/ 41 axle 13 Stephen Gunnell 71 0 21 14/ 36/ 50 sub-type-av c w blue 92 0 21 16/ 74/ 10 Night Vision Michael Constant 58 0 21 18/ 74/ 7 Round Robin Han-Wen Nienhuys 63 0 21 19/ 74/ 7 Papyrus Michael Constant 63 0 21 19/ 75/ 5 Night Vision 2.0 Michael Constant 64 0 21 20/ 74/ 7 Ring of Death Michael Constant 66 0 21 21/ 67/ 12 Expediency Michael Constant 75 0 21 21/ 73/ 6 Get info on the hill Unknown 69 0 21 21/ 75/ 4 test gate c w blue 67 0 21 22/ 43/ 35 Scroll Arno Martin Fuhlendo 100 0 21 22/ 66/ 12 Skip Vampire 1.0 Devin Kilminster 78 0 21 23/ 73/ 5 Gun KE Lewin 73 0 21 24/ 47/ 30 Flash Light Michael Constant 100 0 21 24/ 60/ 16 Invest Andre van Dalen 88 0 21 24/ 61/ 15 Duckula 1.11 Scriv 86 0 21 25/ 74/ 1 test2 Michael Constant 76 0 21 26/ 49/ 25 sharkattack Nandor Sieben 104 0 21 28/ 68/ 4 Eyes Michael Constant 87 0 21 29/ 59/ 12 Duckula Scriv 100 0 21 30/ 52/ 18 Tomb Stone c w blue 107 0 21 33/ 59/ 8 W. Mintardjo Unknown 106 0 21 33/ 61/ 6 flash Nandor Sieben 106 0 ------------------------------------------------------------------------------- VI. The Hint: Vampires! Bloodsucking Leeches. Snakes! Brrr. Let's talk pit-trappers. 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 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 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). Areas to explore: What else can the pit do? Using multiple fang-bombers to better deal with stones. Evolving the fang-bomber into a repeating core-clear. Multi-pass fang-bombing to overcome self-splitting paper (NotePaper) Currently the Hill is hostile to vampires like Sucker 5 and Twilight Pits, but Snake seems pretty successful. Next week we'll discuss anti-vamp and new SUPER anti-vamp (if I can get it to work :-). Meanwhile, maybe someone out there has some thoughts on vampires? ------------------------------------------------------------------------------- VII. The End: Paul Kline pk6811s@acad.drake.edu From: ama@athena.mit.edu (Albert Ma) Subject: Re: _Push Off_ Date: 16 Jun 1993 23:08:28 GMT Message-ID: <1vo95c$2rm@senator-bedfellow.MIT.EDU> In article <1993Jun16.133831.1@acad.drake.edu>, pk6811s@acad.drake.edu writes: |> Take a bow, Dan Nabutovsky, winner of the summer tournament. Dan successfully |> outguessed (or out-lucked :-) every opponent, cruising through the tourney |> without a lost match. And thanks to Stefan for providing some fun and |> entertainment the last few weeks. Credit Albert Ma with making the event |> possible (from Stefan's viewpoint) - his Mercury emulator is clocked |> at over a thousand battles an hour! |> Hmm, try ten thousand battles an hour. 32*32*50 = 51200 rounds were played in between 4 to 5 hours on Stefan's computer (What was the configuration Stefan?) This also includes 1024 file accesses (I hope he was using a disk cache) and 1024 compiles to run the programs. And also his 4DOS script was running mercury and and output file was being generated. Of course, peak Mercury speed is much higher. =) Now that I think of it, that 25x faster than C88 seems awfully low. Anybody out there bored enough to compare the speeds? I hope all mercury users have switched to Mercury2 by now. Mercury2 is so much faster than Mercury. Again, anybody out there bored enough to compare? I've had no response yet about Mercury2, not even the about new debugging features Stefan and I worked so hard on. Not even one email saying: Hey you !$#@! idiot! You crashed my hard drive. I feel so unappreciated. Vaporware announcement: Look for Mercury94 (the first fully '94 compliant simulator) to come out some time after the ICWS '94 standards are published. Albert (the sigless) Ma ama@athena.mit.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: _Push Off_ Message-ID: Date: Thu, 17 Jun 1993 03:36:48 GMT In article <1vo95c$2rm@senator-bedfellow.MIT.EDU> ama@athena.mit.edu (Albert Ma) writes: >Hmm, try ten thousand battles an hour. 32*32*50 = 51200 rounds were played >in between 4 to 5 hours on Stefan's computer (What was the configuration >Stefan?) 51,200 rounds in 4 hrs 43 mins = 10,860 rounds/hour = 181 rounds/min = 3 rounds/sec. This is on my Cyrix 486/25 notebook, SMARTDRV disk cache italled. I also ran a 102,400 round round-robin on my lab 486DX/33 under Windows with kermit running in the foreground: this took just over 6 hours. (Reminds me, I should post the round-robin results of the 41 tourney warriors. Tomorrow) Give Albert an emailed pat-on-the-shoulder; he deserves it. -Stefan (stst@vuse.vanderbilt.edu) >and 1024 compiles to run the programs. And also his 4DOS script was running >mercury and and output file was being generated. > >Of course, peak Mercury speed is much higher. =) > >Now that I think of it, that 25x faster than C88 seems awfully low. >Anybody out there bored enough to compare the speeds? > >I hope all mercury users have switched to Mercury2 by now. >Mercury2 is so much faster than Mercury. Again, anybody out there >bored enough to compare? > >I've had no response yet about Mercury2, not even the about new debugging >features Stefan and I worked so hard on. Not even one email saying: > >Hey you !$#@! idiot! You crashed my hard drive. > >I feel so unappreciated. > >Vaporware announcement: Look for Mercury94 (the first fully '94 compliant >simulator) to come out some time after the ICWS '94 standards are published. > > >Albert (the sigless) Ma ama@athena.mit.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: round robin of EBS summer tourney programs Message-ID: Date: Thu, 17 Jun 1993 17:01:24 GMT Here the round-robin results of all 41 warriors entered in the summer tournament. Each warrior fought every other warrior 100 times for a total of 84050 rounds. This is the straight output of RR.BTM controlling Mercury2. Notice that the tournament winner Pergament scores relatively low due to the high tie percentage. But it also loses very little, and this is all that matters in a one-on-one tournament. score %W %T %L ---------------- 07562 [49 13 38] Chimera v3.5 by W. Mintardjo (CHIMERA.RED) 07524 [49 14 38] Snake by Wayne Sheppard (SNAKE.RED) 07310 [56 34 9] Backstabber by Anders Ivner (BACKSTAB.RED) 07187 [54 33 13] Iron Gate by Wayne Sheppard (IRONGATE.RED) 07149 [45 15 41] HeremPaper v0.9 by Anders Ivner (HPAPER.RED) 07118 [46 18 35] Snake7 by Wayne Sheppard (SNAKE7.RED) 07023 [44 17 39] Sphinx v4.7 by W. Mintardjo (SPHINX47.RED) 06983 [44 18 38] Sphinx v5.1 by W. Mintardjo (SPHINX51.RED) 06917 [49 29 22] Winter Werewolf 3 by W. Mintardjo (WWWOLF3.RED) 06842 [43 18 39] Full moon by Dan Nabutovsky (FULLMOON.RED) 06788 [42 18 41] Sphinx v2.9 by W. Mintardjo (SPHINX29.RED) 06732 [44 24 33] ImpsAreMyFriend 1.1 by James Layland (IMPF11.RED) 06683 [44 24 32] ImpsAreMyFriend by J.Layland (IMPFRND.RED) 06538 [50 40 10] No.6 by Automatic Player (NO6.RED) 06505 [33 8 58] Pergament by Dan Nabutovsky (PERGAM.RED) 06400 [38 20 43] Paper by Wayne Sheppard (PAPER.RED) 06398 [45 33 22] Leprechaun 1b by Anders Ivner (LEPRECH.RED) 06195 [46 41 13] Fire Storm v1.1 by W. Mintardjo (FSTORM.RED) 06101 [38 27 36] Gamma Paper 3.0 by W. Mintardjo (GPAPER.RED) 06044 [36 25 39] Stamped paper by Dan Nabutovsky (STAMPP.RED) 06014 [27 6 67] repimp by nandor sieben (REPIMP.RED) 05934 [41 37 23] B++ by Dan Nabutovsky (BPLUS.RED) 05727 [44 49 7] No.2 by Automatic Player (NO2.RED) 05694 [34 28 38] Plasma-Advanced by Wayne Sheppard (PLASMA.RED) 05590 [40 44 15] Emerald 4 by Paul Kline (EMERALD4.RED) 05284 [36 44 20] SplitBomb by Scott Adkins (SPLITBOM.RED) 05275 [38 48 14] Emerald 5 by P.Kline (EMERALD5.RED) 05262 [28 27 46] Passport by Paul Kline (PASSP.RED) 05218 [39 52 9] aa by nandor sieben (AA.RED) 05166 [30 35 35] Ivy3.4 by Damon Gallaty (IVY.RED) 04779 [36 56 8] flash by Nandor Sieben (FLASH.RED) 04545 [33 56 11] Flail by Pi Qan (FLAIL.RED) 04484 [34 59 7] Pleeeeease Give Me a Cmp-Scanner! by James Layland (PLEASE.RED) 04008 [24 51 25] No.3 by Automatic Player (NO3.RED) 03994 [31 65 4] No.5 by Automatic Player (NO5.RED) 03457 [22 60 18] glass replicant by Pi Qan (GREPLIC.RED) 03353 [27 72 1] No.7 by Automatic Player (NO7.RED) 03106 [11 47 42] Homunculus by Pi Qan (HOMUNC.RED) 03038 [22 71 7] No.4 by Automatic Player (NO4.RED) 02517 [18 74 8] csapda2 by Nandor Sieben (CSAPDA2.RED) 02320 [18 80 2] No.1 by Automatic Player (NO1.RED) From: constant@kestrel.Berkeley.EDU (John Constant) Subject: Imp Spirals Message-ID: <45434@ucbvax.BERKELEY.EDU> Date: 17 Jun 93 23:48:45 GMT I have been reading this newsgroup regularly, and I think that I get the basic idea of how an imp spiral works. However, I don't see how it could kill an enemy program (especially not 0/98/2 like Imprimis does to mine :-( ). The way I see it, the imps would run over the enemy program, and they would tie. Could someone please enlighten me, preferably by showing me code? Thanks, Michael Constant constant@stat.berkeley.edu right now, but normally mconst@ocf.berkeley.edu From: pk6811s@acad.drake.edu Subject: Re: Imp Spirals Message-ID: <1993Jun18.081825.1@acad.drake.edu> Date: Fri, 18 Jun 1993 14:18:25 GMT In article <45434@ucbvax.BERKELEY.EDU>, constant@kestrel.Berkeley.EDU (John Constant) writes: > I have been reading this newsgroup regularly, and I think that I get the basic > idea of how an imp spiral works. However, I don't see how it could kill an > enemy program (especially not 0/98/2 like Imprimis does to mine :-( ). The way > I see it, the imps would run over the enemy program, and they would tie. > Could someone please enlighten me, preferably by showing me code? > > Thanks, > Michael Constant > constant@stat.berkeley.edu right now, but normally mconst@ocf.berkeley.edu There are three possibilities. First, Imprimis has a very strong stone component which may kill your fighter. And it has an anti-vampire component to kill off vampires, if that is what you are using. But the ring itself is also dangerous to certain kinds of opponents. Here's what we're up against with rings. Take a ring running at three points: A copies itself to B B copies itself to C C copies itself to A+1 A+1 copies itself to B+1 B+1 copies itself to C+1 C+1 copies itself to A+2 etc. If you drop a bomb on B you have a one-in-three chance of killing the ring. If it is B's turn to execute he's dead, but if A's or C's then he repairs himself and keeps on going. If it's a seven-point ring, you have a one-in- seven chance, and one-in-nine for a nine-point ring. Rings are made much stronger by running multiple processes at each point. Now if you drop a bomb on B when it's his turn to execute, you kill that process, but only that one because the points take turns and A will repair B before the next B-process executes. I think it was Dan Nabutovsky who pointed out that a spiral is much stronger yet, since killing processes only breaks the spiral into smaller ones. Single process programs, like scanners and some bombers, are vulnerable in this way. A three-point ring running eight processes at each point is 24 processes. When it walks through your code, you will execute the mov 0,x instruction too, but because you are only one process you will run ahead of the ring and out of safe code. You would have to be running at least 24 instructions to avoid outrunning the ring. So one line of defense is to use a spl-0 to constantly increase the number of processes in your fighter, then you can get a tie by following the ring around and around and ... Imp-spirals are tough, but they haven't exactly been dominating the top of the Hill lately. Speaking of which, is KotH down or is my mail server in trouble again? -Paul Kline pk6811s@acad.drake.edu From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Last three weeks' messages. Message-ID: Date: Sun, 20 Jun 1993 17:38:04 GMT Is there anyone out there that has saved any of the last three weeks' messages in this newsgroup? I've been on vacation, and to my dissapointment the local newsservers only had 4 of 38 messages left for me. Especially the summer-tournament results, and Paul's _Push off_ would be appreciated. There is a new, improved version of leprechaun coming up, so beware! Hot, summer greetings, Anders Ivner From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Call for Discussion: ICWS94 draft Message-ID: Date: Sun, 20 Jun 1993 23:46:32 GMT There is a new draft of the ICWS94 standard ready for discussion. I have uploaded the full draft (>85K uncompressed) to soda.berkeley.edu as pub/corewar/incoming/icws94.draft.Z It will be there only temporarily; I'll ask for the draft to be removed again after a week or so. Contact me for an emailed copy if you can't FTP. To tickle your interest, I am including an excerpt of Mark Durham's intro- duction. Please look over the draft and post your comments - it may decide how we are playing corewar next year. -Stefan (stst@vuse.vanderbilt.edu) P.S.: also in /incoming is mtourn11.zip, an update of my MERCURY2 tournament scripts. RR/CH now detect when the user has aborted MERCURY2 by pressing and terminate nicely. > Six opcode modifiers have been added to the Draft. Modifiers are appended > to the opcodes with a dot. Example: "MOV.A". The modifiers are: > > .A Instructions use and write A-numbers. > .B Instructions use and write B-numbers. > .AB Instructions use the A-numbers of the A-instructions and the > B-numbers of the B-instructions and write B-numbers. > .BA Instructions use the B-numbers of the A-instructions and the > A-numbers of the B-instructions and write A-numbers. > .F Instructions use both the A-numbers and the B-numbers, using and > writing A-to-A, B-to-B. > .X Instructions use both the A-numbers and the B-numbers, using and > writing A-to-B, B-to-A. > .I Instructions use and write entire instructions. > > The advantages of opcode modifiers include: greatly expanding the function > of opcodes without greatly expanding the number of opcodes, separating > opcode evaluation from operand evaluation (i.e. the behaviours of the > opcodes no longer depend on the modes), rendering moot questions about > whether ADD, SUB, etc. should use one or two fields (and if one field, > whether to use the A-field or the B-field), adding versatility to the order > of task splitting, and providing a "Skip if greater than" equivalent to > SLT. > > In addition, backwards compatibility with ICWS'88 (and even ICWS'86) is > easily accomplished at the assembly level. Any instructions with opcodes > without modifiers would be translated to the appropriate opcode.modifier > pair. Examples: > > "MOV #a, B", which only moves the A-field of the current instruction to the > B-field of the instruction pointed to by B, would be translated to > "MOV.AB #a, B". Similarly, "MOV a, b", which moves an entire instruction > from A to B, becomes "MOV.I a, b". Instructions which were previously > impossible, such as moving a B-field to an A-field, are now very > simple and intuitive with "MOV.BA A, B". Another example, > "MOV.X target, target" takes the place of "XCH target", exchanging fields. > Finally, "ADD a, b" would translate to "ADD.F a, b" for ICWS'88 and > "ADD.B a, b" for ICWS'86. > > There is one negative to one opcode modifier. ".I" only really makes sense > for MOV and CMP. It would be possible to define results for arithmetic > manipulation and ordinal comparison of opcodes and modes, but it would be > very artificial. As an alternative, .I falls back to .F functionality (for > opcodes other than MOV and CMP) in this document. Date: Tue, 22 Jun 1993 09:18:24 MST From: Message-ID: <93173.091824AZNXS@ASUACAD.BITNET> Subject: Re: Call for Discussion: ICWS94 draft I think these modifiers are too complicated and makes the code pretty ugly. I don't like them at all. Nandor. From: Planar Subject: Re: Call for Discussion: ICWS94 draft Message-ID: <1993Jun22.152457.10380@ens.fr> Date: Tue, 22 Jun 93 15:24:57 GMT In article Stefan Strack writes: >There is a new draft of the ICWS94 standard ready for discussion. I have >uploaded the full draft (>85K uncompressed) to soda.berkeley.edu as >pub/corewar/incoming/icws94.draft.Z >Please look over the draft and post your comments - it may decide >how we are playing corewar next year. Here are my comments. I hope they will be useful. This is the version of the annotated draft I got: >Version 3.1 >Annotated Draft Last Modified: May 7, 1993 Two remarks about the annotations: >[about the opcode modifiers] adding versatility to the order >of task splitting, and providing a "Skip if greater than" equivalent to >SLT. I do not understand how the opcode modifiers will provide this. >The goal is that no two reasonable people could arrive at >two different interpretations of the draft. I think the draft is very close to that goal. Now about the draft itself: >0146 A line may consist of an instruction, a pseudo-instruction, a comment, >0147 or an instruction or pseudo-instruction followed by a comment. Each This phrasing rules out the use of blank lines. This is inconsistent with the formal grammar given in section 2.3. Replace lines 0146 and 0147 with: 0146 A line consists of an optional instruction or pseudo-instruction, 0147 followed by an optional comment. >0176 line termination. End-of-file should occur only where newline could >0177 logically occur, otherwise the load file has been terminated This is also inconsistent with the formal grammar. Replace lines 0176 and 0177 with: 0176 line termination. End-of-file should occur right after a newline, 0177 otherwise the load file has been terminated >0316 Each load file will consist of one or more lines of MARS instructions or >0317 comments. Each line is terminated with a newline. All comments start >0318 with with a semicolon. Each MARS instruction consists of five fields: ^^^^ There is a typo, and this also rules out the use of blank lines. Replace line 0318 with: 0318 with a semicolon, or consist of an empty line. Each MARS instruction 031x consists of five fields: >0329 line termination. End-of-file should occur only where newline could >0330 logically occur, otherwise the load file has been terminated Again, this is inconsistent with the grammar. Replace lines 0329 and 0330 with: 0329 line termination. End-of-file should occur right after a newline, 0330 otherwise the load file has been terminated >0336 line: >0337 comment | instruction >0340 instruction: >0341 opcode.modifier mode number , mode number v* A newline is missing at the end of the "instruction" line. Replace line 0341 with: 0341 opcode.modifier mode number , mode number v* newline >0381 JMP.A $-2 ; Loops back two instructions. Line 0325 says "No blank modes or operands are allowed." Replace line 0381 with: 0381 JMP.A $-2, #0 ; Loops back two instructions. >0485 The loader loads warriors into core, converting all negative field >0486 values N to positive field values P = M + N. Subsequently, all field What if N is less than -M ? Replace line 0486 with: 0486 values N to positive field values P such that 0 <= P < M and 048x P = kM + N for some integer k. Subsequently, all field >0598 the A/B-number of the current instruction (the secondary offset). The >0599 B-number of the instruction pointed to by the A/B-number of the current >0600 instruction is incremented after the A/B-instruction is stored. It is incremented after the instruction is stored, but before anything else is done. This should be made very clear. Replace line 0600 with: 0600 instruction is incremented after the A/B-instruction is stored, but 060x before the B-operand is evaluated (for postincrement indirect A-mode), 060y or the operation is executed (for postincrement indirect B-mode). >0693 DIV replaces the B-target with the integral result of dividing the >0694 B-value by the A-value (B-value / A-value) and queues the next >0695 instruction (PC + 1). DIV.I functions as DIV.F would. What about division by zero ??? Add the following after line 0695: 069x If the A-value is 0, the B-target is unchanged. >0697 MOD replaces the B-target with the integral remainder of dividing the >0698 B-value by the A-value (B-value % A-value) and queues the next >0699 instruction (PC + 1). MOD.I functions as MOD.F would. Division by zero again. Add the following after line 0695: 069y If the A-value is 0, the B-target is unchanged. >0705 Otherwise, the next instruction is queued (PC + 1). JMZ.I functions >0706 as JMZ.F would. The way JMZ.F works should be made more precise. Is the B-value considered equal to 0 if one of its fields is 0, or if both are 0 ? Replace line 0706 with: 0706 as JMZ.F would, i.e. it jumps if both the A-number and the B-number 070x of the B-instruction are 0. >0710 Otherwise, the next instruction is queued (PC + 1). JMN.I functions >0711 as JMN.F would. Same as JMZ, here. Replace line 0711 with: 0711 as JMN.F would, i.e. it jumps if both the A-number and the B-number 071x of the B-instruction are non-zero. This is not the negation 071y of the condition for JMZ.F. >0716 Otherwise, the next instruction is queued (PC + 1). DJN.I functions >0717 as DJN.F would. Once again, replace line 0717 with: 071z as DJN.F would, i.e. it decrements both A/B-numbers of the B-value and 071t B-target, and jumps if both A/B-numbers of the B-value are non-zero. >0727 instruction is queued (PC + 1). SLT.I functions as SLT.F would. At last, replace line 0727 with: 0727 instruction is queued (PC + 1). SLT.I functions as SLT.F would, i.e. 072x the next instruction is skipped if both A/B-numbers of the A-value 072y are less than the corresponding numbers of the B-value. >0729 SPL queues the next instruction (PC + 1) and then queues the sum of >0730 the pointer counter and A-pointer. What happens if the queue is full ? This should be clarified. Replace line 0730 with: 0730 the pointer counter and A-pointer. If the queue is full, only the 073x next instruction is queued. >1025 /* ADD replaces B-target with the sum of the A-value and */ >1026 /* B-value, and queues the next instruction. */ >[...] >1166 break; There is a lot of code duplication going on here. Let the preprocessor do it ! Replace lines 1025 to 1166 with: 1025 /* Arithmetic instructions replace the B-target with the */ 1026 /* "op" of the A-value and B-value, and queue the next */ 102x /* instruction. "op" can be the sum, the difference, or */ 102y /* the product. */ 1027 #define ARITH(op) \ 1028 switch (IR.Modifier) { \ 1029 case A: \ 1030 Core[((PC + WPB) % M)].ANumber = \ 1031 (IRB.ANumber op IRA.ANumber) % M \ 1032 ; \ 1033 break; \ 1034 case B: \ 1035 Core[((PC + WPB) % M)].BNumber = \ 1036 (IRB.BNumber op IRA.BNumber) % M \ 1037 ; \ 1038 break; \ 1039 case AB: \ 1040 Core[((PC + WPB) % M)].BNumber = \ 1041 (IRB.ANumber op IRA.BNumber) % M \ 1042 ; \ 1043 break; \ 1044 case BA: \ 1045 Core[((PC + WPB) % M)].ANumber = \ 1046 (IRB.BNumber op IRA.ANumber) % M \ 1047 ; \ 1048 break; \ 1049 case F: \ 1050 case I: \ 1051 Core[((PC + WPB) % M)].ANumber = \ 1052 (IRB.ANumber op IRA.ANumber) % M \ 1053 ; \ 1054 Core[((PC + WPB) % M)].BNumber = \ 1055 (IRB.BNumber op IRA.BNumber) % M \ 1056 ; \ 1057 break; \ 1058 case X: \ 1059 Core[((PC + WPB) % M)].BNumber = \ 1060 (IRB.ANumber op IRA.BNumber) % M \ 1061 ; \ 1062 Core[((PC + WPB) % M)].ANumber = \ 1063 (IRB.BNumber op IRA.ANumber) % M \ 1064 ; \ 1065 break; \ 1066 default: \ 1067 return(UNDEFINED); \ 1068 break; \ 1069 }; \ 1070 Queue(W, ((PC + 1) % M)); \ 1071 break; 1072 case ADD: ARITH(+) 1073 case SUB: ARITH(+ M -) 1074 case MUL: ARITH(*) >1167 /* DIV replaces the B-target with the integral result of */ >1168 /* dividing the B-value by the A-value, and queues the next */ >1169 /* instruction. */ > >1170 case DIV: >1171 switch (IR.Modifier) { >1172 case A: >1173 Core[((PC + WPB) % M)].ANumber = IRB.ANumber / IRA.ANumber; >1174 break; >1175 [...] >1230 break; You don't want your MARS to crash every time a warrior attempts a division by zero, do you ? Replace lines 1167 to 1230 with: 1167 /* DIV and MOD replace the B-target with the integral */ 1168 /* quotient (for DIV) or remainder (for MOD) of the B-value */ 1169 /* by the A-value, and queues the next instruction. */ 1170 #define ARITH_DIV(op) \ 1171 switch (IR.Modifier) { \ 1172 case A: \ 117x if (IRA.ANumber != 0) \ 1173 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.ANumber; \ 1174 break; \ 1175 case B: \ 117y if (IRA.BNumber != 0) \ 1176 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.BNumber; \ 1177 break; \ 1178 case AB: \ 117z if (IRA.ANumber != 0) \ 1179 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.ANumber; \ 1180 break; \ 1181 case BA: \ 118x if (IRA.BNumber != 0) \ 1182 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.BNumber; \ 1183 break; \ 1184 case F: \ 1185 case I: \ 118y if (IRA.ANumber != 0) \ 1186 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.ANumber; \ 118z if (IRA.BNumber != 0) \ 1187 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.BNumber; \ 1188 break; \ 1189 case X: \ 118t if (IRA.ANumber != 0) \ 1190 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.ANumber; \ 119x if (IRA.BNumber != 0) \ 1191 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.BNumber; \ 1192 break; \ 1193 default: \ 1194 return(UNDEFINED); \ 1195 break; \ 1196 }; \ 1197 Queue(W, ((PC + 1) % M)); \ 1198 break; 1199 case DIV: ARITH_DIV(/) 1200 case MOD: ARITH_DIV(%) >1545 newline A linefeed, formfeed, or combination of linefeed and >1546 formfeed. Whichever newline is native to the host >1547 operating system. The CR character (ASCII 0x0D) is not called "formfeed" but "carriage-return". Replace lines 1545 to 1547 with: 1545 newline A linefeed, carriage-return, or combination of linefeed 1546 and carriage-return. Whichever newline is native to 1547 the host operating system. >1556 whitespace The space, tab, and other non-marking characters. We should have an exhaustive list of all authorised characters here. Do we want to allow DELs, backspaces, formfeeds, EOTs, and so on ? Throughout the draft, the PC is called the "Pointer Counter". In most computer manuals, a pointer to the currently executing instruction is called a "Program Counter". I do not know what the tradition is among the core-war specialists, but I would like to replace every occurence of "Pointer Counter" with "Program Counter". At last, here are a few typos: >0324 load files is more rigid than for assemply files to simplify parsing. No ^ >0858 /* initiallized and the warriors have been loaded before */ ^ >0904 /* For instuctions with a Direct A-mode, the Pointer A */ ^ Of course, all these revisions are only suggestions, and are open to discussion, but I had to use the imperative form to comply with the guidelines for suggested revisions... -- Planar From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: Date: Tue, 22 Jun 1993 16:48:19 GMT In article <1993Jun22.152457.10380@ens.fr> Planar writes: >Here are my comments. I hope they will be useful. Thanks for your thorough reading. You made some very good points. >>[about the opcode modifiers] adding versatility to the order >>of task splitting, and providing a "Skip if greater than" equivalent to >>SLT. > >I do not understand how the opcode modifiers will provide this. > Order of task splitting: What Mark is probably referring to is no longer in the draft, because it was too powerful. Essentially to allow: JMP.F A, B ;continue execution at A and B, essentially SPL SPL.F A, B ;three-way SPL, split to A,B,and (PC+1) Skip if greater than equivalent: trivial. SLT.AB #10,addr ; like ICWS88 SLT.B addr,#10 ; reverse I don't want people to think that this document is carved in stone; please share your opinions on the important changes to ICWS88. In particular: -the (rather radical) opcode modifier system; is this too complex/powerful /"unelegant"/restrictive/difficult to implement/liberating :-) ? -postincrement indirect as additional addressing mode -the addition of MUL/DIV/MOD opcodes -Stefan (stst@vuse.vanderbilt.edu) From: jlayland@kilroy.Jpl.Nasa.Gov (James Layland) Subject: Sample Vampire from _Push Off_ Date: 22 Jun 1993 17:28:23 GMT Message-ID: <207ffn$e15@elroy.jpl.nasa.gov> I was just looking over the Hint from Paul's last _Push Off_. I believe there is a minor error in the sample vampire he posted. It should be: inc dat #3364,#-3364 fang jmp trap-4,4 ^^ start spl 0 add inc,fang mov fang,@fang jmp -2 trap mov 10,<-10 spl -1 jmp -2 As originally posted, the fangs will caused bombed programs to jump to trap+4 (presumably a DAT), which makes this simply a dwarf-type bomber rather than a pit-trapper. Makes a big difference against replicators. James From: pk6811s@acad.drake.edu Subject: _Push Off_ Message-ID: <1993Jun22.121240.1@acad.drake.edu> Date: Tue, 22 Jun 1993 18:12:40 GMT _PUSH OFF_ A midweek review of Corewar June 22, 1993 ------------------------------------------------------------------------------- I. The Standings: # %W/ %L/ %T Name Author Score Age 1 45/ 35/ 20 Winter Werewolf 3 W. Mintardjo 156 82 2 47/ 44/ 9 Agony 6.0 Stefan Strack 150 18 3 46/ 43/ 12 Dragon Spear c w blue 148 866 4 45/ 43/ 12 Impurge Fredrik Ohrstrom 147 88 5 46/ 46/ 8 Backstabber Anders Ivner 146 315 6 44/ 43/ 13 Iron Gate 1.01 Wayne Sheppard 145 592 7 44/ 45/ 11 Fire Storm v1.1 W. Mintardjo 144 403 8 36/ 29/ 34 FlyPaper 3.0 J.Layland 143 188 9 44/ 46/ 10 cproba nandor sieben 142 106 10 33/ 25/ 42 Snake Wayne Sheppard 142 524 11 33/ 24/ 43 Imprimis 7 P.Kline 142 4 12 42/ 42/ 16 Herem V Anders Ivner 141 6 13 32/ 23/ 44 Incrimination v1.0 Brant D. Thomsen 141 168 14 32/ 25/ 43 Night Crawler Wayne Sheppard 139 764 15 32/ 26/ 42 Sphinx v2.8 W. Mintardjo 139 1762 16 39/ 42/ 19 Distance v6.3 Brant D. Thomsen 137 258 17 38/ 43/ 19 Emerald 5.1000 P.Kline 132 1 18 30/ 28/ 43 HeremPaper v0.9 Anders Ivner 132 7 19 33/ 36/ 30 Passport P.Kline 130 23 20 17/ 15/ 30 Imprimis 6 P.Kline 80 1164 21 9/ 67/ 23 Antidwarf Phil Long 52 0 ------------------------------------------------------------------------------- II. The Basics: -Core War Archives 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: Well, Sphinx v2.8 has probably set a new record for duration on KotH by the time you read this. Congratulations! How high can he go? Or how low can he go and survive, since, like Imprimis 6, Sphinx has had the ho-hum-score flu lately, and has been skulking around the bottom of the Hill. I got tired of watching Imprimis holding up the other 19 players and thought I would get a jump on Mintardjo's new version of Sphinx by releasing Imprimis 7 early :-) Imprimis 7 puts fewer processes in the 7-point imps, and arranges to have a jmp -1 dropped on the core-clear routine for faster clearing (got that one from Moonstone :-). Meanwhile S. Strack gassed up Agony with some fresh numbers and raced back into the top five. Looks good, however WM's Winter Werewolf 3 _owns_ the number one spot (for now). Last week's Hint stirred up some interest in Vampires, and a flock of them assaulted the Hill, all unsuccessfully I think. We'll see what happens after this weeks follow-up Hint. ------------------------------------------------------------------------------- IV. The Outlook: 2 47/ 45/ 8 Agony 6.0 Stefan Strack 150 1 7 41/ 43/ 16 Herem V Anders Ivner 140 1 9 31/ 25/ 43 Imprimis 7 P.Kline 138 1 9 39/ 42/ 19 Herem II Anders Ivner 137 1 ------------------------------------------------------------------------------- V. The Quick Look: 17 28/ 28/ 44 HeremPaper v0.9 Anders Ivner 129 1 18 39/ 43/ 18 Grimm's Vampyre c w blue 134 1 19 18/ 17/ 65 Pergament 0.32 Dan Nabutovsky 118 1 19 40/ 51/ 9 Cleaver Wayne Sheppard 128 1 20 6/ 90/ 4 challange Peter Auer 22 1 20 15/ 51/ 35 challange2 Peter Auer 78 1 20 16/ 35/ 49 Seventh Circle v1 Peter van Rossum 97 1 20 28/ 30/ 42 Stoned Again c w blue 125 1 20 32/ 38/ 30 Integrity t P.Kline 126 1 20 34/ 43/ 23 Herem III Anders Ivner 126 1 20 36/ 43/ 21 Herem IV Anders Ivner 128 1 21 0/ 67/ 33 multi-imp Peter Auer 33 0 21 0/ 92/ 7 Sufo Fredrik Ohrstrom 8 0 21 1/ 64/ 35 King Wannabe v0 Planar 38 0 21 3/ 62/ 36 Double spiral Phil Long 43 0 21 7/ 55/ 38 SuperImp 1.1a Jonathan Roy 59 0 21 9/ 67/ 23 Antidwarf Phil Long 52 0 21 9/ 79/ 12 multi-bomb Peter Auer 39 0 21 10/ 54/ 36 Expediency Michael Constant 67 0 21 10/ 68/ 21 pit Peter Auer 53 0 21 10/ 69/ 21 imp-gate Peter Auer 51 0 21 10/ 76/ 13 Bloodsucker I Phil Long 45 0 21 11/ 77/ 11 Chimp Phil Long 45 0 21 13/ 71/ 16 fast-bomb Peter Auer 54 0 21 16/ 38/ 45 multi mice nandor sieben 94 0 21 16/ 78/ 5 KSC 1.0 Devin Kilminster 55 0 21 20/ 73/ 7 Genie Michael Constant 67 0 21 21/ 42/ 37 Unknown Albert Ma 101 0 21 23/ 32/ 46 Deck of Many Things c w blue 114 0 21 24/ 45/ 31 JRoy Imps P.Kline 102 0 21 25/ 52/ 24 IHTFP Albert Ma 97 0 21 26/ 59/ 16 Little Killer Phil Long 93 0 21 26/ 63/ 11 Dwarf28.2 Peter Auer and Phil 90 0 21 27/ 62/ 11 Dwarf52 Phil Long 93 0 21 27/ 64/ 9 Dwarf84 Phil Long 90 0 21 27/ 69/ 4 fast-dwarf Peter Auer 85 0 21 29/ 52/ 19 Anti-Anti-Vamp Vamp Michael Constant 106 0 21 29/ 65/ 6 BloodStalker Fredrik Ohrstrom 93 0 21 30/ 40/ 30 Integrity P.Kline 119 0 21 32/ 51/ 17 Wimp 7.0 Brant D. Thomsen 113 0 ------------------------------------------------------------------------------- VI. The Hint: 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: Tue, 22 Jun 1993 19:42:14 GMT In article <207ffn$e15@elroy.jpl.nasa.gov>, jlayland@kilroy.Jpl.Nasa.Gov (James Layland) writes: > I was just looking over the Hint from Paul's last _Push Off_. I believe > there is a minor error in the sample vampire he posted. It should be: >. . . . Nope, it works as written: inc dat #3364,#-3364 fang jmp trap,0 start spl 0 add inc,fang mov fang,@fang jmp -2 trap mov 10,<-10 spl -1 jmp -2 end start Yours works too, you have just offset the fang's a- and b-operands by 4 and -4 respectively. Which points out another vampire feature, namely that any X/-X can be used to increment the fang _AND_ that X can change during the run while maintaining fang viability. -Paul From: Planar Subject: Re: Call for Discussion: ICWS94 draft Message-ID: <1993Jun23.090337.4905@ens.fr> Date: Wed, 23 Jun 93 09:03:37 GMT In article Stefan Strack writes: >I don't want people to think that this document is carved in stone; please >share your opinions on the important changes to ICWS88. In particular: I did play corewar a few years ago, then I stopped. But I think I will resume playing, now I have found this newsgroup. This is to say I know what this is all about, but I have not played much with modern (post-86) versions of corewar, so do not take my comments too seriously. >-the (rather radical) opcode modifier system; is this too complex/powerful >/"unelegant"/restrictive/difficult to implement/liberating :-) ? I rather like it, but one important issue is: is it going to slow down MARS implementations very much ? >-postincrement indirect as additional addressing mode I like this one very much. It adds orthogonality to the instruction set, and it makes some new interesting code possible. >-the addition of MUL/DIV/MOD opcodes I have some doubts about those. -- Planar Date: Wed, 23 Jun 1993 16:15:52 MST From: Message-ID: <93174.161552AZNXS@ASUACAD.BITNET> Subject: Re: Call for Discussion: ICWS94 draft One more thing about modifiers. I think accessing the A-field shouldn't be cheap (with modifiers it's for free), otherwise the warriors become much more vulnerable. I think right now it's too expensive but maybe not the modifiers is the solution. Maybe exchange but exchange is also very powerfull since it can access 4 core location is one cycle. Nandor. From: doligez@clipper.ens.fr (Planar) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: <1993Jun24.131210.25865@ens.fr> Date: Thu, 24 Jun 93 13:12:10 GMT In article <20agnk$7ta@senator-bedfellow.MIT.EDU> Albert Ma writes: >Hmm I must have emailed instead of posted my first response. Here it is: - - - From: ama@Athena.MIT.EDU Date: Wed, 23 Jun 93 16:24:55 -0400 Subject: Re: Call for Discussion: ICWS94 draft In article <1993Jun23.090337.4905@ens.fr>, you write: |> In article Stefan Strack writes: |> |> >-the (rather radical) opcode modifier system; is this too complex/powerful |> >/"unelegant"/restrictive/difficult to implement/liberating :-) ? |> |> I rather like it, but one important issue is: is it going to slow down |> MARS implementations very much ? |> As an implementor, I think I can shed some light on this isuue. A good implementation should not be slowed down at all. Each modifier changes the instruction so much that internally each opcode/modifier combination will (should) handled as different instructions. So there will be no speed penalty. There is, however, a size penalty. This is exactly like implementing 6 or 7 times as many instructions. Most implementations will increase in size by a few K (guessing around 10%, depends heavily on processor type and language). However expect Mercury2 to increase in size much more than average. About a third of my code is directly responsible for instruction execution. So a ICWS94 version should about double in size to a hefty 15K. Of course it's possible that an implementor might decide to save some space and sacrifice speed. Also, there are two sections on warrior separation in the draft lines 410-412 and lines 425-429. One set has to go. Something happened to the 94 draft on soda The directory listing of pub/corewar/incoming reads . unreadable Albert Ma (with a different sig everytime he posts since he's making it up from scratch) ama@athena.mit.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: Date: Wed, 23 Jun 1993 17:42:45 GMT In article <1993Jun23.090337.4905@ens.fr> Planar writes: >In article Stefan Strack writes: >>-the (rather radical) opcode modifier system; is this too complex/powerful >>/"unelegant"/restrictive/difficult to implement/liberating :-) ? > >I rather like it, but one important issue is: is it going to slow down >MARS implementations very much ? Not likely, or at least not if the simulator is tuned to speed rather than readable code :-). Faster systems, like KotH 3.1 and Mercury2, currently dispatch instruction processing by opcode/Amode/Bmode combinations. It would be trivial to also dispatch by modifier; this might increase the size of the simulator slightly, but shouldn't affect speed. (Someone with more authority might want to comment on this; Bill, Albert, Nandor, Mintardjo?) >>-the addition of MUL/DIV/MOD opcodes > >I have some doubts about those. Same here. The draft committee opined to drop these (no obvious value, division-by-zero problem); but Mark apparently likes them enough to give them another chance. Can anybody _in favor_ of MUL/DIV/MOD think of examples where they might be useful to have? >-- Planar Nandor thinks modifiers are ugly. I couldn't agree more. One thing to keep in mind though is that you can leave them off and the instruction will default to its ICWS88 behavior. -Stefan (stst@vuse.vanderbilt.edu) From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: Date: Wed, 23 Jun 1993 19:04:12 GMT In article <93173.091824AZNXS@ASUACAD.BITNET> writes: I think these modifiers are too complicated and makes the code pretty ugly. I don't like them at all. Nandor. I agree. And it also causes some ambiguity (I think, although I have to admit I haven't checked it thoroughly in the draft.): MOV.BA #1,#2 I don't see any way this instruction could move the B-field of the A-operand to the A-field of the B-operand. (Whatever that's supposed to mean) Anders Ivner From: ama@athena.mit.edu (Albert Ma) Subject: Re: Call for Discussion: ICWS94 draft Date: 23 Jun 1993 20:41:05 GMT Message-ID: <20af51$5tg@senator-bedfellow.MIT.EDU> I have to take that back. (in reference to my previous post about speed) If you're programming in C or assembly then there will be no speed penalty to handle all those modifiers. Those are the only languages (I think) that support the use of jumptables to allow constant time branches. Any other languages have to do some extra comparisons. So there will be at least a small penalty for all those modifiers. Albert Ma ama@athena.mit.edu From: ama@athena.mit.edu (Albert Ma) Subject: Re: Call for Discussion: ICWS94 draft Date: 23 Jun 1993 21:08:04 GMT Message-ID: <20agnk$7ta@senator-bedfellow.MIT.EDU> Hmm I must have emailed instead of posted my first response. (This was supposed to be my third post today, I just love wasting MIT's money) I'll email him again and ask him to post my original post since I forgot what I wrote. Anyway, adding to what I said before. Though the modifiers may not slow down execution, the read/write ranges will. We'll have to check the range every time we access core. And if it's out of range we have to do a division (expensive usually) to get the thing in range. Also, what happens with the indirect addressing modes? Will ranges be checked twice? Where is the second range centered? The draft also doesn't mention standard values for run-time variables. Personally I hope that standard coresize does not exceed 8192. Otherwise it will totally screw up my interpreter because of the 64K segments in the IBM PC architecture. Albert Ma ama@athena.mit.edu From: twilley@dewey.nl.nuwc.navy.mil (Jack Twilley) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: Date: Wed, 23 Jun 1993 22:04:30 GMT >>-the addition of MUL/DIV/MOD opcodes > >I have some doubts about those. Same here. The draft committee opined to drop these (no obvious value, division-by-zero problem); but Mark apparently likes them enough to give them another chance. Can anybody _in favor_ of MUL/DIV/MOD think of examples where they might be useful to have? Division by zero could be another way for MARS code to crash.... Also, for certain currently wasteful algorithms, a onestep DIV may speed them up some.... -Stefan (stst@vuse.vanderbilt.edu) Jack. -- John M. Twilley | Oh, you were licking your lips, and your nautilus@acm.rpi.edu | lipstick was shining, and I was dying twilley@dewey.nl.nuwc.navy.mil | just to ask for a taste... --Meatloaf From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: Date: Thu, 24 Jun 1993 01:42:21 GMT In article <93174.161552AZNXS@ASUACAD.BITNET> writes: >I think accessing the A-field shouldn't be >cheap (with modifiers it's for free), otherwise the warriors become much >more vulnerable. How is that? The only class of warriors I can think of suffering from easy A-field access are bombing vampires, because their fangs become easily traceable (Paul already mentioned that). Bootstrap pointers can easily be destroyed to prevent tracing. >Nandor. -Stefan (stst@vuse.vanderbilt.edu) From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: <1993Jun24.123205.24330@oucsace.cs.ohiou.edu> Date: Thu, 24 Jun 1993 12:32:05 GMT In article <20agnk$7ta@senator-bedfellow.MIT.EDU> ama@athena.mit.edu (Albert Ma) writes: >Anyway, adding to what I said before. Though the modifiers may not slow >down execution, the read/write ranges will. We'll have to check the range >every time we access core. And if it's out of range we have to do a >division (expensive usually) to get the thing in range. >Also, what happens with the indirect addressing modes? Will ranges >be checked twice? Where is the second range centered? And even jump tables help a lot here... I was in the process of moving to the jump table idea on my system (Core Wars Deluxe) before other stuff tore me away from Core Wars. All I have in the jump tables is the instructions, and not the addressing modes, etc. But what I *did* do was separate the slow versions of instructions from the fast ones. For instance, if the user specified read/write range, then I have a function called "mov_readwrite()" and a function just called "mov()". You can have as many of these as you want. For instance, if you use the PCT instruction, then you have to check for instructions being modified while being protected. So, as long as none of the programs have PCT in their code (which means that during game play, there is 0% chance PCT will be executed), thenI will use "mov()", otherwise, I will use "mov_pct()". All in all, you can then build the jump table to have as fast as functions as you can possibly have depending on any particular game (just because PCT is being used in the standard, doesn't mean that you need to use the slow instructions all the time...). This is of course trivial in C and other higher level languages... it is not so trivial with assembler... :-) Scott -- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu Ohio University of Athens Bitnet: adkins@ouaccvma.bitnet From: doligez@clipper.ens.fr (Planar) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: <1993Jun24.132031.26449@ens.fr> Date: Thu, 24 Jun 93 13:20:31 GMT In article Anders Ivner writes: > >MOV.BA #1,#2 > >I don't see any way this instruction could move the B-field of the A-operand >to the A-field of the B-operand. (Whatever that's supposed to mean) This is easy if you look at the C code. This instruction changes itself to: MOV.BA #2,#2 There is another ambiguity in the draft. I don't think it says whether labels and opcodes are case-sensitive or not. I have 2 ICWS'88-compliant MARS systems; the labels are case-sensitive in one, and case-insensitive in the other... -- Planar (My signature is carefully hand-crafted, too. :-) Date: Thu, 24 Jun 1993 16:25:13 MST From: Message-ID: <93175.162513AZNXS@ASUACAD.BITNET> Subject: Re: Call for Discussion: ICWS94 draft Since the jmp, and spl statements use the A-field they are relatively safe. A little change in the A-filed is very dangerous. That's why I think A-field access should not be easy. Jmp tables can be done in turbo pascal, but it's a little bit tricky. Nandor. From: jlayland@kilroy.Jpl.Nasa.Gov (James Layland) Subject: Re: Call for Discussion: ICWS94 draft Date: 24 Jun 1993 17:05:10 GMT Message-ID: <20cms6$sak@elroy.jpl.nasa.gov> 0590 5.3.5 Postincrement Indirect (">") I think this might make it easier for a novice foolish enough to consult the standard rather than the companion tutorial (there _will_ be one?) to decipher a piece of redcode. I can't think of any good use for MUL/DIV/MOD. Not to say I wouldn't use it, but they seem somewhat out of place compared to the rest of the opcodes. While allowing all modes with all opcodes sounds nice, I did think that making empty core an illegal assembler instruction created an interesting set of problems. Also, the draft allows a wide variety of different parameters for corewar tournaments. I just wanted to point out one obvious side-effect of using the RANDOM setting for initial instruction (0402-3): all forms of scanners are dead. I realize this is just an optional parameter like the maximum write distance, etc., but I think ruling out all possibility of an intelligent search for the opponent is a mistake. I think the new opcode modifiers are interesting. They are also ugly as sin. Why doesn't JMP.B xxx,yyy jump to location yyy? Of course this seems like a silly thing to do because predecrement/postincrement stone bombers will still be mutating B-numbers. The standard has not really made use of A/B numbers symmetric (although it comes close). I think a simple XCHG operator might have been preferable to allowing complete freedom to access all combinations of A-numbers and B-numbers. Part of successful redcode programming is a struggle to overcome the limitations of the language. Question: will there be an experimental ICWS'94 server up before the standard is formally adopted? Does anyone really have a feel for what new programs will be made possible by the standard? Then again, imp rings were discovered years after the '88 standard, so perhaps this is a pointless question. Wow. Did someone actually read this far? Thanks. James jlayland@grissom.jpl.nasa.gov From: ama@athena.mit.edu (Albert Ma) Subject: Re: Call for Discussion: ICWS94 draft Date: 24 Jun 1993 17:08:36 GMT Message-ID: <20cn2k$5ie@senator-bedfellow.MIT.EDU> In article <1993Jun24.123205.24330@oucsace.cs.ohiou.edu> sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes: >In article <20agnk$7ta@senator-bedfellow.MIT.EDU> ama@athena.mit.edu (Albert Ma) writes: >>Anyway, adding to what I said before. Though the modifiers may not slow >>down execution, the read/write ranges will. We'll have to check the range >>every time we access core. And if it's out of range we have to do a >>division (expensive usually) to get the thing in range. >[stuff deleted] >All in all, you can then build the jump table to have as fast as functions >as you can possibly have depending on any particular game (just because PCT >is being used in the standard, doesn't mean that you need to use the slow >instructions all the time...). This is of course trivial in C and other >higher level languages... it is not so trivial with assembler... :-) Ooh, great idea for speed. Actually it is pretty trivial in assembler (well as trivial as anything else). How do you build a jump table in other languages like Pascal? But again the problem is speed vs space. We can maintain full speed, but the cost is lots of excess code. Albert Ma ama@athena.mit.edu Er, stupid news server. Won't let me post because I have too many included lines. So I have to write this stupid sig to fill up space and waste bandwidth. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: Date: Thu, 24 Jun 1993 18:01:31 GMT In article <20cms6$sak@elroy.jpl.nasa.gov> jlayland@kilroy.Jpl.Nasa.Gov (James Layland) writes: >Why doesn't JMP.B xxx,yyy jump to location yyy? An earlier version of the standard included the above and similar combinations, i.e. it did not distinguish between "A/B-pointer" (essentially jump-addresses) and "A/B-value" (everything else): A/B-values are subject to modifiers, A/B- pointers are not. This somewhat artificial distinction became necessary to avoid such deadly bombs as SPL.F 0,0 which creates _two_ tasks when executed. Even worse was JMP.F 0,0 which acts like ICWS88 SPL 0, except the original task does not fall thru. Twice as fast and half the size of the ICWS88 "spl 0/jmp -1" combination. It is clear that this would have tipped the game balance in favor of small, dumb bombers. >Question: will there be an experimental ICWS'94 server up before the >standard is formally adopted? This is definetely the plan. I've been trying to get Scott Ellentuch to set up an icws94 KotH at stormking.com. I think he would do it, but does not want to delve into Bill Shubert's sources to do the ICWS94 modifications. Any daring C programmers out there who want to tackle this? Even better of course if Bill found the time to do it himself. >James -Stefan (stst@vuse.vanderbilt.edu) From: wangsawm@prism.CS.ORST.EDU (W. Mintardjo) Subject: Re: Call for Discussion: ICWS94 draft Message-ID: <20cqh5INN2us@flop.ENGR.ORST.EDU> Date: 24 Jun 93 18:07:33 GMT ama@athena.mit.edu (Albert Ma) in article <20cn2k$5ie@senator-bedfellow.MIT.EDU> submit: [stuff deleted] >>All in all, you can then build the jump table to have as fast as functions >>as you can possibly have depending on any particular game (just because PCT >>is being used in the standard, doesn't mean that you need to use the slow >>instructions all the time...). This is of course trivial in C and other >>higher level languages... it is not so trivial with assembler... :-) > >Ooh, great idea for speed. Actually it is pretty trivial in >assembler (well as trivial as anything else). How do you build >a jump table in other languages like Pascal? >But again the problem is speed vs space. We can maintain full >speed, but the cost is lots of excess code. > Basically, if you use 'switch-case' statements in high level languange, I believe that modern compilers such as Turbo C++ and Turbo Pascal are capable to estimate and select the appropriate procedure. They would generate either jump table or binary-search comparison. Minimize or not use at all procedures and functions helps speeding up all MARS regardless of the language used to implement them. Mintardjo W. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 25 Jun 1993 00:00:12 -0400 Message-ID: Archive-name: games/corewar-faq Last-modified: 1993/04/16 Version: 2.0.4 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? 67 2. Is it Core War or Core Wars? 80 3. Where can I find more information about Core War? 88 4. Core War has changed since Dewdney's articles. Where do I get 106 a copy of the current instruction set? 5. What is the ICWS? 120 6. What is TCWN? 130 7. How do I join? 138 8. Are back issues of TCWNs available? 158 9. What is the EBS? 165 10. Where are the Core War archives? 181 11. Where can I find a Core War system for . . . ? 198 12. I do not have ftp. How do I get all of this great stuff? 215 13. I do not have access to Usenet. How do I post and receive news? 222 14. When is the next tournament? 243 15. What is KOTH? How do I enter? 252 16. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 357 17. How does SLT (Skip if Less Than) work? 369 18. What does (expression or term of your choice) mean? 381 19. Other questions? 509 --------------------------------------------------------------------- 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 Q10) --------------------------------------------------------------------- Q 5: What is the ICWS? A 5: 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 6: What is TCWN? A 6: 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 7: How do I join? A 7: For more information about joining the ICWS (which includes a subscription to TCWN), contact: A 7: 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 8: Are back issues of TCWN available? A 8: Recent issues can be found on soda.berkeley.edu (see Q10). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q 9: What is the EBS? A 9: 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. Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- A10: Where is the Core War archive? Q10: 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. 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. ---------------------------------------------------------------------- Q11: Where can I find a Core War system for . . . ? A11: 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. ---------------------------------------------------------------------- Q12: I do not have ftp. How do I get all of this great stuff? A12: 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. ---------------------------------------------------------------------- Q13: I do not have access to Usenet. How do I post and receive news? A13: If you have access to telnet, you can read rec.games.corewar (and many more groups) through the gopher information retrieval system. Telnet to consultant.micro.umn.edu (134.84.132.4) or any of the other gopher servers and go through these menus: 1 - Information about Gopher 10 - Gopher+ example server 11 - non-Gopher+ link 7 - News 11 - USENET news 24 - rec 21 - games 6 - corewar If you somehow receive rec.games.corewar but just can't post, you can email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q14: When is the next tournament? A14: 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. ---------------------------------------------------------------------- Q15: What is KOTH? How do I enter? A15: 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: 8 000 instructions Max processes: 8 000 per program Duration: After 80 000 cycles per program, a tie is declared. Max entry length: 100 instructions Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; 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. ---------------------------------------------------------------------- Q16: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A16: 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. ---------------------------------------------------------------------- Q17: How does SLT (Skip if Less Than) work? A17: 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. ---------------------------------------------------------------------- Q18: What does (expression or term of your choice) mean? A18: 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: Fri, 25 Jun 1993 04:14:49 GMT I've read what has been said here about the new opcode modifier, and only one thing comes to my mind: non-atomic core location. That is, make each location contain the opcode, the A oprrand or the B operand. Then all you need is a .F modifier when you want to "use" thop whole thing: MOV.F moves the three operand from it A operand: MOV.F 3,@5 ; mov 3,4,5 to where location 5 is pointing This way, you remove all ambiguity (I beleive, maybe not, prove me wrong) and makes the code very simple. You could add rules so that full move must be "word-aligned" (multiple of 3), but then you'd have to check all the time when the programs are executing (beside, it may not be that important). The only things to add would beL - opcode encoding: what number correspond to what opcode+A/B addressing mode (MUST be part of the operand field). - this limits the minimum core size (if all opcode+addressing mode take 2000 combinations, the core cannot be smaller than 2000, or maybe it could :^) ). - simplify object-code format (just a bunch of numbers, with the start location as the first number in the file). I admit I didn't read the draft yet, but I believe I'm making sense. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B From: simon@reef.cis.ufl.edu (simon mark arthur) Subject: Re: Call for Discussion: ICWS94 draft Date: 25 Jun 1993 06:26:11 GMT Message-ID: <20e5q3INN596@snoopy.cis.ufl.edu> My 2 cents -- MUL, DIV, MOD are too powerful, as is postincrement. The extended opcodes are great, though. From: jrp@news () Subject: CoreWar -Unix/SGI Date: 25 Jun 1993 11:10:32 GMT Message-ID: <20emf8INNq6b@fstgds15.tu-graz.ac.at> As the title says it I am lookin for a Core Ware System for my SGI maschine. Peter -------------------------------------- Peter Blahowsky AVL List GmbH Computational Fluid Dynamics Res. Dept. Kleiststrasse 48 A 8010 Graz/Austria/Europe Tel: (43) 316 987 ext. 618 FAX ext. 777 email: jrp@fmechsg01.tu-graz.ac.at -------------------------------------- From: jlayland@kilroy.Jpl.Nasa.Gov (James Layland) Subject: A Kinder, Gentler Core Warrior Date: 25 Jun 1993 23:33:56 GMT Message-ID: <20g214$d2q@elroy.jpl.nasa.gov> I think that with so much violence in movies, TV, video games, etc. it is shameful to have this newsgroup dominated by bloodthirsty programs whose sole purpose is to kill each other. In the interests of spawning a kinder, gentler, more productive corewar, I have here a small redcode program which calculates the greatest common divisor of two numbers, showing that our language need not be used solely for warlike purposes. Perhaps we could get funding from the Clinton administration for the Core War Defense Conversion Program, promoting dual use technologies in corewar-- imagine a bomber which finds new primes by bombing with small prime numbers (sieve of Eratosthenes). I see a whole new arena of corewar programming here. Of course, to do meaningful mathematics, we may need to increase the core size to, say, 10^50 or so. But this is just an implementation issue. ;name GCD ;finds the Greatest common divisor of a and b tmp dat #0 a dat #17*151 b dat #23*151 start jmz quit, b ; while (b>0) { loop sub b, a ; for (; a>=b; a-=b); slt a, b jmp loop mov a, tmp ; swap(a,b); mov b, a mov tmp, b jmp start ; } quit ; we're done-- now a=151=gcd(17*151,23*151), b=0 ; insert replicating cmp-scanning imp spiral vampire here James jlayland@grissom.jpl.nasa.gov From: d92-foh@mumrik.nada.kth.se (Fredrik hrstrm) Subject: Suggestions for ICWS-94 Message-ID: <1993Jun26.000431.18011@kth.se> Date: 26 Jun 93 00:04:31 GMT Here are a bunch of ideas for the new corewar standard: ------ Lets start out easy.... :) I have sometimes missed the instruction "skip if not equal". Has anybody else missed it too? The slt function would be more useful if one could use # in the B-field. It could then be used as "skip if greater than", just swap the operands. ------ Now some more radical stuff... Give every memory cell a "has been executed" flag. This flag is set when the cell has been executed. It is cleared when any write command is performed on the cell. This flag can be tested by "jmx A,B" which will jump to A if the cell where B points has the flag set. I hope this would increase scanner-power against bombers. But not so much against papers since they leave executed code all over the core anyway. ------ Even more strange ideas.... I would like to have some sort of static register or memory, where I could communicate between different processes. For example a paper which replicated in a normal fashion until a timer expired and all the paper copies died leaving only one process to clear the core. One could implement this with two instructions, "put" and "get". Put should act like a mov. Only that the B field is not used, as the destination is already known, the static memory cell. Get should retrieve it and move it into the cell specified by the A-field. Like in this six process paper: mov #6, 0 mov <-1, <1 spl @0, 994 get 1 dat #0 djn -1, #100 When it is replicating, the static memory cell contains jmz -4, -4 when we want the paper to start clearing we change it to mov 2, <-4 Unfortunately a vampire will naturally put a "put the_dat" into its slave pit, and thereby cripple the whole paper at once. So perhaps one could have a complete shadow core, which is shared between the competitors just like the ordinary core, except for that the shadow core uses immediate adressing, not relative. Then the vampire won't easily know which adress is used for the global variable. put source, shadow_core_adress get shadow_core_adress, destination This shadow core could be seen as a secondary storage medium, just like a hard disk. You could keep copies of your program in this shadow core to perhaps reach the yet unreached dream of a selfrepairing program. ------ And now a simple idea, but hard to explain.... Give each instruction a number from 0 to the number of instructions minus 1. Let the instruction field be of exactly the same format as the A and B fields. To decode an instruction we take the instruction field value modulo the number of instructions. If we have 16 instructions this is easy, just and with 15. The number we now have is the instruction. The number in the instruction field should not be changed by this evaluation. The adress modifier @<# in the instruction field is ignored. Now continue with the decoding of the A and B field as usual. This means that the instructions mnemonics will act like equates for a number. DAT EQU 0 for example. This means you can use instructions names in the A and B fields, and put an adress modifier @<# in front of the instruction field too. Date: 26 Jun 93 08:21:26 GMT > Example: (coresize=8192=1fff) > Date: Sun, 27 Jun 1993 17:39:43 GMT In article <20cms6$sak@elroy.jpl.nasa.gov>, jlayland@kilroy.Jpl.Nasa.Gov (James Layland) writes: ....> > Also, the draft allows a wide variety of different parameters for corewar > tournaments. I just wanted to point out one obvious side-effect of > using the RANDOM setting for initial instruction (0402-3): all forms of > scanners are dead. I realize this is just an optional parameter like > the maximum write distance, etc., but I think ruling out all possibility > of an intelligent search for the opponent is a mistake. > ... In this setting we introduce a new scanning operator 'SLT'. Yup, just old-fashioned skip-if-less-than. Here's how it works. Since core is randomized the chances of seeing numbers say, less than 10, are 1:800. But in an average warrior, the proportion of numbers less than 10 are usually very much higher. Therefore you look for numbers less than 10 and attack them. You can also look for the imp numbers 2667, 1143, etc. This form of scanner will be much weaker than current forms, but probably still strong enough to beat paper. It just occured to me this week that all mod-1 pattern numbers, or their complements, are imp-numbers. How about that? -Paul pk6811s@acad.drake.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Opinion poll on ICWS94 draft Message-ID: Date: Mon, 28 Jun 1993 03:59:49 GMT It looks like we need some experience programming warriors for ICWS94 before we can decide if this is really an improvement over ICWS88. Mintardjo and I are going to implement the draft ICWS94 based on the source to KotH 3.1 (additional programmers are still welcome). We will then try to get an experimental server started at Scott Ellentuch's site stormking.com, so we can all try out the proposed standard; accept, reject or modify it after we gained some practical experience. From past week's discussion, it isn't entirely clear to me whether people like the proposed standard. No point in implementing a trial ICWS94 server, if no one submits warriors! Please fill out the opinion poll below and mail it back to me. This is not an official vote (you need to be an ICWS member to vote), but protects us from wasting our time implementing the draft standard. Results will be posted as soon as polls stop coming in. Please participate and thanks for your time, -Stefan Configuration for experimental ICWS94 server: coresize: 8000 max. processes: 8000 max. program size: 100 min. program separation: 100 read distance: 8000 write distance: 8000 initial instruction: dat 0,0 additional addressing mode: postincrement indirect (>) additional opcodes: DIV,MUL,MOD instruction modifiers as introduced in icws94.draft (it's back in pub/corewar/incoming at soda.berkeley.edu) Fill out and return to stst@vuse.vanderbilt.edu -------SNIP------SNIP-----SNIP------ 1. Select with X I am an ICWS member [ ] I am not a member but plan to become one soon [ ] I am not a member and don't plan to become one [ ] 2. Select with X I am a veteran corewar player [ ] I am a novice [ ] I have never played corewar before [ ] 3. Select with X I have read the draft [ ] I have glimpsed over the draft [ ] I have not read the draft but followed the discussions [ ] I have no clue what I am talking about :-) [ ] 4. Select with X I like the draft ICWS94 and hope it will be accepted [ ] I like the draft but need to try it out first [ ] I don't like the draft but will still try it out [ ] I don't like the draft and won't try it out [ ] 5. Answer with [Y]es or [N]o. I like instruction modifiers [ ] I like postincrement indirect [ ] I like DIV/MUL/MOD [ ] I like (optional) read/write range limitations [ ] 6. I really would like to see these additional opcodes, addressing modes, etc., included in ICWS94: From: doligez@clipper.ens.fr (Planar) Subject: Re: Suggestions for ICWS-94 Message-ID: <1993Jun28.121909.1476@ens.fr> Date: Mon, 28 Jun 93 12:19:09 GMT In article <1993Jun26.000431.18011@kth.se> Fredrik hrstrm writes: > Here are a bunch of ideas for the new corewar standard: >------ Lets start out easy.... :) >------ Now some more radical stuff... >------ Even more strange ideas.... >------ And now a simple idea, but hard to explain.... If you are going to make so many changes to the standard, why not go all the way and change everything ? For example by introducing ... **************************** ** The RISC-MARS machine. ** **************************** The RISC-MARS machine is a new version of MARS, using modern technology. It is a new, state-of-the-art architecture, featuring: - A reduced instruction set. - 3-argument operations - A byte-addressable memory. - 64-bit words - One cycle per instruction - No register windows, no superscalar load-store architecture. Sorry. Memory layout ^^^^^^^^^^^^^ The memory is composed of bytes. Each byte is 16 bits. A memory address is the address of one byte. Four consecutive bytes starting at a multiple of 4 are one word. A word address is an address which is a multiple of 4. The coresize is always an integral number of words. Each word is an instruction, composed of an op-code and 3 arguments. The op-code and the arguments are 1 byte each. The op-code is further divided into 5 fields: * A one-bit B/W flag, which tells whether the instruction will operate on one byte or one word. If this flag is set to B, the instruction is said to be a byte-instruction; if W it is a word-instruction. The syntax for this flag is to put it right after the opcode. * A 3-bit instruction code, which represents one of the 8 possible instructions. * Three 4-bit addressing-mode codes, which give the addressing mode to use with each argument. op-code byte layout: bits 0 1 2 3 4567 8-11 12-15 +-----+--------+------+------+------+ fields | B/W | i-code | mode | mode | mode | +-----+--------+------+------+------+ The MARS-RISC CPU is a little-endian machine, which means: - The address of the op-code byte is a multiple of 4. - The address of operand number i is equal to i modulo 4. - The op-code byte is considered the least significant byte in word operations. Addressing modes ^^^^^^^^^^^^^^^^ There are enough bits in the op-code layout for 16 different addressing modes. Because there are currently 4 addressing modes, this leaves room for extension. The addressing modes are: 0. # Immediate 1. $ Direct 2. @ Indirect 3. < Predecrement indirect Operand Evaluation ^^^^^^^^^^^^^^^^^^ Operands are evaluated in left-to-right order. All addresses are relative to the byte in which the address was found. Some operations involve changing a byte address into a word address. This transformation is achieved by clearing the 2 least significant bits of the absolute byte address. This operation has the effect of computing the address of the word which contains the addressed byte. For all jump instructions (including SPL), the destination byte-address is converted to a word-address. Source operands are evaluated for their value. The value of an immediate operand is the operand itself. The value of a direct operand is the byte (for byte-instructions) or word (for word-instructions) pointed to by the operand. The value of an indirect operand is the byte or word pointed to by the byte pointed to by the operand. The value of a predecrement indirect operand is the same as for an indirect operand, except that the byte pointed to by the operand is first decremented by 1 (for byte-instructions) or by 4 (for word-instructions). This means that the indirection pointer is decremented by the size of the value. Destination operands are evaluated for their address. The address of an immediate operand is the address of the operand byte itself (address 0 relative to the operand byte.) The address of a direct operand is the contents of the operand byte. The address of an indirect operand is the contents of the byte pointed to by the operand. This contents is decremented prior to evaluation for predecrement indirect. All instructions have the form OPC A, B, C, where OPC is an instruction mnemonic. A is always a destination operand, B and C are source operands. This can be considered the reverse from the old convention for arithmetic operations, but the same as the old convention for jumps. Instruction set ^^^^^^^^^^^^^^^ The instruction set is composed of 8 instructions, which cover almost all the uses of the older, complex MARS instruction set. The exception is DJN, which is not very RISCish anyway. 0. DAT illegal instruction 1. JEQ jump if equal 2. JNE jump if not equal 3. JLT jump if less than 4. JLE jump if less than or equal to 5. ADD addition 6. SUB subtraction 7. SPL split 0. DAT -- Illegal instruction This one exists because processes have to have a way of dying. DAT A, B, C computes its 3 arguments, ignores them, and removes the current process from the run queue. 1. JEQ -- Jump if equal JEQ A, B, C jumps to A if B and C are equal. This instruction replaces the old CMP and JMZ instructions: CMP A, B --> JEQ $2, A, B JMZ A, B --> JEQ A, #0, B 2. JNE -- Jump if not equal JNE A, B, C jumps to A if B and C are different. This instruction replaces the old JMN instruction: JMN A, B --> JNE A, #0, B 3. JLT -- Jump if less than JLT A, B, C jumps to A if B is strictly less than C. The comparison is unsigned. 4. JLE -- Jump if less than or equal to JLE A, B, C jumps to A if B is less than or equal to C. The comparison is unsigned. This instruction replaces the old JMP instruction: JMP A, B --> JLE A, #0, B 5. ADD -- Addition ADD A, B, C replaces the byte (for byte-add) or word (for word-add) at address A with the sum of the values of B and C. For a word-add, the carry is propagated from one byte to the next. This instruction replaces the old MOV instruction: MOV A, B --> ADD B, #0, A 6. SUB -- Subtraction SUB A, B, C replaces the byte or word at address A with the difference B - C of the values of B and C. For a word-sub, the carry is propagated. This instruction can also be used to replace the old MOV instruction: MOV A, B --> SUB B, A, #0 7. SPL -- split the execution stream SPL A, B, C evaluates its three arguments, ignores B and C, and queues a new process starting at address A (in addition to the current process, which continues at the next instruction.) Room for improvement ^^^^^^^^^^^^^^^^^^^^ I would like to know your opinions about the following: The syntax of the B/W flag. Maybe we should put a dot between the opcode and the flag. Or maybe an optional dot. I'm looking for more addressing modes. I do not like all the wasted bits. Maybe postincrement indirect, and even postdecrement and preincrement. We would need to find a syntax for these. Another way would be to use one bit of addressing mode to tell whether the corresponding operand should be considered signed or unsigned. I'm not sure how this would work with a coresize which is not a power of two. Maybe we should always use a power of two. Maybe the carry should not be propagated for word additions and subtractions. Or the op-code could be the most significant byte. If we do not propagate the carry, the little/big endian distinction becomes less important. We might want to drop JLE in order to recover an op-code for DJN. But then we will have to decide what to do with the third argument. DJN could become "add and jump if not zero" or "decrement and jump if different" or even "subtract 1 and store and jump if not zero". The problem with DJN is that it would be the only instruction with two destination operands. We could even drop DAT and decide that the use of an illegal addressing mode will kill the process. This description is very informal. Please tell me about any ambiguous or unclear points. A C compiler will be available Real Soon Now. :-) -- Planar When I started writing this, it was a joke, but now I'm not so sure... From: morrell@math.utah.edu (Steven C. Morrell) Subject: Re: Call for Discussion: ICWS94 Draft Date: Mon, 28 Jun 1993 19:50:49 GMT Message-ID: Here's my two cent's worth. Sorry this is posted so late, but I was on vacation for the last two weeks. Replace line 0210 with 0210 expression According to the draft, "MOV.I , " would be a valid instruction. This seems needlessly obscure, especially when "MOV.I #0,#0" assembles into the same load-file instruction. And what is "MOV.I <,$" supposed to mean? Replace lines 0252 to 0257 with 0251 parenthetical precedence to determine the final value. If there is only 0252 one operand associated with a DAT instruction, this operand is assembled 0253 into the B-mode and B-address fields, and #0 is placed in the A-mode and 0254 A-address fields. For all other instructions with only one operand, this 0255 operand is assembled into the A-mode and A-operand fields, while #0 is 0256 placed in the B-mode and B-address fields. I think this part of the draft is contradictory. In any case, this revision brings the draft and the current method of assembling one-operand codes into agreement. Replace line 0405 with 0405 The maximum number of instructions allowed per load file. The term "initial instructions" does not comply in this instance to the glossary definition of "initial instruction" Replace line 0439 with 0439 currently executing instruction. The write limit can therefore An obvious typo in the draft. Steven Morrell morrell@math.utah.edu Will work for .sig file From: rschuler@iastate.edu (Rodney Schuler) Subject: Re: Suggestions for ICWS-94 Message-ID: Date: Tue, 29 Jun 1993 04:22:52 GMT In <1993Jun28.121909.1476@ens.fr> doligez@clipper.ens.fr (Planar) writes: >0. DAT illegal instruction >1. JEQ jump if equal >2. JNE jump if not equal >3. JLT jump if less than >4. JLE jump if less than or equal to >5. ADD addition >6. SUB subtraction >7. SPL split You need a move. You probably need 16 instructions. RISC architectures tend to have very few (or one) addressing modes. You can save a bit in the addressing mode field to get the 16 instructions. With three operands you definately need some way to move the operands about. >We could even drop DAT and decide that the use of an illegal addressing mode >will kill the process. I don't think this would be fitting. RISC architectures tend to be very orthogonal ie all addressing modes work with all instructions. >When I started writing this, it was a joke, but now I'm not so sure... I always thought a RISC corewar would be kinda cool. Unfortunately I already waste enough time with the CISC corewar. -- From: jhbrown@athena.mit.edu (Jeremy H Brown) Subject: Philisophical questions pertaining to the ICWS '94 proposal Date: 29 Jun 1993 05:57:50 GMT Message-ID: <20olku$g9d@senator-bedfellow.MIT.EDU> What is the philisophical point behind corewar? My impression has been that it is to make the best program possible out of a limited and quirky set of operands. Each quirk you eliminate from the Redcode language, it seems to me, makes the game a little less challenging in terms of coming up with strange new approaches to winning and moves the game a little closer to a battle for the best constants and fastest loops, with less room for cleverness each time. Now, I've never had a program on the Hill, so you experts out there are welcome to shoot me down at will... In closing I'd like to also say that I find the suffix-notation for opcodes to be hideously inelegant and just generally nasty. I much prefer the hard-coded, quirky version of the language specified by ICWS '88 to the mess the suffixes create. Jeremy From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: ICWS94 poll results Message-ID: Date: Wed, 30 Jun 1993 04:19:11 GMT Below the results of the quick icws94 poll. Thanks to all 15 who responded. Answers may not add up to 15 because of multiple selections or no selection. 1. Select with X I am an ICWS member [1] I am not a member but plan to become one soon [7] I am not a member and don't plan to become one [7] It looks like the ICWS has some growth potential :-). Info on how to join is in the FAQ. 2. Select with X I am a veteran corewar player [9] I am a novice [6] I have never played corewar before [1] 3. Select with X I have read the draft [4] I have glimpsed over the draft [5] I have not read the draft but followed the discussions [6] I have no clue what I am talking about :-) [1] 4. Select with X I like the draft ICWS94 and hope it will be accepted [1] I like the draft but need to try it out first [9] I don't like the draft but will still try it out [3] I don't like the draft and won't try it out [2] In other words, 10 like the draft, 5 don't. 13 would give the experimental server a spin, 2 won't. This is enough incentive to implement the server. 5. Answer with [Y]es or [N]o. [Y] [N] I like instruction modifiers 6 7 I like postincrement indirect 13 1 I like DIV/MUL/MOD 5 9 I like (optional) read/write range limitations 8 5 Split decision on modifiers; an overwhelming yes to ">"; bias against extra arithmetic opcodes and for read/write ranges. 6. I really would like to see these additional opcodes, addressing modes, etc., included in ICWS94: People who disliked instruction modifiers often wanted to include XCH as a dedicated instruction to exchange A and B-fields. I found it interesting that two out of three of those who consider themselves "corewar veterans" disliked instruction modifiers, but only one out of four "novices". I refrain from comment and quote Han-Wen Nienhuys instead: > I can't really judge whether the new standard is a good one, but every > time I think I have a great idea about how to write a program, it > turns out somebody else already did it. Maybe we'll need something new > and original with this ICWS 94 standard. Paul Kline on the conservative veterans' side: > Basically, I like the game as is, only the rules need to be written > more clearly. Guess I think there's plenty of room for exploration > yet with the rules we have :-) So, there seems to be enough interest to get an experimental icws94 server going. Mintardjo and I are going to put our heads together and start messing with Bill's KotH simulator source. We'll keep you up to date on our progress. Regards, Stefan (stst@vuse.vanderbilt.edu) Date: Wed, 30 Jun 1993 09:30:14 MST From: Message-ID: <93181.093014AZNXS@ASUACAD.BITNET> Subject: Re: ICWS94 poll results What are the plans about this ICWS94 server? I mean what platforms will be supported? I hope the server won't be the only place to try out a warrior. And because of modifiers we definately need some kind of debugger. I think something like the one in mercury2 would be the least work to implement so that it can run on different platforms. Nandor. From: doligez@clipper.ens.fr (Planar) Subject: Re: Suggestions for ICWS-94 Message-ID: <6891@seti.inria.fr> Date: 30 Jun 93 12:54:54 GMT In article , Rodney Schuler writes: >You need a move. You probably need 16 instructions. RISC architectures >tend to have very few (or one) addressing modes. You can save a bit in the >addressing mode field to get the 16 instructions. You have ADD and SUB. Just add or subtract a constant of zero to do the move. That is what I meant when I wrote: me> This instruction can also be used to replace the old MOV instruction: me> MOV A, B --> ADD B, #0, A This trick is often used in real RISC processors. As for the number of addressing modes, yes I know. RISC-MARS is not really a real RISC machine. It does not even have any register. This is because "hardware" constraints are different from those imposed by silicon. >>We could even drop DAT and decide that the use of an illegal addressing mode >>will kill the process. > I don't think this would be fitting. RISC architectures tend to be very > orthogonal ie all addressing modes work with all instructions. This is not what I meant. We have 4 bits of addressing mode. This means 16 addressing mode codes. Only 4 of them are used. The others would be deemed "illegal", and their use would kill the process. >>When I started writing this, it was a joke, but now I'm not so sure... >I always thought a RISC corewar would be kinda cool. Unfortunately I >already waste enough time with the CISC corewar. I would like to add one question to the opinion poll that was posted a few days ago. Would you like to try a RISC corewar ? The answer to this question can be a part of the answer to question 6. -- Planar From: pk6811s@acad.drake.edu Subject: _Push Off_ (back issues) Message-ID: <1993Jun30.095455.1@acad.drake.edu> Date: Wed, 30 Jun 1993 15:54:55 GMT For your convenience, a bound set of _Push Off_ issues from March 10, through June 22 can now be obtained from soda.berkeley.edu, as pshoff01.txt in pub/corewar/incoming. I had a request for back copies and decided what-the-heck, might as well do it once for everybody. I only stripped out the 'Quick Look' sections to save space - and hey, maybe you didn't want the boss to know, eh? Maybe someone could plow through the weekly standings sections and give us a synopsis of changes, or other tidbits. -Paul pk6811s@acad.drake.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: ICWS94 poll results Message-ID: Date: Wed, 30 Jun 1993 17:37:51 GMT In article <93181.093014AZNXS@ASUACAD.BITNET> writes: >What are the plans about this ICWS94 server? I mean what platforms will be >supported? I hope the server won't be the only place to try out a warrior. Once we're done implementing the draft standard, Scott Ellentuch will install an experimental KotH server at stormking.com. Just preface your warrior with ;redcode-94 and email it there. I think porting the server to anything but another UNIX workstation would be difficult. >And because of modifiers we definately need some kind of debugger. I think >something like the one in mercury2 would be the least work to implement >so that it can run on different platforms. Albert Ma has already announced support for icws94 in the next release of mercury2. Maybe we can get him to implement the draft ahead of time, so at least the PC people have something to work with. How about writing MARS94 yourself, Nandor? What would be really nice to have is a "minimal-standard, portable MARS", a core parser and interpreter, perhaps a simple line-oriented debugger (mercury2 style) all written in portable C. No display, nothing hardware dependent; modular, well-documented code, no speed optimizations, easily extensible with platform-dependent code for GUI, etc. This would make playing with new rules a lot easier. Any takers :-)? -Stefan (stst@vuse.vanderbilt.edu) -Stefan (stst@vuse.vanderbilt.edu) > >Nandor. Date: Wed, 30 Jun 1993 19:18:00 MST From: Message-ID: <93181.191800AZNXS@ASUACAD.BITNET> Subject: Re: Implementing ICWS94 I think this portable MARS is a great idea. I didn't look at Koth but Albert thinks it's not very portable, and as I remember it uses the heap for the program counters which was a problem. Anyway Albert's solution for this is much better, quicker easier to implement, needs less memory. So maybe we need to start it from scrach. Maybe we can use the expression parser in Koth. I think mars94 won't be ready in the near future. I should study analisys for my exam. But I will release a slightly new mars88 that can call Mercury2 or any other program. Nandor.