From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: ICWS'88 too simple? Message-ID: <58279@cup.portal.com> Date: Fri, 1 May 92 00:37:54 PDT in 4/30/92 17:58 28/1263 DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >>ICWS'88. There is just not enough variety to facilitate truly original >>programs. > >I disagree. I would amend the statement to read "There is not enough >variety (in ICWS'88) to facilitate truly original SUCCESSFUL programs" >where success is judged by doing well in a tournament or on the hill. Taking my usual role as the objector, let me say that the INSTRUCTIONS available in ICWS'88 are not at fault for the lack of variety of successful warriors. The size of the hill and number of processes have more to do with how large a warrior can be and still perform well, than the available instructions. If more intelligent, larger programs are what you desire, make the hill bigger. (For those who may disbelieve, try running paper against XTC in an 8000 word core and a 64,000 word core.) Let me go even further and object (Gee, I'm sure objectionable aren't I?) to the original statement that "There is just not enough variety to facilitate truly original programs." IMHO, there are three "basic" strategies employed by the vast majority of warriors, the "paper" strategy (make copies of yourself) used by Mice (and others), the "scissors" strategy (enslave the enemy) used by XTC (and others), and the "rock" strategy (be small) used by Dwarf (and others.) These are simply strategies that work. Just because some warriors use strategies, and even code, that are similar, does not mean that there are _no_ strategies which are truly original. Further, it doesn't even follow that the _similar_ programs are not original. There is no fundamental difference between the strategy of XTC and the strategy of Power Bomb, but they are very different programs. There have been many warriors which do NOT follow the three "basic" strategies (Sync, hideout, Acid Rain, and zipper to name a few.) Finally I must ask, whats so bad about similar programs? Is a corewar tournament so limited that Dwarf-12b and Dwarf-optima are not allowed to compete head to head because they are "too similar?" In my opinion if a program does even one thing differently, it qualifies as an original program. If a warrior can see farther by "Standing on the shoulder of giants," I say "let it." |+---------------------------------------------------------------+| Of course your job is hard, they wouldn't pay you if it was easy! <<>> From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: ICWS'88 too simple? Message-ID: <167D9118FA.DURHAM@ricevm1.rice.edu> Date: Fri, 1 May 1992 00:58:44 GMT In article <1992Apr30.190647.21754@microsoft.com> t-jcisek@microsoft.com (Julius Cisek) writes: >ICWS'88. There is just not enough variety to facilitate truly original >programs. I disagree. I would amend the statement to read "There is not enough variety (in ICWS'88) to facilitate truly original SUCCESSFUL programs" where success is judged by doing well in a tournament or on the hill. People can (and have) written many warriors based on many, many original (at the time) ideas. The sad fact is that most do not fare well against sophisticated (i.e. those that use "tricks") pattern bombers. DJN and pre-decrement mode speed up already speedy Dwarf-like programs. "Variety" in programs means longer programs. Longer programs are larger targets. Larger targets are hit and lose more frequently. Core war is indeed biased against variety. On the plus side, dumb bombers can not really get much smaller. Any changes in the standard which benefit longer programs probably will not benefit dumb-bombers to the same degree. Mark A. Durham MAD P.S. What if Core War programs were more like people - all of the same size (roughly) but of differing intelligence? But then again, C-Robots is that way. We would just be writing Assembly-Robots instead. From: t-jcisek@microsoft.com (Julius Cisek) Subject: Pre-Decrement Indirect concerns Message-ID: <1992May01.113827.18574@microsoft.com> Date: 01 May 92 11:38:27 GMT Can someone clarify the rules for ICWS'88 Pre-Decrement Indirect? I assert that when the following code is executed (at 0), the core will look as shown: Before: -1: dat 0, 0 -> 0: mov 0, <0 After: -1: mov 0, <-1 0: mov 0, <-1 This implies that the effective address of A and the effective address of B are evaluated as absolute addresses before we execute any part of the instruction. This is what ICWS'88 seems to state. However, MADcore (Amiga) and CoreWarPro (PC) both result in the following: After: -1: mov 0, <0 0: mov 0, <-1 This in turn implies that the core at memory location 0 is fetched before B is evaluated. Which one of these is correct? -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Pre-Decrement Indirect concerns Message-ID: <58297@cup.portal.com> Date: Fri, 1 May 92 15:13:28 PDT . . . >This implies that the effective address of A and the effective address >of B are evaluated as absolute addresses before we execute any part of >the instruction. This is what ICWS'88 seems to state. > >However, MADcore (Amiga) and CoreWarPro (PC) both result in the following: > >After: -1: mov 0, <0 > 0: mov 0, <-1 > >This in turn implies that the core at memory location 0 is fetched before >B is evaluated. > >Which one of these is correct? > Copied from MAD's Proposed Validation Suite: -=-=-=-=- ; PVS #12 start MOV 1, <1 stop DAT #0, #1 END start ; Result: Failure on second cycle at stop ; Memory: Unchanged! ; Explanation: This behaviour is open to interpretation. If one ; "completely" evaluates the A-operand first, one should make a copy ; of the instruction labelled "stop" as part of that evaluation. ; Then when the B-operand is completely evaluated as ; start + 1 + (1 - 1) = stop, the copy of the instruction labelled ; "stop" (prior to the decrement) is copied onto the instruction ; labelled "stop" (after the decrement), restoring "stop" to its ; initial state. ; There are those who would argue, and not without ; substantial basis, that there is no explicit reference in the ; standards to a "copy" and therefore the instruction labelled ; "stop" (after the decrement) should be copied onto itself. Thus ; stop would appear as "stop DAT #0, #0" after execution. ; Systems that "copy" the A-operand instruction include The MADgic Core ; and Core War Pro. -=-=-=-=- So there you have it, no consensus exists. It is worth noting that KOTH does work as per MAD's proposal, though I suspect it didn't originally. My system (and only mine it seems) does not, but then I treat MOV as two instructions (move A to B-field and move A-location to B-location) which no one else seems to either. |+--------------------------------------------------------------------+| Agreement is easy to achieve in a committee of one. <<>> From: gt6525c@prism.gatech.EDU (Damon Gallaty) Subject: Two Questions Message-ID: <56298@hydra.gatech.EDU> Date: 1 May 92 17:00:46 GMT 1) What is the -x (experimental) KotH? Is it different from Koth, and how? 2) Since so many people post their code, is anyone maintaining a library of such? I know there's FTP sites that have several examples, but is someone saving the code postings and keeping them together? Thanks. Reply to e-mail is preferred. -- "Have you ever danced with the Devil by the pale moonlight? I ask that of all my prey. I just like the sound of it..." - the Joker ************************************************************************ Damon Gallaty E-mail: dgal@cad.gatech.edu From: wms@iwarp.intel.com (William Shubert) Subject: Re: FAST CoreWar simulator... Message-ID: <1992May1.172001.24769@iWarp.intel.com> Date: Fri, 1 May 1992 17:20:01 GMT Julius Cisek posted: > The initial test is this: SPL 0, JMP -1, >for 80,000 cycles with 8000 tasks allowed. It runs in a little over >2 seconds on a 486/25 Well, I just timed KotH for this same test and got 1.8 seconds here. However, my workstation is about twice the speed of a 486/25, so I guess your code is almost twice as efficient. I've been thinking, ever since people first posted about making corewar more efficient, and have thought of a way, through absolute C preprocessor abuse, to make KotH expand out a small, fairly easy-to-modify-and-understand source file into the super-efficient code, one function per op-mode-mode set, that has been discussed here. I'll probably give it a try soon and see what happens. And, of course, if it works and is fast, I'll release the source code. About the other question Julius posted, both interpretations are correct under the ICWS '88 standard; it just isn't specific enough. KotH used to be the way he expects things to work, but a while ago I modified it to match MADgic corewar, etc. The difference is: when is the value of an operand actually READ from memory? When the operand is evaluated, or when the instruction is executed? -Bill (wms@iwarp.intel.com) From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: FAST CoreWar simulator... Message-ID: Date: 1 May 92 19:46:19 GMT Preprocessor abuse? I thought that was what it was there for. Warning: several versions of gcc bark when macro expansions go over 32k. The solution is just to insert a few bytes more of comment between the calls. Lord knows why. stephen (Oh, how I found this out was writing an interpreter. I was damned if I was going to maintain four functions that differed only in say "+" "-" "*" and "/" in a few crucial places, but the extra call was NOT justifiable performance-wise.... ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Two Questions Message-ID: <1992May2.004305.5525@oucsace.cs.ohiou.edu> Date: 2 May 92 00:43:05 GMT In article <56298@hydra.gatech.EDU> gt6525c@prism.gatech.EDU (Damon Gallaty) writes: >1) What is the -x (experimental) KotH? Is it different from Koth, and how? > We are always interested in trying to find the "best" and "most playable" rules for the game. We currently have had the '86 standards and now currently have the '88 standards. In efforts to improve the rules and clarify them even more for the next standards (hopefully '94), we actually implement some of the new rules to see how they actually work. Much to our surprise, we expect the programs to run one way and produce certain results, and instead produce completely different results. This in turn may elliminate possible new rules or subject them to more change. Currently the experimental hill is where these new rules are tried, and offer quite a few possibilities. The current X-Hill supports all addressing modes (while '88 standards do not), allows the post-increment ('>') indirect addressing mode, and most important of all, only allows instructions to modify memory within 250 memory locations from itself (can read the whole core, but only write, bomb, copy, or whatever near itself). I think we are having moderate success with this, and the X-Hill is producing some interesting programs. The downside is that it is very difficult to get on the Hill (or get knocked off, for that matter). If you do not know what KoTH stands for, or what the word Hill means, I will refer someone else to describe. :-) KoTH stands for King of the Hill. >2) Since so many people post their code, is anyone maintaining a library > of such? I know there's FTP sites that have several examples, but is > someone saving the code postings and keeping them together? I have a copy of all the programs that have been posted to this newsgroup. Most of them are collected together, where I use them to test against my own home brew programs. Some of them are still in my News directory, waiting for the day for me to clean them up and put them with the others. There are quite a few programs that I haven't even tried yet... Among the other code, I have all of the programs that were used in the previous ICWS Tourneys (these can be found at soda.berkeley.edu ftp site), all my programs, other people's programs, and some additional ones that have come down over the years. It is an illaberate system, and currently, I have an "active" directory (one I used to do all my testing) with over 130 programs in it. Please feel free to ask for any particular code from me... I will give most of it away freely, and a few (some of my own and my friend's) I will not even part with (secrets secrets secrets!). Also keep in mind that most of the code has been modified in some way to work on my corewar system. One day I will restore them all back to original shape. This is a problem with any program that remains '86 standard compliable and not the '88 standards. Well, enough of my babble! Happy Happy Joy Joy! Keep them Programs a Running! Scott Adkins sadkins@ohiou.edu From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: Re: ICWS'88 too simple? Message-ID: <1992May2.033123.28778@usenet.ins.cwru.edu> Date: 2 May 92 03:31:23 GMT - (For those who may disbelieve, try running paper against XTC in an - 8000 word core and a 64,000 word core.) Interesting... There is the "normal" KotH, and the experimental KotH right now. Perhaps it could be expanded even more to have multiple sizes... Say, a normal and an experimenal 8000 size core, and a large 24000-64000 size core... You can then choose ;redcode ;redcode-x ;redcode-large ;redcode-large-x Per se... Of course, the demands on KotH's resources would also go up, and a large core would need a longer time of execution. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Pre-Decrement Indirect concerns Message-ID: <1992May2.160010.8367@vuse.vanderbilt.edu> Date: Sat, 2 May 1992 16:00:10 GMT In article <58297@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: >So there you have it, no consensus exists. It is worth noting that KOTH >does work as per MAD's proposal, though I suspect it didn't originally. Up until v2.2, KotH used to be a hybrid: MOV would evaluate its operands "in memory"; the rest of the instructions would work "in register", i.e. like MADgic Core and CoreWar Pro. The current version, Bill tells me, uses "in register" throughout. >My system (and only mine it seems) does not, but then I treat MOV >as two instructions (move A to B-field and move A-location to B-location) >which no one else seems to either. At least one more system, namely Jon Newman's Core! for the Mac goes this route too. BTW, this ambiguity will hopefully be resolved in the next Redcode standard. >|+--------------------------------------------------------------------+| >Agreement is easy to achieve in a committee of one. > <<>> -Stefan (stst@vuse.vanderbilt.edu) From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: VDT Round 4 Results Message-ID: <167DBE2E3.DURHAM@ricevm1.rice.edu> Date: 2 May 92 21:08:02 GMT Here are the results from Round 4 of the Valentine tournament: 0 / 260 Winner Cycle -------- ------ ----- Stefan Strack's Trinity Zwo allows him to continue to advance. He has a BYE for Round 5. Adam Caldwell's XDwarfer sends him to the Loser's Bracket where he will meet William Shubert. Trinity Zwo / XDwarfer Tie XDwarfer / Trinity Zwo Trinity Zwo 742 Stefan Haenssgen's Dime and Nandor Sieben's Return of the Living Dead battled again. This time, RotLD won both rounds. Mr. Sieben will face Scott Adkins next round. Mr. Haenssgen has been eliminated. Dime / Return of the Living Dead Return of the L. Dead 15676 Return of the Living Dead / Dime Return of the L. Dead 17010 Scott Adkins' Virus infected S. Halvorsen's Cake, winning both times. Mr. Adkins advances to meet Nandor Sieben next round. S. Halvorsen has been eliminated. Virus / Cake Virus 1157 Cake / Virus Virus 41 William Shubert's Leech and Aleksey Baulin's V3 also battled again. V3 wins both times. Mr. Baulin will face Kevin Whyte next round. Mr. Shubert will take on Adam Caldwell. Leech / V3 V3 965 V3 / Leech V3 751 Arne Juul's Rat and Campbell Fraser's and Scott Drummond's Intangible Worm battled again too. Intangible Worm was the victor both times. Fraser & Drummond go on to meet John Wetmiller in Round 5. Arne Juul has been eliminated. Rat / Intangible Worm Intangible Worm 4749 Intangible Worm / Rat Intangible Worm 4227 John Wetmiller's Gulliver beat Stig Hemmer's HideOutD once and tied once. Mr. Wetmiller will battle Fraser & Drummond next round. Mr. Hemmer has been eliminated. Gulliver / HideOutD Tie HideOutD / Gulliver Gulliver 691 Jack Twilley's AppleSeed5++ and Ray Cromwell's BullWhip exchanged battles for a tie. Due to Mr. Cromwell's not having contacted me between Round 3 and Round 4, Mr. Twilley wins by forfeit. Mr. Twilley advances to take on Vincent Li next round. Mr. Cromwell will face James Jesensky in the Loser's Bracket. AppleSeed5++ / BullWhip BullWhip 17788 BullWhip / AppleSeed5++ AppleSeed5++ 8130 Kevin Whyte's Kinch beat James Jesensky's Signal Gun once and tied it once to take a win. Mr. Whyte battles Aleksey Baulin in Round 5. Mr. Jesensky will meet Ray Cromwell. Kinch / Signal Gun Tie Signal Gun / Kinch Kinch 16241 Vincent Li's Paratroop2 beat John's and Mike Nidd's Tamper both times. Mr. Li takes on Jack Twilley next round. John and Mr. Nidd will fight against Stephen Beitzel. Paratroop2 / Tamper Paratroop2 401 Tamper / Paratroop2 Paratroop2 29137 Peter Olcott's Dwarf28 beat Kurt Werle's and Stephen Beitzel's Mr. Nasty both times. Mr. Olcott has a BYE for Round 5. Mr. Beitzel battles John and Mike Nidd. Mr. Nasty / Dwarf28 Dwarf28 1345 Dwarf28 / Mr. Nasty Dwarf28 918 Here are the brackets so far: Beg/Winner's Bracket -------------------- Stefan Strack----- vs > Stefan Strack-- Stefan Haenssgen-- \ vs > Stefan Strack- Scott Adkins------ / \ vs > Scott Adkins--- \ Nandor Sieben----- \ > Stefan Strack Arne Juul--------- / / vs > Adam Caldwell-- / / Adam Caldwell----- \ / / vs > Adam Caldwell-- / Fraser & Drummond- / / vs > S. Halvorsen--- / S. Halvorsen------ / >---------- William Shubert--- \ vs > William Shubert \ John Wetmiller---- \ \ vs > Aleksey Baulin- \ Stig Hemmer------- / \ \ vs > Aleksey Baulin- \ \ Aleksey Baulin---- \ \ >--------------- Kevin Whyte------- / vs > Kevin Whyte---- / Werle & Beitzel--- \ / > Kevin Whyte---- Peter Olcott------ / vs > James Jesensky- James Jesensky---- Vincent Li-------- vs > Vincent Li----- John & Mike Nidd-- \ >---------------- Jack Twilley------ / vs > Jack Twilley--- Ray Cromwell------ Loser's Bracket --------------- Arne Juul--------- vs > Fraser--------- Fraser & Drummond- \ >---------------- John Wetmiller---- / \ vs > John Wetmiller- \ Stig Hemmer------- \ >----------------- Stefan Haenssgen-- / vs > Nandor Sieben-- / Nandor Sieben----- \ / >---------------- S. Halvorsen------ / vs > Scott Adkins--- Scott Adkins------ Adam Caldwell----- vs >---------------- William Shubert--- \ >---------------- Ray Cromwell------ / vs >---------------- James Jesensky---- Stephen Beitzel--- vs >---------------- John & Mike Nidd-- \ >---------------- / Peter Olcott----------------------- Out of Contention ----------------- Arne Juul Stig Hemmer Stefan Haenssgen S. Halvorsen From: choke@wet.UUCP (Sean Gallaty) Subject: Andromeda Strain Message-ID: <3884@wet.UUCP> Date: 2 May 92 22:16:37 GMT Hello coders. Here is my attempt at a voracious self-replicator. It has a definate weakness against vampires, but seems to beat most everything else. It was on the hill for a while until a bunch of vampires showed up. The theory of operation is as such: Copy self twice, then start bombing. Each copy does the same. so here is ... ;redcode ;name Andromeda Strain v0.5 ;author Sean Gallaty ;strategy Trying to design the perfect 'voracious self replicator.' ;strategy Designed to be resistant to dat bomb damage. dat #0 start: jmp 2 source: dat #0 mov #2 , countdown restart: mov #fini-source , source copyloop: mov Date: 3 May 92 06:22:00 GMT Could someone please explain to me the concept behind a vampire attack... Thanks Paul From: t-jcisek@microsoft.com (Julius Cisek) Subject: Re: ICWS'88 too simple? Message-ID: <1992May03.161810.25235@microsoft.com> Date: 03 May 92 16:18:10 GMT In article <58279@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: >in 4/30/92 17:58 28/1263 DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: > Taking my usual role as the objector, let me say that the >INSTRUCTIONS available in ICWS'88 are not at fault for the lack of >variety of successful warriors. [...] Okay, but you're just nitpicking at words. Whatever the reason, I really feel that we are slowly reaching an asymptote in warrior design (I'm quite surprised that it took so long, but then again KotH is the main design motivation...). > Let me go even further and object (Gee, I'm sure objectionable >aren't I?) to the original statement that "There is just not enough >variety to facilitate truly original programs." IMHO, there are >three "basic" strategies employed by the vast majority of warriors, >the "paper" strategy (make copies of yourself) used by Mice (and >others), the "scissors" strategy (enslave the enemy) used by XTC (and >others), and the "rock" strategy (be small) used by Dwarf (and >others.) These are simply strategies that work. Just because some >warriors use strategies, and even code, that are similar, does not >mean that there are _no_ strategies which are truly original. True, not yet, anyway, but it's very hard to write something truly original. And as I've said above, we are reaching an asymptote, I'm sure of it. >Further, it doesn't even follow that the _similar_ programs are not >original. There is no fundamental difference between the strategy of >XTC and the strategy of Power Bomb, but they are very different >programs. There have been many warriors which do NOT follow the >three "basic" strategies (Sync, hideout, Acid Rain, and zipper to >name a few.) I'm not talking about similarity. I'm talking about identicality. Your scissors88 program is basically 3 lines! Don't you think that many programmers might come across this solution as well. I did; if you look at my PitTrap v2.3a posting, you should see a MIRROR of scissors88, yet I assure you I came up with it on my own. By the way, I also wrote Mice and Small (Staph and Trapper) way before seeing code for either (those were some of my early efforts, Trapper never got debugged; bad step value). Because programs are being forced into being small, we are also running low on variety. > Finally I must ask, whats so bad about similar programs? Is >a corewar tournament so limited that Dwarf-12b and Dwarf-optima are >not allowed to compete head to head because they are "too similar?" >In my opinion if a program does even one thing differently, it >qualifies as an original program. If a warrior can see farther by >"Standing on the shoulder of giants," I say "let it." The above statement may work well for dwarves which rely on a step value more than anything else. But if I had many different versions of Charon with different step values, it would be a completely different story... When I first read about CoreWar, I envisioned complex programs similar to ICE breakers in Neuromancer; a true code war. I really enjoy the current CoreWar, and I understand that one of it's virtues is the simplicity, but I also believe that changes have to be made to allow this fine recreation to continue (and open itself up to a larger user base). -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: laajarinne@cc.helsinki.fi Subject: KotH question Message-ID: <1992May3.185236.1@cc.helsinki.fi> Date: 3 May 92 16:52:36 GMT I think this is important... What is the minimum distance between warriors in KotH? Jukka Laajarinne laajarinne@cc.Helsinki.fi From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: KotH question Message-ID: Date: 3 May 92 18:00:53 GMT Zero, once the fun starts ;-) ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- Subject: RE: FAST CoreWar simulator Message-ID: <68736.123924629@kcbbs.gen.nz> From: Electric.Monk@kcbbs.gen.nz (Corey Murtagh) Date: 3 May 92 19:05:36 GMT Well I for one would be MOST interested in the source code for the simulator whenever it's done. I haven't been playing with corewars for long, and would like to do some work on it at home as opposed to during my lunch breaks. And of course, I don't have CW for my Apple IIgs, and don't know enough to write the compiler or virtual machine I would need. :-) Electric Monk - electric.monk@kcbbs.gen.nz (This used to be a little net.sig, until I added a line saying so!) From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: vampire attack? Message-ID: <58424@cup.portal.com> Date: Sun, 3 May 92 20:00:40 PDT >5/2/92 23:22 6/100 kilroy@mik.uky.edu (Paul S. Kilroy) > > Could someone please explain to me the concept behind a > vampire attack... > > Thanks > Paul A "vampire" attack is one which rather than killing the opponent outright by hurling DAT's (like dwarf or rock), steals it sole (process) and puts it to work. In my words, "vampires" and "slavers" are all of type "Scissors" Here is an example: the warrior Scissors88 (a.k.a. Pit-trap) --- cut ---- loop add pit, ptr mov ptr, @ptr jmp loop ptr jmp pit pit mov 12, <-12 spl pit spl pit end loop --- end cut ---- |+----------------------------------------------------------------+| A rose, by any other name, would smell as sweet, but would anyone know what you were talking about? <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: KotH question Message-ID: <58425@cup.portal.com> Date: Sun, 3 May 92 20:05:02 PDT >5/3/92 09:52 7/130 laajarinne@cc.helsinki.fi >I think this is important... >What is the minimum distance between warriors in KotH? Now for the boring answer: KotH picks two blocks of 100 words, which are chosen at random, but are guaranteed to be non overlapping. Each warrior is loaded into one block. Therefore the "minimum distance" is either 100 or 0 depending on what you mean by "minimum distance." |+------------------------------------------------------------------+| "Don't you know you'll never reach her? you can only go half way to her every minite" asked the mathmatican. The engineer replied "Well, I can't reach her, but I can get close enoough for all practical purposes" <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: ICWS'88 too simple? Message-ID: <58426@cup.portal.com> Date: Sun, 3 May 92 20:09:09 PDT I do not feel that most of the programs of the hill lack variety. While there may be several similar (or even the same) warriors, most of them are not. Of course the early warriors are likely to be repeated, just as two novice chess players may play the same game as two others, it does not follow that ALL chess games are similarly limited. Also just because two warriors are always at approximately the same location on the hill, does not mean that they are not different; Two paintings might look alike to one man, but might look totally different to a man who was colorblind. As for the idea that we are reaching an asymptote. . . When mice first came on the scene, some people said that no warrior would ever beat it. Then came ferret, (and a host of others) which had no problem beating mice, and these nay-sayers said "Surely no program will ever beat ferret." Of course XTC, Double Storm, and Molerat had no problem doing just that, and the nay-sayers latched onto XTC as the end all (Even though in the tourney before the grand finale XTC placed THIRD!) saying "Corewar obviously favors small, fast, spl bombers." Each time these people thought that the asymptote was just around the corner. Every year they were proved wrong. I personally believe we have not even seen a fraction of the TWO LINE warriors, (of which there are over 1,000,000) much less the complete spectrum of possible warriors. Instead of worrying about how to change corewar BEFORE reaching the asymptote, I think one should wait for it to happen and then change corewar. Please do not feel that I am opposed to _any_ changes, I simply feel that the changes should make corewar less complex, clearer, less ambiguous, more consistent/complete, and/or smaller. How warriors perform under such rules is not the issue. Post Script: Chess has 6 kinds of pieces, two colors, and a field of 64 spaces. Go has one kind of piece, two colors and a field of 361 spaces. No one believes they have reached the asymptote of either game, nor that they will in the foreseeable future. |+-----------------------------------------------------------------+| Before we can have achieve an increase in artificial intelligence, we must first have an increase in natural intelligence. <<>> From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: ICWS'88 too simple? Message-ID: <1992May3.212001.5273@vlsi.polymtl.ca> Date: 3 May 92 21:20:01 GMT as666@cleveland.Freenet.Edu (Jonathan Roy) writes: : : - (For those who may disbelieve, try running paper against XTC in an : - 8000 word core and a 64,000 word core.) : : Interesting... There is the "normal" KotH, and the experimental KotH : right now. Perhaps it could be expanded even more to have multiple : sizes... Say, a normal and an experimenal 8000 size core, and a large : 24000-64000 size core... You can then choose : : ;redcode : ;redcode-x : ;redcode-large : ;redcode-large-x : : Per se... Of course, the demands on KotH's resources would also go up, : and a large core would need a longer time of execution. : Well, running in non-even core size would also dramatically affetc program like XTC which assume even core size. But the ratio core size / numbre of task is very important. dumb program win against xtc and mrbeef in 2000 / 4 tasks. Also, there's a fourth type of program, which i've not seen many (except mines :) - the 'possessor' which seek and execute enemy code. I've also found that combination of strategy make effective warriors. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: kwhyte@math.uchicago.edu (Kevin Whyte) Subject: Re: ICWS'88 too simple? Message-ID: <1992May3.213957.8933@midway.uchicago.edu> Date: Sun, 3 May 1992 21:39:57 GMT In article <1992May03.161810.25235@microsoft.com> t-jcisek@microsoft.com (Julius Cisek) writes: >In article <58279@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: >>in 4/30/92 17:58 28/1263 DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >> Taking my usual role as the objector, let me say that the >>INSTRUCTIONS available in ICWS'88 are not at fault for the lack of >>variety of successful warriors. [...] > >Okay, but you're just nitpicking at words. Whatever the reason, I really >feel that we are slowly reaching an asymptote in warrior design (I'm quite >surprised that it took so long, but then again KotH is the main design >motivation...). > >> Let me go even further and object (Gee, I'm sure objectionable >>aren't I?) to the original statement that "There is just not enough >>variety to facilitate truly original programs." IMHO, there are >>three "basic" strategies employed by the vast majority of warriors, >>the "paper" strategy (make copies of yourself) used by Mice (and >>others), the "scissors" strategy (enslave the enemy) used by XTC (and >>others), and the "rock" strategy (be small) used by Dwarf (and >>others.) These are simply strategies that work. Just because some >>warriors use strategies, and even code, that are similar, does not >>mean that there are _no_ strategies which are truly original. > >True, not yet, anyway, but it's very hard to write something truly >original. And as I've said above, we are reaching an asymptote, I'm >sure of it. > >>Further, it doesn't even follow that the _similar_ programs are not >>original. There is no fundamental difference between the strategy of >>XTC and the strategy of Power Bomb, but they are very different >>programs. There have been many warriors which do NOT follow the >>three "basic" strategies (Sync, hideout, Acid Rain, and zipper to >>name a few.) > >I'm not talking about similarity. I'm talking about identicality. >Your scissors88 program is basically 3 lines! Don't you think that >many programmers might come across this solution as well. I did; if >you look at my PitTrap v2.3a posting, you should see a MIRROR of >scissors88, yet I assure you I came up with it on my own. By the >way, I also wrote Mice and Small (Staph and Trapper) way before seeing >code for either (those were some of my early efforts, Trapper never >got debugged; bad step value). Because programs are being forced >into being small, we are also running low on variety. > >> Finally I must ask, whats so bad about similar programs? Is >>a corewar tournament so limited that Dwarf-12b and Dwarf-optima are >>not allowed to compete head to head because they are "too similar?" >>In my opinion if a program does even one thing differently, it >>qualifies as an original program. If a warrior can see farther by >>"Standing on the shoulder of giants," I say "let it." > >The above statement may work well for dwarves which rely on a step >value more than anything else. But if I had many different versions >of Charon with different step values, it would be a completely different >story... > >When I first read about CoreWar, I envisioned complex programs similar >to ICE breakers in Neuromancer; a true code war. I really enjoy the >current CoreWar, and I understand that one of it's virtues is the >simplicity, but I also believe that changes have to be made to allow this >fine recreation to continue (and open itself up to a larger user base). >-- >Julius Andrew Cisek ,_, >t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated >One Microsoft Way // <>__| /- O O idiot!" >Redmond, WA 98052 \X/ | U| \| I felt the same way when I started writing cw programs; I think most of us did. However, it seems that you get used to it. That is you come to realize that CW is not an AI project - not to put down the idea, but there already are several such game : c-robots, et al. CW is really a different kind of game. In AI situations the trick is programming your warriors to act intelligently ... given the info. they get you could easily beat them ( if you could respond that quickly). In CW the hard part is figuring out what the warrior should do, not how to make it do it ( coding is almost trivial ). I'm curious - does anyone who has been writing CW programs for awhile still feel limited by the scope of the game? It seems you come to appreciate warriors on a different level after awhile. It is somewhat surprising that 3 line programs do well on KotH, but maybe it shouldn't be. Anyone out there sure that they know which program under 4 lines is toughest? Or even that they know all the decent ones? I certainly don't ... Kevin ps: It says something that we don't even know what offset a dwarf should use. There's actually some hard mathematics there .... From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: ICWS'88 too simple? Message-ID: Date: 3 May 92 22:31:44 GMT Well, I'm still a newbie and I still find it depressingly limiting. But I agree that doing something like forcing everything to the same virtual footprint would destroy the whole idea of the game - in fact, this is one of the things that the cyberpunk authors always get depressingly wrong. This is NOT a proposal per se, but it occurs to me that *in real life* the situation is a little different, because of cache behaviour. You could shift the balance a little more in favour of more "intelligent" programmes WITHOUT changing the basic nature of the game by using a rule like this: the 256 (say) most recently used addresses (initially just your warriro's own footprint) are "active" addresses - they are "in you cache". Accessing an address NOT in your cache takes (say) four cycles and bumps out the least recently used. That should encourage using more than four processes, less than 64 processes, and make intelligence a quarter the price of speed. And with full binary compatibility :-). In that formulation it favours slavers too much, but is there interest in this kind of NON-intrusive and computer-realistic kind of tweak? ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: May MADFAQs! (Some new/changed stuff) Message-ID: <167DC150E3.DURHAM@ricevm1.rice.edu> Date: Mon, 4 May 1992 04:57:23 GMT Last Update: May 3, 1992 TABLE OF CONTENTS ----------------- 1. What is Core War? 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. What is the ICWS? 5. What is TCWN? 6. How do I join? 7. Are back issues of TCWNs available? 8. What is the EBS? 9. Where are the Core War archives? 10. Where can I find a Core War system for . . . ? 11. When is the next tournament? 12. What is KOTH? How do I enter? 13. Other questions? --------------------------------------------------------------------- Q1: What is Core War? A1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole possesion of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q2: Is it "Core War" or "Core Wars"? A2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q3: Where can I find more information about Core War? A3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 Library of Congress Call Number: QA76.6 .D517 1988 --------------------------------------------------------------------- Q4: What is the ICWS? A4: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q5: What is TCWN? A5: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and may be available through this newsgroup in the near future. --------------------------------------------------------------------- Q6: How do I join? A6: For more information about joining the ICWS and/or subscribing to TCWN, contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 EMail: jonn@microsoft.com If you wish to contribute an article, cartoon, letter, joke, rumor, etc. to TCWN, please send it to me at Mark A. Durham P.O. Box 301173 Houston, TX 77230-1173 EMail: durham@ricevm1.rice.edu and clearly indicate its destination. The ICWS and TCWN have finally been transferred. You should be seeing much more from each now. ---------------------------------------------------------------------- Q7: Are back issues of TCWN available? A7: Back issues of the TCWN (up to Winter 1991) are available from AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Prices are unknown at this time, but should be around $5.00 (the original cover price). --------------------------------------------------------------------- Q8: What is the EBS? A8: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament will be entered into the annual ICWS tournament. Now that rec.games.corewar has been created, the EBS moved its business to the newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994. Its immediate business will be to set up a Charter and establish its officers. Contact me if you are interested in helping serve the EBS. ---------------------------------------------------------------------- A9: Where is the Core War archive? Q9: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.131.179) in the /pub/corewar directories. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. ---------------------------------------------------------------------- Q10: Where can I find a Core War system for . . . ? A10: First, check out the Core War systems available via anonymous ftp from soda.berkeley.edu. Currently, there are X-Window, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. Others may appear. The following suppliers have ICWS'88 compatible systems for IBM PC compatibles: The Core War Colosseum AMRAN 5712 Kern Drive Huntington Beach, CA 92649-4535 Price: $39.95 CoreMaster(TM) THINK Software 524 Paige Drive Birmingham, AL 35226 (205)979-9475 Price: $34.95 + $3.00 S&H Apple Macintosh computers: Core! Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 EMail: jonn@microsoft.com (Note: Core! is NOT a Microsoft product.) Price: $14.00 registration fee, plus $3.00 S&H. S&H fee waived if you send 800k disk and stamped, self-addressed envelope. Also available from sumex-aim.stanford.edu and listserv@ricevm1.rice.edu and soda.berkeley.edu. Commodore Amiga computers: The MADgic Core Mark A. Durham P.O. Box 301173 Houston, TX 77230-1173 EMail: durham@ricevm1.rice.edu A version of The MADgic Core is available from soda.berkeley.edu. CoreWars (German language version) UNICORN systems Bernstrasse 67 CH-4852 Rothrist Switzerland Price: sFr 45.-- Commodore 64/128 computers: Barry Cohen 65 West 90th Street, #23E New York, NY 10024 Price: Not Available My apologies to those of you who have Core War systems which are not listed here or are incorrectly listed here. Please send me information about the systems (base system, ICWS standards compatibility, extensions, price, etc.) and I will be sure to include it in next month's MAD FAQs. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Please post or EMail to me any review of any Core War system you have tried out so that others may learn from your experience. ---------------------------------------------------------------------- Q11: When is the next tournament? A11: The EBS is in the middle of a tournament right now. There will be another starting in the Fall. Otherwise, keep looking to r.g.cw for upcoming tournament announcements. ---------------------------------------------------------------------- Q12: What is KOTH? How do I enter? A12: King Of The Hill (KOTH) is an ongoing Core War tournament available to anyone with EMail provided by William Shubert . You enter by submitting via EMail a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". If your program finished in the top twenty, it will remain on the hill until such time as it finishes twenty-first against another challenger, at which time it "falls off" the hill. Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail demon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. 3) Mail this file to "wms@iwarp.intel.com". 4) Within a few minutes you should get mail back telling you whether your program compiled correctly or not. If it did compile correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives in an hour, don't worry; entries are put in a queue and run through the tournament one at a time. A backlog may develop. Be patient. If your program makes it onto the hill, you will get mail every time a new program makes it onto the hill. If this is too much mail, you can use ";redcode quiet" when you first mail in your program; then you will only get mail when you make it on the top 20 list or when you are knocked off. Using ";redcode verbose" will give you even more mail; here you get mail every time a new challenger arrives, even if they don't make it onto the top 20 list. Often programmers want to try out slight variations in their programs. If you already have a program named "Foo V1.0" on the hill, adding the line ";kill foo" to a new program will automatically bump foo 1.0 off the hill. Just ";kill" will remove all of your programs when you submit the new one. MORE ON KOTH COREWAR IMPLEMENTATION Core size: 8,000 instructions Max processes: 8,000 per program Duration: After 80,000 cycles per program a tie is declared. Max entry length: 100 instructions Programs are guaranteed a 100 instruction block (inclusive of their warrior's instructions) without overlapping their opponent. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb dat #0 dwarf add #4,bomb mov bomb,@bomb jmp dwarf end dwarf Rule variants for "eXperimental" corewar: The same as above but use ";redcode-x" to start your program. Your program will be entered into a second tournament with slightly different rules. The rules are: - All addressing modes are allowed with all instructions. - There is an additional addressing mode, called "postincrement". To use it try an instruction like "mov >5,6". - The maximum write distance is 250 instructions. That is, every time your program tries to modify memory, the address is checked; if it is more than 250 instructions from the process doing the modify, then memory is left unchanged, but the instruction continues as normal. KotH runs on any Unix system with an X windows interface. The source code to KotH is available by EMail from William Shubert. Write to him at for a copy. ---------------------------------------------------------------------- Q13: Other questions? A13: Just ask. Either ask in the newsgroup or send your question to me at durham@ricevm1.rice.edu. I will do my best to answer your question or put you in touch with someone who can. Mark A. Durham MAD From: nautilus@lachesis.acm.rpi.edu (John M. Twilley) Subject: Re: ICWS'88 too simple? Message-ID: <_!pvxam@rpi.edu> Date: Mon, 4 May 1992 05:03:06 GMT You mentioned a million plus two-line warriors. I know of only one viable two-line warrior, that I am going to send to KotH, and then here. :-) Jack., -- John M. Twilley | "If they can't see the light, nautilus@acm.rpi.edu | let them feel the heat." -- Anonymous From: un035300@wvnvms.wvnet.edu Subject: middle earth 1.4 Message-ID: <1992May4.005327.3078@wvnvms.wvnet.edu> Date: 4 May 92 05:39:05 GMT Ok, the peer pressure has got to me :) Here is one of my first warriors. don't ask me what it does.... I really don't know. It's made up of bits and pieces of code that had been posted. If you figure out what it really does please let me know. ;redcode-x ;name Middle-Earth_1.4 ;author Rob Shultz ;strategy warrior that uses a hobbit,dwarf,mute,and imp dist EQU 333 start SPL dwarf SPL hobbit SPL imp MOV Date: 4 May 92 05:39:03 GMT Here is another one of my warriors. It copies a bunch of imps and 1 dwarf every 175 bytes. It has been the most successful warrior I submitted to KOTH. It has been as high as number 11. Not the greatest but I'm learning! ;redcode-x verbose ;name Eru (The Chosen) ;author Rob Shultz ;strategy copys imps every 175 bytes and releases an imp that ;strategy goes the other way in the core. SPL start kill MOV kill,kill-3 JMP kill start MOV #10,size ADD #175,@target copy MOV Date: 4 May 92 12:05:02 GMT In article <1992May3.212001.5273@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: > Well, running in non-even core size would also dramatically affetc program >like XTC which assume even core size. But the ratio core size / numbre of task >is very important. dumb program win against xtc and mrbeef in 2000 / 4 tasks. > > Also, there's a fourth type of program, which i've not seen many (except >mines :) - the 'possessor' which seek and execute enemy code. I've also found >that combination of strategy make effective warriors. I have been quiet through all this, and now must finally say something. I will first mention that Virus, one of my favorite programs, also executes enemy code. I wrote this program back in High School (4 or 5 years ago) using an idea a friend of mine actually had. It is a good idea, but I found that to limit the number of ties, I had to stick copying code and a couple of dwarves into the program. Why hasn't many people tried it? Well, I have written several programs that use this method, and the number of ties vs wins/losses is just incredible. People prefer to write programs that win, not tie all the time. Now, about this Asymptotic line... :-) I do believe that there is one, especially when given the number of instructions, modes, and the size of the core that we use. If we increases any one of these (size being the most easily and allowable to increase), then the asymptotic line will be moved further out. Have we reached it yet? No, by all means we haven't. When I wrote Virus, Killer and a couple of other programs, I only had Mice, Ferret and Cowboy as measures for a good program. Then XTC came around. People can be funny when they think "that is the end all" as someone previously mentioned... When split bombers became popular and was able to slow enemy down (was Ferret the first of this kind?), people started harping about having to change the SPL instruction. Well, now, in this time, today... :-) Split bombers are definetely popular, but not unstoppable. Regular dumb bombers have made there mark back on the hill... :-) I think it goes to show that Core Wars will go through stages, and no matter what we think, there is always a next step. Now, what about the Future of the Core War game? I would like to think that the instruction set would be increased to allow a more complex game, yet not lose the simplicity that we have now. It would be neat to see how the PCT (protect) instruction would be able to change the face of the game. It was most certainly a hit when SPL was introduce! I would love to see enough instructions in the game to allow more intelligent programs to fight. What is the problem with this philosophy? Well, more instructions do not dictate how smart a program can be. In order for a program to fight intelligently, we would need more powerful instructions, allowing us to probe the core and find where our enemy is. Will this upset the balance of the game? No one really knows. We will just have to try it as another Experimental Hill. Well, I have said enough for now. Maybe I should open another topic for discussion. What dictates an Intelligent program? What is needed for an intelligent program in our current standards? What is needed to make programs more intelligent in future standards? I am curious where this will lead us. I would be willing to set up an Experimental Hill myself to test some ideas of this as well... Scott Adkins sadkins@ohiou.edu Date: Monday, 4 May 1992 13:36:59 EDT From: Jeff Raven Message-ID: <92125.133700JAR129@psuvm.psu.edu> Subject: Redcode - A "Possessor" With the recent mentioning of "possessors", I was reminded of one of the first programs I wrote (about four weeks ago). It's a B-field scanner, which, upon finding a target, SPLits to it, waits a cycle, and then bombs it with a DAT. When I submitted it to the hill a while back, it made it to about 16th, and then fell off. It does particularly bad against some pit trappers, since it has a tendency to attack the pit, and paralyze itself (though the DAT bomb that was placed eventually frees it). ;redcode verbose ;name Overload 1.1 ;author Jeff Raven ; ;strategy - Version 1.1 ;strategy - Overload scans the core, and, upon finding another program, ;strategy - executes it. Not particularly aggressive, it tends to tie ;strategy - programs which make lots of copies. ; first EQU 0 ; First address checked by scanner step EQU 3044 ; Step size for the search bomb DAT #0 start ADD #step, locus locus JMZ start, first SPL @locus MOV 0, 0 MOV bomb, @locus JMP start END start From: JJJ101@psuvm.psu.edu Subject: Re: ICWS'88 too simple? Message-ID: <92125.095355JJJ101@psuvm.psu.edu> Date: 4 May 92 13:53:55 GMT [stuff deleted...] One idea that can be used in tournaments is to have several sets of parameters. For examples, each pair of opponents would fight as follows: 25 matches in a core size of 8000 with a 8000 process limit. 25 matches in a core size of 64000 with a 8000 process limit. 25 matches in a core size of 8000 with a 16 process limit. 25 matches in a core size of 64000 with a 16 process limit. -- James From: JJJ101@psuvm.psu.edu Subject: Re: ICWS'88 too simple? Message-ID: <92125.100057JJJ101@psuvm.psu.edu> Date: 4 May 92 14:00:56 GMT [Stuff deleted...] My bigest complaint with Redcode is the use of A and B fields. One thing I think could be added is a operand size parameter like the .b, .w, and .l suffixes used by 68k assembler. We could have something like: mov.a foo, bar ; move A field of foo to A field of bar mov.b foo, bar ; move B field of foo to B field of bar mov.x foo, bar ; move entire instruction at foo to bar. or we could go even farther and assign suffixes too each operand. For example: mov.x foo.b, bar.a ; move entire instruction whose effect address is ; the B field at foo to the address whose ea is the ; A field at bar. Above the suffux after the instruction indicates the size of the operation while the operand suffixes indicate how to obtain the effect address. James From: janm@Moskva.docs.uu.se (Jan Mattsson) Subject: Re: ICWS'88 too simple? Message-ID: Date: Mon, 4 May 1992 14:37:59 GMT kwhyte@math.uchicago.edu (Kevin Whyte) writes: >In article <1992May03.161810.25235@microsoft.com> t-jcisek@microsoft.com (Julius Cisek) writes: >>When I first read about CoreWar, I envisioned complex programs similar >>to ICE breakers in Neuromancer; a true code war. > I felt the same way when I started writing cw programs; I think >most of us did. However, it seems that you get used to it. That is >you come to realize that CW is not an AI project - not to put down the >idea, but there already are several such game : c-robots, et al. Is c-robots available for Unix? If it is could someone please suggest an anonymous FTP-site, archie doesn't give any hints. Thanks in advance. -- Jan Mattsson, CS Dept., Uppsala University, Sweden janm@bern.docs.uu.se or janm@minsk.docs.uu.se From: wms@iwarp.intel.com (William Shubert) Subject: Koth Weekly Standing Message-ID: <1992May4.200255.22426@iWarp.intel.com> Date: Mon, 4 May 1992 20:02:55 GMT On a side note, I made the performance mods that have been discussed here recently...it took 275 functions (11 instructions * 5 addr modes * 5 addr modes) but I wrote an automatic program generator that did a good job. Performance is now 3 or 4 times better (depending on the instructions getting executed) but code size increased by 55K. I think it's worth it. As soon as I clean it up some I'll be replacing KotH and probably doubling the number of fights per program. Here's the standard hill, as of now: # %W/ %L/ %T Name Score Age 1 56/ 33/ 12 Charon v3.0 (Echo) 178 4 2 54/ 40/ 6 Agony 2.1 169 51 3 54/ 41/ 5 Digital Justice 166 50 4 50/ 38/ 12 Enter Sandman 161 1 5 50/ 40/ 10 scissors88.2 159 116 6 50/ 43/ 6 Synch 6a 158 28 7 47/ 38/ 15 Sucker 155 115 8 39/ 27/ 35 Note Paper 151 63 9 41/ 37/ 22 Small 6 145 48 10 40/ 37/ 23 return of the living dead 143 166 11 37/ 32/ 31 multi mice 142 33 12 37/ 33/ 30 Armadillo 140 123 13 41/ 43/ 16 zipper 2 140 17 14 45/ 52/ 3 worm optima (Eat your heart out nandor) 138 157 15 36/ 38/ 26 dead end 135 32 16 34/ 35/ 30 Wasp 1.1 133 142 17 38/ 44/ 18 Whiplash 132 25 18 36/ 42/ 22 V3 129 9 19 38/ 48/ 14 Mutagen 2.0 129 43 20 24/ 41/ 35 Back Propagation 106 2 Charon, the #1 program as of now, has the following strategy: ;strategy creation date 4/11/92 ;strategy cmp scan, spl trap, clear core, etc. ;strategy v1.1 4/14/92 improved trap [reversed in v1.3] ;strategy v1.2 4/16/92 improved clear core routine ;strategy v1.3 4/21/92 original trap, optimal step, smaller code ;strategy v2.0 4/22/92 total code overhaul ;strategy mod 3 cmp scan with optimal step, new deadly trap ;strategy v3.0 5/3/92 integrated with Stefan Strack's Echo ;strategy Stefan very cleverly rewrote Charon to be much smaller. On the experimental hill most of the top programs are of the "crawl through memory, throwing JMPs to split-traps" type. # %W/ %L/ %T Name Score Age 1 55/ 24/ 21 Juggernaut 5.0 186 4 2 39/ 17/ 44 MiniShwing! [x] v1.2 161 33 3 44/ 33/ 22 Leaper-X 4.0 155 1 4 38/ 33/ 29 Crimson v1.1 142 18 5 27/ 14/ 58 Absolute 250 140 52 6 32/ 25/ 42 Bridge 139 25 7 34/ 36/ 29 UltraSlick 133 32 8 27/ 23/ 50 multi mice -x 132 51 9 31/ 30/ 39 Spreader 2.0 132 27 10 39/ 47/ 13 Shoggoth 1.1 132 54 11 33/ 37/ 30 Slick2.0 129 40 12 26/ 34/ 40 Stonewall 118 38 13 16/ 13/ 71 Eru (The Chosen) 118 22 14 21/ 27/ 52 Virus 115 50 15 30/ 45/ 26 Rail Road 1.0 114 17 16 12/ 13/ 75 Middle-Earth_1.4 112 8 17 12/ 13/ 74 Cyborg 1.0 111 37 18 32/ 54/ 14 Kobold Gun V2.0 109 45 19 28/ 47/ 24 Lurker 2.2 109 5 20 15/ 31/ 54 Artillery 100 41 Here's the ";strategy" for Juggernaut: ;strategy Copy to the next area, then jump there. Well, I guess that says it all. For entry instructions just send mail to "wms@iwarp.intel.com". -Bill (wms@iwarp.intel.com) From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: ICWS'88 too simple? Message-ID: <1992May4.205938.18490@vlsi.polymtl.ca> Date: Mon, 4 May 1992 20:59:38 GMT Is there a good reason why the opcode, the A field and the B field need to be in the same memory location ? Putting them in separate address might provide new challenge. We'd need to define opcode values (DAT = 0, MOV = 1, JMP = 2, ...) and weithre to maintain compatibility with old program by keeping all instruction 3 address long (jmp, spl could be only 2 'word' long). So warrior would have to worry about alignment (especially spl bomber), and could provide for weird optimisation by executing the same instruction on different alignment giving different result (Apple II ROM used that trick). Anothr though would be interrupt (with a trap when executing DAT ? if trap is itself DAT then die) and sub routine. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: t-jcisek@microsoft.com (Julius Cisek) Subject: Pre-decrement woes... Message-ID: <1992May05.001457.13823@microsoft.com> Date: 05 May 92 00:14:57 GMT I think that the ICWS'88 document is VERY concise as to the Pre-Decrement. The problem is that some of the original MARS authors were probably reading INTO the document, being proficient programmers who know how a CPU works. A real CPU DOES fetch the instruction into a register at the time an address is evaluated. However, it is more efficient for a simulator, which doesn't have a HARDWARE register, to evaluate both addresses and then worry about copying the entire instruction (since that isn't even used with many instructions...) and that's what the ICWS'88 document seems to state. Anyway, here are the relevent sections of the ICWS'88 document by Thomas Gettys. These sections are used without permission. Could someone please point out where it is said that an instruction pointed to by the evaluated address ought to be fetched at the time of address evaluation, or any ambiguity for that matter. [Page 5, 2nd column, paragraph 5] The less than (<) sign is used to introduce a pre-decrement indirect operand. The value of the operand is used as an offset, as it is with direct addressing. The B operand of the resulting memory location is fetched, decremented, and then restored. It is then used as an offset from the memory location from which it was fetched. The resulting memory location is the source and/or destination for the data to be used by the instruction, or else is the destination for branching instructions. [Page 9, 1st column, paragraph 4] First the A addressing mode is examined. If immediate, we are done. Otherwise, the program counter is added to the value in the A-field, yielding an absolute address. If direct, we are done. Otherwise, the B-field of this direct memory location is read into the A-Field. If pre-decrement is indicated, the value just read is decremented and written back to the memory location from whence it came. Finally, the program counter is added to the value of the A-Field. It is pretty obvious from the 2 paragraphs above that we don't even look at the location that the address points to. We are only EVALUATING the address itself. The reason why I'm stating all this is because in trying to make a super-fast simulator, an extra step is very costly to me. Also, the discrepency will continue and because of the already existing implementations that are using the incorrect (in my opinion) method, might be incorporated into a new ICWS standard. -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: Redcode - A "Possessor" Message-ID: <1992May5.002018.20232@vlsi.polymtl.ca> Date: 5 May 92 00:20:18 GMT This should only be useful to people who begin (like me). This code copy a child all over memory (but does not copy itself). Just put your code between the destA line and the end statement. You can start at init, or if you put the size of your code in the B operand of the first line of the child, you can start at motherA. Optimisation: no init for destA make all child contiguous, no fix for first opcode of child in B is 0. sizeA equ 4 distA equ 341 fixA equ 2 motherA mov Date: Tue, 5 May 1992 02:30:27 GMT Hello Everyone... I am trying to run Deluxe_v13 on DECstations 2100, 3100, 5000/25/200/240. I downloaded the source code from soda.berkeley.edu and I've tried setting up the makefile for both Xwindows ONLY and Xwindows/curses modes. In either case, as soon as the core window opens and it prints some textual information on the right side (doesn't last long enough to read), I get a segmentation fault. The curses only mode seems to work fine, however. If anyone has any ideas, or has experienced similar problems, PLEASE let me know. I am VERY interested in getting this program to run... I've wanted an Xwindows full-core-view simulator for a long time. I am running Motif, but I will try it with a couple other window managers as well. Thanks, Xeno (Gary Snethen) xeno@iastate.edu From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Warriors Message-ID: <58505@cup.portal.com> Date: 5 May 92 05:44:13 GMT Some more redcode source for the X-hill. The repeat macro is NOT supported by KotH, but it made the listing so much smaller, I thought I'd post it this way. The ;strategy says it all. --- cut --- ;redcode-x ;author Scott Nelson ;name Juggernaut ;strategy Copy to the next area, then jump there. ;kill Juggernaut s dat #0 d dat #0 count dat #25 start mov #0, s mov #106, d mov #25, count ;25*4 copies==100 locations copied jn mov >s, >d mov >s, >d mov >s, >d mov >s, >d djn jn, count jmp start+107 pit spl 1 spl -1 spl -2 jmp -2 .repeat 76 jmp pit .endrepeat end start --- end cut --- |+---------------------------------------------------------------+| You can not win a debate with an avalanche. <<>> From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Problems with Deluxe_v13 Message-ID: <1992May5.120017.17738@oucsace.cs.ohiou.edu> Date: 5 May 92 12:00:17 GMT In article xeno@iastate.edu (Gary L Snethen) writes: >Hello Everyone... > > I am trying to run Deluxe_v13 on DECstations 2100, 3100, 5000/25/200/240. >I downloaded the source code from soda.berkeley.edu and I've tried setting >up the makefile for both Xwindows ONLY and Xwindows/curses modes. In either >case, as soon as the core window opens and it prints some textual information >on the right side (doesn't last long enough to read), I get a segmentation >fault. The curses only mode seems to work fine, however. > Ok, I will post Deluxe_v13b to the incoming directory... This should have everthing fixed and if you have any problems, please let me know. I will have the other version on Soda removed... and replaced with this new version. Coming this summer: Version 2.0!!! :-) Equates will be fully supported, read and write limits will be allowed, you will be allowed to load programs at any location you desire, you may set the minimum distance between programs, full debugging will be allowed in the X-Window display, buttons are provided for you to pause, restart or even single-step the corewars display... and much much more! I will redo the directory structure of how the programs are stored and loaded, and provide many more programs along with the Deluxe package. I will do my best to keep the curses version as up-to-date as possible... but hey, you know X-Windows... Oh, yeah... I promise lots of documentation with Deluxe 2.0 as well. Don't expect too much with 1.3, I haven't had time to write that stuff yet. All of my most significant work has been done on Christmas break, Spring break, and soon to come Summer Vacation! :-) (Heck, the program was written last Christmas I think...) So please be patient. If anyone would like to make suggestions on additions/changes/corrections to the upcoming new versions, please send me mail... I have many suggestions now, which I will be most certainly using most of them. (and no... I am *not* changing the name of the program... you do it...) :-) Well, I hope I haven't forgotten anything... :-) Enjoy and happy happy joy joy keep them progams a 'rollin! (it isn't suppose to rhyme) Scott Adkins sadkins@ohiou.edu <---- Use this address... new improved short version! From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: A few questions Message-ID: <1992May5.080612@IASTATE.EDU> Date: Tue, 5 May 1992 13:06:12 GMT Some of these may be FAQs, but there are a few things I have not seen addressed so far on the board: 1) If one process of a multi-process warrior dies, does the game continue with only that process ending, or does the entire program loose? If the latter, is there any way to kill a process after it has been started? I had always assumed the first, but when I was trying a suicide type program on KoTH for the PC it killed the entire program. 2) Is DJN legal on the X-hill? There is nothing in any of the documentation I have seen for the X-hill, but at least one of the warriors posted here used it. 3) How exactly does the SLT command decide what is less than? Does it normalize the values before a compare? What do the following do: SLT #-10,#7995 SLT #7990,#-10 SLT #-10,#-20 etc. Thanks, *********************************************************************** * Warren Kurt * "Consequences shmonsequences, as long as I'm * * vonRoeschlaub * rich." -Daffy Duck * *********************************************************************** From: laajarinne@cc.helsinki.fi Subject: Digital Justice Message-ID: <1992May5.181640.1@cc.helsinki.fi> Date: 5 May 92 16:16:40 GMT Here is my warrior Digital Justice. It has done quite well on the Hill. It cmp-scans addresses near each other and spl-bombs their surroundings if it finds something. When this is done five times, the program changes spl-bombs to dat-bombs. ;redcode verbose ;name Digital Justice ;author Jukka Laajarinne ; vah dat #23, #23 gotcha slt #26, reg lipas jmp scan, #5 slt #-11, reg kuti jmp kill, #18 scan sub vah, reg reg cmp -800, -790 jmp gotcha jmp scan kill mov #18, kuti add #4, reg shoot mov ammo, Date: Tue, 5 May 1992 18:32:33 GMT I believe I achieved the smallest possible jumper. I don't know how original this is, but I thought it was pretty neat. I call the technique 'temporal loop unrolling' which consist of replacing loop by multiple tasks all executing the same code at the same time. I think it's only useful for small program since it execute ALL instruction multiple time. Here it is: ;redcode ;name MinJump ;author Pierre Dak Baillargeon size equ 3 dist equ -217 start spl split, 0 ; make 3 tasks jmp init, 0 split spl 1, 0 init mov #size, init ; reset size mov Date: Tue, 5 May 1992 19:34:56 GMT I've been reading this newsgroup for a little while, and noticed lots of news dedicated to KotH. Is KotH 24hrs a day, 365 days a year? Or is a tournament that happens every now and then? I tried mailing a warrior to : wms@iwarp.intel.com, however it bounced back (didn't recognize the address). However, @warp.intel.com was recognized... is this the real address? Could someone help me out please? Thanks in advance. -- []=========================================================================[] || The Unknown Author | <{(--==o==--)}> | "Mistrust Authority - || || h309@midway.uchicago.edu | ///||| O |||\\\ | Promote Decentralization" || []=========================================================================[] From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: A few questions Message-ID: <58585@cup.portal.com> Date: Tue, 5 May 92 21:11:34 PDT >Some of these may be FAQs, but there are a few things I have not seen addres >so far on the board: > >1) If one process of a multi-process warrior dies, does the game continue w >only that process ending, or does the entire program loose? If the latter, >there any way to kill a process after it has been started? > I had always assumed the first, but when I was trying a suicide type progr >on KoTH for the PC it killed the entire program. Your first assumtion is correct, only that one process dies, and the game should continue. >2) Is DJN legal on the X-hill? There is nothing in any of the documentation >have seen for the X-hill, but at least one of the warriors posted here used All instructions (including DJN #1, #2) are legal on the X-hill. >3) How exactly does the SLT command decide what is less than? Does it norma >the values before a compare? What do the following do: > SLT #-10,#7995 > SLT #7990,#-10 > SLT #-10,#-20 > etc. There are no negative numbers in REDCODE. When a warrior is loaded, all numbers are mod'ed with .coresize (on KotH -10 becomes 7990). I.e. SLT #-10, #7995 --> SLT #7990, #7995 ;skip SLT #7990,#-10 --> SLT #7990, #7990 ;don't skip (Equal is not less than) SLT #-10,#-20 --> SLT #7990, #7980 ;don't skip Note that these statement will do different things with different .coresize, so be carefull! |+--------------------------------------------------------------------+| There are no bad questions, only bad answers. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Smallest jumper ? Message-ID: <58593@cup.portal.com> Date: Wed, 6 May 92 01:43:44 PDT >5/5/92 11:32 30/1006 dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) > I believe I achieved the smallest possible jumper. I don't know how >original this is, but I thought it was pretty neat. I call the technique >'temporal loop unrolling' which consist of replacing loop by multiple tasks >all executing the same code at the same time. I think it's only useful for >small program since it execute ALL instruction multiple time. I called it 'symbiosis'. It is a VERY useful concept, Molerat (and Note Paper) used it as the core of their copy routines. A minor variant can also be useful in other programs consider 'symbiotic dwarf': spl 0 mov bomb, @bomb add #28, bomb jmp -2 At first glance one might say "so what?", but consider four of these in core at once. (or how about a routine that hurls them out?) Normally having more than one copy is a bad idea, since one SPL 0 hit in any copy slows down all the copies. But the symbiots might not even notice it! By the way, it isn't really the smallest jumper (that title belongs to IMP), and it could be argued (although I wouldn't) that it isn't a jumper since it doesn't move forward a constant amount, or copy the SPL instructions. Also depending on what you mean by 'size' this warrior might be smaller (though personally I feel they are both the same size) ;name Lichen 1988 start spl 1 ; make 3 tasks mov -1, 0 ; the real code source mov #3, 0 ; init. mov >> From: ajpierce@med.unc.edu (Andrew Pierce) Subject: ClaMP Message-ID: <1992May6.141003.9324@samba.oit.unc.edu> Date: 6 May 92 14:10:03 GMT Here is the source to ClaMP which is currently hovering around number 1 or 2 on KotH. It, like the other top 4 programs on the hill currently, is a cmp scanner. In essence, ClaMP is Synch without the intelligence, and with Stefan Strack's incorporated slt idea, which saves one instruction. The core clearing routine is particularly effective. I think that ClaMP is very similar to Agony, except that the different core clear gives ClaMP an edge. As for corewars having hit its limit, I still have at least one more idea to try to get off the ground. :-) The issue of "why post your best programs?" came up. I do so in order to evolve the current state-of-the-art in corewars programming. I think that if you were to fight the current 20 on KotH against previous years' tournaments entries in a sort of team competition, the previous years would get massacred. This is a direct result (IMO) of the feedback testing mechanism of KotH, and of idea sharing from posting programs. Unfortunately, I think that we are also heading for an endpoint in corewars as it stands. I predict that within 6 months, there will be nothing left to do in the current implementation of corewars. ;redcode verbose ;name ClaMP ;author Andy Pierce ;strategy small cmp scanner ret add offset,start start cmp -50,-1 slt #65,start count djn ret,#2000 hit mov bomb2,@start mov bomb1, Date: Wed, 6 May 1992 14:33:31 GMT In article <58585@cup.portal.com>, ScottNelson@cup.portal.com (Scott - Nelson) writes: > >2) Is DJN legal on the X-hill? There is nothing in any of the documentation > >have seen for the X-hill, but at least one of the warriors posted here used > > All instructions (including DJN #1, #2) are legal on the X-hill. An example of what not to do: Try and remember which functions are '88 standard without checking the manual. I had confused DJN with DJZ (which is non-'88) > >3) How exactly does the SLT command decide what is less than? Does it norma > >the values before a compare? What do the following do: > > SLT #-10,#7995 > > SLT #7990,#-10 > > SLT #-10,#-20 > > etc. > There are no negative numbers in REDCODE. When a warrior is loaded, all > numbers are mod'ed with .coresize (on KotH -10 becomes 7990). I.e. > SLT #-10, #7995 --> SLT #7990, #7995 ;skip > SLT #7990,#-10 --> SLT #7990, #7990 ;don't skip (Equal is not less than) > SLT #-10,#-20 --> SLT #7990, #7980 ;don't skip > Note that these statement will do different things with different .coresize, > so be carefull! Alot of experimenting last night had led me to similar conclusions. Of course, it is nice to have it confirmed. *********************************************************************** * Warren Kurt * "I believe there is an inteligence to the universe * * vonRoeschlaub * with the possible exception of certain parts of * * kv07@iastate * New Jersey" -Woody Allen * *********************************************************************** From: wms@iwarp.intel.com (William Shubert) Subject: Re: Smallest jumper ? Message-ID: <1992May6.163944.18854@iWarp.intel.com> Date: 6 May 92 16:39:44 GMT While this "split-for-faster-copy" is being discussed, one of my programs on the experimental hill uses this technique and works pretty well. Here it is: ;name Shoggoth 1.1 ;author Bill Shubert ;strategy Crawl through memory, sweeping aside everything in the way. ;strategy V1.1 - Faster & smaller with a bigger attack range. wdist equ 250 procs equ 16 cpnum equ 11 st spl st1 st1 spl st2 st2 spl st3 st3 spl st4 st4 jmp shog from dat #0 to dat #from shog mov #from-to,to mov to,from,>to jmp (from-procs*cpnum)+(shog-from) end st As you can see, it clears out memory very fast by executing each of the "mov to,from,>to" instruction, and jumps to the new copy. -Bill (wms@iwarp.intel.com) From: t-jcisek@microsoft.com (Julius Cisek) Subject: Simplicity, originality, the future, KotH, and analogies... Message-ID: <1992May07.020106.5234@microsoft.com> Date: 07 May 92 02:01:06 GMT I agree with most of what Scott N. said earlier. But I never said that new programs wouldn't evolve. I just said that they wouldn't be very original. I really believe that we are approaching a limit to ideas (REALLY original ones, that is)... I find creative originality much more rewarding than streamlining an already existing idea. The only warrior that I was really proud of was PitTrap and it turned out it wasn't NEARLY a new idea. There is still room for bright new ideas, but very, very little. We're going to mostly see hybrids and improvements on old ideas (now that Synch 6a was knocked off the hill, what original programs are left??? I certainly don't claim Charon to be anything mind-bogglingly new). I think KotH is responsible for a highly accelerated evolution in CoreWar. Also, it goes through stages. Right now cmp scanners seem to be the lords of the hill, but a simple submission like Mirrormore (by Jeff Raven) and Double Talon (mine) can shake up the hill. The fact that nandor sieben's multi mice and Scott Nelson's Molrat make such often callings to the hill (and stay alive for a few days before being knocked off) says to me that KotH is in a sort of cycle. Pretty soon it'll be prime time for Gnats and Dwarves (which fair poorly vs. multiplying programs, but very nicely against scanners and bombers) which in turn will bring back the multiplying programs, which will bring back the scanners, etc. Sure, each cycle brings better programs, but nothing really new. Anyway, enough about that. I, for one, am just thinking out loud. I love the present CoreWars (although it is taking a toll on my sleeping habits). I just want to see these issues addressed so that the next CoreWar standard allows us some wild creativity and push CoreWar forward. It is a very common thing to use analogies to get your point across, however, it is my opinion that you're only confusing the issue. Analogies are only that, and shouldn't be used as a basis for argument or as fact. -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: Pre-decrement woes... Message-ID: <167DF148CC.DURHAM@ricevm1.rice.edu> Date: 7 May 92 04:22:45 GMT In article <1992May05.001457.13823@microsoft.com> t-jcisek@microsoft.com (Julius Cisek) writes: >A real CPU DOES fetch the instruction into a register at the time an address >is evaluated. And so does MARS. From ICWS'88, page 9, first paragraph under the heading "Effective Address Calculation": "After the instruction to be executed has been fetched" > However, it is more efficient for a simulator, which doesn't >have a HARDWARE register, to evaluate both addresses and then worry about >copying the entire instruction MARS is supposed to be mimicking hardware. The extent to which this has been emphasized has varied over the years, but it is a generally recognized rule-of-thumb. If you are emulating an 8088, you can't change the results of address evaluation just because you are writing a simulator. The difference here is we do not have a piece of silicon as the final arbiter of what is and what is not compatible (or correct). Instead, we have the opportunity to decide. > Could someone please >point out where it is said that an instruction pointed to by the evaluated >address ought to be fetched at the time of address evaluation, or any >ambiguity for that matter. I will try. The ambiguity began in ICWS'86 and carried over into ICWS'88. ICWS'88 is by no means complete in and of itself. Most everything which you may consider being "read into" ICWS'88 has a basis in ICWS'86. The two paragraphs you quote about pre-decrement mode are not the crucial paragraphs. The problem is in the discussion of the Redcode instruction set beginning at the bottom of page 5. From the discussion of MOV on page 8: "Otherwise the contents of the entire memory location specified by the A operand is (sic) moved to the memory location specified by the B operand." The controversy is about WHEN. The contents when? The argument goes that to completely evaluate the A operand, one must copy the contents of the entire memory location specified by the A operand to an internal register BEFORE evaluating the B operand (which, incidentally, will also copy an entire memory location to an internal register - useful for CMP). If there were no such thing as pre-decrement mode, whether you copied the instruction before or after evaluating the B operand would not matter. Both methods would have equivalent results. Note that the heading of the section on page 9 reads "Effective ADDRESS CALCULATION", not "Effective OPERAND EVALUATION". There is a difference. Does operand evaluation occur during address calculation or after? ICWS'88 does not really say. Does ICWS'88 imply "after"? I would have to say yes. In fact, I know that is what Mr. Gettys was trying to state explicitly but failed to do so. Does ICWS'88 permit "during"? Again, I would have to say yes. One can not adhere to a strict reading of ICWS'88 without stumbling across inconsistencies. For instance, again from page 9: "First the A addressing mode is examined. If immediate, we are done. Otherwise, the program counter is added to the value in the A-field." If we really add the program counter TO the A-field, we change core. We all know this is not what is meant. What is meant is: "The address mode of the A-operand in the instruction register (A-mode) is examined. If the A-mode is immediate, copy the pointer counter into the internal A-address register and copy the value of the A-operand in the instruction register (A-field) into the internal A-value register. Otherwise, copy the sum of the program counter and the A-field into the internal A-value register." or, if you want to work from core memory instead of internal registers: "The address mode of the A-operand in core memory (A-mode) is examined. If the A-mode is immediate, the effective A-address is equal to the pointer counter. Otherwise, the effective A-address is the sum of the program counter and the value of the A-operand in core memory." Note that the pointer counter is an internal register and "the effective A-address" has to be stored somewhere. ICWS'88 frequently uses the word "fetch" meaning "copy from core". You cannot get completely away from registers. >The reason why I'm stating all this is because in trying to make a super-fast >simulator, an extra step is very costly to me. Also, the discrepency will >continue and because of the already existing implementations that are using >the incorrect (in my opinion) method, might be incorporated into a new ICWS >standard. There are many changes which could be made to the standard which would improve efficiency but change the game. Removing pre-decrement mode is one example. I think most people will agree that game-play should come before efficiency in writing a new ICWS standard. This issue of operand evaluation does not substantially alter game play, so efficiency may be the deciding factor. On the other hand, other factors may be considered more important as well. How to solve this dilemma? Here are some possible solutions: 1. Market forces. Right now, King of the Hill controls Core War. Bill Shubert can do what he wants and we all would have to follow because everybody writes their code for KotH! (All the entries to the Valentine's Day Tournament begin with ";redcode". I have to strip them all, otherwise Bill never sees the results.) If someone else starts a Core War server with different and better rules, then perhaps KotH would fall by the wayside. 2. Edict. Jon Newman (Director of the ICWS) could issue a statement declaring the "One True Interpretation of ICWS'88". 3. New Standard. This is the one I favor and am working toward. Which interpretation is adopted for the standard is not as important as writing a standard that is as unambiguous as possible. Incidentally, version 4.1 of The MADgic Core now supports both interpretations. Mark A. Durham MAD From: kwhyte@arthur.uchicago.edu (Kevin Whyte) Subject: C robots Message-ID: <1992May7.060612.13954@midway.uchicago.edu> Date: 7 May 92 06:06:12 GMT In a recent discussion on the future of corewar I made a passing reference to C-robots. Many people have asked where they can find it. Would someone who knows kindly post this information. Kevin kwhyte@math.uchicago.edu From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: C robots Message-ID: <1992May7.083905@IASTATE.EDU> Date: Thu, 7 May 1992 13:39:05 GMT I have a copy of its sister program P-robots lying about somewhere if people are interested. *********************************************************************** * Warren Kurt * "Consequences shmonsequences, as long as I'm * * vonRoeschlaub * rich." -Daffy Duck * *********************************************************************** From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: ICWS'88 too simple? Message-ID: <1992May7.214339.25407@samba.oit.unc.edu> Date: 7 May 92 21:43:39 GMT Scott Atkins writes: >Well, I have said enough for now. Maybe I should open another topic for >discussion. What dictates an Intelligent program? What is needed for >an intelligent program in our current standards? What is needed to make >programs more intelligent in future standards? I can offer an opinion on what dictates an Intelligent program. To me, an intelligent program is one which responds dynamically to its environment, rather than passively following a set course of action, regardless of the actions of other programs which may be in the core. The archetypal non-intelligent programs are Imp and Dwarf and bombers in general. Examples of semi-intelligent programs would be ClaMP and Sargent and scanners in general which bomb mindlessly when a given condition is fulfulled. Examples of intelligent programs are Synch, which decides which type of attack to carry out depending upon what it finds in the core, and the 1990 tourney program Gato which checks a barrier to see if a bomber is coming and then copies itself out of the way. Doubtless there are many other example of all three types of program. I too would like to see intelligence given a bit of a boost. I like the idea of a cache of memory locations that someone (I forget who) recently posted. Another possibility is a sort of modified x-KotH. In this, instead of having restrictions on how far away one can write to, how about instructions which access memory outside the given radius take twice as long to execute? That way, searchers and bombers likewise are slowed down when just scanning/bombing the core, but calculations and logic which happen locally are given a premium. -Andy ajpierce@med.unc.edu From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: Super Imp's first battle! Message-ID: <1992May8.040340.2262@usenet.ins.cwru.edu> Date: Fri, 8 May 92 04:03:40 GMT My first program I wrote is called Super Imp. It's basicly an IMP, but altered somewhat to make it Imp-stomper-proof. I submitted it to the hill for the heck of it... I was completely amazed when Super imp not only tied a number of the top 10, but even beat some!! I didn't think it was possible for Super Imp to win... Well, anyways, here's my question... What's one of the best single process kill routines? I'd like to team SuperImp up with something, tosee if I generate more wins. I'd like any advice anyone wants to offer, since I'm a complete newbie to CoreWars... Thanks! My overall score was 83 or so... SuperImp's best battles were: The fact that I won at all shows I don't understand IMP warfare completely yet... ----------- Program "ClaMP" (length 13) by "Andy Pierce" (contact address "ajpierce@med.unc.edu"): Super Imp 1.0 wins: 14 ClaMP wins: 30 Ties: 6 Program "worm optima (Eat your heart out nandor)" (length 100) by "Campbell Fraser" (contact address "fraserc@dcs.glasgow.ac.uk"): Super Imp 1.0 wins: 29 worm optima (Eat your heart out nandor) wins: 21 Ties: 0 Program "Wasp 1.1" (length 6) by "Bill Shubert" (contact address "wms"): Super Imp 1.0 wins: 38 Wasp 1.1 wins: 12 Ties: 0 Program "Bomber" (length 6) by "Jeff" (contact address "jpepper@cs.tamu.edu"): Super Imp 1.0 wins: 30 Bomber wins: 0 Ties: 20 Program "Double Talon v2.2" (length 48) by "J.Cisek" (contact address "t-jcisek@microsoft.com"): Super Imp 1.0 wins: 0 Double Talon v2.2 wins: 6 Ties: 44 Program "Super Imp 1.0" (length 3) by "Jonathan Roy" (contact address "as666@cwns1.ins.cwru.edu"): ;strategy A glorified imp. Can tie most multi-process programs like ;strategy Needs to be implemented with a good kill routine. ;strategy Note: "Imp stompers" rarely affect Supra Imp. ;strategy (This submission is simply to see if I can tie CLamp.) Super Imp 1.0 wins: 0 Ties: 50 -- ||| Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu ||| -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet -- / | \ "...make him want to change his name,take him to the cleaners, devastate him, wipe him out, humiliate him." -CHESS GEnie: J.ROY18 From: JAR129@psuvm.psu.edu (Jeff Raven) Subject: Leaper-X 4.0 Message-ID: <92129.002043JAR129@psuvm.psu.edu> Date: 8 May 92 04:20:43 GMT Well, since I'll be heading home for the summer in a matter of days, I figure it's about time I posted the code to Leaper-X. It has a rather interesting history, which I'll spare you, and just get to the code. True to it's name, it leaps through the core, bombing each time it jumps. The unusual thing about the bombing - and what probably gives it an edge over programs like it - is that, instead of bombing 250 locations on one side, it bombs 125 locations on each side. Although slightly less effective at taking down a charging Imp, it does protect Leaper-X on both sides simultaneously, and it will bomb its 250 locations slightly faster than others because its loop is a little more unrolled (2/3 bombs per instruction compared to the usual 1/2). As for its bombing mechanism - it will bomb 31 times with SPLs (just about hitting every location), and then will switch to DATs. It's done well (better than anything else I've written), usually staying between third and sixth. ;redcode-x verbose ;kill Leaper-X 3.0 ;name Leaper-X 4.0 ;author Jeff Raven ; ;strategy - Leaps through memory, bombing as it goes. The bombing routine ;strategy - has been changed - and hopefully improved. It now uses a more ;strategy - efficient bombing pattern, which should almost halve the time ;strategy - it takes to clear the core. ; lines EQU 14 limit EQU 250 reach EQU 125 upper EQU reach lower EQU -reach leap EQU limit - (storage - copy) time EQU 32 low DAT #0 start MOV #lower, low MOV #upper, high DJN splat, slow MOV #0, point splat MOV @point, >low MOV @point, @high DJN splat, high MOV #lines, low MOV #leap, storage copy MOV @low, Date: 08 May 92 10:43:31 GMT In article <1992May6.141003.9324@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: > Here is the source to ClaMP which is currently hovering around number 1 >or 2 on KotH. > I think that ClaMP is very similar to Agony, except that the different >core clear gives ClaMP an edge. Actually, ClaMP is almost exactly Charon 3.0 (Echo) just as Stefan and I suspected... Bombing with SPL 0, DJN -1 is essentially the same as bombing with SPL 0, JMP -1 (only one process will drop out every 8000 loops) The clear routine is a minor improvement. The definitive edge (and only REAL difference) over Charon is the fact that ClaMP is off-axis. Charon off-axis versions which both Stefan and I tried were failures. My hat's off to you, guy... Anyway, see for yourself, as here's Charon v3.0 (Echo): -- ;redcode verbose ;name Charon v3.0 (Echo) ;author J.Cisek & S.Strack (alphabetical order :) ;strategy creation date 4/11/92 ;strategy cmp scan, spl trap, clear core, etc. ;strategy v3.0 5/3/92 integrated with Stefan Strack's Echo ;strategy Stefan very cleverly rewrote Charon to be much smaller. STEP equ 1581 ;step value START equ search+STEP-3473 ;hit self eventually HALF equ 4000 ;set this to half the core search add steps, target ;turns into JMP -1, 0 eventually target cmp START, START+HALF ;axis-scan slt #switch-target+2, target ;don't hit self jmp search ;search at new location mov jump, @target ;set trap mov split, ;redcode verbose >;name ClaMP >;author Andy Pierce >;strategy small cmp scanner > >ret add offset,start >start cmp -50,-1 > slt #65,start >count djn ret,#2000 >hit mov bomb2,@start > mov bomb1, add next,start > jmn start,count >bomb1 spl 0,0 > mov 2,<1 >bomb2 djn -1,#-3 >next dat #-49,#-48 >offset dat #-98,#-98 If the above is not proof that there simply isn't much room left for originality, I don't know what is. -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: wangs@sol.engr.umbc.edu (Shawe-Shiuan Wang) Subject: What happen to IGS? Message-ID: <1992May8.140622.12387@umbc3.umbc.edu> Date: Fri, 8 May 1992 14:06:22 GMT I am not able to connect with lacerta.unm.edu 6969 from last Tuesday. Does anyone know what happened there? Does 'IGS' dismiss forever? Thank you for any information about 'IGS'. Jeffrey Wang From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: Super Imp's first battle! Message-ID: <1992May8.092656@IASTATE.EDU> Date: Fri, 8 May 1992 14:26:56 GMT This is similar to what happened when I submitted a cute program called Hide 'n' Seek to the experimental hill. Hide 'n' Seek jumped through the core, leaving behind a JMP 0 instruction executing constantly. The idea was mostly to test the waters for B-field scanners (who would tie such a program) for a system which I was intending to submit that would confound this type of strategy. The result was a suprising score of 83! Note that there were some programs this completely non-agressive program beat as many as 10 times (thats 20%!). I am unclear on how this was managed, but I think it may hav disrupted some program while jumping, and then managed to hide out while the enemy slowly died. The point I am trying to make is that sometimes a program that acts in a suprising manner it can be as devistating as a planned attack. *********************************************************************** * Warren Kurt * "Consequences shmonsequences, as long as I'm * * vonRoeschlaub * rich." -Daffy Duck * *********************************************************************** From: ajpierce@med.unc.edu (Andrew Pierce) Subject: cyclical KotH Message-ID: <1992May8.171144.13135@samba.oit.unc.edu> Date: Fri, 8 May 1992 17:11:44 GMT It seems to me that there are 3 fundamentally different types of successful programs on KotH. 1) scanners which bomb with spl: these will kill all large programs 2) small dwarfs (2-4 instructions): these will kill scanners 3) self multipliers: these will kill small dwarfs Can anyone think of another basic class of warrior for the above list? As it stands now, KotH is overpopulated with scanners. Submit those dwarfs! -Andy ajpierce@med.unc.edu From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: Re: Super Imp's first battle! Message-ID: <1992May8.192224.2225@usenet.ins.cwru.edu> Date: Fri, 8 May 92 19:22:24 GMT Program "Super Imp 1.0" (length 3) Your overall score: 83.523810 Program "ImpLance 0.2b" (length 2) Your overall score: 60.571429 Program "ImpLance 0.3b" (length 3) Your overall score: 47.333333 Program "ImpLance 0.4b" (length 4) Your overall score: 40.666667 Program "ImpLance 0.5b" (length 5) Your overall score: 38.095238 Program "ImpLance 0.10b" (length 10) Your overall score: 28.190476 Program "ImpLance 0.20b" (length 20) Your overall score: 21.047619 Here's my latest test results. Lance is simply a IMP 0,X type thig where X is the program length. Not surprisingly, the smaller lances do better. Next....SuperLance 1.0! I'm going to try to merge SuperImp and ImpLance 0.2b and see what happens! I've just submitted a SuperXmp for the -x hill. Should do well... ||| Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu ||| -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet -- / | \ "...make him want to change his name,take him to the cleaners, devastate him, wipe him out, humiliate him." -CHESS GEnie: J.ROY18 From: nicholso@pioneer.arc.nasa.gov (Melvin H. Nicholson YBH) Subject: Re: Smallest jumper ? Message-ID: <1992May8.193937.3263@riacs.edu> Date: 8 May 92 19:39:37 GMT In article <1992May5.183233.250@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: > I believe I achieved the smallest possible jumper. I don't know how >original this is, but I thought it was pretty neat. I call the technique >'temporal loop unrolling' which consist of replacing loop by multiple tasks >all executing the same code at the same time. I think it's only useful for >small program since it execute ALL instruction multiple time. > >Here it is: > >;redcode >;name MinJump >;author Pierre Dak Baillargeon > >size equ 3 >dist equ -217 > >start spl split, 0 ; make 3 tasks > jmp init, 0 >split spl 1, 0 >init mov #size, init ; reset size I have a question about the above line. Doesn't it mean "replace this very line with a dat 3?" If so, why don't the second two threads choke on it? Also, in the new code, would the threads then be unable to function when they reach the new loop? Why not? > mov dest jmp @dest, #dist ; jump to new code > > end start > From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: Smallest jumper ? Message-ID: <1992May8.172524@IASTATE.EDU> Date: Fri, 8 May 1992 22:25:24 GMT In article <1992May8.193937.3263@riacs.edu>, nicholso@pioneer.arc.nasa.gov (Melvin H. Nicholson YBH) writes: > In article <1992May5.183233.250@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: > >;redcode > >;name MinJump > >;author Pierre Dak Baillargeon > > > >size equ 3 > >dist equ -217 > > > >start spl split, 0 ; make 3 tasks > > jmp init, 0 > >split spl 1, 0 > >init mov #size, init ; reset size > > I have a question about the above line. Doesn't it mean "replace this > very line with a dat 3?" If so, why don't the second two threads choke on > it? Also, in the new code, would the threads then be unable to function > when they reach the new loop? Why not? init mov #size, init will move the number 3 to the bfield, so first process will see mov #3, 0, but the next two processes will execute mov #3, 3 which will turn the location right after the end of the program into a dat 0 3. > > mov >dest jmp @dest, #dist ; jump to new code > > > > end start From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Armadillo Message-ID: <1992May8.224945.8187@vuse.vanderbilt.edu> Date: Fri, 8 May 1992 22:49:45 GMT [after a week of abstinence from r.g.cw due to a disk crash, it's good to be back!] With the recent discussion on self-splitting bombers, fast copiers etc., this is a good time to post "Armadillo". This is a dumb SPL 0 bomber/core clearer that's been on the hill for a while, washing to the top whenever a bunch of small DAT-killers (such as recently "dwarf optima" and "shark optima" by Nandor Sieben) enter the hill. It's currently #1 (as I am writing this; not necessarily when you read this :-) ). Execution of SPL 0 confers some resistance to DAT bombs. "Armadillo" starts clearing the core after bombing approx. every 3rd address with SPL 0 by overwriting the "jmp" instruction. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ;redcode verbose ;name Armadillo ;kill Armadillo ;author Stefan Strack ;strategy Not very deadly, but tough to kill: a mod-3.2 SPL-bomber ;strategy Submitted: @date@ ;2891 2947 bomb spl 0 loop add #3039,ptr ptr mov bomb,81 jmp loop mov 1, <-1 end bomb From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Sucker Message-ID: <1992May8.225658.8354@vuse.vanderbilt.edu> Date: Fri, 8 May 1992 22:56:58 GMT Another one of my old-timers on the hill, "Sucker" is your basic pattern- bombing vampire (like PitTrap, Scissors88, and Leech). Similar to "Armadillo" (previous post), the bomb-loop splits itself. This makes the the program more robust and allows very dense mod-1 bombing. Eventually, "Sucker" abducts about half of its processes into the slave pit to help clear the core. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ;redcode verbose ;name Sucker ;author Stefan Strack ;strategy Robust pattern-bombing vampire ;strategy Submitted: @date@ mark equ start+2+785 start spl 0 loop sub dist, scanptr mov scanptr,@scanptr jmp loop dat #0 ;1 dat #0 dat #0 dat #0 dat #0 ;2 dat #0 dat #0 dat #0 dat #0 ;3 dat #0 dat #0 dat #0 dat #0 ;4 dat #0 dat #0 dat #0 dat #0 ;5 dat #0 dat #0 dat #0 dat #0 ;6 dat #0 dat #0 dat #0 dat #0 ;7 dat #0 dat #0 dat #0 dat #0 ;8 dat #0 dat #0 dat #0 dat #0 ;9 dat #0 dat #0 dat #0 dat #0 ;10 dat #0 dat #0 dat #0 dat #0 ;1 dat #0 dat #0 dat #0 dat #0 ;2 dat #0 dat #0 dat #0 dat #0 ;3 dat #0 dat #0 dat #0 dat #0 ;4 dat #0 dat #0 dat #0 dat #0 ;5 dat #0 dat #0 dat #0 dat #0 ;6 dat #0 dat #0 dat #0 dat #0 ;7 dat #0 dat #0 dat #0 dat #0 ;8 dat #0 dat #0 dat #0 dat #0 ;9 dat #0 dat #0 dat #0 dat #0 ;10 dat #0 dat #0 dat #0 dat #0 ;1 dat #0 dat #0 dat #0 dat #0 ;2 dat #0 dat #0 dat #0 dat #0 ;3 scanptr jmp dist-mark,mark dist mov 107, <-107 spl 0 jmp dist end start From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: Version 4.1 of The MADgic Core Message-ID: <167E1119C9.DURHAM@ricevm1.rice.edu> Date: Sat, 9 May 1992 01:02:12 GMT I forgot to mention, both in the post here and the MADgic41.readme file on soda, that the new version 4.1 ASR can handle underscores and colons. Since both of these occur somewhat frequently (at least from my tournament experience), this is an important addition to the system. I regret not mentioning it earlier. To anyone using version 4.0, I can not overstate how much better is version 4.1. There probably will not be another release until 5.0. Version 5.0 will not be out until a new standard proposal (which 5.0 will support) has been completed. Mark A. Durham MAD From: t-jcisek@microsoft.com (Julius Cisek) Subject: Re: Pre-decrement woes... Message-ID: <1992May09.011455.18034@microsoft.com> Date: 09 May 92 01:14:55 GMT [I'm going to try to edit out as much of Mark's message as possible. I'm doing this only to keep the message relatively small, I wish some of you would do the same. Several people here even include other people's signatures. A little editing never hurts and it certainly saves bandwidth.] In article <167DF148CC.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >In article <1992May05.001457.13823@microsoft.com> >t-jcisek@microsoft.com (Julius Cisek) writes: > >>A real CPU DOES fetch the instruction into a register at the time an address >>is evaluated. > >And so does MARS. From ICWS'88, page 9, first paragraph under the heading >"Effective Address Calculation": > > "After the instruction to be executed has been fetched" Right, but this applies to the executing instruction, not the instruction at the evaluated address. So what happens if the address evaluation effects the current PC location? Do you then have to do the modification to the register and then write it back out? That still seems inefficient. >MARS is supposed to be mimicking hardware. >[...] The >difference here is we do not have a piece of silicon as the final arbiter >of what is and what is not compatible (or correct). Instead, we have the >opportunity to decide. Gotcha. However, the decision SHOULD have been for efficiency. >[...] The ambiguity began in ICWS'86 and carried over into ICWS'88. >ICWS'88 is by no means complete in and of itself. Most everything which >you may consider being "read into" ICWS'88 has a basis in ICWS'86. I felt that ICWS'88 covered everything neatly and completely. (I have read ICWS'86 as well...) >From the discussion of MOV on page 8: > > "Otherwise the contents of the entire memory location specified > by the A operand is (sic) moved to the memory location specified > by the B operand." > >The controversy is about WHEN. The contents when? The argument goes >that to completely evaluate the A operand, one must copy the contents >of the entire memory location specified by the A operand to an internal >register BEFORE evaluating the B operand (which, incidentally, will >also copy an entire memory location to an internal register - useful >for CMP). This is what I mean. What is the point of copying the memory out to a register? We should work COMPLETELY in memory... It would make the simulators quite a bit more efficient. But I'm starting to realize that efficiency wasn't a necessary thing when the standards were made. I guess no one considered something like KotH possible. >Note that the heading of the section on page 9 reads "Effective ADDRESS >CALCULATION", not "Effective OPERAND EVALUATION". There is a difference. >Does operand evaluation occur during address calculation or after? >ICWS'88 does not really say. I thought it was pretty clear that address calculation INCLUDES operand evaluation. This would be obvious if no outside registers were used. >[..excellent interpretations of ICWS'88 texts..] >[...] I think most people will agree that game-play should come before >efficiency in writing a new ICWS standard. In this case, the efficiency issue *IS* part of game play... 2 games per pair of warriors tournaments don't show anything except the role of randomness. Even KotH, with 50 games between each pair of warriors can be criticized for it's statistical fluctuations. If this had been realized sooner, efficiency may have been made a primary priority of the standards. I would like to see this happen in the future standard. >How to solve this dilemma? Here are some possible solutions: > > 1. Market forces. Right now, King of the Hill controls Core War. Agreed. But KotH used to support my interpretation, now it supports the other... > 2. Edict. Jon Newman (Director of the ICWS) could issue a statement > declaring the "One True Interpretation of ICWS'88". He's probably too busy right now, he's in the SYStems building... :) > 3. New Standard. This is the one I favor and am working toward. Which > interpretation is adopted for the standard is not as important as > writing a standard that is as unambiguous as possible. And as efficient as possible, right :)? We don't need to emulate a real machine. In a case where something can be done either more like real hardware and something more efficient, the more efficient should ALWAYS be chosen. >Incidentally, version 4.1 of The MADgic Core now supports both >interpretations. Cool. You know, I can never get access to soda, did you put it anywhere else? >Mark A. Durham >MAD -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: cyclical KotH Message-ID: <1992May9.070845.16602@vlsi.polymtl.ca> Date: 9 May 92 07:08:45 GMT ajpierce@med.unc.edu (Andrew Pierce) writes: : : It seems to me that there are 3 fundamentally different types of : successful programs on KotH. : 1) scanners which bomb with spl: these will kill all large programs : 2) small dwarfs (2-4 instructions): these will kill scanners : 3) self multipliers: these will kill small dwarfs : : Can anyone think of another basic class of warrior for the above list? : As it stands now, KotH is overpopulated with scanners. Submit those : dwarfs! : -Andy : ajpierce@med.unc.edu I can make a list of my unsuccesful tries: 1) self repairing (mirror) 2) virus (soul seeker) 3) mother (one process copy process that cannot replicate) 4) sub bomber (use sub @x, @x instead of spl or dat). -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca Date: Saturday, 9 May 1992 16:23:47 EDT From: Message-ID: <92130.162348JJJ101@psuvm.psu.edu> Subject: Re: cyclical KotH In article <1992May9.190046.22884@usenet.ins.cwru.edu>: >> >> - Can anyone think of another basic class of warrior for the above list? > >How about IMPs? (grin) I now have three programs under development. SuperImp The second oldest program on the X-hill (age 61) is an imp-based program, Absolute 250. It hit #1 twice, but usually hangs out between 4th and 9th. For an imp-based program, it scores a lot of wins (25%). Here it is: ;redcode-x verbose ;name Absolute 250 ;author James Jesensky start spl imp, <-199 jmp -1, <-200 imp mov 0, >1 From: kdmiller@m4-035-12.MIT.EDU (Kenneth D Miller) Subject: Goofy Corewar proggies Message-ID: <1992May9.184659.27466@athena.mit.edu> Date: 9 May 92 18:46:59 GMT Here's three cute & clever (well, *I* think so... ;^) redcode menaces that I submitted. All three got reamed brutally. ;redcode verbose ;name ANNOYING ;author Kenneth D. Miller III ;strategy Oh no! Another CMP-scanning SPL bomber! Run and hide! ;^) init jmp 2 a spl 0, -1 scan cmp Date: Sat, 9 May 92 19:00:46 GMT - Can anyone think of another basic class of warrior for the above list? How about IMPs? (grin) I now have three programs under development. SuperImp (great for ties), ImpLance (almost as nice for ties) and ImpBreed (my only "dangerous" one of the three). SuperXmp was on the -x hill for a few days, and ImpRBreed is now there: 15 37/ 51/ 13 Shoggoth 1.1 122 62 16 26/ 34/ 40 Stonewall 117 46 17 32/ 48/ 20 Test 116 6 18 14/ 15/ 70 ImpBreed 1.0 113 1 19 12/ 29/ 59 Hide 'n' Seek 94 3 20 17/ 43/ 41 Crest 1.0 91 4 Notice the high 70% tie rate. As soon as I find a way to kill my own IMP's, there'll be alot more wins. (Every tie is mostly likely my turning the enemy into IMP's as well.) Anyways, that's where it stands. I'm going to start tweaking, and see if I can't make it higher than 15. Alot of it's battles were 50 ties out of 50 battles. If I could only kill them, it would have been 50 wins! ||| Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu ||| -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet -- / | \ "...make him want to change his name,take him to the cleaners, devastate him, wipe him out, humiliate him." -CHESS GEnie: J.ROY18 From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: ImpBreed....victorious! Message-ID: <1992May9.190425.22982@usenet.ins.cwru.edu> Date: 9 May 92 19:04:25 GMT My first sucess! Here's one of the better tieing event you'll ever see! (grin) Program "ImpBreed 1.0" (length 12) by "Jonathan Roy" (contact address "as666@cwns2.ins.cwru.edu"): has challenged the hill. Program "Juggernaut 5.0" (length 91) by "Scott Nelson" ImpBreed 1.0 wins: 17 Juggernaut 5.0 wins: 15 Ties: 18 Program "MiniShwing! [x] v1.2" (length 33) by "T. H. Davies" ImpBreed 1.0 wins: 0 MiniShwing! [x] v1.2 wins: 43 Ties: 7 Program "Leaper-X 4.0" (length 16) by "Jeff Raven" ImpBreed 1.0 wins: 19 Leaper-X 4.0 wins: 6 Ties: 25 Program "multi mice -x" (length 12) by "nandor sieben" ImpBreed 1.0 wins: 1 multi mice -x wins: 0 Ties: 49 Program "Bridge" (length 18) by "Scott Adkins" ImpBreed 1.0 wins: 0 Bridge wins: 9 Ties: 41 Program "Rabbits [x]" (length 10) by "Paul S. Kilroy" ImpBreed 1.0 wins: 0 Rabbits [x] wins: 0 Ties: 50 Program "Spreader 2.0" (length 78) by "Scott Adkins" ImpBreed 1.0 wins: 0 Spreader 2.0 wins: 44 Ties: 6 Program "UltraSlick" (length 48) by "Ray Cromwell" ImpBreed 1.0 wins: 22 UltraSlick wins: 4 Ties: 24 Program "Crimson v1.1" (length 16) by "J.Cisek" ImpBreed 1.0 wins: 7 Crimson v1.1 wins: 11 Ties: 32 Program "Slick2.0" (length 48) by "Ray Cromwell" ImpBreed 1.0 wins: 20 Slick2.0 wins: 7 Ties: 23 Program "Absolute 250" (length 3) by "James Jesensky" ImpBreed 1.0 wins: 0 Absolute 250 wins: 0 Ties: 50 Program "Virus" (length 27) by "Scott Adkins" ImpBreed 1.0 wins: 0 Virus wins: 0 Ties: 50 Program "Rail Road 1.0" (length 100) by "James Jesensky" ImpBreed 1.0 wins: 13 Rail Road 1.0 wins: 3 Ties: 34 Program "ImpDwarf 1.0" (length 10) by "Warren Kurt vonRoeschlaub" ImpBreed 1.0 wins: 4 ImpDwarf 1.0 wins: 7 Ties: 39 Program "Shoggoth 1.1" (length 21) by "Bill Shubert" ImpBreed 1.0 wins: 24 Shoggoth 1.1 wins: 6 Ties: 20 Program "Test" (length 16) by "Jeff Raven" ImpBreed 1.0 wins: 13 Test wins: 1 Ties: 36 Program "Stonewall" (length 98) by "Ray Cromwell" ImpBreed 1.0 wins: 0 Stonewall wins: 5 Ties: 45 Program "Hide 'n' Seek" (length 9) by "Warren Kurt vonRoeschlaub" ImpBreed 1.0 wins: 0 Hide 'n' Seek wins: 0 Ties: 50 Program "Crest 1.0" (length 12) by "Jeff Raven" ImpBreed 1.0 wins: 0 Crest 1.0 wins: 0 Ties: 50 Program "SuperXmp 1.0" (length 4) by "Jonathan Roy" ImpBreed 1.0 wins: 11 SuperXmp 1.0 wins: 0 Ties: 39 Program "ImpBreed 1.0" (length 12) by "Jonathan Roy" ImpBreed 1.0 wins: 0 Ties: 50 Your overall score: 113.428571 SuperXmp 1.0 has been pushed off the hill. The current hill: # %W/ %L/ %T Name Score Age 14 37/ 47/ 16 ImpDwarf 1.0 127 8 15 37/ 51/ 13 Shoggoth 1.1 122 62 16 26/ 34/ 40 Stonewall 117 46 17 32/ 48/ 20 Test 116 6 18 14/ 15/ 70 ImpBreed 1.0 113 1 19 12/ 29/ 59 Hide 'n' Seek 94 3 20 17/ 43/ 41 Crest 1.0 91 4 5 of it's battles were 50 ties out of 50 fights! From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: ImpBreed... A note Message-ID: <1992May9.190730.23232@usenet.ins.cwru.edu> Date: 9 May 92 19:07:30 GMT I just noticed something. Out of 20 programs, ImpBreed beat or tied 14 of them! ImpBreed has the 2nd lowest loss rating on the hill. From: hastings-matthew@CS.YALE.EDU (Matthew Hastings) Subject: A new hybrid type Message-ID: <1992May9.211331.2517@cs.yale.edu> Date: Sat, 9 May 1992 21:13:31 GMT From: dean@coplex.com (Dean Brooks) Subject: Re: Version 4.1 of The MADgic Core Date: Sat, 9 May 1992 21:35:08 GMT Message-ID: <1992May9.213508.3693@coplex.com> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >I forgot to mention, both in the post here and the MADgic41.readme file >on soda, that the new version 4.1 ASR can handle underscores and colons. >Since both of these occur somewhat frequently (at least from my tournament >experience), this is an important addition to the system. I regret not >mentioning it earlier. Has anyone had problems with ASR on an A3000 with OS2.04? The actual simulator worked perfectly, but ASR would lock my machine up when I tried to assemble some of the examples. When I say "lock up", I do mean LOCK up. I couldn't even CTRL-AMI-AMI to reset! I had to power the machine down before I could continue on. It was also repeatable, but not necessarily on the same source file. Once compiled, though, the MARS simulator worked perfectly. If it matters, I have 6MB of memory and was using a CLI stack size of 100,000 bytes (just to make sure). -- <><> Dean Brooks Internet: dean@coplex.com <><> System Administrator / Postmaster CompuServe: 70672,2405 <><> Copper Electronics, Inc. From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Crimp Message-ID: <1992May9.222015.21779@samba.oit.unc.edu> Date: 9 May 92 22:20:15 GMT No more originality huh? Ummm. Here is my program Crimp. Crimp is a combined off axis cmp scanner/mutagen. Notice the cmp engine in the first 4 instructions. The bottom line is that in three cycles, Crimp has compared two different addresses and mutagenized a third for an overall memory access efficiency of 1.0 I know of no other program that is so fast, save Imp. Cmp scanners typically scan two locations in 3 cycles for an efficiency of 0.666, B-field scanners scan 1 location in 2 cycles for an efficiency of 0.5 while dwarfs typically bomb one location in three cycles for an efficiency of 0.333. Of course, the mutagenizing djn is not very destructive however it confers two advantages when fighting other scanners: 1) other scanners will pick up the djn'd instruction and spend time bombing it. 2) scanners typically have very tight main executing loops of 2 to 4 instructions. Triggering another scanner into executing a bombing routine means that a small bomb (such as an spl-jmp) will be executed faster which obviates the need for dropping a large carpet of bombs. The second thing to notice is the choice of scan constant of 566. The way this program is set up, this constant yields a "fibbonacci scan". The distance between scanned locations is first 283, then 207, 76, 55, 21, 13, 8, 5, 3, 2 and finally 1. Since a binary search is not practical, a fibbonacci scan is the next best thing with the maximum evenness of spread. This is the most efficient type of general scanning pattern of which I am aware. Of course, it is possible to come up with more efficient patterns against _a specific size of target_, but I think that in general, this scan is the better choice. Crimp was the "new idea" to which I alluded a few days ago. I credit Stefan Strack and his program Agony for getting me interested in cmp scanners again. Note that the idea of "making the loop useful" is also applicable to dwarfs... I tried something of the sort (not very seriously) with my program "Superdwarf" which appeared briefly on the hill a while ago. -Andy ajpierce@med.unc.edu P.S. It might be fun to have an experimental hill where all 20 programs are put into the arena at the same time to fight it out. ;redcode ;name Crimp ;author Andy Pierce ;strategy small cmp scanner ;strategy bigger than ClaMP, more destructive than ClaMP ;strategy full release version, optimize constants ;kill Crimp ret add offset,start start cmp -834,-551 ;15 - 2n jmp hit,0 count djn ret, Date: Sun, 10 May 1992 04:21:28 GMT Ah yes, Imp. I had forgotten about that one. I then propose as a fourth type of program: worms! Where a worm is any program which replicates itself and executes the copies, but with a limit on total active copies at any one time. Given an infinitely large core, the number of worms reaches a constant value, whereas the number of replicators continues to grow. So then: 1) dwarfs -sit and throw bombs of any type blindly 2) scanners -sit and throw bombs when a target is found 3) replicators -make executing multiple copies with no number limit 4) worms -make executing multiple copies with a set limit on number Programs can be combinations of types. For example, a program which makes 10 copies of itself thoughout the core of dwarf would be first a defective worm (only copies part of self, limit on copy number, copies get executed) and then a dwarf. Does this cover it all? Any more I have forgotten about? -Andy ajpierce@med.unc.edu From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Parthenos Message-ID: <1992May10.044101.1005@vlsi.polymtl.ca> Date: Sun, 10 May 1992 04:41:01 GMT hum... Well, even if I swore not to write one, I did: a spl bomber. The worst thing is right after submitting it, I read the news and saw that Charon and others were basically the same prog... Anyway... the jmp gets over written by a spl 0 eventually, and the core is cleared multiple times. ;redcode ;name Parthenos ;author Pierre Dak Baillargeon ; ;strategy v1.0: auto-splitting splitter, splits itself when ;strategy it doesn't want to split anymore... ; start spl 0, 0 search mov -1, @x sub #132, x jmp search, 0 clear mov bomb, Date: Sun, 10 May 1992 11:27:26 GMT It appears that the "standard" way of scoring a series of corewars battles is 3pts for a win, 1 pt for a tie and 0 pts for a loss. I was just wondering if there is any sort of rationale behind this system, or is it just arbitrary. I think that there are two goals for a corewars program: 1) have yourself survive 2) kill your opponents. Also, I don't think that 1) necessarily follows from 2). It might be useful for the new standard to explicitly state what the objectives are and the relative value of these objectives. I would say that a warrior which kills its opponents and then itself dies 3 cycles later is "less successful" than one which kills its opponents and doesn't itself die at all. This would mean (in a KotH context for example) that the full 80000 cycles would be run (or until both programs were dead) and that at the end of this time, a score is awarded based upon survival to that point for example: your program still alive = +1 pt your opponent dead = +2 pts The +1/+2 system above most closely approximates the current 3/0/1 pt system, with the exception that if both programs die simultaneously (after executing the same number of cycles each), they should both be awarded 2 pts. Explicitly giving points for survival would mean that programs will have to be a little smarter in order to maximize their score. It also removes the value of a "self destruct mechanism" to tweak KotH scores by ensuring that the self battle comes out 25/-/0. Personally, I think goal 1) is equally important with goal 2) and so would advocate a +1/+1 scoring system which would use the following table after a set number of cycles: opponent program alive dead your program: alive 1 2 dead 0 1 -Andy ajpierce@med.unc.edu From: Ordania-DM@cup.portal.com (Charles K Hughes) Subject: Re: corewars scoring Message-ID: <58830@cup.portal.com> Date: Sun, 10 May 92 15:00:01 PDT Speaking of scoring...how about making losses cost ties. I.e. each loss scores -1 pts. I think that losing should be more important, at least as important as tieing. Charles_K_Hughes@cup.portal.com From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Super Imp's first battle! Message-ID: <58835@cup.portal.com> Date: Sun, 10 May 92 16:09:54 PDT > 5/8/92 07:26 21/1135 kv07@IASTATE.EDU (Warren Vonroeschlaub) > . . . > The point I am trying to make is that sometimes a program that acts in a >suprising manner it can be as devistating as a planned attack. I once submitted a warrior with the intention that it get the LOWEST score. Since DAT #0 wins 25 battles (all against itself), the basic strategy was to search for a copy of itself, and if it found itself, loop forever (get a tie), if it could not find itself, commit suicide. I was startled to find that my first attempt not only didn't kill itself in all cases (I expected a few ties against some warriors) but it actually won a battle! At the time I thought that the other programs were just poorly written, but perhaps they were just surprised. |+--------------------------------------------------------------------+| Death is merely a transition from one state to another. Sort of like moving to Kansas. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: cyclical KotH Message-ID: <58836@cup.portal.com> Date: Sun, 10 May 92 16:11:45 PDT 5/8/92 10:11 11/475 ajpierce@med.unc.edu (Andrew Pierce) > It seems to me that there are 3 fundamentally different types of >successful programs on KotH. > 1) scanners which bomb with spl: these will kill all large programs > 2) small dwarfs (2-4 instructions): these will kill scanners > 3) self multipliers: these will kill small dwarfs > > Can anyone think of another basic class of warrior for the above list? >As it stands now, KotH is overpopulated with scanners. Submit those >dwarfs! > -Andy Well, scissors (scanners), rock (small dwarfs), and paper (self multipliers) are very popular strategies, but there are others. How about evasion (Hideout, cowboy), reaction (Sync), target specific (worm optima), suicide (Oddball), motion (worms), colonization (Acid rain), and of course combinations of the above (Snow white and the seven dwarfs) These are just some of the successful strategies, there are many more some of which have not (yet?) proved successful. |+-----------------------------------------------------------------+| The universe is not just stranger than we imagine, it is stranger than we can imagine. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Pre-decrement woes... Message-ID: <58837@cup.portal.com> Date: Sun, 10 May 92 16:14:42 PDT ARRGGHHH!!!!!!! O.k. now that I've said that who out there really believes that: 1.) The speed of a particular technique is not processor dependent? 2.) _ALL_ real CPU's copy the current instruction to an "internal" register? 3.) A new standard will be written to make programs slow and inefficient? I personally feel that proposed changes to corewar should not consider how the changes will be implemented AT ALL! The goal of a standard is to make things clear and consistent, not fast. Of course faster is better, but it is not the important thing, and it should be low on the list of priorities. |+------------------------------------------------------------------+| How you say something is not as important as what you say, just ask any politician. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: corewars scoring Message-ID: <58840@cup.portal.com> Date: Sun, 10 May 92 17:03:01 PDT >5/10/92 04:27 35/1855 ajpierce@med.unc.edu (Andrew Pierce) > It appears that the "standard" way of scoring a series of corewars >battles is 3pts for a win, 1 pt for a tie and 0 pts for a loss. I was >just wondering if there is any sort of rationale behind this system, or is >it just arbitrary. Yes there is one, but I have often wondered at the "rationale" behind this system, and so will let someone else (MAD?) try to explain it to you. > . . . > I think that there are two goals for a corewars program: 1) have >yourself survive 2) kill your opponents. Also, I don't think that 1) >necessarily follows from 2). It might be useful for the new standard to >explicitly state what the objectives are and the relative value of these >objectives. I agree, although there aren't that many battles in which 1) doesn't happen and 2) does. > . . . > Personally, I think goal 1) is equally important with goal 2) I agree completely. I think that suicide should NOT be an effective strategy. Along the same line, I once suggested the JOB instruction as a possible mod, because I felt that continuing to run is a poor measure of a programs performance. To wit: -12.) Add the JOB instruction. (JOB is actually two instructions, one fo -each warrior, so CPW would not skip if warrior A's JOB instruction were CPW -with warrior B's.) JOB must be executed after (coresize*9) cycles and befor -(coresize*10) cycles or that warrior losses. Battles would run the full -number of cycles, even if only one side is running. If no JOB is executed, -all warriors lose. Scoring as follows: Sole winner- 3 points, Two winners- -one point each, Zero winners- zero points each. The JOB idea evolved from the following problem. Two slaver programs place JMP's in each other, but in parts of code not yet being executed. Then they both jump to the other programs slave pit, which begin to wipe core. The warrior which does the WORST job of clearing memory ends up winning. Unfortunately unlike your idea, the JOB instruction fundamentally changes corewar. |+-------------------------------------------------------------------------+| Winning isn't every thing, but losing isn't anything. <<>> From: wms@iwarp.intel.com (William Shubert) Subject: Re: Pre-decrement woes... Message-ID: <1992May10.172246.13776@iWarp.intel.com> Date: 10 May 92 17:22:46 GMT Julius Cisek has been arguing in favor of "in-memory" evaluation. I personally do not care about in-memory vs. in-register. I changed to in-register because it was pointed out to me that most widely available simulators already use this method. However, Julius's argument makes strong use of the fact that a simulator for "in-memory" evaluation will be faster. This is simply wrong - in fact, the truth is the exact opposite. I wrote code for both, compiled them with a very good compiler (GCC V2.1), and looked at the results. As I had guessed, in-register is faster. Why? Because in-register needs far less memory accesses! The fact is that to modify the core your code has to fetch the memory, modify it, then write it back; even though the C code makes it look like it's a single instruction, it isn't (unless you're on a CISC machine, but even then it's a single SLOW instruction). With in-register evaluation you only have to fetch it from memory once. With in-memory evaluation you may have to fetch it multiple times. Anyway, this is all kinda moot because I think that simulator speed is far less important than other factors, like playability and consistency. -Bill (wms@iwarp.intel.com) From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Optimal constants Message-ID: <1992May10.173552.2511@samba.oit.unc.edu> Date: Sun, 10 May 1992 17:35:52 GMT One of the points I made when I posted the source of Crimp to the net was that of chosing bombing offset constants which maximized the evenness of spread throughout the core. I felt that constants which left bombs a distance apart which followed a Fibbonacci series would be about as good as it could get. Here are these constants for a standard bomber (it's a little different for a cmp scanner) in a core of 8000 addresses: MOD 1: 5807,3614,2193,1421,772,649,123,34,21,13,8,5,3,2,1 MOD 2: 5138,2276,586,518,68,42,26,16,10,6,4,2 MOD 3: none MOD 4: 7308,6616,692,388,304,84,52,32,20,12,8,4 MOD 5: 1545,1270,275,170,105,65,40,25,15,10,5 The series listed above show the maximum distance between bombs as bombing progresses where the first value is also the bomb step value. -Andy ajpierce@med.unc.edu From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: cyclical KotH Message-ID: <1992May10.174144.16795@oucsace.cs.ohiou.edu> Date: 10 May 92 17:41:44 GMT In article <1992May9.070845.16602@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: > > 1) self repairing (mirror) > 2) virus (soul seeker) > 3) mother (one process copy process that cannot replicate) > 4) sub bomber (use sub @x, @x instead of spl or dat). I have written a couple virus or sould seeker programs (Virus being my best) that has been quite successful in the past... Being the fact that Koth tends to be Cyclical in nature, it does not do well now in the regular Hill... but may eventually some day down the raod. I wrote a program called Dwarfer once that combined the theories of both #1 and #3 together. There was a base mother process that copied child dwarves out into the core to let them do the bombing (similar to Quarter), but then continued doing so, copying children on top of the old children, thus repairing them if they were damaged, and giving them each more strength. If the mother was killed, the children would be on their own, and would no longer be protected from damage. This idea worked very well for awhile, and eventually fell to the wayside in time... As for the sub bombers, or maybe the decrement bombers (sub #x, Date: 10 May 92 17:47:26 GMT In article <1992May9.190046.22884@usenet.ins.cwru.edu> as666@cleveland.Freenet.Edu (Jonathan Roy) writes: > > - Can anyone think of another basic class of warrior for the above list? > >How about IMPs? (grin) I now have three programs under development. SuperImp >(great for ties), ImpLance (almost as nice for ties) and ImpBreed (my >only "dangerous" one of the three). SuperXmp was on the -x hill >for a few days, and ImpRBreed is now there: I wrote a couple programs called Imporer and Impire... each using a new concept that I though would be neat to try. They do tend to tie a lot, and is almost impossible to actually have them win a lot... :-) The basic idea behind both of them is to move away from the standard imp of mov 0, 1. Instead the program now looks something like the following: mov 0, 5 mov 0, 5 mov 0, 5 mov 0, 5 mov 0, 5 Creating an oversized version imp. I submitted this many many months ago to Koth, and as expected, it couldn't make it on. It becomes easy to kill a program like this just by altering any one line in the program. How do you fix this? Just start multiple over-sized imps, separating them a little distance, but close enough that repair might actually be possible. It isn't a bad idea, but there are still too many ties. Scott Adkins sadkins@ohiou.edu From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: Pre-decrement woes... Message-ID: <1992May10.192042.6221@samba.oit.unc.edu> Date: Sun, 10 May 1992 19:20:42 GMT I too favour "in memory" evaluation because to me, it makes more intuitive sense. On a system with a hardware memory cache of any kind, the speed of in register vs in memory should not be an issue. -Andy ajpierce@med.unc.edu From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Pre-decrement woes... Message-ID: <58848@cup.portal.com> Date: Sun, 10 May 92 21:24:17 PDT >So, let's use our brains: what real instructions or architectural >facilities have we seen that would change the behaviour of the game? If were going to "limit" ourselves to "real" architectures, how about the protected-from-write segments of the 386? |+------------------------------------------------------------------------+| School is a wonderful institution, but I'm not ready for an institution yet. <<>> From: wms@iwarp.intel.com (William Shubert) Subject: KotH V2.4 available Message-ID: <1992May10.221624.17385@iWarp.intel.com> Date: Sun, 10 May 1992 22:16:24 GMT After all that net talk about algorithms to speed up corewar simulators, I just had to give it a try. After putting some serious effort in I managed to speed up KotH in non-interactive mode by a factor of 3 to 4. This is very good for tournaments, but bad in that it now takes very long to compile. Most of the compilation time is spent generating the 275 functions necessary. While I was doing this, I made changes so now I'm 99% sure that KotH will run just fine on X11R3 and X11R4 as well as X11R5 systems. I also added code to correctly work with "-geometry", "-iconic", and "-display" switches. I have uploaded the new KotH as koth24.shar.Z to soda.berkeley.edu in the pub/corewar/incoming directory. Please get it there if you can. If you can't FTP to soda, I can mail out KotH as a single 135K shar file or as three ~50K shar files. -Bill (wms@iwarp.intel.com) From: solman@athena.mit.edu (Jason W Solinsky) Subject: Re: corewars scoring Message-ID: <1992May10.233345.19486@athena.mit.edu> Date: Sun, 10 May 1992 23:33:45 GMT In article <58830@cup.portal.com>, Ordania-DM@cup.portal.com (Charles K Hughes) writes: |> |> Speaking of scoring...how about making losses cost ties. I.e. each loss |> scores -1 pts. I think that losing should be more important, at least as |> important as tieing. :-) :-) :-) Think about what would happen then. Ties would now be worth a half win. The scoring system was designed to make two ties worth less than one win so there is more inclination to write winning programs. What you have proposed is precisely the same as 2 points win, 1 point tie, 0 points loss. Jason W. Solinsky From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: Pre-decrement woes... Message-ID: Date: Mon, 11 May 1992 00:33:23 GMT In article <58837@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: |2.) _ALL_ real CPU's copy the current instruction to an "internal" register? Anything that doesn't have partitioned code and data busses has to. Anything that DOES have two busses will get the same effect. Think about it. This issue needs sharpening, but it doesn't matter which way it goes. Of far more interest to me is that any additions to the instruction set or changes in the rules retain the flavour of real programming. Write-distance limits do not meet this criterion. Ditto "protect" instructions. Sacrificing the whole IDEA of programmes fighting in memory in order to jumble up the scores a bit strikes me as, er, misguided. So, let's use our brains: what real instructions or architectural facilities have we seen that would change the behaviour of the game? Atomic string moves certainly would :-) but I'm not sure we want that. Adding a cache (to encourage programmes with more locality - i.e. more logic) would. What else? ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Bridge Message-ID: <1992May11.020839.15541@oucsace.cs.ohiou.edu> Date: 11 May 92 02:08:39 GMT Here is a program that has been most often found wandering the top 5 in the experimental hill. With the reshuffling of the X-Koth currently going on, it looks like Bridge will fall to be around 10th or so place. The basic idea is to copy itself to the next block of core and then start bombing its own area... then allowing each copy to copy itself and bomb its area. Eventually, the whole core will be effectively bombed... Scott Adkins sadkins@ohiou.edu ------------------------------------------------------------------------------ ;redcode-x verbose ;name Bridge ;author Scott Adkins ; ;strategy Copies itself forward in memory, starts the copy, and then spends ;strategy part of its lifetime bombing the 200 or so locations behind it. ;strategy The bombing routine continues for 20 times, at which time it copies ;strategy itself again and then falls back into the bombing routine again. ; length equ dst-start+1 source equ dst-src+1 output equ 238 write equ 43 road equ start-bomb-1 life equ 20 start mov #length, count mov #source, src mov #output, dst copy mov Date: 11 May 92 02:12:50 GMT Ok, here is another program that has also been doing very well, wandering around the top 10, and sometimes as high as 5th place... Depending on its mood... :-) The basic idea of this program is to set up a heavy defense barrier, allowing programs to fall into its trap, only to get plowed over by the bombing. To add a little to the offensiveness of the program, I also starting two copying routines, moving in opposite directions in the core which cleans out the core as it is being copies. I spent a lot of time tweaking the constants, and figure that the only way to spead it up any more is to go to scanning the core as opposed to blindly bombing. That might be for Spreader 3.0 :-) Scott Adkins sadkins@ohiou.edu ------------------------------------------------------------------------------ ;redcode-x verbose ;name Spreader 2.0 ;author Scott Adkins ;kill Spreader ; ;strategy By the use of copying some heavy-duty bombing programs to the ;strategy extremeties of the write limit, this program effectively bombs ;strategy 1100 memory locations quickly and thorougly. Just in case the ;strategy enemy program does not venture into this war zone, two bombing ;strategy programs are sent out into the core in opposite directions to ;strategy clean everything else out. ; length equ dst1-pest1+100 source equ dst1-src1+100 output1 equ -15 output2 equ 200 pest1 mov #length, count1 mov #source, src1 mov #output1, dst1 move1 mov scan2c mov bomb2, >scan2c mov bomb2, >scan2c mov bomb2, >scan2c mov bomb2, >scan2c scan2b djn scan2a, #50 mov #50, scan2b mov #1, scan2c scan2c jmp scan2a, #1 kill2a mov bomb2, >kill2i kill2b mov bomb2, >kill2i kill2c mov bomb2, >kill2i kill2d mov bomb2, >kill2i kill2e mov bomb2, >kill2i kill2f djn kill2a, #50 kill2g mov #50, kill2f kill2h mov #1, kill2i kill2i jmp kill2a, #1 bomb2 dat #0, #0 copy2 mov kill2a, 250 mov kill2b, 250 mov kill2c, 250 mov kill2d, 250 mov kill2e, 250 mov kill2f, 250 mov kill2g, 250 mov kill2h, 250 mov kill2i, 250 spl 241 jmp scan2a pest2 mov #length, count2 mov #source, src2 mov #output2, dst2 move2 mov Date: 11 May 92 08:12:37 GMT Here's something I though of while taking a shower: Instead of patching the current Redcode language (which, by the way, could really use a PRE-increment instruction), let's use some of those old 8-bit assembly languages. For instance, Motorola 6809 M/L is pretty cool. Think of all the old Williams Electronics games like Defender and Robotron, and those used 6809's. Hey, *I* think that would be neat. It's real machine language, you can get real books that talk about it, you get registers (only 3 though), a stack pointer, lots of useful instructions, and think of all the 6809 programmers who don't have a lot to do ;^) What does everyone think? Oh, the other idea I had was to have something like pre-increment (to be consistent with all the other "stick a character in front of the opcode" modifiers). That could be nice. Also, there was something posted a while ago mentioning a way to access A-Fields. THings like mov.a, mov.b, which would only move the A and B fields respectively. The mov instruction itself (no extension) would act the same. Another recent post mentioned having the A fields and B fields not be tied to instructions. All memory words would be effectively the same. Code as data, data as code, the mind reels ;^) But seriously, separating the OP A, B OP A, B into something like OP A B OP A B in memory could allow some clever effects. Then there's an "exchange" instruction that swaps a and b fields. Things that use "indirect" modes (@ and <, and now >) could use A fields now. Just pop a .a onto the instruction using it. Also, KotH seems to complain when SLT has a #xxx in its B field. SLT #xxx, blah works, but SLT blah, #xxx doesn't. That makes no sense! Sorry if this is hard to read, it's 4:00 AM. -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: ajpierce@med.unc.edu (Andrew Pierce) Subject: putting smarts back into corewar Message-ID: <1992May11.131959.18921@samba.oit.unc.edu> Date: Mon, 11 May 1992 13:19:59 GMT With the recent evolution of scanning programs, it has been made clear to me that perhaps the single most important parameter which determines how well a program does is that program's size. Large programs (say 20+ instructions) are massacred in a relentlessly efficient way. This tends to take the intelligence out of the programs by selecting for programs with "smaller brains". I think the consensus is that smarter programs should do better and various strategies have been proposed (larger core, cache, addressing limits) none of which I particularly like. Larger core is not the answer because in the final analysis, a "smart" program has to somehow "cover" memory just like a "dumb" program does, so this is no help. Cache won't help because the larger programs are being killed because they are large, not because they are slow. The deepest thinking program still has to scan/bomb memory, just like the mindless dwarfs. The only thing addressing limits does it to change the size of programs from n to n+4 where 4 is how many instructions it takes to copy yourself to a new location (for large addressing limits anyway). I think that what is needed is to make the smarter programs smaller. A look at the current corewar instruction set will show that of 11 instructions there are 5 which make logical decisions: jmz, jmn, cmp, slt, and djn. Of these, the most useful for logic are cmp and slt. Unfortunately, these instructions really require two addresses of the form: cmp or slt jmp to routine 1 routine 2 Unless routine 1 can be made 1 instruction long, the cmp or slt instruction needs a jmp to go with it. Given the importance of size, you need a really phenomenally good reason to use either of these instructions as it stands. Here is what I proprose be done about it: change the cmp and slt instuctions to have 3 op fields such that they would be cmp x,y,z. In this case, addresses y and z are compared and if equal, execution is transferred to address x. Likewise slt x,y,z would be "jump to x if y From: Date: Monday, 11 May 1992 13:26:54 EDT In article <1992May10.042128.5608@samba.oit.unc.edu>, ajpierce@med.unc.edu (Andrew Pierce) says: > > > 1) dwarfs -sit and throw bombs of any type blindly > 2) scanners -sit and throw bombs when a target is found > 3) replicators -make executing multiple copies with no number limit > 4) worms -make executing multiple copies with a set limit on number > > Does this cover it all? Any more I have forgotten about? > -Andy >ajpierce@med.unc.edu 5) Self-repairers -Programs which scan their own code for damage and attempt to repair the damage. (Many times combined with one or more dwarfs) 6) Guns -Programs which spawn another type of program forever. Ex. imp-gun, dwarf-gun, signal-gun. 7) Vampires? -Programs which attempt to steal the other program's processes for their own use. 8) Trappers -Programs which try to capture processes in traps. (SPL types being most common). I could probably think of 20 more if I had the time. The problem with Corewars is not the lack of variety, but the lack of variety in winning program types. James From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: Pre-decrement woes... Message-ID: <1992May11.082839@IASTATE.EDU> Date: Mon, 11 May 1992 13:28:39 GMT In article <1992May11.081237.14547@athena.mit.edu>, kdmiller@athena.mit.edu (Kenneth D Miller) writes: > Here's something I though of while taking a shower: > > Instead of patching the current Redcode language (which, by the way, could > really use a PRE-increment instruction), let's use some of those old 8-bit > assembly languages. For instance, Motorola 6809 M/L is pretty cool. Think > of all the old Williams Electronics games like Defender and Robotron, and > those used 6809's. > > Hey, *I* think that would be neat. It's real machine language, you can get > real books that talk about it, you get registers (only 3 though), a stack > pointer, lots of useful instructions, and think of all the 6809 programmers > who don't have a lot to do ;^) > > What does everyone think? Two problems: 1) The 6502 was more popular, so use that (nyah nyah :-) 2) Neither of these processors have multitasking capabilities, this alone would constitute a pretty major change to the language (even just adding a spl command and removing exception handling) Nor do they have interrupts in the traditional sense (an error jumps to the routine pointed to by location 0) or relative adressing (at least, not with JMP). It would be difficult to translate the opcodes into something that is usable by Core Wars. *********************************************************************** * Warren Kurt * "Consequences shmonsequences, as long as I'm * * vonRoeschlaub * rich." -Daffy Duck * *********************************************************************** From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: Super Imp's first battle! Message-ID: <1992May11.154401.2612@vlsi.polymtl.ca> Date: 11 May 92 15:44:01 GMT ScottNelson@cup.portal.com (Scott - Nelson) writes: [...] : : I once submitted a warrior with the intention that it get the : LOWEST score. Since DAT #0 wins 25 battles (all against itself), the Now that's an idea ! The goal of KotH could be changed to be not the first on the hill but the 5th or 10th ! You'd have to adjust carefully the performance of the warriors... -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: cyclical KotH Message-ID: <1992May11.155146.2845@vlsi.polymtl.ca> Date: 11 May 92 15:51:46 GMT sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes: : [...] As for the sub : bombers, or maybe the decrement bombers (sub #x, Date: Mon, 11 May 1992 16:13:56 GMT > Two problems: > 1) The 6502 was more popular, so use that (nyah nyah :-) > 2) Neither of these processors have multitasking capabilities, this alone >would constitute a pretty major change to the language (even just adding a spl >command and removing exception handling) Nor do they have interrupts in the >traditional sense (an error jumps to the routine pointed to by location 0) or >relative adressing (at least, not with JMP). It would be difficult to translate >the opcodes into something that is usable by Core Wars. Yes, I had thought about the 6502. I suppose that there are far more Corewar players who used to code in 6502 M/L than there are that coded in 6809. I suppose adding a fairly simple SPL instruction and converting all absolute access to PC-relative addressing would make things a bit different. However, 6502 M/L does have lots of useful qualities in its favor. And just think of how many 6502 cross-compilers there are... ;^) -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: kdmiller@m37-332-4.MIT.EDU (Kenneth D Miller) Subject: Re: Super Imp's first battle! Message-ID: <1992May11.162621.8044@athena.mit.edu> Date: Mon, 11 May 1992 16:26:21 GMT In article <1992May11.154401.2612@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: >ScottNelson@cup.portal.com (Scott - Nelson) writes: >[...] >: >: I once submitted a warrior with the intention that it get the >: LOWEST score. Since DAT #0 wins 25 battles (all against itself), the > > Now that's an idea ! The goal of KotH could be changed to be not the first >on the hill but the 5th or 10th ! You'd have to adjust carefully the >performance of the warriors... heheheheh I do that all the time. I tend to get stuck around 20th though... I can't figure out why my programs do so badly! I had one that just completely destroyed some programs, but got hosed by others. It's really weird. My current fave is this one: ;redcode ;name BANZAI TOO ;author Kenneth D. Miller III ;strategy I think this one's technically a "slaver". It turns out that ;strategy it bears a frightening semblance to Scissors88. Go figure. start add inc, a jmz start, @a slt #-12, a mov a, @a hit jmp start zot mov inc, Date: Mon, 11 May 1992 16:36:29 GMT Oops! I posted an old version! Here's the newer one: ;redcode verbose ;name BANZAI TOO ;author Kenneth D. Miller III ;strategy I think this one's technically a "slaver". It turns out that ;strategy it bears a frightening semblance to Scissors88. Go figure. start add inc, a jmz start, @a slt #-12, a mov a, @a hit jmp start, #start-1 zot mov inc, 1 From: JJJ101@psuvm.psu.edu Subject: CW scoring Message-ID: <92132.150914JJJ101@psuvm.psu.edu> Date: 11 May 92 19:09:13 GMT I agree that a program should be awared more for killing a program and exhausting the CPU limit, then for killing a program and dying a few (hundred/thousand) instructions later. Here's my suggestion: Action Score ------ ----- Program is killed by other program 0 Tie--Both programs exaust CPU limit 2 each Program kills other program, but dies before CPU limit is reached 3 Program kills other program and doesn't die. 5 James From: darichte@rnd.GBA.NYU.EDU (David Richter) Subject: Re: cyclical KotH Message-ID: <25543@rnd.GBA.NYU.EDU> Date: 11 May 92 21:26:53 GMT In article <1992May8.171144.13135@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: | It seems to me that there are 3 fundamentally different types of |successful programs on KotH. | 1) scanners which bomb with spl: these will kill all large programs | 2) small dwarfs (2-4 instructions): these will kill scanners | 3) self multipliers: these will kill small dwarfs Would then a good program be one which splits off several of each of these? Preferably designed not to attack itself, of course. Programs like these have posted before, but they usually only include two of the three: a scanner and a dwarf-maker, or somesuch. David Richter From: darichte@rnd.GBA.NYU.EDU (David Richter) Subject: Re: corewars scoring Message-ID: <25545@rnd.GBA.NYU.EDU> Date: 11 May 92 21:44:42 GMT In article <1992May10.112726.19745@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: |I would say that a warrior which kills its opponents and then |itself dies 3 cycles later is "less successful" than one which kills its |opponents and doesn't itself die at all. This would mean (in a KotH |context for example) that the full 80000 cycles would be run (or until |both programs were dead) and that at the end of this time, a score is |awarded based upon survival to that point It would be impractical to run all 80000 cycles once one program is dead. Running another 1000 or some other small number is one thing, but if one program is dead after 5000 cycles, the added time for the full 80000 cycles lengthens the match by a factor of 13. Ideally, yes, the idea is good. But until KotH runs on a gigaflop machine, it simply takes too long. JMHO, David Richter From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: Re: the fourth type of program Message-ID: <1992May11.230128.16389@usenet.ins.cwru.edu> Date: Mon, 11 May 92 23:01:28 GMT 6) Guns -Programs which spawn another type of program forever. Ex. imp-gun, dwarf-gun, signal-gun. That's what ImpBreed is. An ImpLanceGun. (grin) ||| Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu ||| -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet -- / | \ Tampa Bay Storm is the Arenabowl '91 champions! Lynx me up! Citanet: ..!{mast,overmind,tpt4}!darkrealm!the_ninja GEnie: J.ROY18 From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: putting smarts back into corewar Message-ID: <1992May12.041557.7013@vuse.vanderbilt.edu> Date: Tue, 12 May 1992 04:15:57 GMT In article <1992May11.131959.18921@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: > I realize that people will complain that it will be harder for MARS, >and probably slower to implement, but I think the key issue here is >playability. Making the logic instructions one address large would go a >long way in helping. > While I'm all for making logical instructions more powerful, I find adding adding a third operand to CMP and SLT in the context of a two-operand architecture, well, unelegant. I agree that ease of implementation and execution speed are secondary considerations, yet it is important that systems can run on platforms with memory constraints. Relaxing the addressing-mode constraints on CMP and SLT, along with adding the inverse CMP opcode (CMN, "CoMpare, skip if Non equal", Kevin Whyte's idea) would go a long way by itself. We might even consider an instruction that tests for executable addresses (JXC, "Jump if eXeCutable", or JND, "Jump if Non-DAT"). Lastly, a way to _efficiently_ access the A-field (XCH, "eXCHange A- and B-field") might add to playability. I am not convinced, though, that more powerful comparisons will necessarily lead to more "intelligent" programs, although they will surely lead to more "perceptive" programs. E.g., Andy's three-operand CMP could be used in the ultra-fast scan-loop scan ADD incr, comp CMP a, b, scan incr DAT #INCR, #INCR where could involve elaborate decision-making, or short, but mindless bombing. -Stefan (stst@vuse.vanderbilt.edu) From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: new corewar specs Message-ID: <1992May12.045853.15171@vlsi.polymtl.ca> Date: 12 May 92 04:58:53 GMT Just my .02$ worth in the debate over a new Core War specification: 1. All memory location should be atomic, with one op-code or operand per location. This serves many purpose. 2. Make instructions variable length. With either zero, one, two or three operands (ie: rts, jmp A, mov A B, add A B C). 3. Make instructions take as many cycle as there are memory read or write. The shortest would be rts (1 for opcode fetch, one for return address fetch), the longest would be add Date: Tue, 12 May 1992 07:23:02 GMT In article <1992May09.011455.18034@microsoft.com> t-jcisek@microsoft.com (Julius Cisek) writes: >[I'm going to try to edit out as much of Mark's message as possible. I'm sure Mr. Cisek did not mean that quite the way it sounds. :) > Several people here even include other people's > signatures. And I'm certain he did not mean to include my signature in his message, but he did. Still, it is only two lines. :) >>In article <1992May05.001457.13823@microsoft.com> >>t-jcisek@microsoft.com (Julius Cisek) writes: >> >>>A real CPU DOES fetch the instruction into a register at the time an address >>>is evaluated. >> >>And so does MARS. From ICWS'88, page 9, first paragraph under the heading >>"Effective Address Calculation": >> >> "After the instruction to be executed has been fetched" > >Right, but this applies to the executing instruction, not the instruction >at the evaluated address. So what happens if the address evaluation >effects the current PC location? Do you then have to do the modification >to the register and then write it back out? That still seems inefficient. No, that is not the correct way to handle that situation. The whole point behind having a register is so that the subsequent execution does not alter the value. In the event execution alters the instruction currently referenced by the pointer counter, the instruction in core is altered but the instruction in the instruction register remains unchanged. >Gotcha. However, the decision SHOULD have been for efficiency. I did not follow the "Gotcha". Decisions are made for many reasons. Historically efficiency was not high on the list. A server like KotH was simply not a realistic opportunity at the time, as pointed out later. > What is the point of copying the memory out to >a register? There are three points to registers. The first is simularity to hardware. The second is so that execution of an instruction does not alter the execution of the instruction currently executing. The third reason is to simplify MARS construction and validation. By completly evaluating operands and storing all results in registers whether needed or not by the opcode, we have separated the two processes and significantly decreased the amount of code which needs to be tested. Here is an example from EMI88.c for the DJN opcode: case DJN: CORE[PCB].BField = (CORE[PCB].BField + memory - 1) % memory; if (BValue != 1) { /* ((BValue - 1) != 0) */ lastCoreNode->PC = PCA; }; break; > KotH used to support my interpretation, now it supports the >other... Actually, KotH worked both ways - depending on which opcode was being executed. The initial inconsistency is a good argument for separating operand evaluation from opcode execution. > I can never get access to soda, did you put it anywhere >else? Try soda again. I never have any trouble. I will put the new version of my program on amiga.physik.unizh.ch as soon as possible. >>Mark A. Durham >>MAD See? :) From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: corewars scoring Message-ID: <167E52A91.DURHAM@ricevm1.rice.edu> Date: Tue, 12 May 1992 08:01:32 GMT In article <58840@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: > I have often wondered at the "rationale" behind >this system, and so will let someone else (MAD?) try to explain it to you. Scoring was originally (Win = 1, Tie = 0, Loss = -1). With this scoring scheme, programs like Mice and Chang1 which SPLit off 64 tasks in almost as many cycles (under ICWS'86) were nearly impossible to beat. It was decided that winning was the important thing, not merely survival, so the scores were bumped up to (Win = 3, Tie = 1, Loss = 0). Up until now, there were no complaints. Under ICWS'86, a "SPL 0/MOV 0, 1" combination was very difficult to kill. It loads up 64 Imps right away. They would keep restoring themselves, take a few losses, and then finally overwrite their opponent. This problem inspired two changes: the change in scoring above and the change in the way SPL works under ICWS'88. The almost instantaneous death guaranteed by being hit by a SPL 0 bomb had a large influence in the latter also. > I think that suicide should NOT be an effective >strategy. Currently, suicide does not seem to be a strategy successfully used on the hill. If suicide were common, a simple program like JMP 0 could win easily by hiding (at least from zero B-field scanners) and waiting for the other program to commit suicide. The situation where someone was writing a program to get the LOWEST possible score on KotH and was surprised to win occasionally can be attributed to the lethality of the warriors currently on the hill. They are deadly not only to other warriors, but also to themselves in the event they are altered in any way. They are not intentionally committing suicide. More like accidentally stinging themselves to death. Mark A. Durham MAD From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: VDT Round 5 Results Message-ID: <167E52FD9.DURHAM@ricevm1.rice.edu> Date: Tue, 12 May 1992 08:24:09 GMT Here are the results from Round 5 of the Valentine tournament: 0 / 3832 Winner Cycle -------- ------ ----- Aleksey Baulin's Terminator traded games with Kevin Whyte's Fleas2. Terminator/Fleas2 Terminator 25607 Fleas2/Terminator Fleas2 8702 Mr. Baulin requested a new opponent for Round 6 in case of a tie. Mr. Whyte listed no preference. Mr. Baulin was the wiser because in continued battles Fleas2 eventually won both matches for a 0/7861 separation. Mr. Baulin faces Vincent Li and Mr. Whyte will take on Stefan Strack. Vincent Li's Paratrooper dropped in on Jack Twilley's AppleSeed Five++ for a win and a tie to advance. Paratrooper/AppleSeed5++ Paratrooper 16277 AppleSeed5++/Paratrooper Tie Mr. Li takes on Aleksey Baulin for Round 6. Mr. Twilley takes on Peter Olcott next round. Campbell Fraser's IntangibleWorm was on John Wetmiller's Gulliver's hook for two losses. IntangibleWorm/Gulliver Gulliver 5126 Gulliver/IntangibleWorm Gulliver 6776 Mr. Wetmiller advances to take on Nandor Sieben in Round 6. Mr. Fraser and Mr. Drummond are no longer in contention. Nandor Sieben's csapda vaccinated Scott Adkins' Bacteria to take two wins. csapda/Bacteria csapda 25446 Bacteria/csapda csapda 25126 Mr. Sieben will face Mr. Wetmiller next round. Mr. Adkins is no longer in contention. Adam Caldwell's Dwarfer took William Shubert's Leech to the doctor twice, each time for a win. Dwarfer/Leech Dwarfer 16183 Leech/Dwarfer Dwarfer 4161 Mr. Caldwell has a bye for Round 6. Mr. Shubert is out of contention. Ray Cromwell's BullWhip and James Jesensky's HeapImp tied twice. BullWhip/HeapImp Tie HeapImp/BullWhip Tie They will battle each other again next round. Stephen Beitzel's Mr. Nasty and John and Michael Nidd's Tamper traded victories (over and over again). Mr. Nasty/Tamper Mr. Nasty 14380 Tamper/Mr. Nasty Tamper 61927 They will battle again in Round 6 unless I do not hear from them, in which case I will take both out of contention or swap opponents because neither warrior can consistently beat the other. Here are the brackets so far: Beg/Winner's Bracket -------------------- Stefan Strack----- vs > Stefan Strack-- Stefan Haenssgen-- \ vs > Stefan Strack- Scott Adkins------ / \ vs > Scott Adkins--- \ Nandor Sieben----- \ > Stefan Strack Arne Juul--------- / / vs > Adam Caldwell-- / / Adam Caldwell----- \ / / vs > Adam Caldwell-- / Fraser & Drummond- / / vs > S. Halvorsen--- / S. Halvorsen------ / >---------- Kevin Whyte------- \ vs > Kevin Whyte---- \ Werle & Beitzel--- \ \ > Kevin Whyte------------------ Peter Olcott------ / vs > James Jesensky- James Jesensky---- William Shubert--- vs > William Shubert John Wetmiller---- \ vs > Aleksey Baulin- Stig Hemmer------- / \ vs > Aleksey Baulin- \ Aleksey Baulin---- \ >--------------- Vincent Li-------- / vs > Vincent Li----- / John & Mike Nidd-- \ / > Vincent Li----- Jack Twilley------ / vs > Jack Twilley--- Ray Cromwell------ Loser's Bracket --------------- Arne Juul--------- vs > Fraser--------- Fraser & Drummond- \ > John Wetmiller- John Wetmiller---- / \ vs > John Wetmiller- \ Stig Hemmer------- \ >----------------- Stefan Haenssgen-- / vs > Nandor Sieben-- / Nandor Sieben----- \ / > Nandor Sieben-- S. Halvorsen------ / vs > Scott Adkins--- Scott Adkins------ Adam Caldwell----- vs > Adam Caldwell-- William Shubert--- \ >---------------- Peter Olcott------ / >---------------- Jack Twilley------ Stephen Beitzel--- vs >---------------- John & Mike Nidd-- \ >---------------- Ray Cromwell------ / vs >---------------- James Jesensky---- Out of Contention ----------------- Arne Juul Stig Hemmer Stefan Haenssgen S. Halvorsen Campbell Fraser and Scott Drummond Scott Adkins William Shubert From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: My Corewar Suggestion (long) Message-ID: <1992May12.090212.27036@athena.mit.edu> Date: Tue, 12 May 1992 09:02:12 GMT While sending Email to William (of KOTH fame), I came up with the following idea, much of which is excerpted from that message. The summary of the proposal: 1. add SNE instruction 2. add Post-increment addressing mode 3. add "near" and "far" indirect addressing distinction 4. add "short" and "long" memory access 5. divide instructions into three separate core words (no more A and B operand fields) This post is quite long. You have been warned! ;^) PROPOSAL FOR ICWS '92 There is a new addressing mode: post-increment (similar to pre-increment) There are no "special" A and B fields, just instruction words which use the two words following them as data bytes. However, these words could be themselves instructions (like the Apple II ROM example posted before). Effectively, the number of memory locations would be tripled (i.e., KOTH would use a core size of 24000 words). The two "skip" instructions CMP and SLT would skip over *THREE* core words to get to the next instruction. The reasoning behind this will be explained later. "Imported" programs from older ICWS revisions would have their addresses and MOV's tripled accordingly (i.e., they'll run, but not well) Also, a new comparison instructions would be added, to make things more convenient for the coder: SNE Skip if Not Equal (the opposite of CMP) This would make even more gross scanning possible: loop SNE -ptr.s, -ptr.s ;see later for expanation of "-" and ".s" jmp loop One big change is to have "near" (from -128 to +127) and "far" (-32768 to +32767) access, "near" being slightly faster, though not really any smaller. This would, unfortunately, necessitate making "far" versions of the addressing modes to distinguish between a long-range indirect and a word-length indirect. NEAR blah #blah @blah blah FAR -- -- =blah -blah +blah The other big change is to have "short" and "long" addressing pointers: A ".s" extension signifies that the argument is short distance; a ".l" extension signifies that the argument is long distance. The equivalent ranges in ICWS '88 would be -42 to +42 (short) and -10922 to +10922 (long). The "short" limitation is fairly major, though not all that limiting, especially since the "DAT" opcode isn't really necessary, and the three words that would compose a DAT can be three indepentently accessible data elements. All instructions and all argument values (both .s and .l) are word length, without exception. The only advantage to ".s" is that it takes 1 cycle less to process. There is no equivalent "far" version of direct or immediate, unlike the indirect modes. The "short" and "long" descriptors are sufficient for dealing with these two modes. This is convenient, because there are now exactly 16 access modes. The Big List of Access Types, with performances blah.s 1 cycle short direct (=near) blah.l 2 cycles long direct (=far) #blah.s 1 cycle short immediate #blah.l 2 cycles long immediate @blah.s 2 cycles short, close indirect @blah.l 3 cycles long, close indirect =blah.s 3 cycles short, far indirect =blah.l 4 cycles long, far indirect blah.s 3 cycles short, close postincrement >blah.l 4 cycles long, close postincrement +blah.s 3 cycles short, far postincrement +blah.l 4 cycles long, far postincrement Here's a simple explanation of how indirect modes work (using normal indirect) @blah.s: "blah" is a nearby location that points to another nearby location @blah.l: "blah" is a far-away location that points to a nearby location =blah.s: "blah" is a nearby location that points to a far-away location =blah.l: "blah" is a far-away location that points to a far-away location Simple enough, right? Instructions themselves take 2 cycles, but each argument fetch adds to this time: ".s" takes 1 cycle, ".l" takes 2, indirect near adds 1, and indirect far adds 2. This would be strong incentive to "keep things close" without necessitating things like caches. Instructions like SPL that only take one argument ordinarily but that can have things in their B fields would keep the B field present in their ordinary mode. However, there are "small" versions of the one-argument functions that only accept one argument. Therefore you could wind up with things like SPL 0, SP. Anyone who's had a computer science course knows that with a stack, registers aren't necessary (though convenient nonetheless). Think of all the joyous fun coders could have with stacks: subroutines...recursion...parameter passing... the mind reels at the possibilities ;^) Currently, ICWS '88 is way too limited to do anything really complex without making the code huge (and vulnerable). I think that the modifications that I just printed would make some new possibilities available. And think, all those goofy mindless bombers will suddenly find themselves at a disadvantage. This is probably a Good Thing (tm) (However, the goofy mindless scanners will become even more powerful...oops) Here's what a sample program would look like: top add #8838.l, @bomb.s ;increment position jmz top.s, @bomb.s ;scan at position mov bomb.s, >bomb.s ;move "SPL" mov bomb.s+1, >bomb.s ;move "0" jmp top.s, >bomb.s ;loop back and realign position bomb spl 0, #-8838.l -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: t-jcisek@microsoft.com (Julius Cisek) Subject: Re: Pre-decrement woes... Message-ID: <1992May12.092818.5453@microsoft.com> Date: 12 May 92 09:28:18 GMT In article <1992May10.172246.13776@iWarp.intel.com> wms@iwarp.intel.com (William Shubert) writes: > However, Julius's argument makes strong use of the fact that a simulator >for "in-memory" evaluation will be faster. This is simply wrong - in fact, >the truth is the exact opposite. I wrote code for both, compiled them with >a very good compiler (GCC V2.1), and looked at the results. As I had guessed, >in-register is faster. Why? Because in-register needs far less memory >accesses! Let me clear something up here. I am certainly not saying that everything should be evaluated in memory (too many index accesses). What I AM saying is that the memory location that the evaluated address points to shouldn't be fetched until the need arises. Maybe this is not how most CW simulators work and it won't make a difference to them, but I really feel that the instruction (memory location) which is going to get copied or compared or whatever shouldn't be fetched until we find out what the instruction is going to do with it. What is the point in actually fetching a memory location when you are going to be executing a jump, for example? If the core memory is structured correctly, even an indexed access (add then mov) is less costly than copying the whole location (which will almost definately take more than one mov depending on the processor). I'm really tired of arguing the point. It really does seem pointless. I think that what happened here is that in *MY* implementation, the register fetch is costly where as in others it is not. When I have the chance I will post some code and you can see for yourself. > Anyway, this is all kinda moot because I think that simulator speed is far >less important than other factors, like playability and consistency. I really do agree, but I found that the in-memory approach (by this I mean that both operands are evaluated and updated in core BEFORE the instruction is executed) seems what the rules of the game imply, and was surprised to see that I was wrong. And since in *MY* simulator it makes a pretty noticable difference, I just wanted to bring it up. -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| From: t-jcisek@microsoft.com (Julius Cisek) Subject: Re: Pre-decrement woes... Message-ID: <1992May12.093629.5629@microsoft.com> Date: 12 May 92 09:36:29 GMT In article <1992May11.161356.7303@athena.mit.edu> kdmiller@m37-332-4.MIT.EDU (Kenneth D Miller) writes: >> Two problems: >> 1) The 6502 was more popular, so use that (nyah nyah :-) I believe it was also a little more intuitive as far as simple assembly goes. >> 2) Neither of these processors have multitasking capabilities, this alone >>would constitute a pretty major change to the language (even just adding a spl >>command and removing exception handling) Nor do they have interrupts in the >>traditional sense (an error jumps to the routine pointed to by location 0) or >>relative adressing (at least, not with JMP). It would be difficult to translate >>the opcodes into something that is usable by Core Wars. If we were able to have an instruction set with POPs and PUSHs it should be up to the programmer to write multiplying code. After all, SPL 0 isn't really multi-tasking, it's very rudimentry time sharing. I think this is a pretty cool idea, but I really doubt it will happen. Too much change from the present redcode. >[...] converting all absolute >access to PC-relative addressing would make things a bit different. However, This would take some debating, eh? -- Julius Andrew Cisek ,_, t-jcisek@microsoft.com "Joy!" /oo \ _.-. "Quiet, you bloated One Microsoft Way // <>__| /- O O idiot!" Redmond, WA 98052 \X/ | U| \| Date: Tuesday, 12 May 1992 11:17:10 EDT From: Message-ID: <92133.111710JJJ101@psuvm.psu.edu> Subject: Re: corewars scoring In article <25545@rnd.GBA.NYU.EDU>, you say: > >In article <1992May10.112726.19745@samba.oit.unc.edu> ajpierce@med.unc.edu >(Andrew Pierce) writes: >|I would say that a warrior which kills its opponents and then >|itself dies 3 cycles later is "less successful" than one which kills its >|opponents and doesn't itself die at all. This would mean (in a KotH [...] >Ideally, yes, the idea is good. But until KotH runs on a gigaflop machine, >it simply takes too long. Perhaps not for something like Koth, but this is feasible for single round robin tournaments. Who needs gigaflops ?? Send it to the batch queue and wait a few days :-) James From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: Re: corewars scoring Message-ID: <1992May12.152120.24973@dcs.glasgow.ac.uk> Date: 12 May 92 15:21:20 GMT In article <167E52A91.DURHAM@ricevm1.rice.edu>, DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: > > Under ICWS'86, a "SPL 0/MOV 0, 1" combination was very difficult to kill. > It loads up 64 Imps right away. They would keep restoring themselves, > take a few losses, and then finally overwrite their opponent. This problem Said program would be very easy to kill in '86 standard as it would be a very slow imp which would not regenerate. However in '88 standard it would be many slow imps which would regenerate - similar to the description given. The (nearly) equivalent program in '86 would be "spl 2/jmp -1/mov 0,1" but clearly the change to "spl" failed to remove this type of program. Campbell --- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. -- Campbell Fraser \/ INTERNET: fraserc%dcs.glasgow.ac.uk@nsfnet-relay.ac.uk Computing Science Dept /\ USENET : fraserc.glasgow.uucp Glasgow University \/ JANET : fraserc@uk.ac.dcs.glasgow Glasgow G12 8QQ, U.K. /\ From: nflynn@wvnvms.wvnet.edu Subject: HELP Message-ID: <1992May12.131504.3102@wvnvms.wvnet.edu> Date: 12 May 92 17:29:56 GMT If some kind soul could help me out it would be most appreciated. I would like to know where on the network I can get corewars (for MS-DS or Amiga). Does it have complete rules? I know a little about corewars already - read the scientific american articles several years back. I have crobots for the amiga but would like to get it for the pc also. Thanks in advance. - Nick Flynn From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: new corewar specs Message-ID: <1992May12.142233@IASTATE.EDU> Date: Tue, 12 May 1992 19:22:33 GMT In article <1992May12.045853.15171@vlsi.polymtl.ca>, dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: > 4. Add all normal instructions: and, or, xor, shifts, rotates, jsr, rts, and > possibly mul, div, push and pop (which would need stack initialisation). For a stack how would the multitasking (okay: timesharing) be handled? There would have to be a stack for each process, which means the simulator would have to copy X values each time a SPL was encountered. This would be a MAJOR slowdown in playing speed. > 6. Add the post-increment addressing mode, to make them balanced. Could be used > to form the base of a stack. This is the right way to handle a stack, no worrying about the questions like above by leaving the problems in the hands of the programmer. *********************************************************************** * Warren Kurt * "Consequences shmonsequences, as long as I'm * * vonRoeschlaub * rich." -Daffy Duck * *********************************************************************** From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: new corewar specs (long) Message-ID: <1992May12.212221.1772@athena.mit.edu> Date: Tue, 12 May 1992 21:22:21 GMT Here's another hideously long post from me... In article <1992May12.045853.15171@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: >Just my .02$ worth in the debate over a new Core War specification: > >1. All memory location should be atomic, with one op-code or operand per > location. This serves many purpose. This is good. In fact, I suggested the very same thing... >2. Make instructions variable length. With either zero, one, two or three > operands (ie: rts, jmp A, mov A B, add A B C). Umm, with atomic memory locations, this would cause a hideous degree of misalignment. Imagine how tough it would be to find the proper memory location even inside of your own program... There's nothing wrong having two args, even if one or both are unused; aligned code is happy code. :^) >3. Make instructions take as many cycle as there are memory read or write. > The shortest would be rts (1 for opcode fetch, one for return address fetch), > the longest would be add ... for a total of 10 cycles). Could make taken jumps 1 cycle longer, and > if mul and div are added, make them something like 4 and 8 cycles. Good point. If anyone remembers (or even read) my post on this subject, I neglected this effect. Add one cycle to all the "near" predecrement and postincrements, and add two cycles to all the "far" ones. That should make some nice balance. >4. Add all normal instructions: and, or, xor, shifts, rotates, jsr, rts, and > possibly mul, div, push and pop (which would need stack initialisation). Hmm. MUL, DIV, PUSH, and POP are probably unnecessary. Redcode is supposed to be fairly "RISC". What would you be doing with MUL and DIV in a combat program, anyway? The rest are also a bit unnecessary. One way to do JSR and RTS is the "hard way": push the Program Counter onto a stack, jump to a subroutine, pop the counter back off, and jump to that location. It would be a challenge to code, but that's the name of the game. :^) >5. Add a unsplit instruction which would remove the preceding task (or next, > we'd need to think about it) if there's one. This would counter balance > the split bomber. After all, good games that last need balance. An > instruction to load the number of task you run would be useful too (starting > to track yourself ??? :). This way, program could really protect themselves. Interesting idea, actually. Hmm. Though you should think of all the gross little replicators that are suddenly SPL-bomb resistant... >6. Add the post-increment addressing mode, to make them balanced. Could be used > to form the base of a stack. This is a definite must. Without it, Redcode is extremely limited. >7. Many more weird things could be added, like turning cache on or off. Cache > would load 16 memory location at a time (in 16 cycles, or we could make it > 12 for 'burst mode' :). Loading and flushing could take their toll on dumb > bomber or scanner programs... do we make warriors cache coherent ??? In my proposal, there are "near" and "far" indirect addressing, as well as "short" and "long" accesses to memory. "near" is anything that points less than 128 words away (+ or -), "far" is anything else; "short" is anything memory access less than 128 words away, "long" is anything further away. This serves the same purpose as a cache, without the problems. >8. Anything else to make emulator writers go mad... I think that this is by far enough... ;^) Here's the only problem with all this (quoting William Shubert): "Yeah, redcode-x already has post-increment. I like the idea; not just because it gives you stacks, but also because it gives you that much more variety than having both predec and preinc. "About the three words per instruction - I like it, I wish that corewar were that way from the start, but it wasn't and I'm afraid that it's a bit big of a change to introduce at this point. Ah well thanks for your input. -Bill (wms@iwarp.intel.com)" Almost none of the old code will work anymore under this scheme. Sigh. But then it would do some good to force a recoding... -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Spring 1992 TCWN Message-ID: <167E51283D.DURHAM@ricevm1.rice.edu> Date: Wed, 13 May 1992 02:03:57 GMT The Spring 1992 Edition of The Core War Newsletter has been posted to soda.berkeley.edu as Spring92TCWN.eps in the /pub/corewar/{incoming|documents} directory. It is plain ASCII PostScript code and about 2 Megs in size. There may be a compacted version available if Jon Blow was kind enough to do that for me. Those due a TCWN will receive one in the mail within the next few weeks. Comments, suggestions, and (especially) submissions are always welcome. Mark A. Durham MAD From: vli@mpr.ca (Vincent Li) Subject: Re: new corewar specs (long) Message-ID: <1992May13.022656.15973@mprgate.mpr.ca> Date: Wed, 13 May 92 02:26:56 GMT In article <1992May12.212221.1772@athena.mit.edu> kdmiller@athena.mit.edu (Kenneth D Miller) writes: > >In article <1992May12.045853.15171@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: >>Just my .02$ worth in the debate over a new Core War specification: >> >>1. All memory location should be atomic, with one op-code or operand per >> location. This serves many purpose. > >This is good. In fact, I suggested the very same thing... > >>2. Make instructions variable length. With either zero, one, two or three >> operands (ie: rts, jmp A, mov A B, add A B C). > >Umm, with atomic memory locations, this would cause a hideous degree of >misalignment. Imagine how tough it would be to find the proper memory location >even inside of your own program... There's nothing wrong having two args, >even if one or both are unused; aligned code is happy code. :^) > For my 2 bits, I think 1 and 2 should go hand-in-hand. Just implementing 1 and 2 will already give a whole host of possibilities. I've always find this A B operand bit too confusing. So you have problem with alignment, so what? That's part of the fun! >>3. Make instructions take as many cycle as there are memory read or write. >> The shortest would be rts (1 for opcode fetch, one for return address fetch), >> the longest would be add > ... for a total of 10 cycles). Could make taken jumps 1 cycle longer, and >> if mul and div are added, make them something like 4 and 8 cycles. > Nice idea, but getting a bit too complicated. > >>4. Add all normal instructions: and, or, xor, shifts, rotates, jsr, rts, and >> possibly mul, div, push and pop (which would need stack initialisation). > >Hmm. MUL, DIV, PUSH, and POP are probably unnecessary. Redcode is supposed >to be fairly "RISC". What would you be doing with MUL and DIV in a combat Yes, redcode should STAY "RISC". Although all these instructions are nice, most will not be useful. And if things get too complicated, you'll only turn off interest as the learning curve grows. Redcode instruction set should stay small. > >>5. Add a unsplit instruction which would remove the preceding task (or next, >> we'd need to think about it) if there's one. This would counter balance >> the split bomber. After all, good games that last need balance. An >> instruction to load the number of task you run would be useful too (starting >> to track yourself ??? :). This way, program could really protect themselves. > >Interesting idea, actually. Hmm. Though you should think of all the gross >little replicators that are suddenly SPL-bomb resistant... > Again, we are getting more complicated here. >>6. Add the post-increment addressing mode, to make them balanced. Could be used >> to form the base of a stack. > >This is a definite must. Without it, Redcode is extremely limited. > New addressing modes, on the other hand, could be intesting. In short, just make the operands & instructions equal, one per memory location, and add the new addressing modes. That's more than enough, I'd think. If you start to get too much resources, you'd have less incentive to be creative. -- Vince --------------------------------------- vli@mprgate.mpr.ca |-) It works well under pressure: Another thing |-] you can say about your pillow. -- Mr Boffo From: user0008@student.anu.edu.au (Michael Fagan) Subject: more Help Message-ID: <1992May13.023918.18572@newshost.anu.edu.au> Date: Wed, 13 May 92 02:39:18 GMT Is there anyone out there who knows of a macintosh version of corewars and where it can be found. Also, has anyone got the source file outputed by bison for KotH24 (My bison kicked the bucket),if so could they send it to me. thanks in advance -Michael Fagan -user0008@student.anu.edu.au From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: new corewar specs Message-ID: <1992May13.043828.28025@vlsi.polymtl.ca> Date: 13 May 92 04:38:28 GMT kv07@IASTATE.EDU (Warren Vonroeschlaub) writes: : : For a stack how would the multitasking (okay: timesharing) be handled? There :would have to be a stack for each process, which means the simulator would have : to copy X values each time a SPL was encountered. This would be a MAJOR : slowdown in playing speed. : The stack itself is not copied. The stack is just a register in the task, the actual data is in memory, with an opcode to load the stack register (switch stack). On another subject, I don't think a new standard should seek to necessarily be compatible with the old ones. After all, warrior that are not updated regularly are dead warriors... -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: new corewar specs (long) Message-ID: <1992May13.045018.28169@vlsi.polymtl.ca> Date: 13 May 92 04:50:18 GMT Well, the only interesting opcode would be shift (to implement binary search :). I really think that we should make different addressing mode not take the same amount of time running, but I personnally think that all that 'near' and 'far' stuff too complex, hard to code (for emulator AND warrior) and not that useful. But would adding atomic memory, post-increment change anything ??? I think spl bomber would still dominate. It's simply the ability to run at 8000 time the relative speed of your opponent that make them so hard to beat. At least include the ability to know how many 'copy' of yourself are running. It would not make any differences for enslavers though... -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Kill question Message-ID: <1992May13.075124@IASTATE.EDU> Date: 13 May 92 12:51:24 GMT How exactly does the ;kill command work in KoTH? If a program has a ;kill line and then doesn't make it onto the hill, which of the following occurs? 1) Nothing, the old program stays put 2) The new program is guaranteed on the hill, after all there is at least one empty spot 3) Both programs are kicked off the hill 4) The higher of the two stays, the other gets dumped, regardless of which is the newer version 5) Something else I didn't think of Thanks in advance *********************************************************************** * Warren Kurt * "Consequences shmonsequences, as long as I'm * * vonRoeschlaub * rich." -Daffy Duck * *********************************************************************** From: dwp+@cs.cmu.edu (Doug Philips) Subject: Re: new corewar specs (long) Message-ID: <1992May13.150754.79151@cs.cmu.edu> Date: 13 May 92 15:07:54 GMT In article <1992May13.022656.15973@mprgate.mpr.ca> vli@mpr.ca (Vincent Li) writes: +find this A B operand bit too confusing. So you have problem with +alignment, so what? That's part of the fun! So which is RISCier? I'm not sure I can see a reason to prefer A B operands over alignment, from what you've said. +Yes, redcode should STAY "RISC". Although all these instructions are +nice, most will not be useful. And if things get too complicated, you'll +only turn off interest as the learning curve grows. Redcode instruction +set should stay small. I quite agree. -Doug From: wms@iwarp.intel.com (William Shubert) Subject: Re: Kill question Message-ID: <1992May13.171211.292@iWarp.intel.com> Date: Wed, 13 May 1992 17:12:11 GMT First, let me say that I'll be gone later today until Monday. I'll leave KotH running but if my machine crashes it'll be down until I come in Monday morning and restart it. kv07@IASTATE.EDU (Warren Vonroeschlaub) asked: >How exactly does the ;kill command work in KoTH? If a program has a ;kill >line and then doesn't make it onto the hill, which of the following occurs? Kill works in a very simple way. It just zeroes the score of the killed program...it does NOT specifically take it off the hill. However, a program with a zero score will get wiped off by the first serious challenger to show up. Programs with just a ";kill" line will zero the score, then lose all fights so the program "killed" is still around, but with only about 5 points. The first new program to come along then finishes off the job. I implemented it this way to simplify the database handling stuff...just pulling a program off of the hill is fairly tricky because you have to subtract the points from its fights from the opponents...then you may have less than 21 program on the hill so you have to adjust the scoring...etc. Basically zeroing the score is easy and works just fine. -Bill (wms@iwarp.intel.com) From: vli@mpr.ca (Vincent Li) Subject: Re: new corewar specs Message-ID: <1992May13.215640.27464@mprgate.mpr.ca> Date: Wed, 13 May 92 21:56:40 GMT In article <1992May13.150754.79151@cs.cmu.edu> dwp+@cs.cmu.edu (Doug Philips) writes: >In article <1992May13.022656.15973@mprgate.mpr.ca> vli@mpr.ca (Vincent Li) writes: >+find this A B operand bit too confusing. So you have problem with >+alignment, so what? That's part of the fun! > >So which is RISCier? I'm not sure I can see a reason to prefer A B >operands over alignment, from what you've said. > Hmmm, well, all I'm saying is, each opcode will take one memory and each operand also one memory. That's all to the physical space. In the time domain, maybe each fetch & decode takes one cycle, or something like that. That should make for a simple implementation of the simulator, I'd think. May be each write also one cycle. All the simulator does, really, is read from memory and write to memory (well, and then some manipulation of the operand, possibly, once it's been read). Now you don't have to worry about should we stick with 2 operand or 3, or what not. If new instructions are added, we can always just add a new opcode. Immediate, and relative addressing is a single cycle read. Indirect is a 2 cycle read: 1 fetch for indirect addres, then fetch again for indexed content. Pre-incr, post-incr, etc would be 2 fetch: fetch & add, and fetch again for content. A mov #a, b will take up 3 memory & 4 cycle to execute (3 reads & 1 write). Time slice per process would still be 1 cycle each, but we might change that if that's not too nice. Could be interesting to see what happens if the operand values get changed in midstream. 8-) -- Vince --------------------------------------- vli@mprgate.mpr.ca |-) It works well under pressure: Another thing |-] you can say about your pillow. -- Mr Boffo From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: new corewar specs (long) Message-ID: <1992May13.233902.23827@athena.mit.edu> Date: 13 May 92 23:39:02 GMT In article <1992May13.150754.79151@cs.cmu.edu> dwp+@cs.cmu.edu (Doug Philips) writes: >In article <1992May13.022656.15973@mprgate.mpr.ca> vli@mpr.ca (Vincent Li) writes: >+find this A B operand bit too confusing. So you have problem with >+alignment, so what? That's part of the fun! > >So which is RISCier? I'm not sure I can see a reason to prefer A B >operands over alignment, from what you've said. One thing I faintly remember about real RISC processors is that every single one of their instructions is exactly the same size. This may sound stupid, but the processor optimization that this allows is quite good. A set instruction size means that the CPU can fetch the entire instruction with all of its arguments at the same time as part of the same memory access. A CPU with variable-length instructions would have to fetch the operand-part, parse it, and then determine how many bytes/words of memory to fetch in next. This makes instructions slower. It's not that I don't like variable-length instructions for Corewar, but it would make Corewar programs (MARS) significantly slower, just like real CPU's (MARS is a virtual machine). It's also an aesthetic thing for me... >+Yes, redcode should STAY "RISC". Although all these instructions are >+nice, most will not be useful. And if things get too complicated, you'll >+only turn off interest as the learning curve grows. Redcode instruction >+set should stay small. > >I quite agree. As do I. Redcode is hard enough to pick up on its own! ;^) -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: new corewar specs (long) Message-ID: <1992May13.234416.23962@athena.mit.edu> Date: 13 May 92 23:44:16 GMT In article <1992May13.045018.28169@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: > Well, the only interesting opcode would be shift (to implement binary search >:). I really think that we should make different addressing mode not take the >same amount of time running, but I personnally think that all that 'near' and >'far' stuff too complex, hard to code (for emulator AND warrior) and not that >useful. Point taken. Alright, how 'bout this? There is no distinction (code-wise, at least) between "Near", "Far", "Short" and "Long". However, the cycles each type of access requires should remain. For example, a pre-decrement indirect would always look the same, regardless of rules; however, it could take a variable amount of time depending upon how far away the memory location is, and how far away it points. Is this better? > But would adding atomic memory, post-increment change anything ??? I think >spl bomber would still dominate. It's simply the ability to run at 8000 time >the relative speed of your opponent that make them so hard to beat. At least >include the ability to know how many 'copy' of yourself are running. It would >not make any differences for enslavers though... I think that it would. Think of all the things you could do if you could modify instructions and A-fields as easily as B-fields. Think of all the things you could do with a real live stack... -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Crimp (new version) Message-ID: <1992May14.143128.12675@samba.oit.unc.edu> Date: 14 May 92 14:31:28 GMT Here is the new version of Crimp. Basically, it is ClaMP, except incorporating the ideas from Crimp of the memory active djn and the fibonacci scanning pattern. The final kill routine has also been simplified such that there is one less executing instruction, which helps add robustness under damage. I have found that program complexity gets punished on KotH. I have also removed ClaMP from KotH. It is very similar to the Agony series of Stefan Strack, differing mainly in that Agony drops an spl carpet and ClaMP drops a spl/jmp combination. I feel that between Crimp and Agony, the category "cmp scanner" is pretty well represented, so I am giving the replicating programs a break. :-) To this end, I have also submitted a "dwarf killer" named Scizz, the source of which is in its ;strategy field. It does o.k. against scanning type programs, sux against replicators but does a real number on small, unintelligent dwarfs. By way of illustration, its record against Notepaper is 0/100/0, but its record against Dwarf Optima is 76/24/0. ;redcode verbose ;name Crimp ;author Andy Pierce ;strategy small cmp scanner ;strategy scan constant optimized ;strategy smaller ret add offset,start start cmp -284,-1 slt #15,start count djn ret,<6223 mov bomb1,@start mov bomb2, Date: Thu, 14 May 1992 18:45:19 GMT kdmiller@athena.mit.edu (Kenneth D Miller) writes: [...] : : One thing I faintly remember about real RISC processors is that every single : one of their instructions is exactly the same size. This may sound stupid, but : the processor optimization that this allows is quite good. A set instruction : size means that the CPU can fetch the entire instruction with all of its : arguments at the same time as part of the same memory access. A CPU with : variable-length instructions would have to fetch the operand-part, parse it, : and then determine how many bytes/words of memory to fetch in next. This : makes instructions slower. Well, the RISC analogy does not hold: RISC have their operand either in the opcode (cannot modify one and not the other, even with byte addressing since the operand have variable length depending weither the opcode is a mov or jmp), or the operand is in a registers. Core War is at the opposite of RISC since everything is done in memory. Also, nothing prevent the emulator to fetch 3 or 4 location at once (in one indirection on array) like you would do in the RISC implementation. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: dwp+@cs.cmu.edu (Doug Philips) Subject: Re: new corewar specs (long) Message-ID: <1992May15.032805.236651@cs.cmu.edu> Date: 15 May 92 03:28:05 GMT In article <1992May13.215640.27464@mprgate.mpr.ca> vli@mpr.ca (Vincent Li) writes: +Hmmm, well, all I'm saying is, each opcode will take one memory and each +operand also one memory. That's all to the physical space. In the time +domain, maybe each fetch & decode takes one cycle, or something like +that. That should make for a simple implementation of the simulator, I'd +think. May be each write also one cycle. All the simulator does, really, +is read from memory and write to memory (well, and then some +manipulation of the operand, possibly, once it's been read). Now you +don't have to worry about should we stick with 2 operand or 3, or what +not. [Details elided...] I agree with what kdmiller@athena.mit.edu (Kenneth D Miller) writes in article <1992May13.233902.23827@athena.mit.edu>: +One thing I faintly remember about real RISC processors is that every single +one of their instructions is exactly the same size. This may sound stupid, but +the processor optimization that this allows is quite good. A set instruction +size means that the CPU can fetch the entire instruction with all of its +arguments at the same time as part of the same memory access. A CPU with +variable-length instructions would have to fetch the operand-part, parse it, +and then determine how many bytes/words of memory to fetch in next. This +makes instructions slower. I think there is a "problem" with multi-fetch instructions, which is: when are the various parts fetched? With indexing or indirection you might end up modifying one of the later operands through/with one of the earlier ones. It just gets too complicated and annoying to specify. We have that problem now (sorry, I cannot recall the subject lines from that set of articles) My suggestion would be to widen the word width and allow multiple operations per instruction. If you keep addresses smaller than the word size, you could allow a next instruction offset/address (depending on how you want to divide up the bits in the word) in addition to some ALU operations. More like microcode. -Doug P.S. Does KotH keeps track of instruction usage (i.e. are some instructions almost never used?)? I'd think that that would have been an interesting thing to keep track of. (If it has already been done, my apologies, I've not been reading this group very long). From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: new corewar specs Message-ID: Date: Fri, 15 May 1992 03:43:58 GMT Here's a good reason NOT to have some instructions be slower than others: I'd lay money on no two implementations doing the same thing in the event that the enemy overwrites the instruction DURING execution. If we can't even get mov right now.... ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- Date: Friday, 15 May 1992 12:36:06 EDT From: Message-ID: <92136.123606JJJ101@psuvm.psu.edu> Subject: Re: new corewar specs Here are some things I'd like to see in the new standard: * Registers: Also all addressing should be memory-register, register-register, or register-memory. This would allow two word instructions Since the opcode, register, and addressing information could be stored in the first word, and the memory address in the second. With register-register addressing, the second word is unused. (Good place to store data). * Condition Codes: The Skip-if-somethingorother concept is limiting. I think we need true flags. I can't see a use for a carry flag since memory is circular. Negative and Zero flags should suffice. JMN, JMZ, and SLT would be eliminated. We would need new jumps such as JCS, JCC, JNS, JNC. DJN would remain. * Size parameter: What I mean by this, is all instruction would have a suffix such as mov.b, mov.l, etc. The suffix indicates the size of the data accessed. For example, mov.b (byte) foo, bar moves one byte from foo to bar. I can think of two choices for suffixes(sp?): Method 1 Method 2 -------- -------- .b byte .h high byte .w word .l low byte .l longword .x word * Initial values: Assuming registers are implemented, some initial values should be loaded into them. For example, the coresize, the process limit, the number of contestants etc. A great thing to put into them is the number of wins/loses/ ties against this opponent so far. (Only meaningful in a multi-matched tournament). If registers aren't implemented, the values should be stored in memory below the program. * System calls: What I mean here is interrupts. The instruction would be something like int #. Things like spawning a process, semaphores, maybe the initial values I talked about above, would be interrupts. Different interrupts could split things in different ways. For example, one interrupt would work like the standard spl, one would create a process which shares the parents time slice, one would suspend the parent until the child dies. Other interrupts could be things like sleep for n cycles, etc. This also allows for an easy way to upgrade redcode, since most interrupt numbers will not be used. Time Slice: I think a new time sharing algorithm is necessary. Something like each process gets so many clock cycles, but MARS always lets a process finish the current instruction. Swapping in the middle of an instruction is difficult to implement and will most likely lead to inconsistency among corewar systems. There are my thoughts. I think we need to seriously overhaul redcode, or the new standard will become the old standard real quick. James jjj101@psuvm.psu.edu jesensky@endor.cs.psu.edu Date: Friday, 15 May 1992 14:57:39 EDT From: Message-ID: <92136.145739JJJ101@psuvm.psu.edu> Subject: Re: new corewar specs In article <1992May15.133854@IASTATE.EDU>, kv07@IASTATE.EDU (Warren Vonroeschlaub) says: > >In article <92136.123606JJJ101@psuvm.psu.edu>, writes: >> Here are some things I'd like to see in the new standard: >> >> * Registers: Also all addressing should be memory-register, [...] > > I still have not heard of a good way to implement this alongside . >multitasking >We are basically left with two options: > > 1) Each task has it's own set of registers (stack, whatever), and we have to >copy all the register data to new task storage every time a SPL is executed. [...] I do not see why this is even an issue. In real multitasking computers, it is standard to give each task it's own registers. To not do so would be madness :-). Also, I do not see why this would slow down simulators so drastically. Assuming there are 4 registers, it would take 8 assignment statements to swap them per context switch. But this raises another issue. As the cost of context switching grows, speed can be gained by switching less often. Say after every 2 or 4 instructions instead of after every one. James From: lindblad@cc.helsinki.fi Subject: To Live Is To Die 3.5 Message-ID: <1992May15.173201.1@cc.helsinki.fi> Date: 15 May 92 15:32:01 GMT Here is possibly smallest possible SPL-bomber w/ core clear. Even smaller than Armadillo... however the cost is speed and that's why this beast has never made it in koth. (actually I have made 3 line version of this but it could only have step of 2.) ;redcode ;name To Live Is To Die 3.5 ;author Jarkko Lindblad ;strategy SPL-bomber with core clear tappo MOV 4, <-1 start MOV bmb, @bmb SUB #5138, bmb ;this will be bombed bmb SPL -2, -998 END start -- Jarkko Lindblad lindblad@cc.helsinki.fi From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: new corewar specs Message-ID: <1992May15.165610.22153@vlsi.polymtl.ca> Date: Fri, 15 May 1992 16:56:10 GMT stephen@estragon.uchicago.edu (Stephen P Spackman) writes: : Here's a good reason NOT to have some instructions be slower than : others: : : I'd lay money on no two implementations doing the same thing in the : event that the enemy overwrites the instruction DURING execution. : Well, right now it's just a matter of speculation and conflicting opinion on the interpretation of the rules. The new spcecs would be more spcific and some people suggested putting up a test suite for emulators. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: new corewar specs Message-ID: <1992May15.133854@IASTATE.EDU> Date: Fri, 15 May 1992 18:38:54 GMT In article <92136.123606JJJ101@psuvm.psu.edu>, writes: > Here are some things I'd like to see in the new standard: > > * Registers: Also all addressing should be memory-register, register-register, > or register-memory. This would allow two word instructions > Since the opcode, register, and addressing information > could be stored in the first word, and the memory address in > the second. With register-register addressing, the second > word is unused. (Good place to store data). I still have not heard of a good way to implement this alongside multitasking. We are basically left with two options: 1) Each task has it's own set of registers (stack, whatever), and we have to copy all the register data to new task storage every time a SPL is executed. This would drop the speed of the simulator to a crawl when a big SPL job comes along. Imagine a program like Absolute 250 against Mice! 100 matches would take forever. 2) One set of registers per program. Then registers become useless for programs that SPL because they can never be sure if the data in the regs will be seriously corrupted when changed. They may be good for counting events across all processes, but useless for almost any program that doesn't have alot of polling routines to slow it down. *********************************************************************** * Warren Kurt * "It is easier to fight for one's principles than * * vonRoeschlaub * to live up to them." - Alfred Adler * *********************************************************************** From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: new corewar specs Message-ID: <1992May15.194823.8837@athena.mit.edu> Date: Fri, 15 May 1992 19:48:23 GMT All this talk about registers... Well, I'm finally going to cave it and say "Yeah, that's a good idea" It would mean that "confusing" a program would be much harder, but even with registers, programs wouldn't necessarily be any smaller or harder to kill. Just maybe a bit harder to find (less random data floating around). But, since we're trying to keep things reasonable, limiting the number of registers is a definite must. With 256 registers like some RISC processors have (really, they do!), programs could hide way too much data in "unhittable" space. Let's go to the old 6502/6809 thing: three real registers, and some "spares" X, Y -- just your "temporary" registers for holding short-term data A -- the "accumulator", where most everything gets done. SP -- the stack pointer, points somewhere in core PC -- the address of the current instruction If anyone remembers how much of a pain having that few registers is, it's a big limitation for "real" code, but it's something Corewars programs don't have the luxury of using. Let's give our code a break and give it some registers. But only five... ;^) Each program has its own set of registers. This data is completely hidden from the other program. Otherwise, the other program could just read the PC and bomb there. Not good! -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: new corewar specs Message-ID: <1992May16.021136.25802@vlsi.polymtl.ca> Date: Sat, 16 May 1992 02:11:36 GMT On the subject on new scheduling algorithm, I think simply letting the program decide the number of instructions to execute in a row, with a reasonable limit (I'd say something like half the core size or half the max number of process). This way you could protect yourself a little against spl bomber, but when your 'other' task would seize control... bye, bye ! -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: new corewar specs Message-ID: <1992May16.142528@IASTATE.EDU> Date: Sat, 16 May 1992 19:25:28 GMT In article <92136.145739JJJ101@psuvm.psu.edu>, writes: > I do not see why this is even an issue. In real multitasking computers, > it is standard to give each task it's own registers. To not do > so would be madness :-). Also, I do not see why this would slow down > simulators so drastically. Assuming there are 4 registers, it would > take 8 assignment statements to swap them per context switch. The major slow down would occur when the SPL is executed. New space for holding the registers for the process needs to be allocated, and values copied into them. Starting out with 8000 register sets for each program would speed things up, but even with 5 registers and limiting to two programs means 160k of memory allocated. Forget trying to run it in anything but (assuming C) a huge model. And on IBMs at least, that is a major slowdown. Even if we do dynamically allocate, the pointers will have to be huge, and that means eating up even more memory. *********************************************************************** * Warren Kurt * "Consequences shmonsequences, as long as I'm * * vonRoeschlaub * rich." -Daffy Duck * *********************************************************************** From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: new corewar specs Message-ID: <1992May17.014210.29989@athena.mit.edu> Date: Sun, 17 May 1992 01:42:10 GMT In article <1992May16.142528@IASTATE.EDU> kv07@IASTATE.EDU (Warren Vonroeschlaub) writes: >In article <92136.145739JJJ101@psuvm.psu.edu>, writes: >> I do not see why this is even an issue. In real multitasking computers, >> it is standard to give each task it's own registers. To not do >> so would be madness :-). Also, I do not see why this would slow down >> simulators so drastically. Assuming there are 4 registers, it would >> take 8 assignment statements to swap them per context switch. > > The major slow down would occur when the SPL is executed. New space for >holding the registers for the process needs to be allocated, and values copied >into them. Starting out with 8000 register sets for each program would speed >things up, but even with 5 registers and limiting to two programs means 160k of >memory allocated. Forget trying to run it in anything but (assuming C) a huge >model. And on IBMs at least, that is a major slowdown. Even if we do >dynamically allocate, the pointers will have to be huge, and that means eating >up even more memory. Who says we need 8000 tasks? The only reason that ever happened was that there wasn't any disadvantage to it. Now, with the new specs, there would be a huge disadvantage to having 8000 tasks, so the limit should be dropped to maybe 256 tasks. Thats' way more reasonable and more "realistic" (who has 8000 tasks running on their computer???) If we had 8 registers (four Data registers, two Accumulators, a Stack Pointer, and Program Counter), then that would be 2048 words of data stored, total. Only 4K. That's not too horrible at all. -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Mutagen 2.1 Message-ID: <1992May17.020951.28695@vuse.vanderbilt.edu> Date: Sun, 17 May 1992 02:09:51 GMT BRRR, registers, interrupts, variable-length instructions ... Am I alone in thinking that the beauty of corewar lies in its simplicity? It's hard enough for someone who doesn't do assembly programming for a living to get started in this game as it is; so please, folks, don't make it even harder. While I think that KotH and the code exchange in this group has advanced the state of the art in redcode programming significantly, I believe there's still a lot out there to be discovered even within ICWS'88. A few _modest_ additions and rectifications of ambiguities are likely to open up new strategies; just consider what dramatic effect the relatively minor change in specifications from ICWS'86 to '88 had! Anyway, as the subject line says, I just wanted to share my latest KotH entry with you. "Mutagen 2.1" is a short linear bomber that decrements core as it goes to corrupt enemy code and distract scanners. -Stefan (stst@vuse.vanderbilt.edu) ;redcode verbose ;name Mutagen 2.1 ;author Stefan Strack ;strategy backwards bomber that also decrements B-fields ;strategy 2.0: more robust ;strategy 2.1: smaller, starts bombing away from self ;strategy Submitted: @date@ DIST equ 442 OFFSET equ -49 split spl 0 start mov Date: 17 May 92 15:24:17 GMT In article <1992May17.020951.28695@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >BRRR, registers, interrupts, variable-length instructions ... Am I alone >in thinking that the beauty of corewar lies in its simplicity? I must concur with Stefan. As far as I am concerned, if people want to have registers, interrupts etc., let them go out and buy themselves an Apple II+ or Commodore 64 and have at it at their leisure. Let's keep in mind that corewar is a _game_. The point is not to come up with yet another microprocessor. Let's leave that to the people at Intel and Motorola. -Andy ajpierce@med.unc.edu From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: New Specs too Complex? (was Re: Mutagen 2.1) Message-ID: <1992May17.172151.8468@athena.mit.edu> Date: Sun, 17 May 1992 17:21:51 GMT In article <1992May17.152417.25391@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: >In article <1992May17.020951.28695@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >>BRRR, registers, interrupts, variable-length instructions ... Am I alone >>in thinking that the beauty of corewar lies in its simplicity? > > I must concur with Stefan. As far as I am concerned, if people want to >have registers, interrupts etc., let them go out and buy themselves an >Apple II+ or Commodore 64 and have at it at their leisure. Let's keep in >mind that corewar is a _game_. The point is not to come up with yet >another microprocessor. Let's leave that to the people at Intel and >Motorola. Good point. I think we're getting too nuts about the new corewar specs. Sure, there's lots of cool things we could do, but remember how much trouble we had learning even the OLD corewar specs ('88)??? If it gets even more complicated, we probably wouldn't care, but all the people who are new to corewar would get shafted. Expect my "new & improved" new corewar specs real soon now. SHORTENED! Yeah! -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: New New Corewar Specs Message-ID: <1992May17.195131.15472@athena.mit.edu> Date: Sun, 17 May 1992 19:51:31 GMT After absorbing several complaints about the new corewar specs (registers, interrupts, etc.), I decided to modify my corewar proposal and so, here is: THE NEW & IMPROVED COREWAR PROPOSAL This proposal is almost 100% compatible with ICWS'88 Redcode. THINGS WE REALLY REALLY REALLY NEED: 1. To complement the "<" predecrement indirect, there should be a ">" postincrement indirect. This also just happens to make stacks possible... 2. There would be a SNE (Skip if Not Equal), to complement the CMP (skip if equal) instruction. This would be very nice to have. top SNE ") would be exactly the same. To add an interesting twist to things, memory accesses outside of some pre-determined range should take longer. Memory accesses inside this range would be "cache hits", and have an instantaneous fetch, whereas those outside the range would require access to "physical memory" and use up cycles. The Indirect modes make two accesses: one to fetch the pointer location, and another to fetch the location being pointed to. The pre-decrement and post- increment modes add one cycle, as they have to perform an addition or subtraction on the pointer location. However, the "write" operation is is assumed to take place in the same cycle as the arithmetic. Instructions themselves should take one cycle. Since they are "in the cache", there is no fetch time for the instruction and operands themselves; the only time taken is that required to execute the instruction. Cache hits take no cycles to fetch or write Memory access takes one cycle to fetch or write #xxxx (Immediate) no memory access xxxx (Direct) one memory access @xxxx (Indirect) two memory accesses xxxx (Postincrement) two memory accesses, +1 cycle Direct, cache.................................. 0 cycles Direct, memory................................. 1 cycle Indirect, cache pointer, cache destination..... 0 cycles Indirect, cache pointer, memory destination.... 1 cycle Indirect, memory pointer, cache destination.... 1 cycle << rare! Indirect, memory pointer, memory destination... 2 cycles The Predecrement and Postincrement modes are identical to Indirect, but take 1 cycle longer because of the arithmetic operation (1, 2, or 3 cycles instead of 0, 1, or 2) All "null" operands (such as the second operand of "SPL 0") are assumed to be a 0 cycle access. Here's the basis for a Zero-scanner top ADD #8838, bomb ;increment position ; 1 0 0 JMZ top, @bomb ;scan at position ; 1 0 1 Scan time: 3 cycles per iteration Here's the basis for a two-location SNE scanner top ADD #8838, scan+1 ;increment first position (the "0") ; 1 0 0 ADD #8838, scan+2 ;increment second position (the "12000") ; 1 0 0 scan SNE 0, 12000 ;compare contents of positions ; 1 (1) (1) JMP top ;loop if they're the same ; 1 0 Scan time: 6 cycles per iteration To allow ICWS'86 and ICWS'88 code to run properly in this new standard, there would have to be a "fallback" mode to compile them. I'm not entirely sure how this would work, but it shouldn't be too difficult... (moral of the story: use labels!) -- kdmiller@athena.mit.edu | Kenny Miller, sole member of Digital Horizons USA /// | UPCOMING COOL STUFF: KMUS music format, BrotBusters \\\/// Amiga Makes | Demo, Scrolly Roller Demo, Columns, Psycho Ball, \XX/ It Possible! | AmigAtaxx, etc. (don't hold your breath ;^) From: kertsine@castle.ed.ac.uk (K Scheffler) Subject: A few ideas for the NEWARS IS. (long) Message-ID: <21547@castle.ed.ac.uk> Date: 17 May 92 20:02:56 GMT Thesis : COREWARS learning curve is too damn long at the moment. One of the reasons I don't play much at present is because too much leg work is required to take an algorithm and make it into an effective warrior. ANY new instruction set ought to take these as it's primary considerations. So, my suggestion looks like this. (Dons asbestos clothing, and throws his $0.50 into the pot :-) ). 1 > Registers are Go! Four registers : one as the PC, the others used for data. No fixed stack pointer. Four is a bit arbitary, but seems enough to be flexible without running into other kinds of problems. 2 > No PRE/POST decrement stuff. Forget it. It's useful, but its a pain in the ass also. Cut it. 3 > Fully RISC design By which I mean that any instruction can apply to any register, and there should be the *minimum* of quirks. 4 > *Minimum* number of addressing modes I don't see any reason, if you have registers, to have *any* addressing modes other than direct and offset-by-another-register's contents. 5 > Free Stack Give programs a stack to use for free : ie, it exists as part of the "processor". If programs want a stack pointer, they can use one of the other registers : but by and large, I don't think the typical "newcode" program will have much use for complex stack manipulation. Be generous with the stack too : give them 255 words each. (actually, I can see a problem with this one. Suppose a program pushes it's code on to the stack then copies a "boot block", JUMPs to the boot block, then SPLITS back to the original code? Is this making life too easy?). So what does the instruction set look like? Well, *basic*. Registers A B C P (P is program counter). [] = using value of another register. So MOVE [A] [B] moves contents of address pointed to by A to address pointed to by B. I'm fairly sure we'd want to be able to use immediate constants like ADD A 1, but not so sure that things like MOVE [2] [4] ought to be legal : if you have this, what's the point of having any registers (label a memory address, and voila, it's a register). I'm *very* uncertain about this. Arithmetic Instructions : Really ought to have a full set : I'm not sure about MULT and DIV, which really ought to take longer than a single instruction. I'd be tempted to allow programs to use them in one cycle just to keep life simple, and to encourage more complex algorithms. Logical Instructions : Ditto. The lack of things like AND, NOT imposes quite a lot of restrictions on programs (and when was the last time you saw a processor without them, huh?). Flow of Controll statements : Keep life simple. Instead of having special instructions to do these things, use general instructions on P. For instance, ADD P 5 would be make the next instruction executed the one 5 hence. I don't have any ideas about the decision making instructions, but I don't like the current method much. Addressing : This is the toughie. Are things like MOVE [3] [4] ok? And if so, what about ADD [3] [2]? My suggestion would be to outlaw use of immediate constants in relative instructions (ie no MOVE [3] [4]), and *possibly* outlaw instructions of the form ADD [a] b, forcing most non-MOVE instructions to be register-to-register only. Also, should addressing be relative? And if so, relative to what? Things being relative to the PC is a little confusing, that's for sure. Perhaps a SETREL instruction would help (when executed, all addresses become relative to that point). But if so, we certainly *don't* want SETREL to take any arguments..... Problems : A few obvious ones. Do instructions have to have the same binary values over different systems, so tricks like using your own instructions as data always work? Do registers always have to be the same size (obviously yes if left and right shift will still work). And how will multi-tasking and program replication work? (I have a few suggestions about this, but they have probably been aired in the ICWS newsletter by now). ======================================================================= =========== Vinay Gupta (posted by K Scheffer as a favour) ============ ======== Reply to kertsine@uk.ac.ed.castle, or vg@uk.ac.ed.dcs ======== ======================================================================= Subject: Re: Mutagen 2.1 Message-ID: <1992May17.204327.29772@midway.uchicago.edu> From: kwhyte@daisy.uchicago.edu (Kevin Whyte) Date: Sun, 17 May 1992 20:43:27 GMT In article <1992May17.152417.25391@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: >In article <1992May17.020951.28695@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >>BRRR, registers, interrupts, variable-length instructions ... Am I alone >>in thinking that the beauty of corewar lies in its simplicity? > > I must concur with Stefan. As far as I am concerned, if people want to >have registers, interrupts etc., let them go out and buy themselves an >Apple II+ or Commodore 64 and have at it at their leisure. Let's keep in >mind that corewar is a _game_. The point is not to come up with yet >another microprocessor. Let's leave that to the people at Intel and >Motorola. > -Andy >ajpierce@med.unc.edu Agreed. I would even be interested in playing a 6502 based CW-like game, but it wouldn't be corewar. Kevin kwhyte@math.uchicago.edu From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: New New Corewar Specs Message-ID: Date: Mon, 18 May 1992 04:05:05 GMT Control transfers out of cache should suffer the same fetch penalty. I'm sure of this on the basis of consistency, I suspect it may be useful for game balance too. ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: A few ideas for the NEWARS IS. (long) Message-ID: Date: Mon, 18 May 1992 04:34:39 GMT (Actually I fall in the "minimal revisions" camp, even though I was the one who suggested looking at "real" machines for ideas. But some of the following deserved comment, I thought, for one reason or another). Anyone, incidentally, want to talk some more about "8000"? In article <21547@castle.ed.ac.uk> kertsine@castle.ed.ac.uk (K Scheffler) writes: |Thesis : COREWARS learning curve is too damn long at the moment. One of |the reasons I don't play much at present is because too much leg work |is required to take an algorithm and make it into an effective warrior. |ANY new instruction set ought to take these as it's primary considerations. I strongly disagree. I found it to be a definite case of "read spec, write code" (ok, I admit my brain is optimisaed for this function, but still). There is a definite knee at around the performance of XTC, but the information you need to get this far is staring you in the face in the spec (what a pity I didn't take up the game when that could still win ;-). |3 > Fully RISC design |By which I mean that any instruction can apply to any register, and |there should be the *minimum* of quirks. You mean "orthogonal". The VAX, the ultimate CISC, had orthogonality to the hilt. The RISC philosophy (in my formulation) is "if it extends the cycle time by one tenth of one percent, it needs to shorten the instruction stream by more than that", and fuck everything else. If a RISC (in the real world) has no "quirks" of this sort, that tells you something about what kinds of hardware work well. If that is ALSO good for the programmer, this is evidence for the profound fact that your brain is also a finite state machine, and the SAME optimisations apply! |4 > *Minimum* number of addressing modes |I don't see any reason, if you have registers, to have *any* addressing |modes other than direct and offset-by-another-register's contents. If you've got an add instruction, no need! |5 > Free Stack |Give programs a stack to use for free : ie, it exists as part of the |"processor". If programs want a stack pointer, they can use one of the |other registers : but by and large, I don't think the typical "newcode" |program will have much use for complex stack manipulation. Be generous Ha ha. I was experimenting, for instance, with keeping a kill target queue. They get big. |with the stack too : give them 255 words each. (actually, I can see a 255 is a BIG STACK???? It's certainly small enough that overflow will be algorithmically crucial. |problem with this one. Suppose a program pushes it's code on to the |stack then copies a "boot block", JUMPs to the boot block, then SPLITS |back to the original code? Is this making life too easy?). Yes. State needs to be exposed in this game. It's the point! (I think.) |Registers A B C P (P is program counter). [] = using value of another |register. So MOVE [A] [B] moves contents of address pointed to by A to |address pointed to by B. I'm fairly sure we'd want to be able to use |immediate constants like ADD A 1, but not so sure that things like |MOVE [2] [4] ought to be legal : if you have this, what's the point of |having any registers (label a memory address, and voila, it's a |register). I'm *very* uncertain about this. "Minimum quirks" you said. It's legal. |Arithmetic Instructions : |Really ought to have a full set : I'm not sure about MULT and DIV, which |really ought to take longer than a single instruction. I'd be tempted |to allow programs to use them in one cycle just to keep life simple, and |to encourage more complex algorithms. Why ought they? If they are sufficiently strategically crucial that this statement is justified, then you'd be SURE they should go in! (BTW, there are things they would be very useful for - not least writing core-size-independent code. It would be fun, and encourage SOME kinds of intelligence, to choose the core size randomly - telling the warriors about it, of course). |Logical Instructions : |Ditto. The lack of things like AND, NOT imposes quite a lot of |restrictions on programs (and when was the last time you saw a processor |without them, huh?). I've honestly had less need. And the reason they are there conventionally is to do with ALU structure: they're just easy to do. Certainly in a situation where the core size is not a power of two they raise some thorny issues; 8000 is 2^6 * 5^3 so for absolute strict consistency the "boolean" operators ought to provide arithmetic in six copies of Z|2 and three of Z|5. What ORDER do these go into the word? But on reflection, I approve. Hi kwhyte. |Flow of Controll statements : |Keep life simple. Instead of having special instructions to do these |things, use general instructions on P. For instance, ADD P 5 would be |make the next instruction executed the one 5 hence. I don't have any |ideas about the decision making instructions, but I don't like the |current method much. If you had an add-with-carry instruction.... ;-) |Addressing : |This is the toughie. Are things like MOVE [3] [4] ok? And if so, what |about ADD [3] [2]? My suggestion would be to outlaw use of immediate |constants in relative instructions (ie no MOVE [3] [4]), and *possibly* |outlaw instructions of the form ADD [a] b, forcing most non-MOVE |instructions to be register-to-register only. Minimum of quirks. Put those back! |Also, should addressing be relative? And if so, relative to what? |Things being relative to the PC is a little confusing, that's for sure. It's a DAMN sight better than absolute, both in real life and in the Core. |Perhaps a SETREL instruction would help (when executed, all addresses |become relative to that point). But if so, we certainly *don't* want |SETREL to take any arguments..... And you just added another register.... |Problems : |A few obvious ones. Do instructions have to have the same binary values |over different systems, so tricks like using your own instructions as data |always work? Do registers always have to be the same size (obviously YES. |yes if left and right shift will still work). And how will multi-tasking Remember that these shifts are working in Z|coresize. Think hard.... |and program replication work? (I have a few suggestions about this, but |they have probably been aired in the ICWS newsletter by now). ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- Date: Mon, 18 May 1992 13:43:10 EDT From: Message-ID: <92139.134310JJJ101@psuvm.psu.edu> Subject: Re: new corewar specs In article <1992May15.194823.8837@athena.mit.edu>, kdmiller@athena.mit.edu (Kenneth D Miller) says: > >But, since we're trying to keep things reasonable, limiting the number of >registers is a definite must. With 256 registers like some RISC processors >have (really, they do!), programs could hide way too much data in "unhittable" >space. Let's go to the old 6502/6809 thing: three real registers, and >some "spares" > How about just 4 general purpose registers: r1, r2, r3, and r4. From: eric@turing.acs.virginia.edu (Eric Prestemon) Subject: Is KotH Biased? Message-ID: <1992May18.145513.24848@murdoch.acc.Virginia.EDU> Date: 18 May 92 14:55:13 GMT As I understand KotH (and no flames if I am wrong), the scores of the current Hill'ers (of which I have 2 =) ) are based upon their fights with the current Hill'ers and all challengers since they arrived. In other words, my 2 programs have fought 19 tough programs and many programs of various degrees of difficulty. On the other hand, a challenger's score is only based on fighting 19 tough programs...more difficult, I would say. As I see it, this isn't fair, and there are 2 choices... 1) People stop sending in attempts to get low scores and/or files meant only to kill existing programs. 2) The scores of the top 20 only reflect their battles against each other. Now, if the idea is to make it more difficult to get on than to stay on, fine....but for us bottom 5'ers, it would be nice to have those bottom positions more fairly determined. (Top codes surely can get on without the help of this 'feature') Even at the top, a new code is probably coming in a few spots too low, compared to the older programs. Thoughts? -- Eric Prestemon (ecp2z@virginia.edu) "Jesus saves! Gretzky steals! Gretzky scores!" From: wms@iwarp.intel.com (William Shubert) Subject: KotH weekly standings Message-ID: <1992May18.195807.22815@iWarp.intel.com> Date: Mon, 18 May 1992 19:58:07 GMT OK, here's the current standings: # %W/ %L/ %T Name Author Score Age 1 55/ 35/ 10 Crimp Andy Pierce 175 59 2 49/ 29/ 23 Note Paper Scott Nelson 168 115 3 51/ 38/ 11 Charon v5.0 J.Cisek & S.Strack 164 80 4 48/ 35/ 17 Dynamic Duo 4.0 Stefan Strack 160 5 5 48/ 41/ 10 Agony 2.3a Stefan Strack 155 31 6 48/ 40/ 12 Sucker 2 Stefan Strack 155 17 7 50/ 45/ 6 Frantic 0.5 Unknown Author 155 82 8 46/ 40/ 15 return of the living dead nandor sieben 151 110 9 47/ 44/ 9 PitTrap v3.0 J.Cisek 149 42 10 40/ 35/ 24 Armadillo Stefan Strack 146 119 11 45/ 45/ 9 scissors88.3 Scott Nelson 145 26 12 40/ 40/ 20 Parthenos Pierre Dak Baillarge 139 3 13 44/ 54/ 2 worm optima (Eat your hea Campbell Fraser 135 120 14 41/ 47/ 12 Mutagen 2.1 Stefan Strack 134 21 15 41/ 48/ 11 Salammbo Pierre Dak Baillarge 133 13 16 42/ 53/ 5 sparkles Eric Prestemon 131 1 17 38/ 46/ 16 V3 Aleksey A. Baulin (s 130 64 18 41/ 51/ 8 tse-tse Eric Prestemon 130 4 19 41/ 54/ 5 Scizz Andy Pierce 128 57 20 35/ 46/ 19 Small 6o Andy Pierce 124 108 "Crimp" was posted to rec.games.corewar just recently so I won't bother with it's ";strategy" lines. On the X-hill: # %W/ %L/ %T Name Author Score Age 1 61/ 26/ 14 Juggernaut 5.0 Scott Nelson 196 39 2 53/ 34/ 13 Leaper-X 4.0 Jeff Raven 171 24 3 38/ 18/ 44 multi mice -x nandor sieben 158 23 4 43/ 34/ 23 Crimson v1.2a J.Cisek 153 5 5 33/ 16/ 51 MiniShwing! [x] v1.2 T. H. Davies 150 28 6 39/ 29/ 32 Spreader 2.0 Scott Adkins 149 26 7 32/ 18/ 51 Rabbits [x] Paul S. Kilroy 146 16 8 31/ 25/ 44 Bridge Scott Adkins 137 3 9 38/ 41/ 21 Test Jeff Raven 136 33 10 36/ 39/ 25 Slick2.0 Ray Cromwell 134 36 11 28/ 24/ 47 Virus Scott Adkins 132 35 12 36/ 41/ 22 UltraSlick Ray Cromwell 132 37 13 21/ 15/ 64 Tie-dye James Jesensky 128 10 14 18/ 10/ 71 ImpBreed-x 1.0 Jonathan Roy 127 30 15 27/ 29/ 44 Hitchhiker 1.0 James Jesensky 126 12 16 15/ 7/ 78 Absolute 251 James Jesensky 124 11 17 28/ 34/ 38 Stonewall Ray Cromwell 121 32 18 29/ 47/ 24 Rail Road 1.0 James Jesensky 111 17 19 30/ 50/ 20 Perpetual v1.1 Brant D. Thomsen 110 1 20 5/ 0/ 0 Night Train 1.0 James Jesensky 14 4 Nothing terribly new here. I hope to write a program of my own to try out as soon as I get some free time. "Night Train" has such a low score because it has been ";kill"ed but no challenger has come along yet to replace it. That it! For submission instructions just write. -Bill (wms@iwarp.intel.com) From: sbeitzel@wet.UUCP (Stephen Beitzel) Subject: Re: new corewar specs Message-ID: <3946@wet.UUCP> Date: 18 May 92 22:58:02 GMT There has been quite a bit of discussion of using registers and assorted low-level instructions in corewar. I must wonder, though, if they are appropriate. When A. K. Dewdney proposed the game 'way back when, didn't he state that the MARS (virtual machine) had *no registers*? I seem to recall that having been said somewhere, but I don't have that article anymore. Really, the lack of registers has been why I accepted such things as the lack of other instructions that every real processor has (shift, and the scads of instructions dealing with the stack and the branching instructions and...). Really, the MARS is a _virtual_ machine, meaning that we can do stuff with it that doesn't require all the knowledge of assembly programming that some of us have acquired. It allows us to focus on one aspect of AI. I realize that "original intent" doesn't count for a whole lot (in later columns, Dewdney proposed using the "blinkers" in Life to create rudimentary computers), but I think we should consider what we want to do with this keen tool/toy we've got. Steve -- Stephen Beitzel -- sbeitzel@wet.com | "Happy, happy. Joy, joy." "Ownership of the above opinions | depends solely on how offended you are | Relax. Have a homebrew. by them." | From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Straw Pole Message-ID: <59269@cup.portal.com> Date: Tue, 19 May 92 00:21:56 PDT Lots of people seem to have suggestions for how to make redcode better. There seems to be a lots of idea and very little consensus, there is one point however that I have seen brought up many times, with no one arguing against: All modes should be legal for all instructions (most notably SLT). Is there anyone who thinks this is a bad idea? |+---------------------------------------------------------------+| The people who complain the loudest about the incumbents, are usually the ones who didn't vote in the last election. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Modifications to corewar Message-ID: <59268@cup.portal.com> Date: Tue, 19 May 92 00:21:08 PDT Before posting changes I think you should ask yourself if the change will make Redcode; less complex, clearer, less ambiguous, more consistent/complete, and/or smaller. (I suppose one might add "easier to code specific ideas" to the list, but frankly I think that too many people confuse shorter code, with "easier" code.) If your answer is "yes" or "maybe" then post it, but if your answer is "no" then I think you should refine your idea first. It is o.k. to contemplate variable length instructions and/or cycle times and such, but are these changes going to make things any better, or just more complex? Remember too that any changes will have to be defined completely, This isn't to big a problem for things like DIV MUL and MOD, but could be devastating for things like cycle times, and caches. Just my two cents. |+---------------------------------------------------------------+| I don't care what the rules are, just tell 'em to me in advance. <<>> Subject: Re: new corewar specs Message-ID: From: stephen@estragon.uchicago.edu (Stephen P Spackman) Date: Tue, 19 May 1992 17:15:04 GMT I say, the phrase "virtual machine" (like "pseudocode"!) has a good and useful technical meaning. Could we perhaps avoid using it (and "pseudocode"!) when we just mean, "it's interpreted"? I, for one, would be majorly pissed if my operating system "implemented" virtualisation through interpretation! ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- Subject: Fibonacci scan Message-ID: <92140.190534AZNXS@ASUACAD.BITNET> From: Date: Tuesday, 19 May 1992 19:05:34 MST Could somebody explain why this is the best? We hardly know what does good mean. From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: RoboSport by Maxxis Message-ID: <167ECF0BE.DURHAM@ricevm1.rice.edu> Date: Tue, 19 May 1992 22:07:10 GMT Does anyone have any experience with the software game "RoboSport" published by Maxxis (the "SimCity/Earth/Ant" company)? Is it worthwhile? Mark A. Durham MAD From: rodmur@ecst.csuchico.edu (Dale or Wolfgang or the Molasses Man) Subject: Code examples Message-ID: <1992May19.230307.19568@ecst.csuchico.edu> Date: 19 May 92 23:03:07 GMT Does anyone happen to have any good examples of good corewar code sitting out there at an anonymous ftp'able site. -- __ _ Dale A. Harris / ) // / rodmur@ecst.csuchico.edu / / __. // _ , , , __. _ /_ _ __ _ {Internet} /__/_(_/|_ Date: Wed, 20 May 1992 02:32:24 GMT On the register idea, i'd just like to add my .02$ worth (for a current total of 4 cents): Even only one register would be a good thing and would make it so much easier to implement stack and subroutines. But I had an idea... What about making the register be the equivalent of the address 'coresize' ? So the next address of the register would be 1 (relatie to the last memory you fetched (using the separate address for opcode and operand). This would lend sense to something like: jmp r0. That would execute the opcode in the register, its argument (A and possibly B) would be the address right after the jmp r0. The only problem with registers is that you'd need to define a value that would be the register so that it can be detected. Any value would put limit on the implementation and coresize (for example if 32000 was chosen, you would be restricted to coresize of less than 32000, but if we use 20000000, then all implementations of corewar would need to use long int. The easy way around this would be to add an addressing mode: register. We could use ':' for it's symbol. The neat thing about this would be that, just like memory, the register number would be modulated (moduloed ?) to the number supported by the interpretor. This would make some programs crash when not enough registers are available (lost of data) but anyway, KotH truly shows that whatever the limitation (core size, number of tasks) programs are crafted for a specific environnement. That would just be another variable in the env. Also, on another subject, the idea of variable length move (mov.l mov.s mov.b etc...) is good but I think the implementation suggested are not adequate. It would be much more useful to simply specify the word size you move: mov.2 0, 1 ; move two locations We would need to specify a maximum (could be like task number, adjustable), so that program like move.99999 1, 2 don't show up... Of course, this idea need the "one read or write" = "one cycle" idea... -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: KOTH -x question. Message-ID: <1992May20.065856.25148@usenet.ins.cwru.edu> Date: 20 May 92 06:58:56 GMT How is addressing over 256 handled? I mean, when programs are compiled on the KOTH -x hill, they still show as 7999 for -1, and so on. Basicly, my question is this. On a normal hill MOV 0 8001 is the same as MOV 0 1. On the -x hill, is MOV 0 257 the same as MOV 0 1? I'm not to clear on this point... Thanks. ||| Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu ||| -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet -- / | \ "...make him want to change his name,take him to the cleaners, devastate him, wipe him out, humiliate him." -CHESS GEnie: J.ROY18 From: ee01th@ee.surrey.ac.uk (Piglet) Subject: Re: KOTH -x question. Message-ID: <1992May20.112111.3495@EE.Surrey.Ac.UK> Date: 20 May 92 11:21:11 GMT In article <1992May20.065856.25148@usenet.ins.cwru.edu>, as666@cleveland.Freenet.Edu (Jonathan Roy) writes: |> |> How is addressing over 256 handled? I mean, when programs are compiled |> on the KOTH -x hill, they still show as 7999 for -1, and so on. Basicly, |> my question is this. |> |> On a normal hill MOV 0 8001 is the same as MOV 0 1. On the -x hill, |> is MOV 0 257 the same as MOV 0 1? |> |> I'm not to clear on this point... Thanks. My understanding of it is MOV 0 257 is exactly what it says. However, the write address is out of range, and therefore no writing takes place. On the other hand MOV 257 0 wound actually copy the data in address +257 to the current loc. as the restriction only applies to writing. Please someone correct me if I am wrong. -- / \ |email: ee01th@ee.surrey.ac.uk O O |---------------------------- ______ |Science is the game you play / \ |with God to find out what His | | |rules are | o o | |----------------------------- | | |ham(X) :- pink(X). |\______/ |pink (i). | |?-ham(i). | |yes. \______/ I G L E T ! | I am a .signature virus. Copy me to your .signature file and watch me spread. From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: JMP r0 Message-ID: <167ED87A0.DURHAM@ricevm1.rice.edu> Date: 20 May 92 14:38:34 GMT In article <1992May20.023224.19407@vlsi.polymtl.ca> dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) writes: > This would lend >sense to something like: jmp r0. That would execute the opcode in the register Executing anything in a register is not only non-sensical (unless you consider cache to be a big set of registers), it is also very dangerous to the game. If Core War were to admit protected instructions in the sense of private memory inaccessible to opponents, indestructable programs would surely arise (because they ran entirely as protected instructions) and then what would be the point of the game? I know that this is not exactly what Mr. Baillargeon was suggesting, but a great deal of the discussion has been moving in this direction. Mark A. Durham MAD From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Protect (PCT) and intelligence Message-ID: <167ED8AE0.DURHAM@ricevm1.rice.edu> Date: Wed, 20 May 1992 14:52:31 GMT A brief review of the PCT instruction: The PCT instruction was mentioned briefly by A. K. Dewdney at the end of his original Core War article. He suggested that the instruction be used to protect memory (one instruction at a time) from a single attempt at overwriting the protected instruction. Thus protect PCT 0 ; protects this instruction MOV bomb, protect ; fails to overwrite instruction at protect MOV bomb, protect ; succeeds in overwriting instruction at bomb DAT #0 ; protect The immediate result of adding PCT to Core War would be that "dumb"-bombers would have to bomb each location twice to virtually (ooops, excuse the non-technical use of the word :) guarantee success. My question is this: "Would adding PCT benefit larger, more 'intelligent' programs moreso than 'dumb'-bombers?" (Note: My 0.5 claim-to-fame is in the use of PCT as an offensive "landmine" weapon by protecting DAT instructions in the hopes of a program like IMP failing to copy itself over it.) Mark A. Durham MAD From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Re: Code examples Message-ID: <1992May20.100554@IASTATE.EDU> Date: Wed, 20 May 1992 15:05:54 GMT Lots of good stuff on soda.berkeley.edu in the public/corewar directory. Check it out!! :-) *********************************************************************** * Warren Kurt * "I believe there is an inteligence to the universe * * vonRoeschlaub * with the possible exception of certain parts of * * kv07@iastate * New Jersey" -Woody Allen * *********************************************************************** From: eric@turing.acs.virginia.edu (Eric Prestemon) Subject: Need Postincrement implementation Message-ID: <1992May20.154620.21924@murdoch.acc.Virginia.EDU> Date: Wed, 20 May 1992 15:46:20 GMT I currently use Corewars Deluxe v1.3 to test my programs. However, I have been dabbling in the experimental hill, which uses postincrement mode. This is non-standard, and not supported (at least in the version I have) by Corewars Deluxe. So, does anyone have a patch for corewars deluxe, or another program that can handle postincrement? Much thanks... -Eric -- Eric Prestemon (ecp2z@virginia.edu) "Jesus saves! Gretzky steals! Gretzky scores!" From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Protect (PCT) and intelligence Message-ID: <1992May20.162914.20528@vuse.vanderbilt.edu> Date: Wed, 20 May 1992 16:29:14 GMT In article <167ED8AE0.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >My question is this: "Would adding PCT benefit larger, more 'intelligent' >programs moreso than 'dumb'-bombers?" Great! I am very glad Mark brought up PCT. What were the reason for its exclusion from ICWS'86 (while just about everything else from AKD's articles was included)? Apart from allowing neat imp-traps, new modes of attack (protecting enemy data), methinks it would allow larger programs to be viable competitors: (a) programs would need to be fairly certain that an address contains enemy code before double-bombing, because this is expensive both in time and space. (b) "static" code of large programs can be protected by an initialization loop. -Stefan (stst@vuse.vanderbilt.edu) P.S.: I included PCT in CoreWar Pro and spent quite some time designing nifty self-protecting warriors, before I found out that ICWS omitted PCT. Boy was I disappointed! From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Re: Protect (PCT) and intelligence Message-ID: <167EDCCE6.DURHAM@ricevm1.rice.edu> Date: 20 May 1992 19:34:08 GMT In article <1992May20.162914.20528@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: > What were the reason[s] for [PCT's] >exclusion from ICWS'86 (while just about everything else from AKD's articles >was included)? > 1) It was a speculative opcode in Dewdney's original article. 2) Graeme McRae did not write it into his draft standard (I do not know why). 3) Dewdney had not anticipated offensive uses of the opcode. He seemed a bit disturbed by it (at least in print) and more or less frowned on its use in the follow-up article. 4) It requires an extra bit for each instruction. 5) No one thought it was worth the trouble at the time. Mark A. Durham MAD From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: Need Postincrement implementation Message-ID: <1992May21.002202.19330@oucsace.cs.ohiou.edu> Date: 21 May 92 00:22:02 GMT In article <1992May20.154620.21924@murdoch.acc.Virginia.EDU> eric@turing.acs.virginia.edu (Eric Prestemon) writes: >I currently use Corewars Deluxe v1.3 to test my programs. >However, I have been dabbling in the experimental hill, which >uses postincrement mode. This is non-standard, and not supported >(at least in the version I have) by Corewars Deluxe. > >So, does anyone have a patch for corewars deluxe, or another program >that can handle postincrement? Much thanks... > >-Eric >-- >Eric Prestemon (ecp2z@virginia.edu) >"Jesus saves! Gretzky steals! Gretzky scores!" Ok, I will see what I can do... :-) I have the post-increment already in the program... I will have a new version (just a minor change) distributed to soda.berkeley.edu by this Friday or by the weekend. It is definitely time to have it! :-) If anyone would like to suggest any additions, changes or corrections to the Core Wars Deluxe, please feel free to send me mail! I have had some wonderful suggestions, and it is you that make the program the best that it can be. The major new version will be released sometime this summer, with complete fully compliant standards, and will in all probability be completely compatible with any of the experimental rules that are currenlty being used in X-Koth... (post-inc, write limit, all modes, etc). Please send all mail to "sadkins@ohiou.edu". Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: cpbeaure@cayley.waterloo.edu (Chris Beauregard) Subject: Re: Protect (PCT) and intelligence Message-ID: <1992May21.013746.8091@undergrad.math.waterloo.edu> Date: Thu, 21 May 1992 01:37:46 GMT In article <167ED8AE0.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >A brief review of the PCT instruction: > > The PCT instruction was mentioned briefly by A. K. Dewdney at the end >of his original Core War article. He suggested that the instruction be >used to protect memory (one instruction at a time) from a single attempt >at overwriting the protected instruction. Thus [Chop chop chop] >My question is this: "Would adding PCT benefit larger, more 'intelligent' >programs moreso than 'dumb'-bombers?" I like to beleive so. As a veteran of the R. Martin Mac implementation of CW, I did a lot of work with the PCT instruction. I found that I could put together a lot of fairly smart programs that could take on many of the smaller ones without that much problems. A few things PCT can bring about... Turtles: programs that protect their own code...this could mean the code itself or a copy of it. Imp Stompers are a piece of cake.. You can make some VERY nasty bombs with the PCT. Bombs resistant to, say attempts to clear them made by mobile programs. Series of 'PCT 0' instructions, etc. Imp-like bombs become more feasable when there's a sure-fire (almost) way of killing the target. There's probably a heap of new things that I never got around to using... >(Note: My 0.5 claim-to-fame is in the use of PCT as an offensive "landmine" >weapon by protecting DAT instructions in the hopes of a program like IMP >failing to copy itself over it.) Yeah, that's fun. You can also use it to capture an IMP to do all kinds of neat things (rebuilding the protection is pretty important) The following at the start of a program is pretty handy... PCT 0 DAT 0 start PCT -2 An imp-stomp that doesn't take up any processes, and rebuilds itself. No good aganst worms, but it's a start...Replacing the DAT with some slaver code gives the program some potential (and makes it a little better target for scanners...but life's like that) A possible extension of the PCT instruction that would make the game tougher would make a protected cell CoMPare as a 'DAT #0,#0' cell. Would make life hell for scanners, but it would also limit things like trying to compare a chunk of your own code to instructions (like, trying to find that imp coming at you...) >Mark A. Durham >MAD ---------------------------------------------------------------------------- Chris Beauregard cpbeaure@cayley.waterloo.edu .sig under construction beware falling characters From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: new corewar specs Message-ID: <1992May21.023419.29817@vlsi.polymtl.ca> Date: Thu, 21 May 1992 02:34:19 GMT These are comment on several recent post: I agree that too many registers would be dangerous, but since only one word is contained, no instruction can be completly in the register. It would be just like a jmp 0 currently (one vulnerable location). On the x-hill, is pre-decrement also considered a write to memory ? If not that would be most interesting (but surprising). On the PCT, that wouldn't change dwarf too much, just slowing it down 33% (might be significant, but this would allow only 33% larger programs). This is no big deal. Effective algorythm have a bigger influence (for example, Parthenos is a slaver-clearer only 6 instructions long but gets beaten by program twice its size). It would really kill mice off however... atomic location: currently, a move immediate just move the value, not the addressing mode. Where would be coded the addressing mode ?? I guess it would not have influence on execution. Using a separate location for the mode would be REALLY pushing things too far. And finally, all the things I said were just idea thrown in the air, not necessarily things I'd like to see or think would be important. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: DURHAM@ricevm1.rice.edu (Mark A. Durham) Subject: Absence Message-ID: <167ED147EC.DURHAM@ricevm1.rice.edu> Date: 21 May 1992 04:19:07 GMT I regret I will be absent from the net and unable to answer EMail for an undetermined period. I will most probably re-appear with a new address. I will post a message when I have returned. Sorry for any inconvenience this may cause. I am absent . . . now! Mark A. Durham MAD From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: Fibonacci scan (long & theoretical) Message-ID: <1992May21.060729.6508@samba.oit.unc.edu> Date: Thu, 21 May 1992 06:07:29 GMT In article <92140.190534AZNXS@ASUACAD.BITNET> writes: >Could somebody explain why this is the best? We hardly know what does >good mean. Well, since I brought this thing up, posted appropriate constants and use it on KotH, I suppose I better have a crack at explaining the theory. The object is, simply put: find your opponent's executing code. The question is: what is the most efficient way to do that? The optimal way to find/hit a piece of code N instructions long is to bomb/search memory in steps of N. For simplicity, let's assume a coresize of 60 addresses. Now if you know that your target is 5 instructions long, you begin by bombing at an arbitrary address which I will designate as 30. For a 5 instruction target, you have covered starting addresses of the 5 instruction target in the range of 26-30. It is tempting to think that you have covered addresses 26-34 but this is not the case. There could be 60 initial placements of the target. Your single bomb has reduced the number of viable initial placements by the target length, i.e. 5. Now. Where should your next bomb go? You want each bomb to reduce the number of viable initial opponent placements by a maximum value, which can be no greater than your opponent's length (which is why length of a program is such a cruical parameter BTW). If your next bomb goes in locations 26-34, the amount of core covered has not been maximized. At location 33 for example, there are now 8 addresses covered. A bomb dropped in any location away from a previous bomb +/-N will cover N more initial placements (the maximum) so for convenience, you might as well bomb N units away from a previous bomb. By way of illustration, consider trying to bomb an N=5 target with a mod 5 (mod N in this case) scan. After 60/N=12 bombing cycles, there is nowhere in the 60 address space that the target could have been placed without being hit. If you use a mod 6 scan, then after 60/6=10 bombing cycles, you have covered the core once, leaving 10 possible safe initial placements. It takes a further 10 bombing cycles to cover all possible placements in this case for a total of 20 cycles. If you use a mod 4 scan, then it takes 60/4=15 bombing cycles to completely cover the core which again is less efficient than a mod N scan. The bottom line: if your increment is _smaller_ than the target size, you lose efficiency because you do not cover the core as fast as you could have to ensure one hit on the target. If your increment is _larger_ than the target size, you lose efficiency only if, when you go back to rescan the areas you missed on the first pass, you now are scanning, relative to your first pass, at increments smaller than the target size. Now on KotH, the programs are of various sizes. Ideally one would have a pattern that initially takes big steps through the core in order to rapidly kill the large programs and which then subdivides these initial big steps into the largest possible substeps in order to most efficiently find intermediate size programs and so on subdividing until the smallest programs have been found. The best way to do this would be with a binary search, i.e. initially put bombs coresize/2 apart, then coresize/4 from those bombs, then coresize/8 from all previous bombs etc., however, as has been pointed out in r.g.c., this is practically not viable. What is the next best practical pattern? I have found a fibonacci type pattern to fit the bill here. In this type of scan, bomb intervals of 34 are subdivided into 21 and 13. The 21 is then divided into 8 and 13. The 13's are then divided into 8 and 5. Then all the 8's are divided into 5 and 3. Then all the 5's are divided into 3 and 2, the 3's go to 2 and 1's and finally the 2's go to 1's and the scan is complete. It's not a binary scan, but it's reasonably close, still pretty efficient and, _it can be done easily_. Try it yourself with a coresize of 8000 and a graphical display and see how quickly the big holes in the bombing pattern get reduced to small holes. mod1 scan (every location ultimately hit): 5807 (offset from last bomb) mod2 scan (hits every other location): 5138 mod4 scan (finishes with bombs 4 apart): 7308 mod5 scan: 1545 Note that in a coresize=8000, there is no simple offset which will bomb mod3 and then not keep on bombing down to a mod1 scan. If anyone can come up with a more efficient pattern which can be implemented by having a constant displacement from the previously dropped bomb, I would love to hear about it. -Andy ajpierce@med.unc.edu P.S. Efficiency could possibly be modelled as approaching a maximum as the following function is minimized: last bomb dropped --- \ (distance from newest bomb to closest previous bomb behind)^X+ / (distance from newest bomb to closest previous bomb ahead)^X --- second bomb dropped where X>1. From: mendels@eniac.seas.upenn.edu (Jeffrey Mendelsohn ) Subject: KOTH, I made a boo-boo Message-ID: <78591@netnews.upenn.edu> Date: 21 May 92 12:48:09 GMT OOPS!!! I accidentally submitted a program to the hill with the same name as a previous program. I will kill both of them and resubmit later. Sorry all, J. Mendelsohn From: rt22@unix.brighton.ac.uk (Richard Thomassen) Subject: Corewar - what is it? Message-ID: <1992May21.144114.6162@unix.brighton.ac.uk> Date: 21 May 92 14:41:14 GMT Greetings. I have just found this user group. 1 question - what the hell is corewar? Richard Thomassen. From: doetzl@spot.Colorado.EDU (Joe Doetzl) Subject: Scientific American Message-ID: <1992May21.164028.20165@ucsu.Colorado.EDU> Date: Thu, 21 May 1992 16:40:28 GMT Could someone please send me the bibliographical reference(s) for the Scientific American article(s) about corewars? Thank you --Joe From: ray@chopin.udel.edu (Thomas Ray) Subject: Tierra V3.12: Evolution of Digital Organisms Message-ID: <19869@chopin.udel.edu> Date: 21 May 92 16:54:34 GMT TIERRA UPDATE: (Version 3.12 Now Available, Unified License Agreement, FTP Site Reorganized, Bug Fixes, Resolution Toggle, Phylogeny, Tierra in the News, Tierra Publications, Mailing Lists, What Tierra Is) Note: V3.12 has been released because of an additional bug fix, the template search bug. See section 4) below. This message contains: 1) Availability of Tierra V3.12 Source Code a) by ftp b) by snail mail on disk 2) Unified License Agreement 3) FTP Site Reorganized 4) Bug Fix 5) Resolution Toggle 6) Future Phylogeny 7) Tierra in the News 8) Tierra Publications 9) Mailing Lists 10) What Tierra Is 1) Availability of Tierra V3.12 Source Code The Tierra V3.12 source code; and the source code, and DOS executables of all tools is available now. Please note that the source code in the ftp site and the source code provided on disk will each compile and run on either DOS or UNIX platforms. It is exactly the same source code in either case. If you purchase this program on disk, thank you for your support. If you obtain the source code through the net or friends, we invite you to contribute an amount that represents the program's worth to you. You may make a check in US dollars payable to Virtual Life, and mail the check to one of the two addresses listed below. a) by ftp If you use the software, be sure to pick up new versions from the ftp site. The source in the ftp site will be replaced on a roughly monthly or bi-monthly basis. The complete source code and documentation is available by anonymous ftp at: tierra.slhs.udel.edu [128.175.41.34] and life.slhs.udel.edu [128.175.41.33] in the directories: almond/, beagle/, doc/, and tierra/. To get it, ftp to tierra or life, log in as user "anonymous" and give your email address (eg. tom@udel.edu) as a password. Be sure to transfer binaries in binary mode (it is safe to transfer everything in binary mode). Each directory contains a compressed tar file (filename.tar.Z) and a SRC directory that contains all the files in raw ascii format. You can just pick up the .tar.Z files, and they will expand into the complete directory structure with the following commands (Unix only): uncompress tierra.tar.Z tar oxvf tierra.tar b) by snail mail on disk The source code, documentation and the beagle.exe file can be distributed freely, however, the executables (the .exe files in DOS) are for sale and cannot be freely distributed (with the exeception of beagle.exe). If you do not have ftp access you may obtain everything on DOS disks by making a check for $65 (US dollars drawn on a US bank) payable to Virtual Life. Specify 3.5" or 5.25" disks. Send the check to one of the following addresses: Tom Ray (January through August) Santa Fe Institute 1660 Old Pecos Trail Suite A Santa Fe, NM 87501 Virtual Life (September through December) P.O. Box 625 Newark, Delaware 19715 The DOS disks contain everything but ALmond (ALmond can be provided on disk by request, but it only runs on a Unix platform). The disks include DOS executables, source code and documentation. The DOS disks include an easy installation program. This is the same source code available in the ftp site. If you have ftp access, there is no need to buy the disks. 2) Unified License Agreement If you have seen the earlier versions, you may have noticed that there were different license agreements for the DOS and Unix versions. There is now a single and perhaps more coherent license agreement. 3) FTP Site Reorganized With Version 3.11 the ftp site was reorganized. The files are no longer distributed in shar format. They are in both raw form, and in compressed tar files. All the documentation has been moved to the doc/ directory. The doc/ directory also includes manuscripts on Tierra in LaTeX and Postscripts formats. 4) Bug Fix template search - Version 3.11 and earlier had a bug in the bi-directional template search algorithm. God intended that the search should move outward at equal rates in both directions. However, some situations caused one direction to get ahead of the other. This does not matter to the creatures or evolution; evolution makes due with whatever physics or chemistry it has at hand. However, it makes it difficult for the observer reading the genome files to tell what the outcome of a bi-directional template search might be. Another problem with the same algorithm is that the limit on the distance of the template search was not properly implemented, they tend to search farther than the intended limit. Both these bugs are fixed in V3.12. 5) Resolution Toggle In V3.12 on DOS machines with a VGA display, the simulator will come up in low resolution mode. If you select a histogram or size list display, it will toggle into high resolution mode. When you return to the plan display, it will toggle back into low resolution mode. This is easier on the eyes. 6) Future Phylogeny At the moment, the primary effort in new code development is dedicated to an extension to the genebanker that will produce an ironclad phylogeny. The requires that we trace the genetic source of every instruction written into every creature. Stay tuned. 7) Tierra in the News The Tierra Simulator has been widely reported in the media. Below is a list of most of the national or international reports that I am aware of. If you know of some news report not on this list, please send me a hard copy. Nature (John Maynard Smith, UK) February 27, 1992: ``Byte-sized evolution. ...we badly need a comparative biology. So far, we have been able to study only one evolving system and we cannot wait for interstellar flight to provide us with a second. If we want to discover generalizations about evolving systems, we will have to look at artificial ones. Ray's study is a good start.'' New York Times (Malcolm Browne, USA) August 27, 1991: ``Lively Computer Creation Blurs Definition of Life. Software forms, obeying Darwin's rules, vie to avoid the `reaper'.'' Science News (John Travis, USA) August 10, 1991: ``Digital Darwinism: Electronic Ecosystem. Evolving `life' flourishes and surprises in a novel electronic world''. Scientific American (John Rennie, USA) January 1992: ``Cybernetic Parasites... Tierra... has been hailed as the most sophisticated artificial-life program yet developed...'' New Scientist (Roger Lewin, UK) February 22, 1992: ``Life and death in a digital world. No one can turn back the evolutionary clock, but we can follow the fate of a rich menagerie of artificial organisms as they evolve in a model world.'' The Economist (Anon, UK) January 4, 1992: ``The meaning of `life'. In order to understand the origin of life, scientists are switching from the chemistry set to the computer. In the process, they are beginning to understand what it means to be alive.'' Actuel (Ariel Kyrou, France) April 1992: ``Visite Guidee Aux Extremes De La Science: La Vie Artificielle. Etes-vous pr\^{e}ts \`{a} entrer dans l'univers vertigineux de la vie artificielle? Un champ scientifique tout neuf sur lequel se penchent les grosses t\^{e}tes et les Nobel de labos am\'{e}ricains.'' The Chronicle of Higher Education (David Wilson, USA) December 4, 1991: ``Approaching Artificial Life on a Computer. Survival-of-the-fittest electronic organisms dramatically illustrate Darwinian principles.'' Mikrobitti (Pekka Tolonen, Finland) November 1991: ``Olemmeko humanoiden biologinen koe? Tierra simuloi el\"{a}m\"{a}\"{a}.'' Europeo (Giovanni Caprara, Italy) September 1991: ``Anche il computer ha fatto un figlio. Un biologo americano ha creato un software capace di elaborare programmi che si evolvono da soli.'' GenteMoney (Riccardo Orizio, Italy) November 1991: ``Cos\`{\i} ho dato la vita al software.'' Computerworld (Michael Alexander, USA) September 30, 1991: ``Tierra adds to evolutionary studies. A computerized world created on an IBM PC could have real-world benefits for scientists.'' Sueddeutsche Zeitung (Konrad Peters, Germany) October 21, 1991: ``Die Evolution im Computer. `K\"{u}nstliches Leben' hilft Biologen und Informatikern auf die Spr\"{u}nge.'' Super Interessante (Anon, Brazil) November 1991: ``A vida dentro do computador.'' Technology Review (Susan Scheck, USA) April 14, 1991: ``Is It Live Or Is It Memory?'' Corriere Della Sera (Giovanni Capara, Italy) August 28, 1991: ``Pronto in USA il programma che si riproduce. Il computer `padre' crea vita informatica.'' Fakta (Tom Ottmar, Norway) March 1992: ``Den Lever! En `skabning', der best\aa r af nuller og \'{e}nere, er vokset ud af indamaden p\aa \ en computer og er blevet en videnskabelig sensation i USA.'' Associated Press (Theresa Humphrey, USA) October 1991: ``Bringing life to computer. U of D biologist's program is self-replicating, shows evolution.'' Hovedomr\aa det (Jakob Skipper, Denmark) December 6, 1990: ``Kunstigt liv. Nu kommer det kunstige liv. En voksende gruppe af dataloger, biologer, fysikere, psykologer og mange andre forskere efterlinger p\aa \ computer det naturlige liv.'' 8) Tierra Publications Ray, T. S. 1991. ``Is it alive, or is it GA?'' Proceedings of the 1991 International Conference on Genetic Algorithms, Eds. Belew, R. K., and L. B. Booker, San Mateo, CA: Morgan Kaufmann, 527-534. Ray, T. S. 1991. ``An approach to the synthesis of life.'' Artificial Life II, Santa Fe Institute Studies in the Sciences of Complexity, vol. XI, Eds. Farmer, J. D., C. Langton, S. Rasmussen, & C. Taylor, Redwood City, CA: Addison-Wesley, 371-408. Ray, T. S. 1991. ``Population dynamics of digital organisms.'' Artificial Life II Video Proceedings, Ed. C.G. Langton, Redwood City, CA: Addison Wesley. Ray, T. S. 1991. ``Evolution and optimization of digital organisms.'' Scientific Excellence in Supercomputing: The IBM 1990 Contest Prize Papers, Eds. Keith R. Billingsley, Ed Derohanes, Hilton Brown, III. Athens, GA, 30602, The Baldwin Press, The University of Georgia. 9) Mailing Lists There are two mailing lists for Tierra users. The first list is for people who only want to get the official announcements, updates and bug-fixes. The other will carry the official postings, and are intended for discussion of Tierra by users. This one is distributed in digest form, when there is enough material. The lists are: tierra-announce official updates, patches and announcements only tierra-digest discussion, updates, etc. (digest form) The addresses are: tierra-request@life.slhs.udel.edu the list administrator (Tom Uffner). to be added, removed, or complain about problems with any of these lists. tierra-digest@life.slhs.udel.edu to post to the list. tierra-bug@life.slhs.udel.edu for bug-reports or questions about the code or installation. You may also be interested in the Artificial Life mailing list. Subscribe to the list by sending a message to: alife-request@cognet.ucla.edu Post to the list by sending a message to: alife@cognet.ucla.edu 10) What Tierra Is The C source code creates a virtual computer and its operating system, whose architecture has been designed in such a way that the executable machine codes are evolvable. This means that the machine code can be mutated (by flipping bits at random) or recombined (by swapping segments of code between algorithms), and the resulting code remains functional enough of the time for natural (or presumably artificial) selection to be able to improve the code over time. Along with the C source code which generates the virtual computer, we provide several programs written in the assembler code of the virtual computer. One of these was written by a human and does nothing more than make copies of itself in the RAM of the virtual computer. The others evolved from the first, and are included to illustrate the power of natural selection. The operating system of the virtual computer provides memory management and timesharing services. It also provides control for a variety of factors that affect the course of evolution: three kinds of mutation rates, disturbances, the allocation of CPU time to each creature, the size of the soup, etc. In addition, the operating system provides a very elaborate observational system that keeps a record of births and deaths, sequences the code of every creature, and maintains a genebank of successful genomes. The operating system also provides facilities for automating the ecological analysis, that is, for recording the kinds of interactions taking place between creatures. This system results in the production of synthetic organisms based on a computer metaphor of organic life in which CPU time is the ``energy'' resource and memory is the ``material'' resource. Memory is organized into informational patterns that exploit CPU time for self-replication. Mutation generates new forms, and evolution proceeds by natural selection as different genotypes compete for CPU time and memory space. Diverse ecological communities have emerged. These digital communities have been used to experimentally examine ecological and evolutionary processes: e.g., competitive exclusion and coexistence, host/parasite density dependent population regulation, the effect of parasites in enhancing community diversity, evolutionary arms race, punctuated equilibrium, and the role of chance and historical factors in evolution. This evolution in a bottle may prove to be a valuable tool for the study of evolution and ecology. From: wms@iwarp.intel.com (William Shubert) Subject: Error in KotH detected Message-ID: <1992May21.235705.23510@iWarp.intel.com> Date: Thu, 21 May 1992 23:57:05 GMT Eric Prestemon noticed a pretty severe bug in KotH V2.4: postincrement just doesn't work...in fact, it acts a lot like predecrement. This bug was NOT present in V2.3, and it has NO effect on the ICWS '88 hill. However, I've fixed the bug and am rebuilding the experimental hill...if a program of yours that made heavy use of ">" fell off the hill, you might want to try again. In the meantime, this mean I'll have to release a V2.5. It'll probably be this weekend. Sorry for the inconvience. -Bill (wms@iwarp.intel.com) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Should KotH scores include self-battles? Message-ID: <1992May22.082301.9414@vuse.vanderbilt.edu> Date: Fri, 22 May 1992 08:23:01 GMT I'd like to put this up for discussion: Is it relevant whether a warrior can beat itself consistently? If not, why not save the time pitting a new challenger against itself on KotH? A lot of clever programs (foremost self-replicators) are robust against simple DAT-attacks by executing, e.g. a SPL 0 instruction. These warriors convert many losses to ties, but are punished because they tie themselves too frequently. With KotH scores being as tight as they are, self-battles can make a big difference, and it is often possible to move up a few ranks by including a provision for suicide after a few thousand cycles. ICWS tournaments don't include a bracket for self-battles, why should KotH? -Stefan (stst@vuse.vanderbilt.edu) From: dwp@willett.pgh.pa.us (Doug Philips) Subject: Re: New New Corewar Specs Message-ID: <3582.UUL1.3#5129@willett.pgh.pa.us> Date: 22 May 92 14:22:03 GMT In article <1992May17.195131.15472@athena.mit.edu> kdmiller@athena.mit.edu (Kenneth D Miller) writes: +After absorbing several complaints about the new corewar specs (registers, +interrupts, etc.), I decided to modify my corewar proposal and so, here is: + THE NEW & IMPROVED COREWAR PROPOSAL + Variable Instruction Times +All of the old addressing methods (with the addition of ">") would be exactly +the same. To add an interesting twist to things, memory accesses outside of +some pre-determined range should take longer. Memory accesses inside this +range would be "cache hits", and have an instantaneous fetch, whereas those +outside the range would require access to "physical memory" and use up cycles. +Instructions themselves should take one cycle. Since they are "in the cache", +there is no fetch time for the instruction and operands themselves; the only +time taken is that required to execute the instruction. Pardon me if I've missed this going by already, but one thing I'm not real clear on for variable instruction times is how "timesharing" is to be done. Does the simulator alternate on the basis of cycles or instructions? If cycles, then you have some non-trivial amount of hassle worrying about what happens to the data in multicycle instructions if the opponent happens to write over it. If you make the simulator switch on instructions, then that might just give an advantage to more complicated instructions. Although VITs are interesting, I'd suggest playing with them on an experimental basis before considering them for a standard. Seems to me like there is just too little data about just how that feature would affect playability. Play with it for a while, but don't standardize it yet. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei}!willett!dwp From: dwp@willett.pgh.pa.us (Doug Philips) Subject: Re: A few ideas for the NEWARS IS. (long) Message-ID: <3583.UUL1.3#5129@willett.pgh.pa.us> Date: 22 May 92 14:22:08 GMT In article stephen@estragon.uchicago.edu (Stephen P Spackman) writes: +(Actually I fall in the "minimal revisions" camp, even though I was +the one who suggested looking at "real" machines for ideas. But some +of the following deserved comment, I thought, for one reason or +another). ditto. ;-) +Anyone, incidentally, want to talk some more about "8000"? [...] +(BTW, there are things they would be very useful for - not least +writing core-size-independent code. It would be fun, and encourage +SOME kinds of intelligence, to choose the core size randomly - telling +the warriors about it, of course). Indeed. Wouldn't it be more interesting to have a range of core sizes instead of one fixed one? (you might put such environment-status info in memory at a known offset relative to the beginning (or end) each of the programs' code) +255 is a BIG STACK???? It's certainly small enough that overflow will +be algorithmically crucial. 255 is a SMALL STACK???? ;-) Depends on what kinds of things you want to use it for, don't it? +|Also, should addressing be relative? And if so, relative to what? +|Things being relative to the PC is a little confusing, that's for sure. +It's a DAMN sight better than absolute, both in real life and in the +Core. Indeed. +|Problems : +|A few obvious ones. Do instructions have to have the same binary values +|over different systems, so tricks like using your own instructions as data +|always work? Do registers always have to be the same size (obviously +YES. I second that YES. If you are going to implement a virtual machine (one that runs redcode in this case), then that stuff has to be common amongst all systems or they are not implementing the same virtual machine. If you want to talk about a family of processors... but then that is a whole 'nother ball game. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei}!willett!dwp From: Ordania-DM@cup.portal.com (Charles K Hughes) Subject: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <59452@cup.portal.com> Date: Fri, 22 May 92 16:42:18 PDT First, a complaint: KOTH is not ICWS'88 compliant. Specifically, the ADD and SUB instructions are supposed to add/sub the A and B values of both instructions if neither mode is immediate. The EMI88.C source that I have shows them adding only the B-values. Second, another complaint: Mark, your tutorial is nice, but you caused me great consternation with your explanation of the SLT instruction. The SLT instruction is not simply a CMP that does a LESS THAN comparison as I assumed (yes, I know what happens when you assume :). The ICWS'88 text explains this, yours does not. In addition, KOTH does not use SLT as I misunderstood it from your tutorial, but does follow ICWS'88 standards. (God, everybodys' a critic, aren't they? :) DISCLAIMER: I'm just a small fish in a big pond, I don't speak for the ICWS, so remember these are my SUGGESTIONS, OPINIONS, and THOUGHTS. I'm not laying them in stone, and couldn't even if I tried. Ok, now for the meat of this post...my suggestions for the UCWS'92 (USENET COREWAR STANDARD 1992) : New modes: > preincrement (+1 instead of -1 :), otherwise same as changed predecrement Changed modes: < predecrementing - works one way or the other. :) I think ICWS'88 is pretty clear on it (decrement memory, then load final reference), if there are objections, voice them. Change instructions: DAT the direct mode is allowed. SLT immediate modes are allowed (this obviates the need for an SGT instruction) Mode Effect # # Is A-value less than B-value? # B Is A-value less than the B-value of B? A # Is B-value less than the B-value of A? A B Is the B-value of A, less than the B-value of B? (an A or B in the MODE column indicates a non-immediate mode) MOV =\ ADD } immediate B modes are allowed. The effect is as in SUB =/ ICWS'86. CMP immediate B modes are allowed. The effect is that the B-value of the instruction pointed to by the A-field must be equal to the B-value of the current instruction. New instructions: (roughly in order of importance) CNE Compare Not Equal. Same as CMP, but they must NOT be equal. CLT Compare Less Than. This would work EXACTLY the same as the CMP instruction except that A must be LESS THAN B to skip the next instruction. SNE SLT not equal. SEQ SLT equal. DJZ Same as DJN except Jmp if Zero IJN Same as DJN, except that an increment is performed. IJZ Same as DJZ, except that an increment is performed. ZER Drop-copy a DAT instruction at the specified location. Mode Effect ? # Drop a DAT ?,# on the current instruction. ? B Drop a DAT ?,0 on the instruction pointed to by B. (an A or B in the MODE column indicates a non-immediate mode) OVL Overlay. Similar to move except only the instruction and modes are copied. The A-value and B-value of the destination are not changed. NOTE: Since the size of core exceeds the permutations of OPCODES*64 (64 is 6 bits or 3 bits per MODE) there is no need to restrict immediate modes. Since 8 modes, and 32 opcodes need only 11 bits per instruction, core would have to be less than 2k to cause problems with holding the value of the instruction. Mode Effect # # Move the A-value to the B-value of the current instruction. # B move the A-value of the current instruction to the instruction&mode value of B. A # move the instruction&mode value to the B-value of the current instruction. A B move the instruction&mode value of A to the instruction&mode value of B. (an A or B in the MODE column indicates a non-immediate mode. Predecrement and preincrement do not work on the instruction&mode value, they will still work on the B-value of the instruction being modified.) DMP Dump. Similar to move except only the A-value and B-value are copied. The instruction and modes at the destination are not affected. Mode Effect # # Not allowed. A # move B-value of A to B-value of current instruction. # B move A-value to A-value of B. A B move the A and B values of A to the A and B values, respectively, of B. (an A or B in the MODE column indicates a non-immediate mode.) XCH The effects are dependent on the modes used: or Mode Effect SWP # # exchange the A and B values of the current instruction. # B move the A-value of the current instruction to the A-value of B. A # move the B-value of the current instruction to the B-value of A. A B exchange the A and B values of the instruction pointed to by B. A is ignored. (an A or B in the MODE column indicates a non-immediate mode) FLP Generate a random number from 0-(coresize-1). If less than B, JMP to A. Immediate A-modes are not allowed. CON Make a constant. This is the same as a DAT except that MOV fails when trying to overwrite a CON instruction. To overwrite a CON you need to do a ZER or OVL on it. PCT Protect the specified location from the next access. The first time this location is accessed again it is protected from being changed. After that it becomes unprotected. Mode Effect ? # Current instruction. ? B The instruction pointed to by B. (an A or B in the MODE column indicates a non-immediate mode) MUL Multiply. (various effects) Mode Effect # # Multiply the values. Store the remainder of result/CORESIZE in the B-value, and the result of result/CORESIZE in the A-value. A # Multiply the A-value of A by the B-value of A. Store the remainder of result/CORESIZE in the B-value, and the result of result/CORESIZE in the A-value. # B Multiply the A-value by the B-value of B. Store the remainder of result/CORESIZE in the B-value of B, and the result of result/CORESIZE in the A-value of B. A B Multiply the A-value of A by the B-value of A. Store the remainder of result/CORESIZE in the B-value of B, and the result of result/CORESIZE in the A-value of B. (an A or B in the MODE column indicates a non-immediate mode) DIV Divide. (various effects) Division by 0 results in a 0 result and 0 remainder. Mode Effect # # Divide the A-value by the B-value. Store, in the current instruction, the result in the B-value, and the remainder in the A-value. A # Divide the A-value of A by the B-value of A. Store, in the current instruction, the result in the B-value, and the remainder in the A-value. # B Divide the A-value by the B-value of B. Store, in B, the result in the B-field and the remainder in the A-field. A B Divide the A-value of A by the B-value of A. Store, in B, the result in the B-field and the remainder in the A-field. (an A or B in the MODE column indicates a non-immediate mode) RND Generate a random number from 0-(A-value) and add the B-value. Mode Effect # # Use the values from the current instruction. Store the result (mod CORESIZE) in the B-value of the current instruction. A # Use the A-value and B-value of A. Store the result (mod CORESIZE) in the B-value of the current instruction. # B Use the A-value of the current instruction, and the B-value of B. Store the result (mod CORESIZE) in the B-value of B. A B Use the A-value and B-value of A. Store the result (mod CORESIZE) in the B-value of B. (an A or B in the MODE column indicates a non-immediate mode) Pundits will note that I've added more instructions than many CISC architectures have. My answer to that is...oops. :) Now, to answer some criticisms before they're voiced... Preincrement mode - I think this is beyond discussion. There is a very real need for the preincrement mode. In defense of the changes to the way certain instructions work with certain modes: DAT using direct mode is needed because the ICWS'88 standard states that core will be initialized to DAT 0,0 before loading programs. MOV, ADD, and SUB can be used as DATs in addition to allowing for easy programming of self-modifying programs. SLT needs the immediate B-mode to allow for .GREATER THAN. comparisons. The only alternative to this is using another instruction as a DAT and I think that is a terrible alternative. CMP doesn't need it, but there is no reason for it not to have it. Also, the new CMP instructions do need it. MOV, ADD, SUB, SLT, and DAT with both modes immediate allow for interesting effects. Why disallow it? Memory requirements - Currently it requires 4 bits to encode the 11 existing instructions. My 17 additional instructions require only 1 more bit to encode. Since adding even 1 new mode requires an additional bit, the total number of bits needed for the instruction and modes would exceed 8 and require the use of another byte. As this is the case, memory use is not a consideration in the number of instructions. Simplicity - Okay, you got me, I can't justify this number of instructions on the basis of making the game simpler. I *CAN* justify it on the basis of making the programming easier. (And easier=more programmers in my mind. :) The new instructions CNE, CLT, SNE, and SEQ are merely extensions of current instructions that allow decisions to be made easier. There are no ?GT instructions because they aren't needed if immediate B-mode addressing is allowed. Given how useful these 4 additional instructions would be, I can't see anyone objecting to them. The ?NE instructions mean the difference between using 2 instructions for a comparision or 3. Since program size still means a lot (PCT reduces that a LITTLE) that extra instruction can be costly. The new instructions DJZ, IJN, and IJZ are extensions of DJN. They make programming loops easier. Though harder to justify, I think the ?JZ instructions are worthwhile because of the use they can be put to in writing programs that avoid themselves. (And if that doesn't work on you, consider just that it's nice to have instructions that do something both ways.) ZER is just a way of reducing the size of a dwarf. :) Actually, it is useful to anti-scanners too. OVL and DMP are two instructions that I'd really like to see. They can be duplicated using ADDs and MOVs right now, but it requires several instructions to do this in. These two allow programs to gain some smarts without sacrificing size. XCH/SWP is an instruction desired by the masses. It is useful in allowing self-modifying programs. I can see a real need for this in making programs more intelligent. FLP like RND below allows for some random activity but is specifically for writing programs that make random actions since it is a flow control instruction like the other comparisons. CON is my answer to data corrupting bombs. This instruction (like those that follow it) is nice to have, but not necessary. PCT is an interesting instruction but I think it hurts intelligent programs more than it helps. However, the masses desire it, so I have suggested it here. MUL and DIV would be invaluable in creating binary searches and allowing other interesting programming. I think they're more valuable than CON or PCT but much harder to use. RND, my last suggestion, is not very useful in general but it allows locations to be chosen at random, something that I have felt necessary in the past few weeks as I have tried writing various types of bombers. Core instruction corruption - because of OVL it is possible to create an instruction that is illegal. The answer to this is simple...one more instruction: NOP This instruction does nothing except waste a cycle. The A & B modes will be executed normally, but no action will occur after that except incrementing the PC counter. *ANY* illegal opcode or opcode&mode combination will perform a NOP. If used in a program this instruction will code as the highest possible illegal instruction&modes. Using 11 bits for the instruction and modes would result in a value of 2047 (all bits on) for this instruction. NOTE: There are illegal modes (3 bits per mode allows 8 modes, but with this standard we would have only 5 legal ones) so illegal mode instruction&mode combinations would also act as NOPs. I can't think of any more arguments right now, so I'll let everyone else do it for me. If you don't like something, or you would like to see something, go ahead and post or email me. Charles_K_Hughes@cup.portal.com From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: Should KotH scores include self-battles? Message-ID: <1992May22.165359.5626@samba.oit.unc.edu> Date: Fri, 22 May 1992 16:53:59 GMT In article <1992May22.082301.9414@vuse.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >I'd like to put this up for discussion: Is it relevant whether a warrior >can beat itself consistently? If not, why not save the time pitting a >new challenger against itself on KotH? The time saving is not going to be really big. It means fighting 2000 battles vs 2050. Likewise, the score is not going to be really different; I think the difference between all self-wins vs all self-ties is less than 3 points. More generally though, why not fight against yourself? Otherwise it seems like a bit of a waste of a KotH slot. After all, if replicating programs tend to tie other replicating programs, then we can see this with only one replicating program on the hill, rather than requiring two replicating programs on the hill, which would be a duplication of battles for the other 18 programs they both fight against. I think that the suicide approach is probably not worth the effort. One would be better off improving the kill-the-other-guy algorithm; the other programs will take care of killing your own program off for you. :-) -Andy ajpierce@med.unc.edu From: jonn@microsoft.com (Jon Newman) Subject: Re: RoboSport by Maxxis Message-ID: <1992May22.201927.10539@microsoft.com> Date: 22 May 92 20:19:27 GMT In article <167ECF0BE.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >Does anyone have any experience with the software game "RoboSport" >published by Maxxis (the "SimCity/Earth/Ant" company)? Is it worthwhile? > >Mark A. Durham >MAD Yes, I have this game. In RoboSport, you give orders to your team of robots to fight against another team of robots. The player programs his robots for a fixed period of time into the future, then they carry out their orders. For example, you might program a robot to "run behind that wall, crouch down, get out your grenade launcher, and fire at will for six seconds." It is very reminiscent of Avalon Hill's hex-boardgame "Squad Leader," but with the massive ruleset replaced by computer moderation. The robots do not have general purpose programs, but only sets of orders specific to their surroundings. The player periodically renews these sets of orders. As such, RoboSport is not really a programmer's game like Core War. It isn't a bad game, although it isn't up to the SimCity standard (and isn't at all similar to SimCity except for the classy Maxis implementation). It might be more enjoyable when played against other humans over a network. Jon Newman -- jonn@microsoft.com This is not the official opinion of Microsoft Corporation. Bill Rules! From: jonn@microsoft.com (Jon Newman) Subject: Re: Protect (PCT) and intelligence Message-ID: <1992May22.202338.10755@microsoft.com> Date: 22 May 92 20:23:38 GMT In article <167EDCCE6.DURHAM@ricevm1.rice.edu> DURHAM@ricevm1.rice.edu (Mark A. Durham) writes: >In article <1992May20.162914.20528@vuse.vanderbilt.edu> >stst@vuse.vanderbilt.edu (Stefan Strack) writes: > >> What were the reason[s] for [PCT's] >>exclusion from ICWS'86 (while just about everything else from AKD's articles >>was included)? >> > >1) It was a speculative opcode in Dewdney's original article. >2) Graeme McRae did not write it into his draft standard (I do not know why). >3) Dewdney had not anticipated offensive uses of the opcode. He seemed a bit > disturbed by it (at least in print) and more or less frowned on its use > in the follow-up article. >4) It requires an extra bit for each instruction. >5) No one thought it was worth the trouble at the time. I should add: PCT does not really protect from IMPs. It is very easy to construct a double-IMP, or "short worm," which contains two synchronized IMPS. "Short worm" will overrun PCT protection with no problem. I think the following should be sufficient: ; Short Worm SPL 1 MOV 0,1 Jon Newman Director, ICWS -- jonn@microsoft.com This is not the official opinion of Microsoft Corporation. Bill Rules! From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <1992May23.013338.21240@vlsi.polymtl.ca> Date: Sat, 23 May 1992 01:33:38 GMT Ordania-DM@cup.portal.com (Charles K Hughes) writes: : : First, a complaint: : KOTH is not ICWS'88 compliant. Specifically, the ADD and : SUB instructions are supposed to add/sub the A and B values : of both instructions if neither mode is immediate. The : EMI88.C source that I have shows them adding only the : B-values. I can't believe this is true ! My program uses it, and even though it's not very high on the hill, it would be dead if it were true ! Also, we need POSTincrement, not preincrement ! For complementation sake. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: New New Corewar Specs Message-ID: <59484@cup.portal.com> Date: Sat, 23 May 92 01:34:21 PDT Re: New New Corewar Specs >5/22/92 07:22 31/1803 dwp@willett.pgh.pa.us (Doug Philips) . . . >Pardon me if I've missed this going by already, but one thing I'm not real >clear on for variable instruction times is how "timesharing" is to be done. >Does the simulator alternate on the basis of cycles or instructions? . . . Of course anything is possible, but would suggest that if you were going to implement variable instruction times (and I still haven't heard a good reason to have v.i.t.) that you 'swap' after each instruction, but keep track of how much time has been 'used' for each instruction. So if an instruction took N cycles, then the opposing side could run until it had executed at least N, with instructions not being 'interrupted'. For example: Let R = relative cycles. When R is non-negative, side A executes one instruction and subtracts the number of cycles the instruction required from R. When R is negative, side B executes one instruction and adds the number of cycles the instruction required to R. If each memory access required one cycle, and read-modify-write access required two. Imp vs. Dwarf 12b would run as follows A:0000:MOV 0, 1 ;r = -3 B:4000:MOV 2, -1 ;r = 0 A:0001:MOV 0, 1 ;r = -3 B:4001:SUB #12, 1 ;r = 0 A:0002:MOV 0, 1 ;r = -3 B:4002:JMP -2 ;r = -2 B:4000:MOV 2, -13 ;r = 1 A:0003:MOV 0, 1 ;r = -2 B:4001:SUB #12, 1 ;r = 1 A:0004:MOV 0, 1 ;r = -2 B:4002:JMP -2 ;r = -1 B:4000:MOV 2, -25 ;r = 2 O.K. it sounds confusing, it's still less confusing than anything else I could come up with. |+------------------------------------------------------------------+| I may not like going to the bathroom, but I still do it. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: Should KotH scores include self-battles? Message-ID: <59485@cup.portal.com> Date: Sat, 23 May 92 01:35:46 PDT >5/22/92 09:53 20/1182 ajpierce@med.unc.edu (Andrew Pierce) writes: . . . > I think that the suicide approach is probably not worth the effort. . . . On the X-hill, I have submitted several programs which committed suicide. The 3 extra points currently only change 2 - 3 places, but there have been times when 3 points was the difference between last and second. It has always seemed worth while to me. Note that "team" suicides can also be very effective, raising scores by 3 points per warrior on your "team." |+---------------------------------------------------------------+| Aspirin and Penicillin are drugs. <<>> From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <59489@cup.portal.com> Date: Sat, 23 May 92 02:54:18 PDT >5/22/92 16:42 298/15k Ordania-DM@cup.portal.com (Charles K Hughes) First, a complaint: Your post is too big. I will summarize the relevant parts. >[complaints] >[disclaimer] >[suggested that pre-increment be added] >[suggested that many instructions allow more modes.] Rather than changing some modes, I agree with MAD that we should just allow ALL modes with ALL instructions. >[lots of new branch instructions] >[new DJZ, IJZ, and IJN instructions (Dec. jump if 0, inc. jump if 0/non 0] >[ZER, set location to DAT] Many people seem to think that "smaller" code is somehow the same as "easier to write" code. All these new instructions do is shorten some programs by one line, they do not make it easier to write them. >[OVL, DMP, XCH] Rather than any of these I would prefer an A-field mode ('%'), and an instruction-field mode ('!'). MOV !A, B would move the instruction field of A to the b-field of B. MOV A, %B would move the b-field of A to the a-field of B. >[FLP, generate a random branch] IMHO, randomness and Corewar do not mix. >[CON - non alterable data.] >[PCT - protect a location] I suspect that if this instruction existed, that most programs would simply write to every location twice. This would slow down everybody, but really have very little effect. (Of course I could be wrong.) >[MUL, DIV - Multiply and divide] Multiply and divide are perhaps useful. I would also like to see MOD (take the remainder of the division) if DIV is going to be around. >[RND - generate a random number] IMHO, randomness and Corewar do not mix. >[answers to some obvious criticisms] . . . > Memory requirements - Currently it requires 4 bits to encode the 11 >existing instructions. My 17 additional instructions require only 1 more >bit to encode. Since adding even 1 new mode requires an additional bit, >the total number of bits needed for the instruction and modes would exceed >8 and require the use of another byte. As this is the case, memory use is >not a consideration in the number of instructions. Not all Mars systems work as you imply. My system for instance has one value for each instruction/A-mode/B-mode. I do not waste bits, the value is Instruction*25+A-mode*5+B-mode*5, the number of bits required is therefore fuzzy at best. If you want to define that MARS works that way, thats one thing, but remember that the standards do not define them that way currently. > [NOP - do nothing] Well the '86 standard claims that an illegal instruction is the same as a DAT (it halts that process.) But I have nothing against the NOP, if nothing else, it is useful for demonstration and debugging. |+--------------------------------------------------------------------+| Well, it has a good beat but you can't dance to it, I give it a 3. <<>> From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <1992May23.045805.19696@vuse.vanderbilt.edu> Date: Sat, 23 May 1992 04:58:05 GMT In article <59452@cup.portal.com> Ordania-DM@cup.portal.com (Charles K Hughes) writes: > Ok, now for the meat of this post...my suggestions for the UCWS'92 >(USENET COREWAR STANDARD 1992) : >[..] *Sigh*, another one .. I suggest you give ICWS'88 a spin first (e.g. by submitting a few programs to KotH), and _then_ present your enhancements to us masses. -Stefan (stst@vuse.vanderbilt.edu) > >New modes: > > preincrement (+1 instead of -1 :), otherwise same as changed > predecrement > >Changed modes: > < predecrementing - works one way or the other. :) I think > ICWS'88 is pretty clear on it (decrement memory, then load > final reference), if there are objections, voice them. > >Change instructions: > DAT the direct mode is allowed. > SLT immediate modes are allowed (this obviates the need for > an SGT instruction) > Mode Effect > # # Is A-value less than B-value? > # B Is A-value less than the B-value of B? > A # Is B-value less than the B-value of A? > A B Is the B-value of A, less than the B-value of B? > (an A or B in the MODE column indicates a non-immediate > mode) > > MOV =\ > ADD } immediate B modes are allowed. The effect is as in > SUB =/ ICWS'86. > > CMP immediate B modes are allowed. The effect is that the > B-value of the instruction pointed to by the A-field > must be equal to the B-value of the current instruction. > > >New instructions: (roughly in order of importance) > CNE Compare Not Equal. Same as CMP, but they must NOT be equal. > > CLT Compare Less Than. This would work EXACTLY the same as the > CMP instruction except that A must be LESS THAN B to skip > the next instruction. > > SNE SLT not equal. > > SEQ SLT equal. > > DJZ Same as DJN except Jmp if Zero > > IJN Same as DJN, except that an increment is performed. > > IJZ Same as DJZ, except that an increment is performed. > > ZER Drop-copy a DAT instruction at the specified location. > Mode Effect > ? # Drop a DAT ?,# on the current instruction. > ? B Drop a DAT ?,0 on the instruction pointed to by B. > (an A or B in the MODE column indicates a non-immediate > mode) > > OVL Overlay. Similar to move except only the instruction and > modes are copied. The A-value and B-value of the > destination are not changed. NOTE: Since the size of > core exceeds the permutations of OPCODES*64 (64 is 6 bits > or 3 bits per MODE) there is no need to restrict immediate > modes. Since 8 modes, and 32 opcodes need only 11 bits > per instruction, core would have to be less than 2k > to cause problems with holding the value of the instruction. > Mode Effect > # # Move the A-value to the B-value of the current > instruction. > # B move the A-value of the current instruction to the > instruction&mode value of B. > A # move the instruction&mode value to the B-value of > the current instruction. > A B move the instruction&mode value of A to the > instruction&mode value of B. > (an A or B in the MODE column indicates a non-immediate > mode. Predecrement and preincrement do not work on > the instruction&mode value, they will still work on the > B-value of the instruction being modified.) > > DMP Dump. Similar to move except only the A-value and B-value > are copied. The instruction and modes at the destination > are not affected. > Mode Effect > # # Not allowed. > A # move B-value of A to B-value of current instruction. > # B move A-value to A-value of B. > A B move the A and B values of A to the A and B values, > respectively, of B. > (an A or B in the MODE column indicates a non-immediate > mode.) > > XCH The effects are dependent on the modes used: > or Mode Effect > SWP # # exchange the A and B values of the current > instruction. > # B move the A-value of the current instruction to the > A-value of B. > A # move the B-value of the current instruction to the > B-value of A. > A B exchange the A and B values of the instruction > pointed to by B. A is ignored. > (an A or B in the MODE column indicates a non-immediate > mode) > > FLP Generate a random number from 0-(coresize-1). If less than > B, JMP to A. Immediate A-modes are not allowed. > > CON Make a constant. This is the same as a DAT except that MOV > fails when trying to overwrite a CON instruction. To > overwrite a CON you need to do a ZER or OVL on it. > > PCT Protect the specified location from the next access. The > first time this location is accessed again it is protected > from being changed. After that it becomes unprotected. > Mode Effect > ? # Current instruction. > ? B The instruction pointed to by B. > (an A or B in the MODE column indicates a non-immediate > mode) > > MUL Multiply. (various effects) > Mode Effect > # # Multiply the values. > Store the remainder of result/CORESIZE > in the B-value, and the result of > result/CORESIZE in the A-value. > A # Multiply the A-value of A by the B-value of A. > Store the remainder of result/CORESIZE > in the B-value, and the result of > result/CORESIZE in the A-value. > # B Multiply the A-value by the B-value of B. > Store the remainder of result/CORESIZE > in the B-value of B, and the result of > result/CORESIZE in the A-value of B. > A B Multiply the A-value of A by the B-value of A. > Store the remainder of result/CORESIZE > in the B-value of B, and the result of > result/CORESIZE in the A-value of B. > (an A or B in the MODE column indicates a non-immediate > mode) > > DIV Divide. (various effects) Division by 0 results in > a 0 result and 0 remainder. > Mode Effect > # # Divide the A-value by the B-value. > Store, in the current instruction, the result > in the B-value, and the remainder in the > A-value. > A # Divide the A-value of A by the B-value of A. > Store, in the current instruction, the result > in the B-value, and the remainder in the > A-value. > # B Divide the A-value by the B-value of B. > Store, in B, the result in the B-field and > the remainder in the A-field. > A B Divide the A-value of A by the B-value of A. > Store, in B, the result in the B-field and > the remainder in the A-field. > (an A or B in the MODE column indicates a non-immediate > mode) > > RND Generate a random number from 0-(A-value) and add the B-value. > Mode Effect > # # Use the values from the current instruction. > Store the result (mod CORESIZE) in the > B-value of the current instruction. > A # Use the A-value and B-value of A. > Store the result (mod CORESIZE) in the > B-value of the current instruction. > # B Use the A-value of the current instruction, and > the B-value of B. > Store the result (mod CORESIZE) in the > B-value of B. > A B Use the A-value and B-value of A. > Store the result (mod CORESIZE) in the > B-value of B. > (an A or B in the MODE column indicates a non-immediate > mode) > > > Pundits will note that I've added more instructions than many CISC >architectures have. My answer to that is...oops. :) > >Now, to answer some criticisms before they're voiced... > > Preincrement mode - I think this is beyond discussion. There is a >very real need for the preincrement mode. > > In defense of the changes to the way certain instructions work with >certain modes: > DAT using direct mode is needed because the ICWS'88 standard states >that core will be initialized to DAT 0,0 before loading programs. > MOV, ADD, and SUB can be used as DATs in addition to allowing for >easy programming of self-modifying programs. > SLT needs the immediate B-mode to allow for .GREATER THAN. >comparisons. The only alternative to this is using another instruction >as a DAT and I think that is a terrible alternative. > CMP doesn't need it, but there is no reason for it not to have it. >Also, the new CMP instructions do need it. > MOV, ADD, SUB, SLT, and DAT with both modes immediate allow for >interesting effects. Why disallow it? > > Memory requirements - Currently it requires 4 bits to encode the 11 >existing instructions. My 17 additional instructions require only 1 more >bit to encode. Since adding even 1 new mode requires an additional bit, >the total number of bits needed for the instruction and modes would exceed >8 and require the use of another byte. As this is the case, memory use is >not a consideration in the number of instructions. > > Simplicity - Okay, you got me, I can't justify this number of >instructions on the basis of making the game simpler. I *CAN* justify it >on the basis of making the programming easier. (And easier=more programmers >in my mind. :) > The new instructions CNE, CLT, SNE, and SEQ are merely extensions >of current instructions that allow decisions to be made easier. There are >no ?GT instructions because they aren't needed if immediate B-mode addressing >is allowed. Given how useful these 4 additional instructions would be, I >can't see anyone objecting to them. The ?NE instructions mean the difference >between using 2 instructions for a comparision or 3. Since program size >still means a lot (PCT reduces that a LITTLE) that extra instruction can >be costly. > The new instructions DJZ, IJN, and IJZ are extensions of DJN. They >make programming loops easier. Though harder to justify, I think the ?JZ >instructions are worthwhile because of the use they can be put to in >writing programs that avoid themselves. (And if that doesn't work on you, >consider just that it's nice to have instructions that do something both >ways.) > ZER is just a way of reducing the size of a dwarf. :) Actually, >it is useful to anti-scanners too. > OVL and DMP are two instructions that I'd really like to see. They >can be duplicated using ADDs and MOVs right now, but it requires several >instructions to do this in. These two allow programs to gain some smarts >without sacrificing size. > XCH/SWP is an instruction desired by the masses. It is useful in >allowing self-modifying programs. I can see a real need for this in >making programs more intelligent. > FLP like RND below allows for some random activity but is >specifically for writing programs that make random actions since it is >a flow control instruction like the other comparisons. > CON is my answer to data corrupting bombs. This instruction (like >those that follow it) is nice to have, but not necessary. > PCT is an interesting instruction but I think it hurts intelligent >programs more than it helps. However, the masses desire it, so I have >suggested it here. > MUL and DIV would be invaluable in creating binary searches and >allowing other interesting programming. I think they're more valuable >than CON or PCT but much harder to use. > RND, my last suggestion, is not very useful in general but it allows >locations to be chosen at random, something that I have felt necessary in >the past few weeks as I have tried writing various types of bombers. > > Core instruction corruption - because of OVL it is possible to create >an instruction that is illegal. The answer to this is simple...one more >instruction: > NOP This instruction does nothing except waste a cycle. The > A & B modes will be executed normally, but no action > will occur after that except incrementing the PC counter. > *ANY* illegal opcode or opcode&mode combination will > perform a NOP. If used in a program this instruction will > code as the highest possible illegal instruction&modes. > Using 11 bits for the instruction and modes would result > in a value of 2047 (all bits on) for this instruction. > NOTE: There are illegal modes (3 bits per mode allows > 8 modes, but with this standard we would have only 5 legal > ones) so illegal mode instruction&mode combinations would > also act as NOPs. > > > > I can't think of any more arguments right now, so I'll let everyone else >do it for me. If you don't like something, or you would like to see >something, go ahead and post or email me. > >Charles_K_Hughes@cup.portal.com > From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <1992May23.134017.21070@samba.oit.unc.edu> Date: Sat, 23 May 1992 13:40:17 GMT In article <59489@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: >>5/22/92 16:42 298/15k Ordania-DM@cup.portal.com (Charles K Hughes) >>[CON - non alterable data.] >>[PCT - protect a location] > I suspect that if this instruction existed, that most programs would >simply write to every location twice. This would slow down everybody, >but really have very little effect. (Of course I could be wrong.) I almost agree with this. The dwarfs would simply write twice. The scanners though would still only have to look once, and then write twice. If you think scanners are hammering KotH now... >> [talk about the NOP instruction] > Well the '86 standard claims that an illegal instruction is the same >as a DAT (it halts that process.) But I have nothing against the NOP, if >nothing else, it is useful for demonstration and debugging. If all addressing modes are allowed (something I am in favour of) then there can be no illegal instructions. If you want a NOP instruction, one already exists: SLT #-1,0 -Andy ajpierce@med.unc.edu From: simonk@castle.ed.ac.uk (Simon Kinahan) Subject: Re: New New Corewar Specs Message-ID: <21781@castle.ed.ac.uk> Date: 23 May 92 14:05:13 GMT I'm not absolutely clear why core-wars needs any of these registers and stuff at all. It seems from the original spec that the RedCode language that the language allows all the things people normally do in registers to be done in memeory locations. Why do we need registers ? Simon. PS sorry if this has gone by already but we seem to be getting very little news here these days. From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <1992May23.143913.5823@oucsace.cs.ohiou.edu> Date: 23 May 92 14:39:13 GMT In article <1992May23.134017.21070@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: >In article <59489@cup.portal.com> ScottNelson@cup.portal.com (Scott - Nelson) writes: >>>5/22/92 16:42 298/15k Ordania-DM@cup.portal.com (Charles K Hughes) >>>[CON - non alterable data.] >>>[PCT - protect a location] >> I suspect that if this instruction existed, that most programs would >>simply write to every location twice. This would slow down everybody, >>but really have very little effect. (Of course I could be wrong.) > I almost agree with this. The dwarfs would simply write twice. The >scanners though would still only have to look once, and then write twice. >If you think scanners are hammering KotH now... I still think that the PCT instruction should still be considered... it should at least be tried out in the next X-Hill... Bill? How about a whirl? I can seem to think of several different uses... my favorite is a dwarf-like bomber that doesn't bomb with DAT's but instead protects each instruction through memory. The enemy program will eventually have its own locations protected so it couldn't modify its own data, and hopefully cause its own destruction. Should we also consider two possibilities for the accessing of protected memory? 1) If an attempt to write to a protected memory location is made, treat as if a DAT was executed instead and kill the violating process... (this would cause many programs to split off more processes... possibly not good...) 2) If an attempt to write to a protected memory location is made, ignore it and pretend that the instruction was never executed, going to the next instruction in the code. (this is the normal way of thinking about it and probably the better...) Well, I think this is one of those things we just have to try out, like the post increment and the split modification thing we did awhile back. Scott Adkins ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: mendels@eniac.seas.upenn.edu (Jeffrey Mendelsohn ) Subject: quick question on predecrement in unused fields Message-ID: <78794@netnews.upenn.edu> Date: 23 May 92 15:20:26 GMT I have a question. Consider the following: jmp -20, Date: 23 May 92 17:39:39 GMT In article <3583.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: |Indeed. Wouldn't it be more interesting to have a range of core sizes |instead of one fixed one? (you might put such environment-status info in |memory at a known offset relative to the beginning (or end) each of the |programs' code) We'd need mul and div instructions, and it should NOT go in a data block: this penalises complex, static programmes by increasing their effective footprint. ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: New New Corewar Specs Message-ID: <1992May23.180459.26857@vlsi.polymtl.ca> Date: 23 May 92 18:04:59 GMT I have read the CoreWar newsletter (by Mark A. Durham and all) and I wonder what weight this whole discussion really has and if there's a real, or more official forum or body where suggestions should be sent (or where they will be compiled). Maybe some people from ICWS could give us some info. On the current subject, here are the points I back: 1. SNE instruction for Skip Not Equal. 2. All addressing modes permitted anywhere (required for atomic location). 3. Postincrement indirect addressing mode. 4. Atomic memory location (solve elegantly the A field addressing problem). -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: cpbeaure@cayley.waterloo.edu (Chris Beauregard) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <1992May24.003021.16523@undergrad.math.waterloo.edu> Date: Sun, 24 May 1992 00:30:21 GMT In article <1992May23.143913.5823@oucsace.cs.ohiou.edu> sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes: >I still think that the PCT instruction should still be considered... it >should at least be tried out in the next X-Hill... Bill? How about a whirl? Yeah, that would be interesting. >destruction. Should we also consider two possibilities for the accessing >of protected memory? > 1) If an attempt to write to a protected memory location is made, > treat as if a DAT was executed instead and kill the violating > process... (this would cause many programs to split off more > processes... possibly not good...) This would be vicious, both to the program hunting a program with the PCT and the program using it at all. A couple points: How does a turtle-like program unprotect its own data? Easily, that is? You could allow programs that protect a cell to write to it without penalty, but that can be a pain. How do you determine if a cell is protected before attacking it? You would always have to split off a bomber, because you just never know when it's going to hit a protected cell. While I agree that it would make programs a heck of a lot smarter - making a dwarf that constantly split off a move instruction would slow things down nicely - and scanners would take much more precedence, a lot of nifty attacks would likely be lost - the entire concept of the IMP would be even more useless than it is under normal PCT rules. > 2) If an attempt to write to a protected memory location is made, > ignore it and pretend that the instruction was never executed, > going to the next instruction in the code. (this is the normal > way of thinking about it and probably the better...) Clarify for me. Does 'instruction was never executed' extend to things like pre-decrements? I would hope not, that would, in a number of cases, make things like turtle programs next to useless. Something like target DAT #0,#-x bomb mov #0,Scott Adkins ---------------------------------------------------------------------------- Chris Beauregard cpbeaure@cayley.waterloo.edu "A clean directory structure is a sign of a person with nothing to do." From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: Date: 24 May 92 01:35:20 GMT In article <1992May23.143913.5823@oucsace.cs.ohiou.edu> sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes: |I still think that the PCT instruction should still be considered... it |should at least be tried out in the next X-Hill... Bill? How about a whirl? I really don't like the idea of PCT (which is not to say that I don't like the idea of protection) because it is so completely unlike a "real" machine instruction, raises the ugly question of what OTHER state bits a core cell should have, and has its effects undone in a rather irregular and bizarre manner. |I can seem to think of several different uses... my favorite is a dwarf-like |bomber that doesn't bomb with DAT's but instead protects each instruction |through memory. The enemy program will eventually have its own locations |protected so it couldn't modify its own data, and hopefully cause its own |destruction. Should we also consider two possibilities for the accessing |of protected memory? | 1) If an attempt to write to a protected memory location is made, | treat as if a DAT was executed instead and kill the violating | process... (this would cause many programs to split off more | processes... possibly not good...) | 2) If an attempt to write to a protected memory location is made, | ignore it and pretend that the instruction was never executed, | going to the next instruction in the code. (this is the normal | way of thinking about it and probably the better...) Each of these possibilities seems insanely vindictive - and hard to implement. If PCT *is* implemented, it seems quite clear (to me :-) that the semantics should be that the single WRITE fails, (presumably the protection is erased, and) there is no other effect on instruction execution. In particular, side effects on other cells arising from addressing modes are NOT backed out, any transfers of control or process forks that would otherwise have taken place DO take place, etc., etc., etc.. Or then again (this is a JOKE coming up here) we could have different protection statuses for memory, determined by the A field of PCT: PCT mode, addr where the mode for a desired effect is computed as follows: condition + effect where condition is the sum of any or all of the following: 1 if target read 2 if target written 4 if target executed 8 if target of PCT instruction and effect is the sum of any or all of the following: 16 terminate process 32 inhibit ALU operation 64 inhibit addressing side effects, A operand 128 inhibit addressing side effects, B operand 256 inhibit transfer of control 512 inhibit protection operations 1024 inhibit A field access 2048 inhibit B field access 4096 inhibit opcode access where inhibition of access for read or execute means that you see a "dat ,", a 0 or a 0 (for opcode, A and B fields, resp.) and for write means that no change occurs. Then again, a few instructions containing this kind of (typical for real hardware!) mumbo-jumbo and we'll be spending the next decade exploring yummy ramifications.... ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <1992May24.022246.11009@oucsace.cs.ohiou.edu> Date: 24 May 92 02:22:46 GMT In article <1992May24.003021.16523@undergrad.math.waterloo.edu> cpbeaure@cayley.waterloo.edu (Chris Beauregard) writes: > >> 2) If an attempt to write to a protected memory location is made, >> ignore it and pretend that the instruction was never executed, >> going to the next instruction in the code. (this is the normal >> way of thinking about it and probably the better...) > > Clarify for me. Does 'instruction was never executed' extend to things >like pre-decrements? I would hope not, that would, in a number of cases, >make things like turtle programs next to useless. Something like > target DAT #0,#-x > bomb mov #0, jmp bomb > >would first break the protection, and on the next iteration, because the >target hasn't changed, bomb it again, for real. The dumb bombers return. The way I interpreted the writing to a protected memory location would be exacly like it would be for a program writing to a memory location that is outside its write limit... If the memory location is protected, execute the instruction normally but do not change the contents of the memory location under scrutiny, but instead mark it as unprotected. I didn't give much thought to pre-decrements/post-increments on memory locations... I suspect that they should act in the same way as the write limit stuff, so that you can indeed unprotect an instruction first with a '<' or '>', and then bomb it on the next iteration. Hmmm.... Don't forget to have a good day! Some people never remember this. ------------------------------------------------------------------------------- Scott W. Adkins Internet: sadkins@ohiou.edu ~~~~~~~~~~~~~~~ ak323@cleveland.freenet.edu (Flame me, not the net!) Bitnet: adkins@ouaccvma.bitnet ------------------------------------------------------------------------------- Ohio University of Athens Home of the Great Hocking River From: wms@iwarp.intel.com (William Shubert) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <1992May24.222907.19616@iWarp.intel.com> Date: Sun, 24 May 1992 22:29:07 GMT >KOTH is not ICWS'88 compliant. Specifically, the ADD and >SUB instructions are supposed to add/sub the A and B values >of both instructions if neither mode is immediate. The >EMI88.C source that I have shows them adding only the >B-values. OK, everybody, I don't know WHAT this guy is thinking of, but KotH does handle the situation he specifies correctly. I also have no idea what "EMI88.C" is; I've never heard of this file, and I wrote KotH, so I'm pretty sure he has no idea what he's talking about. Mr. Hughes: Please, in the future, make sure your accusations are correct before you make them. -Bill (wms@iwarp.intel.com) From: wms@iwarp.intel.com (William Shubert) Subject: KotH V2.5 Message-ID: <1992May25.003356.21209@iWarp.intel.com> Date: Mon, 25 May 1992 00:33:56 GMT I apologise for the postincrement bug in KotH V2.4. I have fixed it and put the fixed version of KotH on soda.berkeley.edu as "koth25.shar.Z". At the same time I fixed several minor (but irritating) interface bugs. -Bill (wms@iwarp.intel.com) From: nautilus@lachesis.acm.rpi.edu (John M. Twilley) Subject: Mailing List Information Requested Message-ID: <57!wk3q@rpi.edu> Date: Mon, 25 May 1992 04:25:42 GMT I will be moving out of local calling distance of my normal site, and will be losing my basic news feed. If someone would be kind enough to send me mail regarding possible mailing lists with either digests of these groups or similar lists, I would be very appreciative. Thanks in advance, Jack. -- John M. Twilley | A decapitated cockroach lives for several nautilus@acm.rpi.edu | weeks before finally dying of starvation. From: dwp@willett.pgh.pa.us (Doug Philips) Subject: Re: A few ideas for the NEWARS IS. (long) Message-ID: <3600.UUL1.3#5129@willett.pgh.pa.us> Date: 26 May 92 12:22:08 GMT In article , stephen@estragon.uchicago.edu (Stephen P Spackman) writes: +In article <3583.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: +|Indeed. Wouldn't it be more interesting to have a range of core sizes +|instead of one fixed one? (you might put such environment-status info in +|memory at a known offset relative to the beginning (or end) each of the +|programs' code) +We'd need mul and div instructions, and it should NOT go in a data +block: this penalises complex, static programmes by increasing their +effective footprint. Not sure about mul and div, but at least shift. As for where to put the data block... it penalizes small programs more than large (complex?) ones, increasing their size by a larger percentage. -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei}!willett!dwp From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: A few ideas for the NEWARS IS. (long) Message-ID: <1992May26.142851.28418@samba.oit.unc.edu> Date: 26 May 92 14:28:51 GMT In article <3600.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: >Not sure about mul and div, but at least shift. As for where to put >the data block... it penalizes small programs more than large (complex?) >ones, increasing their size by a larger percentage. This is NOT true. Both programs evidence the same amount of reduced survivability. If a bombing routine divides the core into X sized chunks (eg by bombing every 20 addresses X=20) then the probability that a program of size N instructions will not be hit is (X-N)/X. Clearly the dependance of survivability upon N is linear and so both small and large programs suffer equally by being made longer by the same amount. -Andy ajpierce@med.unc.edu From: Ordania-DM@cup.portal.com (Charles K Hughes) Subject: Re: UCWS'92 (Usenet Core War Standards 1992) Message-ID: <59618@cup.portal.com> Date: Tue, 26 May 92 15:54:19 PDT First, an apology: :) KOTH does not have the problem I accused it of, my apologies to Bill, and anyone else I may have scared/confused/ angered, etc, etc. (I'll respond to the UCWS'92 comments in another post.) Charles_K_Hughes@cup.portal.com From: wms@iwarp.intel.com (William Shubert) Subject: Weekly KotH Posting Message-ID: <1992May26.163827.22969@iWarp.intel.com> Date: Tue, 26 May 1992 16:38:27 GMT On the ICWS '88 hill, not much motion in the past week; "Crimp" has been sitting at #1 for a while. The complete listing has been posted by Andy in the past few weeks...it's a CMP scanner. # %W/ %L/ %T Name Author Score Age 1 51/ 40/ 9 Crimp Andy Pierce 161 100 2 42/ 32/ 26 Note Paper Scott Nelson 151 156 3 48/ 45/ 7 Frantic 0.5 Unknown Author 151 123 4 43/ 36/ 20 Dynamic Duo 4.0 Stefan Strack 150 19 5 47/ 44/ 10 Agony 2.3a Stefan Strack 149 72 6 47/ 46/ 7 Frantic 0.6 Unknown Soldier 148 14 7 45/ 43/ 13 Charon v5.0 J.Cisek & S.Strack 146 121 8 41/ 35/ 24 Parthenos Pierre Dak Baillarge 146 3 9 44/ 45/ 11 scissors88.3 Scott Nelson 144 67 10 43/ 43/ 14 Mutagen 2.1 Stefan Strack 143 62 11 43/ 44/ 14 Sucker 2 Stefan Strack 142 5 12 42/ 42/ 16 return of the living dead nandor sieben 142 151 13 38/ 35/ 27 Armadillo Stefan Strack 141 160 14 46/ 51/ 3 worm optima (Eat your hea Campbell Fraser 141 161 15 41/ 42/ 17 dead end nandor sieben 139 13 16 42/ 46/ 12 PitTrap v3.0 J.Cisek 138 83 17 41/ 45/ 14 izotop nandor sieben 136 1 18 37/ 38/ 25 color dwarf optima nandor sieben 136 10 19 40/ 45/ 14 Salammbo Pierre Dak Baillarge 135 2 20 42/ 49/ 9 Frenetic 1.1 Unknown Author 135 28 On the experimental hill, I have taken the #1 position with "Spider 1.1". Yay me. Anyway, it takes heavy advantage of a process being able to read farther than it can write. I'll pretty up the code with some comments and post it as soon as I'm done. In the meantime, the ";strategy" lines will be at the end of this message. # %W/ %L/ %T Name Author Score Age 1 63/ 22/ 14 Spider 1.1 Bill Shubert 205 1 2 53/ 36/ 10 Snark 7 Scott Nelson 170 4 3 49/ 38/ 13 Juggernaut 5.0 Scott Nelson 161 27 4 44/ 43/ 14 tse-tse-x 1.1 Eric Prestemon 144 12 5 44/ 44/ 12 Odin J.Cisek 144 16 6 36/ 29/ 35 MiniShwing! [x] v1.2 T. H. Davies 143 11 7 32/ 30/ 38 Rabbits [x] Paul S. Kilroy 135 8 8 38/ 45/ 17 UltraSlick Ray Cromwell 130 26 9 36/ 42/ 22 Leaper-X 4.0 Jeff Raven 130 13 10 32/ 34/ 34 multi mice -x nandor sieben 129 25 11 33/ 38/ 29 Stonewall Ray Cromwell 128 22 12 30/ 33/ 37 Virus Scott Adkins 127 20 13 35/ 45/ 20 Crimson v1.2a J.Cisek 126 10 14 36/ 47/ 18 Rail Road 1.0 James Jesensky 125 21 15 32/ 41/ 27 Spreader 2.0 Scott Adkins 124 7 16 23/ 23/ 54 ImpBreed-x 1.0 Jonathan Roy 123 17 17 29/ 38/ 32 Bridge Scott Adkins 120 24 18 31/ 46/ 22 Slick2.0 Ray Cromwell 116 23 19 30/ 49/ 21 Test Jeff Raven 110 19 20 31/ 54/ 15 spanish fly-x 1.1 Eric Prestemon 107 9 ;name Spider 1.1 ;author Bill Shubert ;strategy Sit and wait. When the enemy approaches, strike with a small and ;strategy fast offense. ;strategy This is an attempt to demonstrate that an extremely complex and ;strategy long fighter can succeed in the experimental hill. Let's see how ;strategy it goes. ;strategy 1.1 mod: Spider gets bored eventually and goes on the offense. That's it for this week. For submission instructions send me mail. The source code for the unix/X11 corewar program used in this tournament is available from soda.berkeley.edu as "koth25.shar.Z". -Bill (wms@iwarp.intel.com) From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: New Hill Message-ID: <1992May26.182217.1899@dcs.glasgow.ac.uk> Date: 26 May 92 18:22:17 GMT How do all concerned feel about running the experimental hill with '88 standard code, all addressing modes, max 64 processes and the increment mode ? Reasons for asking :- 1. We haven't tried a low process limit yet, which seem silly. MAIN REASON 2: I am convinced that scanners will not dominate with a 64 process limit. Not because programs will only be split to 64 processes by split bombs but because effective programs which run with 64 processes can be written and can therefore have strong resistance to split bombs. This should start a new 'breed' of program which will have `intelligent` structure if not intelligent behaviour. With Agony and Crimp (both excellent programs), scanners, I believe, have become as efficient as they can get and without becoming target-specific are unlikely to improve much. 3. OK, I admit it, I have some programs (like above) which I think will do well under these conditions. Campbell --- Hi, I'm a .signature virus. Copy me to yours and then wipe all your files. --- -- Campbell Fraser \/ INTERNET: fraserc%dcs.glasgow.ac.uk@nsfnet-relay.ac.uk Computing Science Dept /\ USENET : fraserc.glasgow.uucp Glasgow University \/ JANET : fraserc@uk.ac.dcs.glasgow Glasgow G12 8QQ, U.K. /\ From: wms@iwarp.intel.com (William Shubert) Subject: Code for "Spider 1.1" Message-ID: <1992May27.004417.29339@iWarp.intel.com> Date: Wed, 27 May 1992 00:44:17 GMT OK, here's the source code to "Spider 1.1". It's currently #1 on the experimental hill by a pretty large margin. It's fairly long and fairly complex. ;name Spider 1.1 ;author Bill Shubert ;strategy Sit and wait. When the enemy approaches, strike with a small and ;strategy fast offense. ;strategy This is an attempt to demonstrate that an extremely complex and ;strategy long fighter can succeed in the experimental hill. Let's see how ;strategy it goes. ;strategy 1.1 mod: Spider gets bored eventually and goes on the offense. ;kill Spider ;This program operates by effectively doubling it's reach by using what I call ; "fangs". A fang is the following pair of instructions: ;fang mov bite,@bite ; jmp fang ;The variable "bite" is located very far away, and is modified by a cooperating ; process which is also very far away. By putting fangs in the path of ; attacking processes, it is possible to have a 2-instruction target size ; but still have a decent amount of intelligence. The main loop is at the ; label "spider". spider loops, looking for opponents arriving from either ; side. When it sees an opponent, it goes to a routine that throws a fang ; in from of the opponent and makes a few bombing passes. After the passes ; are done, hopefully the opponent is trapped and control transfers to a ; piece of code that clears the entire core. ;Lots of improvements could be made - a better "clear" routine, and ; especially a better routine to go to after boredom sets in. Adding code ; is not hazardous, since if an enemy gets close enough to hit my main ; chunk of code I've probably lost already anyway. And, of course, there's ; no reason that a fang-style offense couldn't be put on a mobile program. coresize equ 8000 wdist equ 250 bspace equ 17 ;How far apart to but the bombs. bpasses equ 5 ;Number of bombing passes before giving up. passlen equ wdist * 2 / bspace ;Number of bombs per bombing pass. patience equ 150 ;Number of times to look for enemy before ; getting bored and going offensive. lofang equ loatt - wdist ;Position for low fang. lohit1 equ lofang - wdist + 1 ;Position for first low bomb. hifang equ hiatt + wdist ;Position for high fang. hihit1 equ hifang + wdist ;Position for first high bomb. loatt mov lokill1,lofang ;Move the lo fang to attack position. mov lokill2,lofang+1 spl lofang ;Start it running. loattl1 add bmov,lobomb ;Move the bomb. loattl2 djn loattl1,#passlen ;Jump back. mov #passlen,loattl2 add breset,lobomb ;Pass over; adjust position. djn loattl1,#bpasses mov locb,lobomb ;Passes over; first kill fang... jmp clear ; then start clearing core. locb dat #lofang-lobomb clfrom equ clbomb clto equ cllpc cljd equ -199 hicb clbomb dat #hifang-hibomb clear mov clbomb,clend-cljd ;Make sure the old "clear" is no good. mov #-cljd+20,cllpc ;Reset the clearing loop counter. mov #0,clbomb ;Reset the bomb location. cllp mov clbomb,locmp,cmpspot jmp loatt ;Enemy approaching from lo end! cmp Date: Wed, 27 May 1992 01:09:28 GMT In article <1992May26.142851.28418@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: |In article <3600.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: |>Not sure about mul and div, but at least shift. As for where to put |>the data block... it penalizes small programs more than large (complex?) |>ones, increasing their size by a larger percentage. | | This is NOT true. Both programs evidence the same amount of reduced |survivability. If a bombing routine divides the core into X sized chunks |(eg by bombing every 20 addresses X=20) then the probability that a |program of size N instructions will not be hit is (X-N)/X. Clearly the |dependance of survivability upon N is linear and so both small and large |programs suffer equally by being made longer by the same amount. The operative word in my note was STATIC. Large programmes are penalised more because the effective countermeasure to this extra footprint (assuming you can't erase it because you need it) is to copy yourself to a random location, which is clearly more expensive for the "large, static" kind of programme, as I noted. On the other hand, the point that small, static programmes are penalised even more IS true (despite the reasoning above): a constant amount of extra footprint is added to your programme - remember that the danger of big footprint comes from scanners, not bombers: with scanners it is expected time to FIRST CONTACT that determines the outcome of the game. And yes, you DO need mul and/or div because with variable core size you have to COMPUTE your optimal strides, and I don't think it's reasonable to have to code multiplication out the hard way.... ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: ScottNelson@cup.portal.com (Scott - Nelson) Subject: Re: New Hill Message-ID: <59647@cup.portal.com> Date: Wed, 27 May 92 02:19:11 PDT > 5/26/92 11:22 29/1252 fraserc@dcs.glasgow.ac.uk (Campbell Fraser) >How do all concerned feel about running the experimental hill with '88 >standard code, all addressing modes, max 64 processes and the increment mode . . . >MAIN REASON 2: I am convinced that scanners will not dominate with a >64 process limit. . . . Are scanners dominating the hill? Note paper (a 'paper' variant) is number 2 last time I checked. While it might stroke my Ego to believe that Note paper is such an incredibly strong mouse that it survives most scanners, I think it more likely that their just aren't as many scanners out there as you think. |+-----------------------------------------------------------------+| A theory that can't be proved wrong, can't be proved right either. <<>> From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91)) Subject: Re: A few ideas for the NEWARS IS. (long) Message-ID: <1992May27.030009.6991@vlsi.polymtl.ca> Date: Wed, 27 May 1992 03:00:09 GMT ajpierce@med.unc.edu (Andrew Pierce) writes: : In article <3600.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: : >Not sure about mul and div, but at least shift. As for where to put : >the data block... it penalizes small programs more than large (complex?) : >ones, increasing their size by a larger percentage. : : This is NOT true. Both programs evidence the same amount of reduced : survivability. If a bombing routine divides the core into X sized chunks : (eg by bombing every 20 addresses X=20) then the probability that a : program of size N instructions will not be hit is (X-N)/X. Clearly the : dependance of survivability upon N is linear and so both small and large : programs suffer equally by being made longer by the same amount. : -Andy : ajpierce@med.unc.edu Don't mix relative and absolute value ! They will be increase by the same amount, but the probability of hitting small program will be more significantly changed. Since they are so simple, they are penalized. -- "Pis Bourassa qui est toujours la. Y'a pas d'remede contre le SIDA" - French B "This is a mad house !" - Rosencrantz ...........................................................dak@info.polymtl.ca From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: Simple Scan 2 Message-ID: <1992May27.103545.8230@dcs.glasgow.ac.uk> Date: 27 May 92 10:35:45 GMT The code for a program just submitted. ;redcode verbose ;name SimpleScan 2 ;author Campbell Fraser ;strategy +------------------------------+ ;strategy | Program posted to net. | ;strategy +------------------------------+ LEN equ 9 NEXT add INC, POS POS cmp -2, 3998 EXIT slt #LEN, POS jmz NEXT, Date: Wed, 27 May 92 20:45:18 PDT How many instructions does it take YOU to move the contents of the A-field, to the B-field? Accessing a location in core, and copying it's A-field to a B-field in my program takes a minimum of 4 instructions. If I want to reuse that code it takes another instruction and a memory location to do so. Has anyone got better ways of doing it? Charles_K_Hughes@cup.portal.com From: as666@cleveland.Freenet.Edu (Jonathan Roy) Subject: ImpBreed-x 1.0 slain! Message-ID: <1992May28.060546.29347@usenet.ins.cwru.edu> Date: Thu, 28 May 92 06:05:46 GMT My ImpBreed has been slain. Here's the code: ;redcode-x verbose ;name ImpBreed-x 1.0a ;author Jonathan Roy ;strategy A glorified imp. Breeds a special type of ImpLance. ;strategy 1.0a: One line/instruction shorter. start MOV 1,20 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 MOV 0,10 SPL -10 END ;kill I'm still trying to construct a SuperImp with a weapon. Oh well. I'll resubmit ImpBreed in a few days and try sneaking back on. (^= ||| Jonathan Roy (The Ninja) Internet: as666@cleveland.freenet.edu ||| -- BBS: Darkest Realm - (Down for now) - Public UUCP/Usenet -- / | \ "...make him want to change his name,take him to the cleaners, devastate him, wipe him out, humiliate him." -CHESS GEnie: J.ROY18 From: stephen@estragon.uchicago.edu (Stephen P Spackman) Subject: Re: Move contents of A-field to B-field? Message-ID: Date: 28 May 92 06:22:45 GMT This may be the wrong question! In scanners you can use an external invariant, like a-field = -b-field (plus mirroring can't save you now!). Oops. Another trade secret slips away :-). ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies stephen@estragon.uchicago.edu University of Chicago ---------------------------------------------------------------------- From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser) Subject: Re: New Hill Message-ID: <1992May28.094549.21091@dcs.glasgow.ac.uk> Date: 28 May 92 09:45:49 GMT In article <59647@cup.portal.com>, ScottNelson@cup.portal.com (Scott - Nelson) writes: > > 5/26/92 11:22 29/1252 fraserc@dcs.glasgow.ac.uk (Campbell Fraser) > >How do all concerned feel about running the experimental hill with '88 > >standard code, all addressing modes, max 64 processes and the increment mode > . . . > >MAIN REASON 2: I am convinced that scanners will not dominate with a > >64 process limit. > . . . > > Are scanners dominating the hill? Note paper (a 'paper' variant) is > number 2 last time I checked. While it might stroke my Ego to believe > that Note paper is such an incredibly strong mouse that it survives > most scanners, I think it more likely that their just aren't as many > scanners out there as you think. >: > <<>> The current hill: # %W/ %L/ %T Name Author Score Age 1 55/ 36/ 9 Crimp Andy Pierce 173 109 2 52/ 42/ 6 Frantic 0.5 Unknown Author 163 132 3 50/ 38/ 12 Charon v5.0 J.Cisek & S.Strack 161 130 4 51/ 41/ 9 Agony 2.3a Stefan Strack 161 81 5 48/ 40/ 13 PitTrap v3.1f J.Cisek 156 4 6 48/ 42/ 10 scissors88.3 Scott Nelson 155 76 7 45/ 35/ 21 Dynamic Duo 4.0 Stefan Strack 154 28 8 46/ 41/ 13 Sucker 2 Stefan Strack 151 14 9 45/ 41/ 13 izotop nandor sieben 150 10 10 47/ 45/ 8 Frenetic 1.1 Unknown Author 149 37 11 41/ 35/ 24 Parthenos Pierre Dak Baillarge 148 12 12 40/ 32/ 28 Armadillo Stefan Strack 148 169 13 37/ 32/ 31 Note Paper Scott Nelson 143 165 : : etc. Correct me if I'm wrong but Crimp, Frantic 0.5, Charon v5.0, Agony 2.3a and PitTrap v3.1f are all scanners. The last I heard of the experimental hill, Bill's program Spider is in the lead by a large margin. Spider is a scanner. Note: news/mail is usually slow getting to me so this might not be the most recent. Campbell -- Campbell Fraser \/ INTERNET: fraserc%dcs.glasgow.ac.uk@nsfnet-relay.ac.uk Computing Science Dept /\ USENET : fraserc.glasgow.uucp Glasgow University \/ JANET : fraserc@uk.ac.dcs.glasgow Glasgow G12 8QQ, U.K. /\ Subject: Re: New Hill Message-ID: <92149.125512AZNXS@ASUACAD.BITNET> From: Date: Thursday, 28 May 1992 12:55:12 MST izotop is a scanner. From: ajpierce@med.unc.edu (Andrew Pierce) Subject: Re: New Hill Message-ID: <1992May28.143415.6142@samba.oit.unc.edu> Date: Thu, 28 May 1992 14:34:15 GMT In article <1992May28.094549.21091@dcs.glasgow.ac.uk> fraserc@dcs.glasgow.ac.uk (Campbell Fraser) writes: >Correct me if I'm wrong but Crimp, Frantic 0.5, Charon v5.0, Agony 2.3a and >PitTrap v3.1f are all scanners. The last I heard of the experimental hill, >Bill's program Spider is in the lead by a large margin. Spider is a scanner. Crimp, Agony and Charon are scanners. I don't know what Frantic is. I think that PitTrap is NOT a scanner, but rather a vampiric bomber. I also think that you just caught the hill at a scanner upswing. People will write some good vampiric bombers and dwarfs and the scanners will go back down again. The fact that Note Paper is on the hill at all would be somewhat of a miracle if scanners were superabundant. Note Paper has only very recently hit a down-cycle. -Andy ajpierce@med.unc.edu From: h309@ellis.uchicago.edu (Unknown Soldier) Subject: Re: New Hill Message-ID: <1992May28.152147.17770@midway.uchicago.edu> Date: 28 May 92 15:21:47 GMT In article <1992May28.143415.6142@samba.oit.unc.edu> ajpierce@med.unc.edu (Andrew Pierce) writes: >In article <1992May28.094549.21091@dcs.glasgow.ac.uk> fraserc@dcs.glasgow.ac.uk (Campbell Fraser) writes: >>Correct me if I'm wrong but Crimp, Frantic 0.5, Charon v5.0, Agony 2.3a and >>PitTrap v3.1f are all scanners. The last I heard of the experimental hill, >>Bill's program Spider is in the lead by a large margin. Spider is a scanner. > > Crimp, Agony and Charon are scanners. I don't know what Frantic is. I >think that PitTrap is NOT a scanner, but rather a vampiric bomber. I also Frantic is a scanner also. -- []=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=[] || ~~ The Unknown Soldier ~~ + //|^|\\ + "Mistrust Authority, Promote || || h309@midway.uchicago.edu + <{-o-}> + Decentralization" - The H.E. || []=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=[] From: kv07@IASTATE.EDU (Warren Vonroeschlaub) Subject: Impdwarf Message-ID: <1992May29.090647@IASTATE.EDU> Date: 29 May 92 14:06:47 GMT Impdwarf did not do too well on the x-hill (it crawled up to #15 at it's peak). The main problem being that if the copy fails the program ends up killing itself. I tried to adress this problem in 2.0, but other problems cropped up keeping in off the hill altogether. The code is ;redcode-x ;name ImpDwarf 1.0 ;author Warren Kurt vonRoeschlaub ;strategy It's the Imp that acts like a Dwarf ;strategy Slightly more prolific than original start spl 1 source spl 1 go mov #(1+dest-source),source cloop mov Date: Fri, 29 May 92 21:18:04 PDT In the interests of speeding up program development, I am collecting various 'standard' routines. If you have a little trick that you like to use, by all means, send it to me, I'd like to see it. Anyway, I'm better at brute force than elegance, so I put my skills to work figuring out a standard program copier. It wasn't difficult: ; Start of your program. M equ 2 ; The number of MOVs in the copier SIZE equ (0-START+LAST+1)/M ; Size of our program FROM equ LAST ; Our FROM counter TO equ LAST+1 ; Our TO counter BOTM equ 0 ; It's always zero dest equ -500 ; Where we jump to. ; START ; Stick all your code here. jmp 1 ; Do nothing except even out the code ; ??? A, B ; Lots and lots of redcode. :) ; Entrance to the copier FLEE mov #dest, TO ; set our TO location mov #BOTM, FROM ; set our starting location mov #SIZE, CNT ; the length of our program needs to be set LOOP mov INT(TI/M) then add (M+D) cycles to the processing time. The reason you need to add cycles if TI/M is not an integer is because the loop moves nM instructions. The final JMP in the copy is set up the JMP to the last instruction copied under the possibly mistaken belief that the last instruction happens to be the start of the program. If this isn't true, just change the @TO to a direct value. Technically, the final JMP might be considered another used cycle. If you feel that it is, just add 1 to all the cycle counts above. Okay, I've written long enough, it's somebody else's turn now. Charles_Hughes@cup.portal.com From: Ordania-DM@cup.portal.com (Charles K Hughes) Subject: Re: The demise of B-field scanners? Message-ID: <59814@cup.portal.com> Date: Fri, 29 May 92 21:24:24 PDT Stefan Strack asked whether the current hill was hostile to B-field scanners. And whether this meant their death. The answer... yes. I'm working on a program to decimate SPL/JMP bombers and the simple B-field scanner defense is a part of it. The B-field scanners have it too easy right now so everyone is using the defense. I think, however, the another generation of B-field scanners will appear when people start scanning consecutive B-fields. Charles_K_Hughes@cup.portal.com From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: The demise of B-field scanners? Message-ID: <1992May30.015703.29511@vuse.vanderbilt.edu> Date: Sat, 30 May 1992 01:57:03 GMT The current hill seems very hostile to B-field scanners. Until an hour ago, there did not seem to be a single B-field scanning warrior on the standard hill (people with cryptic/missing ;strategy programs may correct me here). Coincidence? I submitted XTC (the grande finale winner of last years ICWS tournament, by Stefan Roettger) and Drone, a B-field scanning vampire I wrote for MADs Valetine tournament. XTC ended up as #19 with 117 pts and survived 2 challenges before being pushed off. Drone currently clings around #18. I see two reason for their lack of success on the hill: 1. the overwhelming presence of faster CMP scanners 2. B-field decoys/mutagenizers Is this just the current "hill climate"? Or are B-field scanners going the way of the dinosaurs? -Stefan (stst@vuse.vanderbilt.edu)