From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Re: finding mod numbers Date: 1 May 1994 19:42:09 -0600 Message-ID: <2q1lph$4a2@cwis.isu.edu> In article <2pumll$l5t@agate.berkeley.edu>, Michael Constant wrote: >There are two easy ways. By far the better of the two is to get my Optima >program (not Nandor's -- his doesn't have this feature) from soda (mail me >for the filenames if you don't have them already). Optima has a feature for >testing any given step size and telling you its mod number and optima number. What is the filename? I have the one that came with pmars, but I guess that's not yours. >The other way is to write a Dwarf program using that step size, and watch >it on a graphical core-viewer until the pattern repeats. Then count the >space between bombs. (You have to write a slightly more complicated bomber >if the mod number is less than 4, so that is doesn't hit itself. It's not >hard though. Mail me if you have any questions.) When I asked for an algorithm, I was hoping for some C example code... I guess I COULD do a dwarf for each of the 8000 possible constants..! And, actually, I'm not really just looking for an algorithm. I could probably write one up in a few minutes, but I'd be willing to bet that it would be MUCH slower than it really needs to be. :-) So, let me try this question. How did you do it in your optima program? From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Mars simulator allowing only one program to load.. Date: 1 May 1994 19:49:04 -0600 Message-ID: <2q1m6g$5hu@cwis.isu.edu> Is there a MARS that will let you load only one warrior, for testing purposes? I've been playing around a lot with bombing constants lately, and it bothers me to have to load a second program to just test the first. (Especially when the bomber hits its unintended target, when all I wanted to do is test the bombing patter until the program hit itself..!) :-) I've been using an imp-gate up to now, but I've been playing around with mod-2 bombing patterns a lot, which means the gate gets hit 50% of the time. This also would be useful to find out if a program is self-destructing, as a few of mine have been....sometimes I don't discover it until I'm watching in the graphical simulator, and it kills itself right at the point before it should have won. :-) From: kdmiller@ATHENA.MIT.EDU (Kenneth D Miller) Subject: Servers Date: 1 May 1994 21:47:41 GMT Message-ID: <2q181t$h36@senator-bedfellow.MIT.EDU> Okay, dumb question time. What's the current corewar server? I've got a program to try out, but I can't remember the site to send it. -- Ken! "Evil is afoot!" "Really, that's very philosophical, Tick. A foot? I always envisioned evil as a dark, brooding shape with sqinty eyes..." From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: Servers Date: 1 May 1994 22:23:18 GMT Message-ID: <2q1a4m$89m@agate.berkeley.edu> Someone Whose Name I Deleted By Mistake wrote: >Okay, dumb question time. > >What's the current corewar server? I've got a program to try out, but I can't >remember the site to send it. Okay, dumb answer time. The corewar FAQ is available by mailing pizza@ecst.csuchico.edu with a subject of "koth faq". This will give you a complete copy of the corewar FAQ, which includes instructions on how to submit corewar programs to the ongoing corewar competition called "King of the Hill" (I assume this is what you what to submit your program to). Good luck with your program! -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Re: finding mod numbers Date: 1 May 1994 23:47:49 -0600 Message-ID: <2q2465$8mq@cwis.isu.edu> In article <2q1nrm$bct@agate.berkeley.edu>, Michael Constant wrote: >You're right. You can get mine by anonymous ftp to soda.berkeley.edu, as >/pub/corewar/incoming/optimapc.exe (for PC users) or optima.shar (for >anyone else). Mine is significantly slower than Nandor's (the one that >comes with pmars), but more feature-rich. I just downloaded it, and you're right. It is more feature-rich. I no longer need to write the program I was going to, since I can just use yours...:-) >Are you trying to generate a list of all possible step sizes with the mod >number for each one? If so, then I should tell you that this has already >been done -- check out /pub/corewar/incoming/num8000a.zip, also on soda. >This file has all possible step sizes, with the mod number (and a lot of >other useful information) for each one. Unfortunately it doesn't uncompress >properly on my machine :-( but it might work on yours. Something like that...I looked at num8000a, but it did't uncompress on my machine properly either, and there wasn't ANY explanation of what anything was, except for cryptic headers. (I could read about the first 100 lines or so) Anybody have a good version of num8000a that they'd care to upload to soda? From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: Mars simulator allowing only one program to load.. Date: 2 May 1994 02:09:32 GMT Message-ID: <2q1ncs$bal@agate.berkeley.edu> Antonette Nixon wrote: > Is there a MARS that will let you load only one warrior, for testing > purposes? Yes, pMARS will let you load a single warrior. If you don't already have a copy of pMARS, you should get one by anon ftp to soda.berkeley.edu, as /pub/corewar/incoming/pmars05?.?, where the question marks indicate that there are several versions. pmars05s.zip is the source; pmars05.zip is the PC executables; pmars05g.zip is the PC 32-bit executables; and I think there's one other but I can't check right now because soda's down :-( -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y Date: Thu, 5 May 1994 14:13:47 MST From: Message-ID: <94125.141347AHNAS@ASUACAD.BITNET> Subject: mod m numbers Path: asuacad!asuvax!gatech!europa.eng.gtefsd.com!howland.reston.ans.net!agate!mconst From: mconst@OCF.Berkeley.EDU (Michael Constant) Newsgroups: rec.games.corewar Subject: Re: finding mod numbers Date: 2 May 1994 02:17:26 GMT Organization: U.C. Berkeley Open Computing Facility Lines: 42 Message-ID: <2q1nrm$bct@agate.berkeley.edu> References: <2pt2jt$5vn@cwis.isu.edu> <2pumll$l5t@agate.berkeley.edu> <2q1lph$4a2@cwis.isu.edu> NNTP-Posting-Host: flood.berkeley.edu >Michael Constant wrote: >>There are two easy ways. By far the better of the two is to get my Optima >>program (not Nandor's -- his doesn't have this feature) from soda (mail me Well this is not quite true. At my optima program (gee we should use different names ) there are two parameters (start, stop) that determines the range we are looking for the constants. If you use start=stop then it basically tests that particular number. If this number is not a desired modulo number then optima does not condider it . So if optima doesn't find anything than this number is not the the desired modulo number. In a manner of speaking this is a more powerfull feature then Michael's :-) Mischael writes: >My Optima program basically simulates a bombing run with that step size, >waits until it repeats, and counts the distance between bombs. However, I'm >*sure* there's a better way to do it -- I just haven't bothered to find it. Sure it is. This is the explanation for the slowness. This is a way to find out if a number is mod m . It is a function of my optima.c program: /* greatest common divisor */ unsigned int gcd(unsigned int a, unsigned int b) { while ((a != 0) && (b != 0)) if (a > b) a = a % b; else b = b % a; return a + b; } This is the Euclidean algorithm. If gcd(a,CORESIZE)==4 then a is a mod 4 bombing number. Nandor. From: mchapman@isle.waterloo-rdp.on.ca (M.Chapman) Subject: Re: Corewar Tutorials Date: Mon, 2 May 1994 15:11:31 GMT Message-ID: <1994May2.151131.1413@isle.waterloo-rdp.on.ca> Michael Constant (mconst@soda.berkeley.edu) wrote: : To go with Steven Morrell's wonderful corewar tutorial, I would like to write : a basic redcode tutorial for new corewar programmers. I think that this would : be useful because the standard tutorial.1,2 files are getting dated, and there : is no really good '94 draft tutorial for beginners (that I can find). : Does anyone else think this would be useful? : -- : - Michael Constant (mconst@soda.berkeley.edu) - I think that woudl be great. I'm having a hard time at it with the old ones so any help would be greatly appreciated. -- | Tass Chapman | m.chapman@ieee.org | FIDO 1:221\403 | | Conestoga College- Elec' Tech' Eng. Telecommunications | | Kitchener Ontario Canada | "OOPS... I guess that's not a thing conductive to a long life." From: humber@elearn.edu.yorku.ca (The Humberview School) Subject: Updated Redcode List Message-ID: Date: Mon, 2 May 1994 16:33:27 GMT Hello. I am a 13-year-old student interested in Core War programming. The Core War programs I have support the ICWS '88 standard. However, I'm curious. Is there any standard developed after '88? Could someone please send a list of Redcode commands of the most recent standard to me?? And if there's a standard beyond '88, could you point out some programs for any more recent standards? I have an IBM PC XT with an 8088 microprocessor. Please respond soon! Sincerely, Vikram Ravindran From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Warrior by startegy list? Date: 2 May 1994 21:02:24 GMT Message-ID: <2q3pp0$q7p@agate.berkeley.edu> Mitchell N. Quinn wrote: >I was wondering if anybody out there has a list of warriors according to >the strategy they employ. I have written a program using a Genetic Algorithm >to breed and test corewar programs. A list of this type, or just a listing >of the 'classic' warriors by stategy would be a great help. Well, here's a list (off the top of my head) of the major corewar strategies, with an example of each (most of these should be available on soda.berkeley.edu in the /pub/corewar/redcode/warrior10.tar archive -- mail me if you can't find one). Note that for the most part, these are the *simple* examples of strategy, rather than the most *effective* ones. Replicator: Paper by Matt Hastings Scanner: Iron Gate by Wayne Sheppard Bomber: Stone by Matthew Householder Imp-Spiral: IMPire by Anders Ivner Vampire: Sucker by Stefan Strack This is by no means a complete list, and most of these programs are not advanced enough to compete in a modern corewar tournament. They should, however, provide a good starting point for genetic algorithms. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: bharat@shadow.Eng.Sun.COM (Bharat Mediratta) Subject: C-Robots Date: 2 May 1994 22:49:52 GMT Message-ID: <2q402g$nde@engnews2.Eng.Sun.COM> Whatever happened to C-robots? It would be interesting to compare the strategies in that arena vs. Corewars. I took a look around with Archie, but the only C-robots I could turn up was for the PC (and I suspect that source code was not included). -Bharat --- Bharat Mediratta | Above opinions are mine and have bharat.mediratta@eng.sun.com | nothing to do with Sun Microsystems From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Warrior by startegy list? Message-ID: <1994May2.234743.3118@news.vanderbilt.edu> Date: Mon, 2 May 1994 23:47:43 GMT In article <2q3pp0$q7p@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: > Replicator: Paper by Matt Hastings Paper (a.k.a. Molerat), the ICWST'91 winner is by Scott Nelson. Most modern day papers are based on the smaller "Notepaper" also by him. Matt Hastings wrote a number of stone/paper combos (e.g. Flashpaper) but no pure paper as far as I recall. -Stefan (stst@vuse.vanderbilt.edu) From: pk6811s@acad.drake.edu Subject: Mod numbers & other number stuff Message-ID: <1994May3.083834.1@acad.drake.edu> Date: Tue, 3 May 1994 14:38:34 GMT > Quick question. How would I go about writing an algorithm to figure out > what mod a particular constant is? For example, if I had the number 3158 > (picked randomly just now), how would I go about finding what kind of a > bombing pattern using that constant would give? > Test = yournumber Counter = 1 while Test <> 0 Test = Test + yournumber if Test >= 8000 then Test = Test - 8000 Counter = Counter + 1 wend Mod = 8000 / Counter Or you could look it up in the NUM8000.ZIP file in pub/corewar at soda.berkeley.edu. NUM8000.ZIP has metrics on all the numbers in coresize of 8000, including mod, imp-number, time to scan imps, and maximum time to scan opponents of various sizes. Here's how I use NUM8000 to find a number with these characteristics: - mod = 1 - finds opponents of size 13 in the minimum time - approximates a mod-4 - smaller than 100 Sort the file in ascending order on these columns: 1. mod 2. find4 This collects all the mod-1's which approximate mod-4's together. Then scan down for numbers less than 100 and compare their find13 columns. This is how I chose 73 as a constant for Torch. It has a find4 of 1014 and find13 of 316, which are close to the minimums of 998 and 307 (for 4 and 13 themselves). NUM8000's 'find' numbers are approximately 1/2 the actual time to scan one location in every equal-sized chunk of core, so a find4 of 1014 means it would take 2028 or so steps to scan one location out of every 4. The theoretical limit is 8000/4 = 2000. For a bomber, this means there will be gaps of size 3 between most of the bombs, which can be important in protecting your other components. Using mod-1's that approximate other mods gives us a wider choice of numbers to choose from in any given setup. Paul Kline pk6811s@acad.drake.edu From: Joseph Ku Subject: .tar Date: Tue, 3 May 1994 16:14:54 -0400 Message-ID: Can anybody tell me how to un"tar" those "tar" files? Thanks. -- Joseph ============================================================================== ***RRRRRRRRRRR*** Joseph Ku \ ****OOOOOOOOO**** Verraeter+@CMU.EDU +----+ ----- *****YYYYYYY***** Carnegie Institute of Technology |____| / ******GGGGG****** Carnegie Mellon University /_/ +---+ *******BBB******* Pittsburgh, PA / |__\_ |___| ********V******** "Ku-"nature / |__|_ |___| version 3.0 |__|_ |___| -I- -M- -R- -U- February 27, 1994 |__|_ / \ ============================================================================== From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: New "big core" pMARS with graphics display uploaded Message-ID: <1994May3.173255.19114@news.vanderbilt.edu> Date: Tue, 3 May 1994 17:32:55 GMT Now available as: soda.berkeley.edu:/pub/corewar/incoming/pmars051.zip - DOS execs, req. 386+ We haven't updated the source archive yet, because the UNIX version hasn't changed. From whatsnew.051: >We added a graphics and textmode display to the 32-bit DJGPP >compiled, big core version of pmarsv.exe. While it looks almost >identical to 16-bit pmarsv, the new display is a complete rewrite >using the GRX graphics library for DJGPP. The graphics display is >ca. 2x faster than the BGI graphics of the 16-bit version and >supports SVGA cards (entered with -v 23 thru -v 63). pmars.exe and >pmarsv.exe support core sizes of up to 65536 and require a 386 or >better. The DOS extender go32.exe must be in the PATH for these >programs to run. > >The graphics display may be incompatible with certain memory >managers and DPMI hosts (it works with HIMEM.SYS and QEMM.SYS). This >includes older versions of Quarterdeck's QDPMI.SYS. You may get an >error message "GrSetMode: unknown adapter type in driver" if you are >entering pmarsv.exe from an extended text mode (80x43, 80x50). This >error message usually disappears if you run pmarsv again (don't ask >me why :-). > >Let us know if you are using pMARS on a 286 or below. We may no >longer provide BC compiled (16-bit) versions unless there is demand. > >The mouse can now trigger different events depending on which button >is pressed. These events are defined by the macros "mousel", >"mousem" and "mouser" in "pmars.mac". A new macro "next" (also >"Ctrl-N") kills the current warrior and advances to the next round. > >Cycle and process meters (lines at the top of the graphics display) >are now scaled to the display width. The process meter provides a >graphical display of the rate of process gain or loss. > >Thanks to our alpha testers Michael Constant, Mike Nonemacher and Brant >Thomsen. > -Stefan (stst@vuse.vanderbilt.edu) From: pk6811s@acad.drake.edu Subject: new num8000 file on soda Message-ID: <1994May3.131642.1@acad.drake.edu> Date: Tue, 3 May 1994 19:16:42 GMT Well, I have had some complaints that my num8000a.zip file is unreadable or something. So I just uploaded a comma-delimited, text-only version called num8000.txt. Enjoy! Paul Kline pk6811s@acad.drake.edu From: pk6811s@acad.drake.edu Subject: Re: finding mod numbers Message-ID: <1994May3.162659.1@acad.drake.edu> Date: Tue, 3 May 1994 22:26:59 GMT > The other way is to write a Dwarf program using that step size, and watch > it on a graphical core-viewer until the pattern repeats. Then count the > space between bombs. (You have to write a slightly more complicated bomber > if the mod number is less than 4, so that is doesn't hit itself. It's not > hard though. Mail me if you have any questions.) How about: dwf mov @0,0 add #x,dwf jmp dwf Works for me :-) Paul Kline pk6811s@acad.drake.edu From: mconst@soda.berkeley.edu (Michael Constant) Subject: Optima v3.0 Date: 3 May 1994 23:41:37 GMT Message-ID: <2q6nfh$l9c@agate.berkeley.edu> Yes! I just finished optimizing Optima v3.0 for speed and... well Nandor... you're going to have to make your program just a little bit faster if you want it to compete... :-) Optima v3.0 is a *lot* faster than any of my previous attempts, and it's significantly faster than Nandor's for most calculations. To show what I mean, here are the times for my Optima v3.0 and Nandor's optima on two different calculations (on my 386DX/25 -- your mileage may vary): Coresize 8000, mod 5 Coresize 55440, mod 8 Michael 0:05 2:48 Nandor 0:22 3:45 Note that Nandor's program will be more consistent over different coresizes and mod numbers than mine. My program optimizes for certain conditions, and these conditions do not always hold. It's conceivable that there are certain coresize/mod number combinations for which Nandor's program will be faster. However, mine will be faster for the vast majority of coresize/mod number combinations. I'm in a little bit of a rush right now, so an explanation of how Optima v3.0 works will have to wait a day or two. Besides, it's kind of fun keeping everyone in suspense for a little while. In the meantime, you can download your very own copy from soda (same filenames as usual (mail me if you don't have them)). Nandor, no peeking at the source until I tell everybody how it works. :-) -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: Joseph Ku Subject: Re: .tar Date: Tue, 3 May 1994 23:52:09 -0400 Message-ID: Thanks to everybody who has responded to my question. I was aware of such a command called "tar;" I just didn't have the right switches, i.e., tar "xf" filename. Thanks again, -- Joseph From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Optima v3.0 Date: 3 May 1994 23:56:47 GMT Message-ID: <2q6obv$llp@agate.berkeley.edu> Before anyone mails me saying that Optima v3.0 is buggy because it produces different numbers from Nandor's program, let me say that it's *supposed* to produce slightly different numbers. It will all be explained in a day or two, or whenever I get around to it. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Optima v3.0 Date: 4 May 1994 02:10:34 GMT Message-ID: <2q706q$o2s@agate.berkeley.edu> Here is the promised description of how Optima v3.0 works. First of all, it uses a quick and easy optimization I discovered: if Optima is simulating a bombing run and it finds at some point that the bomb it just placed is adjacent to a previous bomb, then it doesn't have to simulate the rest of the bombing -- *all* following bombs will be adjacent to some previously placed bomb. (This is easy to prove.) This speeds up operation, especially in big coresizes. But the main performance gain comes from something different. Optima v3.0 uses a slightly different formula than Nandor's optima. Optima v3.0's formula for coresize M is equivalent to Nandor's formula in a step-size block of an infinite coresize (*). The nice thing about using an infinite coresize is that all the nasty edge effects drop out. An example will help: Suppose we are trying to calculate the optima number of the step 3 in coresize 8000. Nandor would simulate the bombing run and count the distance between bombs at each point. But this wastes a lot of time! The program spends most of its time recalculating the same thing -- first it adds up a bunch of 3s, then it adds a bunch of 1s, then it adds up another bunch of 1s. The only deviation from this pattern is that right as it switches from the 3s to the 1s, we get edge effects -- there is a single 2 between the 3s and the 1s. This is the difference between my program and Nandor's. Mine understands that *except for the edge effects*, the optima number for 3 in coresize 8000 will be (3+1+1)/3. Optima v3.0 will just simulate 3 adjacent locations in core, and look at what happens to them. Since 3 is our step size, we know that except for edge effects, these 3 core locations will look just like every other group of 3 core locations. All we have to do is use Nandor's method to simulate a bombing run of step (8000 % 3) in coresize 3, add Stradivarius' Constant (**), and this will very closely approximate Nandor's optima value for step 3, coresize 8000. But we have only had to simulate the placement of 3 bombs, while Nandor had to simulate 8000 (since 3 is a mod-1 step in coresize 8000). Our answer is wrong by the magnitude of th edge effects we have ignored, which in this case is 1 in ~13550 (we used a 1 where it should have been 2). The advantage of my method becomes apparent. Of course, this method works proportionally less well as the step size increases. However, it is always faster than Nandor's method, because at worst we will be using a step size of CORESIZE/2. Since the step size becomes the effective coresize in my method, this method is therefore twice as fast as Nandor's method even in the worst case. So why, you may ask, is my program not even twice as fast as Nandor's? Answer: because of the way they manage memory. Mine uses every bit of allocated memory to store useful information. Unfortunately this requires lots of type-casting and bitwise operators, which slow the program down. Nandor's C version (the Pascal version is efficient but slower) wastes memory by a factor of 16 (using an int to store a boolean value) and thus requires DJGPP to compile, but can use regular int pointers and gain quite a bit of speed. When (if?) Nandor incorporates the algorithm described here into his program, it will again be faster than mine. Two other comments: I eliminated the time estimate from Optima v3.0 because it was too inaccurate with the new calculating method (because the new method zips through the small step sizes but slows down for the large ones). I also eliminated the line of moving dots when the program was calculating, because they created problems when redirecting Optima's output to a file. ------------------------ (*) But the infinite coresize must be congruent to the real coresize (mod step-size). It doesn't matter how big it *really* is, because we are only looking at a step-size block. (**) Stradivarius' Constant (colloq. known as the "fiddle factor") In order to make the results accurate, it is necessary to add the step size to the total score value obtained in the opt() function. This is because the first pass through core is not counted (for speed reasons). If we counted the first pass, then this would not be necessary. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Imp-gates Date: 4 May 1994 08:33:11 -0600 Message-ID: <2q8bn7$fgq@cwis.isu.edu> Quick question about imp-gates. Which is better: SPL 0 DJN 0,<-35 or just JMP 0,<-35 ? The DJN imp needs a spl instruction, because it will die if it encounters locations with Bfield of 1, correct? But, it also decrements in reverse throughout core? (And wreaks havoc on anything that needs to point to a specific place, including sometimes itself...) :-) My first instinct is to say the DJN imp is more effective, since it gets more chances to decrement an imp's instruction as the imp is executing. Am I missing something? From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: mars simulators Date: 4 May 1994 08:38:38 -0600 Message-ID: <2q8c1e$g63@cwis.isu.edu> Is there a simulator similar to MARS88, but written for the '94 standard? I've been looking at pmars, but MARS88 has one feature that pmars doesn't that I really like. (like enough to not want to switch) In the graphical display of mars88, you can execute one step at a time, and it shows the current execution locations of both programs. Is there a way to do this in pmars? Pmars has what seems to be a wonderful debugger, and may work well for all you assembly-gurus out there, but to me it's EXTREMELY confusing. From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: Mod numbers & other number stuff Message-ID: Date: 04 May 1994 10:18:32 GMT In article <1994May3.083834.1@acad.drake.edu> pk6811s@acad.drake.edu writes: > From: pk6811s@acad.drake.edu > Subject: Mod numbers & other number stuff > Date: 03 May 1994 14:38:34 PST-8 > > > Quick question. How would I go about writing an algorithm to figure out > > what mod a particular constant is? For example, if I had the number 3158 > > (picked randomly just now), how would I go about finding what kind of a > > bombing pattern using that constant would give? > > > > Test = yournumber > Counter = 1 > while Test <> 0 > Test = Test + yournumber > if Test >= 8000 then Test = Test - 8000 > Counter = Counter + 1 > wend > Mod = 8000 / Counter [Stuff on NUM8000] The NUM8000 file is a great package. Someone up to produce the same thing for the big core? Anyway, I just wanted to say that you don't need to do all the above to find out what mod-number 3158 is. What you need to do is find the gcd (greater common divisor) of 3158 and 8000, which can be done with Euclid's algorithm in no time at all. In this case, the gcd is 2, so 3158 is a mod-2 number. The idea here is that any relative prime to 8000 is a mod-1 number. If you take a *relative* prime to 8000 (e.g. 9, which is *not* a prime) and multiply it by N, the result is a mod-N number. Thus, the gcd eliminates the relative prime factors in the number, and preserves only the N factor. Another way of putting it would be to say that if N divides 8000, then any linear sequence of step N*x dwells in Z/(8000/N)Z, so that the sequence is at most a mod-N number. Finding a gcd between two numbers a and b can take at most log(c) operations, where c is the largest of a and b, and log() is the binary logarithm. Thus, it involves far fewer steps than simulating the bombing run, as described in Paul's article. It can make a difference on a slow PC with the big core... Notice that this trick only works to find out what mod-number a given number is. It won't help at all if you're looking for near-mod numbers, or anything like what Paul describes about the NUM8000 file. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 Date: Wed, 4 May 1994 10:33:54 MST From: Message-ID: <94124.103354AHNAS@ASUACAD.BITNET> Subject: Re: finding mod numbers You have to find the greatest common divisor of coresize and the bombing number. One way to do it is the Euclidean algorithm. Check out any number theory book, or look at optimap.zip on soda . Another way is to do the prime factorization of both numbers, and multiply all the common prime factors with the smaller multiplicity. Nandor. From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: mars simulators Date: 4 May 1994 19:03:59 GMT Message-ID: <2q8riv$7f4@agate.berkeley.edu> Antonette Nixon wrote: >In the graphical display of mars88, you can execute one step at a time, >and it shows the current execution locations of both programs. Is there >a way to do this in pmars? Yes there is. In the graphics display, just hit "d" (for "debug") and you will enter the debugger. In the debugger, you can enter "s" (for "step") to execute the next instruction, so you can single-step through the program. If you enter a blank line in the debugger it will repeat the last command, so once you have entered "s" once you can just keep hitting Enter and it will step through the program. The mouse cursor moves to show you where the next instruction will be executed. When you're done, enter "c" (for "continue") to exit the debugger. The pmars debugger is *very* powerful and you should read the help file to find out what it can do. Single-stepping through your program is just the beginning (although I have to admit that single-stepping through a program is what I use the debugger for most :-) -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 5 May 1994 05:06:00 GMT Message-ID: <2q9uro$okk@magus.cs.utah.edu> __ __| | ) _ \ | | \ \ / _) | __ \ _ \ / ( | | | \ \ \ / _` | __| __| | _ \ __| | | | | __/ \__ |___ __| \ \ \ / ( | | | | ( | | _| _| |_|\___| _/ _| \_/\_/ \__,_|_| _| _|\___/ _| May 4, 1994 Issue #7 ______________________________________________________________________________ This newletter covers the current status of the ICWS '94 Draft hills, and also attempts to keep up with the latest ideas in how the new standard will affect corewars in general. I hope you enjoy it! If you are unfamiliar with the '94 draft standard, you can learn more about it by reading the FAQ for this newsgroup. In addition, the program pMARS includes a highly recommended tutorial on the new standard. Feel free to send me e-mail if you have any difficulty finding either of them, if you need to have a corewar item mailed to you, or if you have any other questions. The FAQ is available through anonymous FTP to rtfm.mit.edu, as /pub/usenet/news.answers/games/corewar-faq.Z ______________________________________________________________________________ CHANGES and CORRECTIONS: Excitment is thick in the air after the first two rounds of Stefan Strack's corewar tournament. It's still too early to tell what will happen, and if the fierce competition on the '94 hills is any indication of what's to come, it will not get any easier to predict later on. (Still, I know who I want to win!) Good luck to all the remaining participants! (... and condolences to Michael Constant and Nandor Sieben, the first two participants to be eliminated.) If you are working on warriors for a large size core on an IBM computer with Super-VGA graphics, you will definitely want to grab the latest version of pMARS off of "soda.berkeley.edu". It is now possible to watch your large warriors in action! Thanks to the pMARS team for a great effort! Other helps now available include a faster verion of Optima (by Michael Constant) and a step-size help file for 8000 size cores by Paul Kline that is readable. Both are tools no redcode developer should be without. ______________________________________________________________________________ The ICWS '94 Draft Hill: Core size: 8000 instrucitons Max processes: 8000 per program Duration: After 80,000 cycles, a tie is declared. Max entry length: 100 instructions The current ICWS '94 Draft hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 44/ 36/ 20 Pyramid v1.0 Michael Constant 151 1 2 38/ 25/ 38 Der Zweite Blitzkrieg - 9 Mike Nonemacher 151 112 3 39/ 28/ 33 Torch P.Kline 150 2 4 43/ 36/ 21 Sauron v5.0 Michael Constant 150 12 5 32/ 16/ 52 Blue Funk Steven Morrell 148 129 6 32/ 17/ 51 Cannonade P.Kline 147 4 7 44/ 43/ 14 Iron Gate 1.5 Wayne Sheppard 145 106 8 33/ 23/ 44 Lucky 3 Stefan Strack 144 122 9 32/ 21/ 47 Twimpede+/Small-X Jay Han 143 5 10 40/ 38/ 21 Request v2.0 Brant D. Thomsen 143 160 11 32/ 22/ 46 NC 94 Wayne Sheppard 142 142 12 43/ 48/ 8 Rave 4.1 Stefan Strack 138 94 13 41/ 45/ 14 Dragon Spear c w blue 137 162 14 29/ 21/ 50 ^C Steven Morrell 137 21 15 36/ 36/ 28 Christopher Steven Morrell 135 50 16 30/ 25/ 45 Splash Jay Han 134 100 17 29/ 25/ 46 Imperfection v3.4 Michael Constant 133 25 18 35/ 37/ 28 Yop La Boum v2.1 P.E.M & E.C. 133 92 19 38/ 44/ 18 SJ-4 J.Layland 133 36 20 40/ 48/ 12 Iron Gate 1.2b Wayne Sheppard 131 3 21 2/ 98/ 0 Looking Brant D. Thomsen 7 0 Since the last issue of the Warrior, exactly 99 programs have made it onto the '94 standard hill. "Der Zweite Blitzkrieg - 9", "Pyramid v1.0", "Sauron v5.0", and "Torch" are all been fighting for the top slot on the hill, and all of them deserve it. It looks like the "pizza" hill is well represented by every type of program but "paper". (Anders Ivner's "Killer Instinct" was in third place on the hill last month. However, it is still doing well on the "stormking" hill.) Perhaps "paper" is the one warrior type that doesn't benefit from the newer standard. (Opinions, anyone?) I am also including the results of the "stormking" hills in this, and future, issues of _The_'94_Warrior_. I had planned to cover the "pizza" hill exclusively, but later decided that the "stormking" hills have enough traffic to warrant their coverage as well. In addition, they also tend to have a much different "flavor" resulting from the quite different programs on the hill. If you have a program that can't quite get onto a hill on one server, I'd recommend trying it on the other one -- it may do quite well! The current ICWS '94 Draft hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 45/ 29/ 26 Sauron v3.6 Michael Constant 160 1 2 41/ 27/ 32 Killer instinct Anders Ivner 155 24 3 36/ 21/ 43 Twimpede+/8000-d1 Jay Han 150 14 4 44/ 38/ 17 Ntttgtstitd Simon Hovell 150 25 5 43/ 38/ 19 Request v2.0 Brant D. Thomsen 148 17 6 34/ 21/ 44 Lucky 3 Stefan Strack 147 12 7 35/ 23/ 42 NC II Wayne Sheppard 147 79 8 35/ 25/ 40 Sphinx v5.1 W. Mintardjo 145 82 9 43/ 41/ 17 Sylvester v1.0 Brant D. Thomsen 144 61 10 29/ 19/ 53 ttti nandor sieben 139 35 11 32/ 26/ 42 JustTakingALookSee J.Layland 138 78 12 31/ 24/ 45 Snake Wayne Sheppard 138 34 13 43/ 47/ 10 Rave 4.1 Stefan Strack 138 7 14 39/ 40/ 21 tiny J.Layland 138 59 15 29/ 20/ 51 ttti94 nandor sieben 137 30 16 39/ 42/ 19 Beholder's Eye v1.7 W. Mintardjo 137 91 17 38/ 42/ 19 Christopher Steven Morrell 135 23 18 39/ 43/ 18 SJ-4 J.Layland 134 28 19 37/ 43/ 20 Fast Food v2.1 Brant D. Thomsen 131 37 20 35/ 40/ 26 pepper P.Kline 129 6 The "stormking" hill appears to be even more diverse than the "pizza" hill. This hill will be a fun one to watch as it developes. Many of the programs on it are '88 standard programs, and several other programs have been converted from the '88 to the '94 standard. The "pizza" hill, on the other hand, has many warriors that are highly '94 dependent. ______________________________________________________________________________ The ICWS '94 Draft Experimental Hill: Core size: 55,440 instructions Max processes: 10,000 per program Duration: After 500,000 cycles, a tie is declared. Max entry length: 200 instructions The current ICWS '94 Experimental (Big) hill on "Pizza": # %W/ %L/ %T Name Author Score Age 1 51/ 32/ 18 Demand-55440 M. Constant & B. Tho 170 9 2 39/ 21/ 40 Variation G-1 Jay Han 157 44 3 44/ 35/ 20 Request-55440 Brant D. Thomsen 153 80 4 35/ 22/ 43 Splash 1 Jay Han 149 45 5 45/ 43/ 12 Squint Mike Nonemacher 148 18 6 37/ 27/ 36 Lucky 13 Stefan Strack 148 86 7 41/ 37/ 22 Vanity IIx Stefan Strack 146 35 8 33/ 24/ 44 BigImps James Layland 142 15 9 43/ 45/ 12 Virus Jay Han 141 3 10 43/ 46/ 11 Rave B4.1 Stefan Strack 141 41 11 41/ 42/ 17 Raiden Richard van der Brug 139 14 12 39/ 40/ 21 White Fang Steven Morrell 139 5 13 32/ 25/ 42 Der Zweite Blitzkrieg - 9 Mike Nonemacher 139 42 14 28/ 18/ 54 Imperfection v2.4 Michael Constant 138 51 15 43/ 49/ 8 Scanalyzer Jay Han 138 4 16 38/ 38/ 24 Sauron v3.4 Michael Constant 137 23 17 38/ 38/ 24 Lump J.Layland 137 25 18 34/ 32/ 34 Sissy Jay Han 137 40 19 37/ 45/ 18 testing2 J.Layland 129 1 20 5/ 0/ 0 Big J-1 Jay Han 14 2 Although many new programs have made it onto the hill, the hill hasn't changed all that much. Scanners, imp-spirals, and vampires all seem to be well represented. Perhaps the largest change is the addition of "Demand-55440", which currently has a stronghold on the top position. "Demand" appears to be good proof of something I've heard repeated many times in the newsgroup by prominent redcode authors: the best warriors tend to be those that have a combination of strategies or types. The current ICWS '94 Experimental (Big) hill on "Stormking": # %W/ %L/ %T Name Author Score Age 1 53/ 31/ 15 Raiden Richard van der Brug 175 1 2 44/ 21/ 35 Lucky 13 Stefan Strack 168 18 3 46/ 30/ 25 Request-55440 Brant D. Thomsen 161 52 4 39/ 19/ 42 Bakers Dozen Wayne Sheppard 159 11 5 43/ 28/ 29 Sauron v2.4 Michael Constant 158 3 6 41/ 28/ 30 Variation D-1 Jay Han 155 13 7 45/ 36/ 20 Vanity IIx Stefan Strack 154 6 8 33/ 17/ 50 Imperfection v2.3 Michael Constant 149 46 9 44/ 46/ 10 Rave B4.1 Stefan Strack 141 7 10 30/ 23/ 47 BigImps James Layland 138 112 11 41/ 45/ 14 Dagger v7.0 Michael Constant 136 12 12 41/ 46/ 13 bigproba nandor sieben 136 10 13 30/ 24/ 47 BigImp Alex MacAulay 135 93 14 34/ 34/ 32 Industrious Stefan Strack 134 2 15 41/ 47/ 12 The Count Jay Han 134 42 16 34/ 38/ 27 Test Stefan Strack 131 4 17 34/ 38/ 27 Open Arms Stefan Strack 130 5 18 31/ 34/ 35 Veeble Jr. T. H. Davies 129 14 19 35/ 45/ 19 IceCube 1.4 Richard van der Brug 125 8 20 37/ 51/ 11 Kill Imps!!! Steven Morrell 123 39 ______________________________________________________________________________ HINTS and HELPS: I wanted to come up with some good use for the MUL and DIV instructions for this issue's hint. There has been a large amount of '94 code posted recently, but I don't recall any of it that used either of these instructions. The two things that I was able to imagine that MUL and DIV would be useful for is a binary bomber (where the programs bombs over successively smaller intervals), and programs that must be able to run in many different possible coresizes. So, along this line, I came up with a program which will launch an imp-spiral with the minimum number of points for any size core (given a know size limit). At first, I tried to do this without using any constants, but the "mod" mathematical limitations became too much. Recall that for an "P" point imp-spiral to be possible in a size "C" core, then for any step-size "S" where S * P = N * C + 1 (and N is any possible integer in the range 1 <= N < P), then we have a stepsize to create an imp-spiral with that many points. The problem is, of course, that N * C + 1 becomes 1 in the core no matter what integer value N is assigned. This can make finding the possible imp-steps for large values of N quite difficult to do during run-time. So, instead, I took a compromise. I take the CORESIZE value supplied by pMARS, and use it to determine all the possible imp-spiral step sizes I want to try. Then I use a simple loop to determine whether or not each possible imp-spiral step size will work. To do this, I take the value I want to test and multiply it by the number of points I am considering for the imp-spiral. If the result is 1 larger than the coresize, I have a successful number. The corewars interpreter automatically takes care of the modular arithmetic, making the loop surprisingly short and simple. You may want to pay special attention to the main loop in the code, as I do some things in it that are heavily '94 dependent. Each of the modifiers in this loop had to be chosen carefully for the program to work correctly. The DAT statements on the end of the program will find an imp-spiral for any coresize that is not divisible by 30030. (Notice that 30030 is the product of all the primes no greater than 13.) I have also added the first two 17 point imp-spiral sizes needed to handle 30030 and 60060. If you add all of the DAT statements for the 17-point imp-spiral steps, then you will be able to handle any coresize that is not divisible by 510510. (B.T.W.: 510510 = 17 * 30030) This should be adequate for most programmers. ;-) Since a randomly sized core will be divisible by 2 half the time, the average number of cycles needed to find the wanted imp-spiral step size should be small. Most of your cycles will be taken up in generating the processes for the imp-spiral and launching it. (In reality, you would probably want less processes than I have here.) Perhaps some of you corewar experts out there could even figure out a way to have the number of processes sent to the imp- spiral vary dymanically based on the number of points it will have. ;redcode-94 ;name Imp-Spiral Finder ;author Brant Thomsen ;strategy Launch the smallest possible imp-spiral for any coresize < 90090 ;macro boot equ 150 imp mov.I #0, 0 ; Will copy value here later. find mov.B I asked before, but it's been a while, and I didn't get any responses. Are there any Corewar tutorials that assume no prior knowledge of machine langugage? (I'd assume there probably aren't, seeing as how nobody pointed me to one.) If I wanted to learn enough rudimentary machine langugage to figure Corewar out, what would be a good book to read? Thanks in advance. From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Numbers, numbers... Message-ID: Date: 05 May 1994 10:55:30 GMT Hi all, Remember I suggested someone make a num55440? Well, I decided to go ahead and do it. I uploaded the result to soda.berkeley.edu:/pub/corewar/incoming/num55440.Z Since I don't have a [PK]zip on my machine, I compressed it. If there is enough demand, I'll try to get hold of a PC and use PKZIP. BTW, the uncompressed file is over 1M long. It has a more generous formatting than the packed-comma-delimited format. The information contained in it is the same: step size, mod number, every4, every5, every10, every13. A "-1" means that the find is never complete. I started the computation on a DECstation (MIPS R3200), and after a couple of hours, it was working on step 4000+, so I killed the job and re-started it on an Alpha. It still took several hours to complete. So... don't try it at home! Because the file is so big, and your sort program may not be able to handle it at all, I also uploaded two files. use55440.Z contains all step sizes that have at least one of the "every"'s. sm55440.Z contains those that are mod-3 or less, so that all "every"'s exist. They are respectively 650K and 400K in size, uncompressed. If you want a more compact comma-delimited file, let me know, and I'll upload them. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: pk6811s@acad.drake.edu Subject: num8000.doc Message-ID: <1994May5.085116.1@acad.drake.edu> Date: Thu, 5 May 1994 14:51:16 GMT OK, OK .. Here is the .doc file for num8000, which I just posted to soda :-) The NUM8000 file has several useful metrics for all the numbers in a coresize of 8000. It is a comma-delimited text file intended to be read into a spreadsheet or database program. Columns: N The number (2-8000) Mod Bombing with N will hit every Mod'th location Imp# All mod-1 numbers are imp numbers that can be used in an imp-ring or spiral. The imp# for 9 is 881, so the mov statement for a 9-point imp would be MOV 0,881. Scan2667 The number of steps required for a bomber/scanner using N as an increment to bomb/scan two locations X and X+2667. A spl-jmp bomber/scanner working against a slow-running 3-point imp (MOV 0,2667) could choose an N which had a low FindX value (depending on the size of other components in the opponent) AND a low Scan2667 value, giving him an efficient bomb/scan pattern which could also zap the imp. Scan1143 Like Scan2667, but for 7-point imps (MOV 0,1143). Find4 If core is divided up into chunks of 4 locations, how long would it take a bomber/scanner using N as a step to hit at least one location in every chunk? Or - if your opponent is 4 lines long, what is the maximum possible time to find him, no matter where he's located? Due to the algorithm I used to determine these values, they are approximately one-half the actual time, but are still very useful for comparing N's. Find5 Like Find4 only for chunks of 5. Find10 Like Find4 only for chunks of 10. Find13 Like Find4 only for chunks of 13. Here's how to use NUM8000 to find a number with these characteristics: - mod = 1 - finds opponents of size 13 in the minimum time - approximates a mod-4 - smaller than 100 Sort the file in ascending order on these columns: 1. mod 2. find4 This collects all the mod-1's which approximate mod-4's together. Then scan down for numbers less than 100 and compare their find13 columns. This is how I chose 73 as a constant for Torch. It has a find4 of 1014 and find13 of 316, which are close to the minimums of 998 and 307 (for 4 and 13 themselves). NUM8000's 'find' numbers are approximately 1/2 the actual time to scan one location in every equal-sized chunk of core, so a find4 of 1014 means it would take 2028 or so steps to scan one location out of every 4. The theoretical limit is 8000/4 = 2000. For a bomber, this means there will be gaps of size 3 between most of the bombs, which can be important in protecting your other components. Using mod-1's that approximate other mods gives us a wider choice of numbers to choose from in any given setup. Paul Kline pk6811s@acad.drake.edu From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: Imp-gates Message-ID: Date: 05 May 1994 15:52:43 GMT In article <2q8bn7$fgq@cwis.isu.edu> fullanto@cwis.isu.edu (Antonette Nixon) writes: > From: fullanto@cwis.isu.edu (Antonette Nixon) > Subject: Imp-gates > Date: 04 May 1994 14:33:11 PST-8 > > Quick question about imp-gates. > > Which is better: > > SPL 0 > DJN 0,<-35 > or just > JMP 0,<-35 > ? > The DJN imp needs a spl instruction, because it will die if it encounters > locations with Bfield of 1, correct? But, it also decrements in reverse > throughout core? (And wreaks havoc on anything that needs to point to a > specific place, including sometimes itself...) :-) > My first instinct is to say the DJN imp is more effective, since it > gets more chances to decrement an imp's instruction as the imp is > executing. Am I missing something? These two devices behave differently, and address different goals. The first one, let's call it the split-wimp, is what makes CG tick. CG is just eight split-wimps spread in the core. The advantage of the split-wimp over the simple wimp is that: - it accumulates processes - it can kill The drawbacks, of course, are: - it accumulates processes - it's twice larger The big difference is that the split-wimp can kill. Especially if (under the '94 standard) you program it: SPL #0, <-10 DJN.F #0, <-11 This alone is a perfect gate, and decrements both A- and B-fields of almost every core location. It also accumulates processes, which means that if an imp crashes through, it'll get a tie. The immediate A-field makes it durable: it won't kill itself when the pointer wraps around. It will probably kill the opponent's stone component, and can make a mess to any self-modifying warrior. It will probably also confuse a vampire. All jumps will be shifted, which can be deadly. All in all, it's very potent, but only if your main component can accumulate processes faster (e.g. ExtraExtra). Now, you can also put just: DJN.F #0, <-10 It's still pretty useful, and I don't think having both A- and B-fields zero in random core is likely to happen (i.e. it won't break out of the loop). However, it doesn't accumulate processes, which may be a plus or a minus, depending on what you do besides. Anyway, I can't see any reason to prefer JMP #0, <-10 over DJN.F #0, <-10 CG did pretty well, but was too vulnerable to smart scanners and vampires. The problem is that if you put a single split-wimp, there's no chance it can decrement the core fast enough to kill a scanner. On the other hand, if you put several of them, no one will be a perfect gate, since they share cycles. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: The '94 Warrior Date: 5 May 1994 21:01:40 GMT Message-ID: <2qbmrk$2jd@agate.berkeley.edu> Brant Thomsen wrote: > [...] "Der Zweite Blitzkrieg - 9", "Pyramid v1.0", "Sauron v5.0", and > "Torch" have all been fighting for the top slot on the hill, and all of > them deserve it. They *were* fighting for first place but then I submitted Pyramid v2.0... :-) The source is coming soon to a newsgroup near you! >I am also including the results of the "stormking" hills in this, and future, >issues of _The_'94_Warrior_. I had planned to cover the "pizza" hill >exclusively, but later decided that the "stormking" hills have enough traffic >to warrant their coverage as well. I beg to differ. I submitted Sauron v3.6 to stormking on April 23, I got the results back April 24, and it's still at age 1 today. That means that no programs have gotten onto the stormking '94 hill since April 24. Hmmm... >The "stormking" hill appears to be even more diverse than the "pizza" hill. >This hill will be a fun one to watch as it developes. Many of the programs >on it are '88 standard programs, and several other programs have been >converted from the '88 to the '94 standard. The "pizza" hill, on the other >hand, has many warriors that are highly '94 dependent. Maybe I'm being cynical, but I would view this as further evidence that the main hill traffic has moved from stormking to pizza. I have nothing against continued reviews of the stormking hills, and I would certainly encourage people -- especially beginners -- to submit to stormking. However, I would say that right now, stormking holds a lot of second-rate warriors which have already been pushed off pizza. And I believe that new, good warriors -- what _The_'94_Warrior_ is interested in -- will appear first on the pizza hill, and only on stormking after they are established on pizza (if they appear on stormking at all!). -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: mod m numbers Date: 5 May 1994 23:40:35 GMT Message-ID: <2qc05j$5gp@agate.berkeley.edu> In article <94125.141347AHNAS@asuacad.bitnet>, Na'ndor Sieben wrote: >Well this is not quite true. At my optima program (gee we should use different >names ) there are two parameters (start, stop) that determines the range >we are looking for the constants. If you use start=stop then it basicly tests >that particular number. If this number is not a desired modulo number then >optima does not condider it . So if optima doesn't find anything than this >number is not the the desired modulo number. In a manner of speaking this >is a more powerfull feature then Michael's :-) I guess... my Optima v3.0 (hey, the names *are* different, mine starts with a capital "O" :-) allows you to specify a maximum step size, though, and I can't really see any use for the minimum step size except to kludge the single-number testing of Optima v3.0 (and if you use Nandor's you still don't get the same effect, because mine will find the mod number of an unknown step size for you -- with Nandor's you would have to manually test every possible mod number). Anyway, Nandor pointed out a *really* stupid mistake in my Optima v3.0 in his last post. Optima v3.0 checks a lot of unnecessary numbers -- it checks all numbers with mod numbers >= the mod number we are looking for. I just finished installing a simple gcd test (like Nandor uses) and the speed doubled! The new version is called Optima v3.1 and is available on soda (same filenames). Optima v3.1 is now about 5 times faster than Nandor's optima (I tested coresize 8000, mod 4 -- results were Michael 0:6.6; Nandor 0:34.4). If you're still using Nandor's optima you no longer have any excuse not to switch! :-) -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: Joseph Ku Subject: Mod, Step, Size, etc.?????? Date: Fri, 6 May 1994 02:41:25 -0400 Message-ID: Can somebody explain? What's the purpose of [O,o]ptima? And why should [I] use it? -- Joseph From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: corestep: the faster way to optima numbers Date: 6 May 1994 04:19:58 GMT Message-ID: <2qcghe$a15@agate.berkeley.edu> Jay "Thierry" Han wrote: >Yes, a *much* faster method exists to compute the optima numbers! Wow! Great program! Since Optima v3.1 is now rather outclassed, I have removed it from soda instead of bothering to fix the most recent bug I found. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: Re: The '94 Warrior Date: 6 May 1994 06:04:03 GMT Message-ID: <2qcmkj$37b@magus.cs.utah.edu> In article <2qbmrk$2jd@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: |Brant Thomsen wrote: |>I am also including the results of the "stormking" hills in this, and future, |>issues of _The_'94_Warrior_. I had planned to cover the "pizza" hill |>exclusively, but later decided that the "stormking" hills have enough traffic |>to warrant their coverage as well. | |I beg to differ. I submitted Sauron v3.6 to stormking on April 23, I got |the results back April 24, and it's still at age 1 today. That means that |no programs have gotten onto the stormking '94 hill since April 24. Hmmm... There is quite a bit of traffic, it just tends to be to be focused on only one of the two hills. I included both of them for completeness. |>The "stormking" hill appears to be even more diverse than the "pizza" hill. |>This hill will be a fun one to watch as it developes. Many of the programs |>on it are '88 standard programs, and several other programs have been |>converted from the '88 to the '94 standard. The "pizza" hill, on the other |>hand, has many warriors that are highly '94 dependent. | |Maybe I'm being cynical, but I would view this as further evidence that the |main hill traffic has moved from stormking to pizza. | |I have nothing against continued reviews of the stormking hills, and I |would certainly encourage people -- especially beginners -- to submit to |stormking. However, I would say that right now, stormking holds a lot |of second-rate warriors which have already been pushed off pizza. And |I believe that new, good warriors -- what _The_'94_Warrior_ is interested |in -- will appear first on the pizza hill, and only on stormking after |they are established on pizza (if they appear on stormking at all!). Although I never explicitly said it, I've noticed that the "stormking" hills have -- by default, I suppose -- become the beginner hills for the '94 standard. That is simply another reason I want to include them: to encourate everyone, and especially beginners, by allowing them to get their name in "print" even if they are "only" on the "beginners" hill. Back when I was still new at this, there was nothing I enjoyed more than when I kept a warrior on the hill long enough to make it into a copy of Paul Kline's _PushOff_. I want other beginners to have the same thrill as well. -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: finding mod numbers Message-ID: Date: 06 May 1994 10:00:22 GMT In article <94124.103354AHNAS@ASUACAD.BITNET> writes: > Date: 04 May 1994 17:33:54 PST-8 > From: > Subject: Re: finding mod numbers > > You have to find the greatest common divisor of coresize and the bombing > number. One way to do it is the Euclidean algorithm. Check out any > number theory book, or look at optimap.zip on soda . To make it complete, here's the algorithm for computing the GCD: if (ab */ if (b == 0 || b == 1) return b; do { r = a%b; a = b; b = r; } while (r); return a; -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Corestep v2: An alternate optima scoring Message-ID: Date: 06 May 1994 11:23:00 GMT Hi again. Have you actually looked at what step 3044 yields in the 8000 core? Well, as num8000 shows it, it's pretty good at finding 3 or 4 sized opponents, but not very good at finding the bigger opponents. Now in the big core, what we want for a scanner is to quickly find a larger opponent (e.g. imp startup code, or quickscan). If you're good at finding small numbers, that won't help you. Since the last corestep, I had this idea for a new optima scoring. What we really want is each bomb to land precisely in between two previous bombs. But of course that's impossible with a single step size (it would require some DIV... some experiments are in order!). Anyway, here's the scoring scheme I developed. For each bomb, its individual score is the distance to the middle of the neighboring locations that have been previously bombed. For example, in the following a "." marks empty core, "*" are previous bombs, and "@" is the current one: ..*.@.!...*... The "@" would score 2, because it's 2 locations away from the "!" which marks the middle between the two "*". It turns out that this scoring scheme can also be fitted in the recursive algorithm of corestep. So here's corestep v2. I changed some minor cosmetic details. You must now put a space between a switch and its argument (e.g. "-m 4" as opposed to "-m4"). The alternate scoring is much slower than the classic one: it takes about twice the time at worst. The computation is still comfortably fast: under a second on my workstation to find all mod-4 numbers in the 55440 core, under 2 seconds for mod-2. I wanted to replace the copy on soda, but I couldn't. So it's under the name: soda.berkeley.edu:/pub/corewar/incoming/corestep.c2 You should rename it to corestep.c before anything else. Stay tuned. For those without a compiler or with slow machines, I plan to upload a list of optima numbers by core size and mod-number. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: decrementing A-fields .. Message-ID: <1994May6.174232.1405@news.vanderbilt.edu> Date: Fri, 6 May 1994 17:42:32 GMT This started off as a mail exchange between Brant Thomsen and myself, but I thought it might be of general interest, because it deals with a common misconception about modifiers in ICWS'94. To recap (I don't have the first two messages anymore), Brant mailed me saying there was a bug in pMARS because jmp.a #0, <-10 would decrement the *B*-field of the address 10 behind, rather than the A-field as he intended. My reply was that this was not a bug, but behavior fully specified by the draft, and that the only way to decrement an A-field was with DJN. Brant replied back: >Sorry, but I can't seem to find anything in the draft that would indicate >the behavior I am getting. For the instruction: > > JMP.A #0, <-10 > >I could find two possibilities that seemed to fit the specifications. >Either the value in the A-field of the instruction ten spaces before the >instruction is decremented, or the entire B-field of the JMP is ignored >and the instruction in front of it is not modified. > >(The lines I found that appeared relevant were 611-619 and 713-714.) > >Even if I have missed where in the draft this behavior is specified, I personally >feel it ought to be modified to decrement the A-field of the instruction it is >pointing at. That seems much more intuitive to me, more powerful, and it won't >cause some new users the headaches I got when your A-field pointers just don't >seem to be decrementing like you expect them to. (Still, I did get my imp- >spiral code in the '94 Warrior to work, so I guess I can't complain too loudly.) > >I'd be very interested in hearing your opinions on the matter either way. > > Brant > Modifiers affect the way that the _effective_ address is accessed. I.e. mov.a Jay "Thierry" Han wrote: >I wanted to replace the copy on soda, but I couldn't. So it's under >the name: soda.berkeley.edu:/pub/corewar/incoming/corestep.c2 I replaced the old version. Now just "corestep.c" accesses the new one. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Pyramid v2.0 Date: 7 May 1994 03:20:08 GMT Message-ID: <2qf1d8$1s4@agate.berkeley.edu> Yes! Pyramid v2.0 has been in first place on the Pizza '94 hill for a while now, with a strong 10-point lead above second (Torch). So, it's time to post the source. Pyramid is a standard vampire with a quick-vamp attached. (I just *love* quick-scanners.) Why, you may ask, do I use a standard vampire when I could use a non-standard one like Request which is not vulnerable to anti- vamps? Well, it's because of the quick-scan. All modern anti-vamps are either packaged with, or incorporated into, some sort of paper. (The reason for this is that the anti-vamp will destroy either the pit or the fangsource (depending on the type of anti-vamp) but this will usually leave the vampire intact -- acting as a stone. The purpose of the paper is to beat that stone.) However, Pyramid will find paper (and any attached anti-vamps) with the quick-scan before even starting the regular vampire bombing, so the poor anti-vamp won't have any fangs to look at before it is bombed. So, I can use a regular vampire (and thus gain a little efficiency) without fear of anti-vamp programs. In fact, P.Kline recently submitted a combo including an anti-vamp to KotH, and Pyramid beat it 81/11/9. Pyramid also beats Deck of Many Things, though not quite as spectacularly (53/43/4). Note that Pyramid v3.0 (which I submitted and then killed because it scored lower than v2.0) is more advanced, and will defeat some of the programs which can beat Pyramid v2.0. It's not on the hill now... but don't think it's safe to submit some anti-vamp that beats Pyramid v2.0, I just may dig out v3.0 again... :-) The quick-scanning routing is rather nicely written, IMHO. You can adjust its behaviour by varying the numbers in the "quick-scan parameters" box. Yes, they do make a big difference. The reason: contrary to popular belief, the main problem with writing a quick-scanner is not *finding* the enemy (which we can do in 39 cycles, guaranteed) but *bombing* the enemy once we have found him. This is not as easy as it looks. We are not writing a cmp-scanner which has a lot of time to bomb (and a limited area to cover). We need to (theoretically) cover 100 instructions in front of and behind the point where we find an enemy program. Unfortunately, this would take on the order of 300 cycles (with reasonable coverage). Remember, we are trying to hit a program as it's bootstrapping. If possible we should hit it within 20 cycles or so after the quick-scan -- some programs are even too fast for that. So, I found (through trial and error against lots of different programs) that a pretty-close-to-optimal quick-scanner bombing pattern comes from the numbers shown here. Of course, different sets of numbers work better against different types of programs. The numbers here were chosen to beat imps especially, but they work pretty well against just about everything :-) See the diagrams at the end of the program for an explanation of what each of the constants controls. Pyramid v2.0 (slightly modified) is also on the big hill, and also in first place (although just *barely* ahead of Demand-55440 -- this makes sense because Demand-55440 and Pyramid are actually quite similar). A question for the general public: is it rude to put a high-scoring program on both hills when there is very little modification involved? Should I restrict Pyramid (and my programs in general) to only one hill, or should I submit any program (that's easy enough to translate) to both? Anyway, the imp infestation on the big hill should be coming to an end soon... :-) Here is how Pyramid does against the big hill's imps: Variation G-1: 60/33/7 Variation L-1: 64/29/7 Splash 1: 71/16/13 Lucky 13: 50/35/15 BigImps: 60/29/11 Sissy: 66/25/9 Imperfection: 63/11/26 I have not included the source for the big-hill Pyramid because it's just too similar to the small version, so it would be rather a waste of bandwidth. However, I would be happy to mail it to anyone who wants it. Enjoy! ;redcode-94 ;name Pyramid v2.0 ;author Michael Constant ;strategy quick-vamp -> vampire ;macro ; ----------------- Quick-Scan Parameters -------------------- OVERLAP1 equ 30 OVERLAP2 equ 0 BIGSTEP equ 100 OFFSET equ 150 BOMBDIR equ 1 ; 1 is forward, -1 is backward SPACE equ 6 ; must be even ; ------------------------------------------------------------ STEP equ 3364 first mov wimp, wimp+22 spl wimp+22 jmp split wimp jmp 0, <-30 look qscan for 38 cmp.x (first+OFFSET+(qscan*BIGSTEP)), (first+(CORESIZE/2)+OFFSET+(qscan*BIGSTEP)) mov.ab #(-BOMBDIR*OVERLAP1)+(first+OFFSET+(qscan*BIGSTEP))-found, @found rof found jmz.b first, #0 mkfang sub.ba found, qfang add.b found, qfang mov.i qfang, @qfang sub.f subber, qfang djn.b -2, #(((BIGSTEP+(OVERLAP1+OVERLAP2))/SPACE)*2)+1 jmp first qfang jmp pit+(qfang-found), #found-qfang subber dat Date: Sat, 7 May 94 04:30:00 GMT I am interested in learning about Corewar and have downloaded the pMARS executive and the tutorial.1 and .2 files. I also got the '94 draft. So I have this good reference material and a place to try things out, but the docs I have so far really don't talk all that clearly about learning to program in Redcode. Can anyone point me towards other tutorial documents that might get me started? In particular, I don't really understand the A and B field stuff and how they are interpreted by various opcodes. Thanks... Dave Goodwin (goodwin@smcvax.smcvt.edu) From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: Mod, Step, Size, etc.?????? Date: 7 May 1994 05:07:20 GMT Message-ID: <2qf7m8$30o@agate.berkeley.edu> Joseph Ku wrote: >What's the purpose of [O,o]ptima? And why should [I] use it? The purpose is best explained through an example. Let's take the standard Dwarf program: MOV -1, -1 ADD #4, -1 JMP -2 We can make it *much* more deadly by simply changing the number 4 in the second line to an optimum mod-4 bombing step like 3044 (mod-4 means that if you let it run long enough it will eventually hit every 4th core location). To see visually how much better it is with 3044 as the step size, try running both versions of Dwarf and just looking at what they do to core! Optima calculates numbers (like 3044) which are suited to your particular needs. For example, if you need an optimum mod-5 number less than 200, Optima can find one for you. However, Optima has just been replaced by Jay Han's new program, Corestep. Corestep does exactly the same thing as Optima except about 100 times faster :-) Corestep is available by anon ftp to soda.berkeley.edu as /pub/corewar/incoming/corestep.c. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: decrementing A-fields .. Date: 7 May 1994 05:21:13 GMT Message-ID: <2qf8g9$34v@agate.berkeley.edu> Stefan Strack wrote: > If we wanted to also be able to specify the 'field of indirection', we > would need another modifier field: > > jmp.?.a #0, <-10 ; the ? means we don't really care what goes here since > ; jmp does do anything with the effective B-address > > Another way of writing the first example now is: > > mov.a.b > or if you wanted the A-field for indirection: > > mov.a.a > Now, this is certainly too messy to even consider adding, or isn't it? Maybe, or maybe not. Modifiers are ugly in the first place, but they are powerful. And the whole idea behind the '94 standard is to make Redcode a more powerful language. I'm not sure I like the syntax here (I prefer my own syntax with seperate symbols like { and } for A-field pre-decrement indirect and post-incrment indirect, and maybe ~ (most of the symbols are already taken!) for regular A-field indirect) but I think that with some work we might be able to make this a really usable feature. I think I would support *any* proposed extentions to the current '94 draft! I mean, sure, we still have to find a use for SNE and NOP, but I have no doubt that we will find one sooner or later... and who knows what programs we might make with the new power of extra modifiers? -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: rowin@plains.NoDak.edu (Chad W Rowin) Subject: ????? Message-ID: Date: Sat, 7 May 1994 17:56:56 GMT so let me get this strait, you write a computer program using redcode, submit it to a core war facility, and then watch the game play? does that about sum things up? From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: ;assert Message-ID: <1994May8.015708.1663@news.vanderbilt.edu> Date: Sun, 8 May 1994 01:57:08 GMT We from the pMARS team would like to encourage you to start including a new directive in your warriors submitted to koth, and especially posted to the net: ;assert The currently used ;redcode identifiers (-94x, -b) are not terribly descriptive and don't tell you what pMARS settings this warrior requires. Who knows if, e.g. the 94x parameters won't change over time? With ;assert, you can tell pMARS (and people who fetch your warrior from the net or soda) exactly what settings are required. Some examples: ;assert CORESIZE == 8000 ;assert (CORESIZE % 4 == 0) && MAXPROCESSES > 1000 ;assert CORESIZE == 8000 || CORESIZE == 55440 ;assert 1 (if you think your warrior works under all settings) ;assert CORESIZE==8000 && MAXCYCLES==80000 && MAXPROCESSES==8000 && MAXLENGTH==100 && MINDISTANCE==100 (you can also write this as separate ;assert lines which are treated like a boolean AND) The current pMARS v0.5x simply ignores these directives, but starting with the next version, the C-type expression following ;assert will be evaluated. If it fails, an error message is generated and your warrior is not executed (also useful if you accidentally send your warrior to the wrong hill). If there is no ;assert line in your code, a warning is issued. -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: EBS spring '94 tourney: round 3 results Message-ID: <1994May8.172700.11883@news.vanderbilt.edu> Date: Sun, 8 May 1994 17:27:00 GMT Much more diversity in the 3rd round of the EBS spring tourney than in the 1st round with "big core" rules: We had an anti-imp scanner (ivscan6), bombers (CG-X V, Riff, Blitz), and imps (Big again, Twister). If you're wondering why Mike Nonemacher is represented with _two_ warriors in this round, it's because his adversary Wayne Sheppard tried to defeat him with his own weapon. Should submitting somebody else's warrior be allowed in future tourney's? I actually think yes, because this is more honest than plagiarizing somebody else's code and submitting it as your own. Anyway, here the results. In the winner bracket, Jay Han counted on James Layland's ivy not being ready for the big core yet. Not so. Jay moves to the loser bracket and James has 2 weeks to prepare himself for the final round against the finalist of the loser bracket. Big again by Jay Han scores 66 (16 66 18) ivscan6 by J.Layland scores 216 (66 16 18) In the loser bracket, Mike Nonemacher's "Tail of the Twister" prevailed over his own "Der Zweite Blitzkrieg - 94X" submitted by Wayne Sheppard, and Brant Thomsen's CG-X V took out Steven Morrell's Riff. Wayne and Steven are out, while Mike and Brant remain in the loser bracket. Der Zweite Blitzkrieg - by Mike Nonemacher scores 86 (8 30 62) Tail of the Twister by Mike Nonemacher scores 152 (30 8 62) CG-X V by Brant D. Thomsen scores 251 (81 11 8) Riff by Steven Morrell scores 41 (11 81 8) With three people left in the loser bracket, I thought I'd cut things short by making round 4 a round robin without self-fights, i.e. each warrior fights the other two but not itself. So, round 4 held on May the 13th with "regular" core rules will confront Jay, Mike and Brant. The winner of this round will then challenge James for the championship on May 20th. As usual, here the round robin results for this round: Elapsed time: 20945 seconds (05:49:05) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 ivscan6 J.Layland 44 27 28 1130 2 Tail of the Twister Mike Nonemacher 30 21 49 973 3 Big again Jay Han 23 18 59 891 4 CG-X V Brant D. Thomsen 18 18 63 830 5 Der Zweite Blitzkrieg - Mike Nonemacher 17 24 59 765 6 Riff Steven Morrell 18 41 41 663 -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 8 May 1994 18:24:57 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/04/11 Version: 2.2.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 126 6. What is the ICWS? 143 7. What is TCWN? 153 8. How do I join? 161 9. Are back issues of TCWNs available? 178 10. What is the EBS? 185 11. Where are the Core War archives? 201 12. Where can I find a Core War system for . . . ? 219 13. I do not have ftp. How do I get all of this great stuff? 268 14. I do not have access to Usenet. How do I post and receive news? 275 15. When is the next tournament? 293 16. What is KotH? How do I enter? 304 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 466 18. How does SLT (Skip if Less Than) work? 478 19. What does (expression or term of your choice) mean? 490 20. Other questions? 633 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more pratically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). ----------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-20.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars05s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars05s.tar.Z - same as above pmars05.zip - 16-bit PC executables, graphics display version pmars05g.zip - 32-bit PC execs (djgpp, large core) macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincore.zip - MS-Windows system, shareware ($35) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. n select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, 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. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.5, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. le ... ... SPL 0, Stefan Strack wrote: > Should submitting somebody else's warrior be allowed in future tourney's? > I actually think yes, because this is more honest than plagiarizing > somebody else's code and submitting it as your own. I disagree. I think that the point of tournaments is to see who can *write* the best programs, not who can dig through listings of programs to find the best. Would it be fair if someone won a tournament without writing any programs, just submitting other people's old code? When I post a program, it is with the intention that other people can learn from it -- not that other people can use it in competition. I think I'd be mad if anyone tried using one of my posted warriors in a tournament (hear that Wayne? ;-) ), just as I'd be mad if someone submitted it to the hill. It wouldn't matter if my name was still on it. When I post a warrior, I am making the *strategy* public domain, not the code. -- - Michael Constant (mconst@soda.berkeley.edu) - GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: ????? Date: 8 May 1994 22:19:40 GMT Message-ID: <2qjohs$ldg@agate.berkeley.edu> Chad W Rowin wrote: >so let me get this straight, you write a computer program using redcode, >submit it to a core war facility, and then watch the game play? Almost. First you write a program in redcode, and you watch it fight against other programs _on_your_home_computer_. Then when you are satisfied that your program works well, you can submit it to the ongoing corewar tournament called King of the Hill (KotH). For instructions on how to submit a program to KotH, mail pizza@ecst.csuchico.edu with a subject of "koth help". -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Scanning for Imps/Fangs (possible new '94 modifier?) Date: 9 May 1994 17:45:09 GMT Message-ID: <2qlsr5$20o@elroy.jpl.nasa.gov> The '94 standard has made A-fields (almost) as easy to access as B-fields. (The almost is because increment/decrements only affect B-fields.) This allows more powerful DJN-streams, more efficient backtracing of vampire fangs, and new B-scanner like programs which look at A-fields or both A- and B-fields. One region which remains inaccessable is the instruction opcode. The addition of a ".O" modifier (for example) could assist in implementing programs which target specific warrior types. The only way to look for a specific opcode is to subtract a location from itself (to set A and B to zero) then compare with the opcode combined with all possible modifiers. For example, the following code identifies all '88 style imps: imp mov 0, 0 ... sub loc, loc cmp loc, imp jmp scanAgain ; put anti-imp stuff here A '94 warrior can identify '94 style imps by comparing to "MOV #0, 0", but this will miss any '88 style imps (fortunately, there are no '88 style imps on the 94x hill :) If '88 style imps come back on the hill (as anti-anti-imp strategies?) then this style of scanner would need two comparisons. There are alternate strategies for looking for imps. The best is probably one I used in my round 2 entry, which I got from someone else's imp-scanning warrior (can't remember who), which uses a scanning routine including something like: inc dat #step, #step add inc, 1 cmp x, @x jmp loop This compares a core location with the contents of the location it points to. This successfully identifies imps, but it also catches DJN-streams, without additional code to (at least) throw out -1 B-fields. If we are trying to identify fangs, the situation is much worse. We would like to catch all JMP statements (possibly with some tests to skip SPL-JMP bombs). Instead we are forced to look separately for statements like JMP x,y or JMP @x, y or JMP x, Date: 09 May 1994 18:04:32 GMT In article <2qjnrs$l86@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: > From: mconst@soda.berkeley.edu (Michael Constant) > Subject: Re: EBS spring '94 tourney: round 3 results > Date: 08 May 1994 22:07:56 PST-8 > > Stefan Strack wrote: > Should > submitting somebody else's warrior be allowed in future tourney's? > > I actually think yes, because this is more honest than > plagiarizing > somebody else's code and submitting it as your own. > > I disagree. I think that the point of tournaments is to see who > can *write* the best programs, not who can dig through listings of > programs to find the best. Would it be fair if someone won a > tournament without writing any programs, just submitting other > people's old code? Don't take this as Wayne-bashing, or Michael-flaming, or whatever. The point is, modern warriors are a mix of two or more components. As it is, it's pretty hard to come up with a brand new idea. At that point, there are two possibilities: either you have the idea of putting together components that have never been mixed before, or you write a new, more efficient implementation of a known component. What I can understand, and I've done this before, is that you look at a given strategy (= mix of components), and try to improve it. You experiment adding stuff, removing stuff, changing constants, relative positions, you try bootstrapping, etc. Well, sometimes it happens that none of those "improvements" improve anything. Now if it was a tournament such as a Hill, I'd give up by then. It doesn't make sense to post a copy of a program that's already there. If it's an elimination tournament like the EBS tourney, then it makes sense to use the strongest warrior against the likeliest opponent. Suppose you happen to know your opponent will use strategies A or B. The only warrior you have that licks both A and B is this program C written by some else. You haven't been able to improve it, or even rewrite it without deteriorating the performance. I think that at that point it's legitimate to use that program C. Now on whether you'll put your name on it or leave the original author's name, I don't think it matters much anymore. For clarity, though, I'd put my name on it, and put a ;stragey line stating clearly that it's just a copy of someone else's program. But I wouldn't do it anyway, just because I'm too selfish. > When I post a program, it is with the intention that other people > can learn from it -- not that other people can use it in > competition. I think I'd be mad if anyone tried using one of my > posted warriors in a tournament (hear that Wayne? ;-) ), just as > I'd be mad if someone submitted it to the hill. It wouldn't > matter if my name was still on it. Personally, I differ from Michael. I'd be mad indeed if someone sent one of my warriors to the Hill. I'm kind of embarrased when I send two similar warriors myself! In an elimination tournament situation, however, it's my challenge to anticipate this kind of trick, and be ready for it. That's the whole point in having the code of all warriors sent to all participants after each round. You're supposed to outwit your opponent not only with Redcode, but also with reverse psychology, if you dare. As it is, Mike appears to be a tough opponent to beat. I, for instance, was foolish to turn in the same warrior twice. I guess it wasn't a very smart idea either to publish the code of *all* my warriors just before the tournament... :-} > When I post a warrior, I am making the *strategy* public domain, > not the code. I'm not so sure. Take the stone/spiral for example. At one point there were a dozen of them on the big Hill. I felt it legitimate to post my "Variation" though, because it had been riding at the top and I felt everybody would want to have the "latest and greatest" to test their program against. Well, that's history now anyway... :-( -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: morrell@math.utah.edu (Steven C. Morrell) Subject: Re: decrementing A-fields .. Date: Mon, 9 May 1994 20:09:59 GMT Message-ID: You can decrement the A-field of an instruction if its B-field is zero: DJN.f #0,>-10 This decrements the A-field while leaving the B-field zero. (Well, actaully, the B-field is decremented and then incremented back to zero, but nobody needs to know this, do they?) I can't imagine any place where this would be useful, though Oh, well. Steven Morrell morrell@math.utah.edu From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: ivscan6 Date: 9 May 1994 21:09:05 GMT Message-ID: <2qm8ph$1jc@elroy.jpl.nasa.gov> After Michael's posting on Pyramid promised the end of the domination of the Big Hill by imps, I thought I would hasten the end along a little. ivscan6 is now in first place on the Big Hill by about 20 points. It uses a Leprechaun-style bomber/scanner. If the scanner finds something, it erases the A- and B-fields and compares it to 1) empty core, and 2) MOV #0, 0. Case 1 has probably found an increment or decrement, and continues the bomb/scan. Case 2 has found a '94 style imp, and initiates a spiral stun, followed by a core clear. All other cases are assumed to be fangs (which is a good guess with the current makeup of the big hill) and the program launches an anti-vamp paper. The bomb/scan makes ivscan6 competitive with scanning programs, and the anti-imp/vamp have a field day with the current strategies on the big hill. The program is small enough to avoid quick-scans in Demand/Pyramid. The only program that soundly defeats ivscan6 is a pure stone (which loses to everything else except scanners). Like my last high-flying program (FlyPaper) from a year ago, ivscan6 is far too dependent on the current makeup of the hill to have much longevity, but it's fun for now. Note to EBS tournament participants: there are a couple lines changed from my round 3 entry. The line labeled "kill" in my tournament entry is gone from the start of the bombing loop (where it bombed DAT statements) and has moved to the start of the anti-vamp (where it may actually bomb an enemy program). Here is a current list of scores, followed by redcode. ivscan6 wins: 64 Demand-55440 wins: 25 (vamp w/ quick-scan) Ties: 11 ivscan6 wins: 48 Pyramid v2.0 wins: 25 (vamp w/ quick-scan) Ties: 27 ivscan6 wins: 74 Request-55440 wins: 14 (vamp) Ties: 12 ivscan6 wins: 60 Variation G-1 wins: 23 (stone/spiral) Ties: 17 ivscan6 wins: 49 Squint wins: 44 (b-scanning vamp) Ties: 7 ivscan6 wins: 38 Vanity IIx wins: 50 (S-J bombing b-scanner) Ties: 12 ivscan6 wins: 51 Scanalyzer wins: 43 (b-scanning vamp) Ties: 6 ivscan6 wins: 66 Splash 1 wins: 19 (stone/spiral) Ties: 15 ivscan6 wins: 45 Rave B4.1 wins: 48 (carpet bombing cmp-scan) Ties: 7 ivscan6 wins: 45 Sissy wins: 35 (hybrid stone/spiral/b-scanning vamp) Ties: 20 ivscan6 wins: 77 Lucky 13 wins: 13 (stone/spiral) Ties: 10 ivscan6 wins: 64 Sauron v3.4 wins: 20 (stone/spiral) Ties: 16 ivscan6 wins: 72 Der Zweite Blitzkrieg - 94x wins: 14 (stone/spiral) Ties: 14 ivscan6 wins: 61 BigImps wins: 14 (stone/spiral) Ties: 25 ivscan6 wins: 18 Lump wins: 70 (stone) Ties: 12 ivscan6 wins: 80 Virus wins: 18 (vamp) Ties: 2 ivscan6 wins: 17 Deck of Many Things wins: 1 (paper/stone/etc.) Ties: 82 ivscan6 wins: 68 Tail of the Twister wins: 9 (stone/spiral) Ties: 23 ivscan6 wins: 42 Imperfection v2.4 wins: 21 (stone/spiral) Ties: 37 ivscan6 wins: 28 Ties: 38 Your overall score: 177.190476 ivscan6 has been pushed off the ICWS '94 Experimental (Big) hill. The current ICWS '94 Experimental (Big) hill: # %W/ %L/ %T Name Author Score Age 1 52/ 27/ 21 ivscan6 J.Layland 177 1 2 47/ 37/ 16 Demand-55440 M. Constant & B. Tho 157 23 3 47/ 38/ 15 Pyramid v2.0 Michael Constant 156 7 Sorry for that bit of self-congratulation, but how often will I have a warrior that beats all but 3 of the programs on the hill? ;redcode-94x ;name ivscan6 ;author J.Layland ;kill ivscan6 ;strategy EBS Tournament round 3 entry ;strategy Leprechaun-style bomb/scan ;strategy Scanner tries to identify imps/vamps and run special-purpose ;strategy anti-imp/vamp modules. ;macro org loop step equ 13 scan equ 27725 ; If I bomb myself, I'm probably dead anyway impsize mov.i 100 ; now bomb forward to kill jump mov b1,>avamp jmz paper, paper b1 dat <34117, Subject: Re: Scanning for Imps/Fangs (possible new '94 modifier?) Date: Mon, 9 May 1994 21:35:51 -0400 Message-ID: Excerpts from netnews.rec.games.corewar: 9-May-94 Scanning for Imps/Fangs (po.. by James Layland@kilroy.jpl >A '94 warrior can identify '94 style imps by comparing to "MOV #0, 0", >but this will miss any '88 style imps (fortunately, there are no '88 >style imps on the 94x hill :) If '88 style imps come back on the >hill (as anti-anti-imp strategies?) then this style of scanner would >need two comparisons. I was just playing around with some of this, and found a GREAT use for SEQ/SNE. Granted, it adds a line, but it's a lot more elegant than some other methods... a add #step, 1 c jmz.b -1, FIRST slt.ab #LEN, -1 jmp a seq.i @c, imp1 sne.i @c, imp2 jmp antiimp ;do other stuff, depending on what you found And I'm definitely in favor of ".o" opcode modifiers! It would help greatly with the '94 version of Genocide (OK, this sounds a little weird if you don't remember the warrior...), and I think it would lead to better warriors all around. The question is whether the modifier is considered part of the opcode. So would "dat.a" have a different opcode than "dat.f"? I think this is necessary, and if they were the same, it would be counter-intuitive. As far as applying add, sub, mul, div, mod, djn, etc., with opcodes, I have no idea. Although djn.o could make a pretty powerful djn-stream... And would also provide lots of annoying decoys for James' opcode-scanner... :-) Mike Nonemacher mn2f+@andrew.cmu.edu From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: decrementing A-fields .. Date: 9 May 1994 21:55:46 GMT Message-ID: <2qmbh2$csu@agate.berkeley.edu> Steven C. Morrell wrote: >You can decrement the A-field of an instruction if its B-field is zero: > >DJN.f #0,>-10 > >This decrements the A-field while leaving the B-field zero. (Well, >actaully, the B-field is decremented and then incremented back to zero, >but nobody needs to know this, do they?) Uh... why not just use DJN.A #0, 10? This doesn't require a zero B-field. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Knowing little about machine lang. Date: 9 May 1994 22:09:04 GMT Message-ID: <2qmca0$d4t@agate.berkeley.edu> Francis P Hwang wrote: > I asked before, but it's been a while, and I didn't get any responses. > Are there any Corewar tutorials that assume no prior knowledge of machine > langugage? (I'd assume there probably aren't, seeing as how nobody pointed > me to one.) If I wanted to learn enough rudimentary machine langugage to > figure Corewar out, what would be a good book to read? Well, I'm working on a corewar tutorial right now, and it will assume no prior knowledge of assembly. I will post a message here when it's done... until then, the best thing I can recommend is guessing your way through the tutorial.1 and tutorial.2 files on soda.berkeley.edu (in the /pub/corewar/documents directory). If you have any questions about those files, you can post them here or mail me. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: djael@unirsvl.rsvl.unisys.com (Caryn Zange x3922) Subject: :wa Message-ID: Date: Mon, 9 May 1994 22:24:05 GMT From: djael@unirsvl.rsvl.unisys.com (Caryn Zange x3922) Subject: HACK-SINGAPORE-DUNGEON Message-ID: Date: Mon, 9 May 1994 22:26:02 GMT From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Request and antivamps (was Re: Pyramid v2.0) Date: 9 May 1994 23:12:18 GMT Message-ID: <2qmg0i$1ko@elroy.jpl.nasa.gov> In article <2qf1d8$1s4@agate.berkeley.edu>, Michael Constant wrote: >quick-scanners.) Why, you may ask, do I use a standard vampire when I >could use a non-standard one like Request which is not vulnerable to anti- >vamps? Well, it's because of the quick-scan. All modern anti-vamps are >either packaged with, or incorporated into, some sort of paper. (The reason >for this is that the anti-vamp will destroy either the pit or the fangsource >(depending on the type of anti-vamp) but this will usually leave the vampire >intact -- acting as a stone. The purpose of the paper is to beat that Request is invulnerable to _some_ anti-vamps. Request bombs with fangs like JMP @xx, yy. xx points to a DAT statement, which points to the pit. An antivamp which tries to kill the pit by bombing through xx will only kill the pointer (leaving any processes already trapped in the pit). Request has a small routine which occasionally refreshes the pointer in case it has been destroyed. However, any anti-vamp which bombs the fang source (tracing back through yy) will still work. This effectively turns the vamp into a stone, which can be defeated by paper. If the vamp has already caught something, the processes stay trapped and a tie is likely. For example, this paper will beat Request about 70% of the time. spl 1 spl 1 spl 1 start mov #8, 0 copy mov <-1, 100 ; now bomb forward to kill jump mov bomb,>avamp jmz start, start bomb dat <2667, <2*2667 ; might take out an imp if I'm lucky -- James Layland jlayland@grissom.jpl.nasa.gov From: psr@acsu.buffalo.edu (Strider) Subject: help with writing a mars? Message-ID: Date: Tue, 10 May 1994 02:36:54 GMT Hi all. I'm trying to write my own mars program for the 88 standard. The big problem I'm having is writing the parser to translate human code to something a machine can understand. The whole concept of labels is making this very difficult. So basically I have some questions regarding labels. In the example given in the ftp-able tutorial the author describes imp as looking like the following: imp MOV imp, imp+1 END But, according to the explanation of labels later in the document, this would not work as an imp. The label 'imp' is defined as the offset to the particular instruction where the label is introduced. So: x DAT #0, #x DAT #0, #x DAT #0, #x is defined as (this is straight from the tutorial): x DAT #0, #0 DAT #0, #-1 DAT #0, #-2 This makes the above imp program behave like: imp MOV 0, 1 MOV -1, 0 MOV -2, -1 etc. which is not really an imp. Or does MOV copy the label as well? That would make imp: imp MOV 0, 1 imp MOV 0, 1 etc. Can someone clarify how labels work? The other label question I have is can a value of a label be changed during the program's execution? In other words, can I read in a program, strip comments, translate labels, and then run the program as if the labels weren't there? Thanks in advance. -S -- Strider | SUNY @ Buffalo | psr@acsu.buffalo.edu Lord Mayor, The Hill People | (716) 645 4167 | V127MHSK@ubvms.bitnet ------------------------------------------------------------------------------- "Son, I am able," she said, "though you scare me." "Watch," said I, "beloved." From: morrell@math.utah.edu (Steven C. Morrell) Subject: Re: Pyramid v2.0 Date: Tue, 10 May 1994 03:10:08 GMT Message-ID: In article <2qf1d8$1s4@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: because Demand-55440 and Pyramid are actually quite similar). A question for the general public: is it rude to put a high-scoring program on both hills when there is very little modification involved? Should I restrict Pyramid (and my programs in general) to only one hill, or should I submit any program (that's easy enough to translate) to both? Even though your program ports easily, many of them do not. I think the hills will stay different enough that you should put your programs on both hills. A case in point: Blue Funk got kicked off the big hill quite quickly, while it is doing very well on the 94 hill, and it didn't require much of a port. The fact that you can write a program that scores first place on both hills really annoys those of us who would like to do that ourselves, but this doesn't really matter in terms of ettiquite. Which brings up an idea that I've been kicking around for a while, but haven't mentioned before for fear of being laughed at. Wouldn't it be neat to have a Poor Sportsmanship Hill where you could submit multiple copies of the same program, and you win if all of the warriors on the hill are yours? This hill would probably have to be limited to 10 warriors to make winning feasable. What does everyone think? Steven Morrell From: wsheppar@sct.edu (Wayne Sheppard) Subject: A better quick-cmp Date: 10 May 1994 06:16:44 -0400 Message-ID: <2qnmuc$14ic@st6000.sct.edu> Now is the time for everyone to rewrite thier quick-cmp scanners. I figured out several improvements that can be made. First is the use of the new opcode SNE. Interleaved with SEQ, it is possible to increase the density of your quick-cmp code. SNE 200,300 SEQ 400,500 MOV #200,loc SNE ...... SEQ ...... and so on. My quick-cmp structure is only 54 lines long, leaving more room for other code, and being less vulnerable to a lucky shot at the beginning because my length is less. Improvement #2: Out of all of the quick-cmps published, I have yet to see one that doesn't waste half of its time bombing the core that is known to be completely on the opposite side of the core. The cmps are set up to check at X and X+4000. If the enemy is known to be at X or X+4000, why waste your time bombing both locations? I guess Plasma is a smart warrior cause it checks to see which location needs to be bombed. SNE @loc,DAT0 ;test against a known DAT 0 location like start-1 ADD #4000,loc Sorry, no code yet. I still need to try a couple of things before I give it up. But here are the results: Score results for Plasma-test-v5 --------------------------- W L T Gain 233 Pyramid v2.0 76 19 5 171 ; these quick-cmps waste 219 Sauron v5.0 70 21 9 147 ; time bombing the wrong spot 213 Yop La Boum v2.1 71 29 0 126 181 Iron Gate 1.5 60 39 1 63 180 Dragon Spear 59 38 3 63 165 SJ-4 54 43 3 33 159 Scorch 45 31 24 42 157 Cannonade 48 39 13 27 148 Plasma-test-v5 46 44 10 0 145 Der Zweite 42 39 19 9 140 ^C 40 40 20 0 139 Twimpede+/Small-X 43 47 10 -12 131 Deck of Many Things 40 49 11 -27 122 Rave 4.1 39 56 5 -51 118 Lucky 3 33 48 19 -45 101 Request v2.0 30 59 11 -87 100 Blue Funk 22 44 34 -66 91 Torch 26 61 13 -105 ; this is where the warriors 82 test 26 70 4 -132 ; are booting too fast to 73 Christopher 16 59 25 -129 ; catch 56 NC 94 16 76 8 -180 140 AVERAGE 42 45 11 -7 -- Wayne Sheppard wsheppar@st6000.sct.edu Date: Tue, 10 May 1994 10:25:53 MST From: Message-ID: <94130.102553AHNAS@ASUACAD.BITNET> Subject: Re: mod m numbers Michael, now both of our O/optima programs are obsolate. This is the end of the competition. It was fun :-) I'm just curious. Does anybody use pShell.exe ? Should we bother to create a portable pShell ? Nandor. From: Michael N Nonemacher Subject: Re: EBS spring '94 tourney: round 3 results Date: Tue, 10 May 1994 14:15:00 -0400 Message-ID: OK, I guess I'll get in on this thread. First of all, I thought it was pretty cool that Wayne tried to use Der Zweite Blitzkrieg against me. That may just be cause I won, and I honestly don't know how I'd feel about it if I lost to my own program. But the point of these tournaments isn't to find the all-around *best* warrior. That's more along the lines of KotH. It's just to beat one person (or, in this round, two... :-). If we allow people to use _any_ program that's already written, it seems like it would lead to better all-around warriors in a tournament. If I think my opponent's using a scanner, just cause that's all he's ever written, I could write a pretty cheesy stone and still win. But if my opponent could go thru all kinds of other already written redcode, I'd write something that would do OK against everything. I guess I personally wouldn't use somebody else's warrior unless I was really pressed for time (and in previous rounds, Wayne's 94x warriors always said he hadn't done much at all on the big hill), but I don't think we should rule out that possibility. This would just lead to better all-around warriors being written for tournaments. Mike Nonemacher mn2f+@andrew.cmu.edu From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: Scanning for Imps/Fangs (possible new '94 modifier?) Message-ID: Date: 10 May 1994 15:44:26 GMT In article <2qlsr5$20o@elroy.jpl.nasa.gov> jlayland@kilroy.jpl.nasa.gov (James Layland) writes: [...] > If we adopted the convention that DATs are zero and non-DATs non-zero, > this would scan through core for any executable instructions. It would > still be fooled by bombers which drop executable instructions (fangs, > SPL-JMPs) but conventional DAT bombs would be invisible. Such a scanner > might be a match for stones. Whether this would be a Good Thing is open > to debate. I'm the kind to believe every addition to the flexibility of Redcode is a Good Thing. :-) This suggestion had me thinking back when it was first made. The "DAT=0, else != 0" behaviour also was the most sensible I could think of. I think that for those operations that don't make sense (MUL DIV MOD ADD DJN), we should just make the modifier nonfunctional, i.e. it doesn't do anything. This lack of consistency could be justified by the fact that for MOV CMP JMN and JMZ, the modifier makes perfect sense, and could be quite powerful. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: Pyramid v2.0 Date: 10 May 1994 20:03:25 GMT Message-ID: <2qopad$3n7@agate.berkeley.edu> Steven C. Morrell wrote: >Which brings up an idea that I've been kicking around for a while, but >haven't mentioned before for fear of being laughed at. Wouldn't it be >neat to have a Poor Sportsmanship Hill where you could submit multiple >copies of the same program, and you win if all of the warriors on the >hill are yours? This hill would probably have to be limited to 10 >warriors to make winning feasable. What does everyone think? I think it would overload the koth server, because people would submit multiple copies of each program. Neat idea though! -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Re: mod m numbers Date: 10 May 1994 20:37:30 -0600 Message-ID: <2qpgda$kkf@cwis.isu.edu> In article <94130.102553AHNAS@asuacad.bitnet>, wrote: >I'm just curious. Does anybody use pShell.exe ? Should we bother to create a >portable pShell ? I would, if it were a little easier to use. I much prefer the Mars88 shell, though it may be less powerful... From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: optima again Message-ID: Date: Tue, 10 May 1994 21:02:38 GMT I just thought of something which could be useful in an optima program. What if your bombing pattern uses alternating steps? The previous sentance is probably cryptic, so I'll try an example: ;Standard carpet-bombing cmp-scanner add step, scan scan cmp a, a+offset slt jmp -3 ... ; code to bomb a through a+offset In this case the optima numbers are not optimal stepsizes. So, is it possible to modify corestep's algorithm to handle this kind of multiple steps? This could come in handy in many programs, I think. Besides, you seemed to be enjoying yourselves so much... /Anders BTW, I'm kind of tied up in a project right now, but I'll be back, don't you worry :-) From: Michael N Nonemacher Subject: Re: mod m numbers Date: Tue, 10 May 1994 23:01:15 -0400 Message-ID: Nandor wrote: "I'm just curious. Does anybody use pShell.exe ? Should we bother to create a portable pShell ?" (what kind of newsreader doesn't have "excerpt" on it?) I use pshell all the time! I now have two different versions - one in my "pmars" directory, and one in my "pmarsx" directory, configured for normal and big hill rules. The only problem is, the "command line" field isn't long enough to put all the big hill specs on F9 or F10, but other than that, it works great! As for creating a portable pshell, I use pmars a little on UNIX, but never do any real development on it, so I can't say if a portable pshell would be worth it. But thanx for pshell!!! Mike Nonemacher mn2f+@andrew.cmu.edu From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Scanning for Imps/Fangs (possible new '94 modifier?) Message-ID: <1994May11.014204.1059@news.vanderbilt.edu> Date: Wed, 11 May 1994 01:42:04 GMT In article jayhan@cs.washington.edu (Jay "Thierry" Han) writes: >I think that for those operations that don't make sense (MUL DIV MOD >ADD DJN), we should just make the modifier nonfunctional, i.e. it >doesn't do anything. > >[...] >-=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu You mean ADD.O 1,2 is a no-op? That goes counter to the ICWS'94 spirit that non-sensical opcode/modifier combinations are executed like the next closer combination that makes sense (i.e. ADD.I is executed as ADD.F). Perhaps ADD.O should also be treated like ADD.F? Or perhaps adding DAT to any other opcode leaves the opcode intact; whereas anything else to an opcode overwrites the target opcode with the source opcode. This would make arithmetic sense if one of the effective addresses is a DAT. -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Scanning for Imps/Fangs (possible new '94 modifier?) Date: 11 May 1994 04:29:02 GMT Message-ID: <2qpmue$cmu@agate.berkeley.edu> Stefan Strack wrote: >jayhan@cs.washington.edu (Jay "Thierry" Han) writes: >>I think that for those operations that don't make sense (MUL DIV MOD >>ADD DJN), we should just make the modifier nonfunctional, i.e. it >>doesn't do anything. > >You mean ADD.O 1,2 is a no-op? That goes counter to the ICWS'94 spirit >that non-sensical opcode/modifier combinations are executed like the >next closer combination that makes sense (i.e. ADD.I is executed as >ADD.F). Perhaps ADD.O should also be treated like ADD.F? Or maybe we should take the plunge and allow true opcode arithmetic! If this isn't in the ICWS'94 spirit, nothing is! Here is my proposed system: The opcodes like MOV, DAT, etc. would actually just become automatic EQU's for numbers. DAT would be 0, MOV might be 1, etc. Opcode arithmetic would be done modulo whatever the total number of opcodes is. Thus we could use JMZ.O to check if an opcode is DAT (I feel strongly that DAT should be 0. I don't care about the rest of the numbering system.). And we could use DJN.O to have an opcode-DJN-stream. Even better, DJN.I would leave a path of FOO -1,-1 instructions (where FOO is whatever instruction we assign to the last number). And we would finally have a meaning for previously nonsensical instructions like ADD.I. We would have to have another few modifiers (.AO, .BO, .OA and .OB), so that we could say things like MOV.AO #DJN, 5 (which would change the opcode of instruction 5 to DJN). Wow, there are some neat possibilities! I know this is a little radical, but it just might work. What does everybody think? -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: Michael N Nonemacher Subject: Re: Scanning for Imps/Fangs (possible new '94 modifier?) Date: Wed, 11 May 1994 09:59:22 -0400 Message-ID: Michael Constant writes: "Opcode arithmetic would be done modulo whatever the total number of opcodes is. Thus we could use JMZ.O to check if an opcode is DAT (I feel strongly that DAT should be 0. I don't care about the rest of the numbering system.). And we could use DJN.O to have an opcode-DJN-stream. Even better, DJN.I would leave a path of FOO -1,-1 instructions (where FOO is whatever instruction we assign to the last number). And we would finally have a meaning for previously nonsensical instructions like ADD.I. We would have to have another few modifiers (.AO, .BO, .OA and .OB), so that we could say things like MOV.AO #DJN, 5 (which would change the opcode of instruction 5 to DJN). Wow, there are some neat possibilities! I know this is a little radical, but it just might work. What does everybody think?" (still on this "excerpt"-less newsreader... ) I like this idea. I think we could come up with some pretty deadly warriors using it. The question is, is there any way to deal with modifiers? Could (for example) dat.f=0, dat.a=1, dat.b=2, etc.? I really don't know if distinguishing between modifiers for a given opcode would ever help, but the possibility's there. Any opinions? Mike Nonemacher mn2f+@andrew.cmu.edu From: jojaste@descartes.uwaterloo.ca (James Ojaste) Subject: Re: mod m numbers Message-ID: Date: Wed, 11 May 1994 14:56:16 GMT In article <94130.102553AHNAS@ASUACAD.BITNET>, writes: > I'm just curious. Does anybody use pShell.exe ? Should we bother to create a > portable pShell ? Well, on the DOS side, I use it - it's handy being able to test/edit/debug code quickly... The tourney-holding menu is pretty poor, though - it won't accept 94x cores (the command-line is too small). Or can you specify an @file? Hmm. Maybe I should read the docs before complaining... On the unix side, I just leave a couple of windows open at the same time - one for editing, one for testing, one for debugging, etc. It'd be nice to have a display like the graphical DOS display, though... -- /* 0F 90 3E 44 F9 13 E7 CC (jojaste@descartes.uwaterloo.ca) ** 10 20 44 C8 42 21 08 98 ** 38 40 F9 50 87 C2 1F 30 "Woof bloody woof" - Gaspode the Wonder Dog ** 40 81 12 61 08 84 22 00 (Terry Pratchett, Moving Pictures) */ F9 FA 24 42 11 3F 44 C0 From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Scanning for Imps/Fangs (possible new '94 modifier?) Message-ID: <1994May11.164541.14062@news.vanderbilt.edu> Date: Wed, 11 May 1994 16:45:41 GMT If DJN.I is to decrement operands and opcodes, wouldn't it be logical to have it decrement addressing modes as well? Maybe we also need two more modifiers (which?) to access the modes? If modifiers are part of the opcode, then (SUB.AB - 1) is not ADD.AB, but SUB.A or something. Perhaps another modifier for modifiers :) ? (it should be pretty plain by now that I am not enthused with .O et al.) -Stefan (stst@vuse.vanderbilt.edu) From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Genetic algorithms for corewars Date: 11 May 1994 18:55:40 -0600 Message-ID: <2qruqc$7e5@cwis.isu.edu> A little while ago, I recall hearing about somebody that was evolving corewars warriors with genetic algorithms. If I remember correctly, the major problem was the time-consumption of the survival testing. (having to run 100 or so battles between each combination of two siblings) Here's my question. Would you really have to run 100 battles, or would you just have to run one? Here's my thought process: The reason you run more than one battle is because pure randomness can cause a weaker warrior to defeat a stronger one. But over a length of time, the stronger will tend to win more often. If you only ran one battle for the survival testing, would you not be selecting for warriors that were resilient under the greatest number of random circumstances? Granted, it would take much longer to develop decent warriors, since excellent ones could be taken out by a streak of bad luck, but I'm thinking that this might not necessarily be a bad thing. I wish I were a better programmer and had more resources available, because I'd really like to play with this idea. Even if the algorithms never developed any hill-worthy warriors, it certainly would be interesting to take a look at the warriors every few generations or so, just to see what kinds of things developed. From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: optima again Message-ID: <1994May11.210217.18015@news.vanderbilt.edu> Date: Wed, 11 May 1994 21:02:17 GMT >What if your bombing pattern uses alternating steps? >[..] >So, is it possible to modify corestep's algorithm to handle this kind >of multiple steps? > >/Anders I have written such a "multiple constant optimizer". It comes in pretty handy when chosing constants for stones as well. The algorithm is a straightforward extension of Nandor's iterative method, simply using multiple bomb pointers that are cycled trough. I have no clue whether this translates into a formula (a la Jay Han's corestep.c). Mail me for a copy if you want it now; I was going to add a man page and upload it to soda some time later next week. -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: help with writing a mars? Date: 12 May 1994 01:02:50 GMT Message-ID: <2qrv7q$201@agate.berkeley.edu> In article , Strider wrote: >Can someone clarify how labels work? The other label question I have is can a >value of a label be changed during the program's execution? In other words, >can I read in a program, strip comments, translate labels, and then run the >program as if the labels weren't there? Labels are evaluated *at compile time*. This means that the compiled program will have only numbers, with no labels. I think this answers all of your questions at once. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Genetic algorithms for corewars Date: 12 May 1994 01:14:35 GMT Message-ID: <2qrvtr$254@agate.berkeley.edu> Antonette Nixon wrote: > A little while ago, I recall hearing about somebody that was evolving >corewars warriors with genetic algorithms. If I remember correctly, the >major problem was the time-consumption of the survival testing. (having >to run 100 or so battles between each combination of two siblings) > Here's my question. Would you really have to run 100 battles, or >would you just have to run one? Here's my thought process: The reason >you run more than one battle is because pure randomness can cause a >weaker warrior to defeat a stronger one. But over a length of time, the >stronger will tend to win more often. I would say that it's still better to run at least 20 or 30 battles. In real life evolution, you only get one try, but the scores are not just win/lose -- the scores would be represented by a fraction from (say) 0 to 1 representing your fitness. But in single-battle corewar, the only possible scores are 0 and 1. This gives you *very* little information about the fitness of one warrior over that of another. I haven't bothered to do the calculations, but I would guess that in the long run it would actually take *more* time to run a genetic simulation with only one battle per warrior, because you'd have to have *way* more generations to evolve anything good -- and you will also have faster diminishing returns, because once the warriors get to a certain level of fitness, most changes will be swamped by the random errors. Of course this will also happen if you run 100 battles, but it will take a lot longer and you should be able to evolve better warriors. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Genetic algorithms for corewars Message-ID: <1994May12.012942.22862@news.vanderbilt.edu> Date: Thu, 12 May 1994 01:29:42 GMT In article <2qruqc$7e5@cwis.isu.edu> fullanto@cwis.isu.edu (Antonette Nixon) writes: > A little while ago, I recall hearing about somebody that was evolving >corewars warriors with genetic algorithms. [..] Karl Lewin (lewin@alife.santafe.edu) has developed a GA based warrior evolution system based on John Perry's paper (soda.berkeley.edu: /pub/corewar/documents/evolving.warriors). He's been meaning to post the following to this newsgroup, but apparently wasn't successful. Here goes: -------BEGIN OF INCLUDED TEXT-------------------------- I have had a couple of requests for more information on what, for lack of a better name I am calling EC94 Evolver. It is a set of programs I have developed to try and evolve successful corewar warriors. Here is a little background. Some time ago a paper (2 actually) by John Perry appeared on the corewar archive titled _Core_Wars_Genetics:_The_Evolution_of_Predation. After reading it I started to wonder what it would take to do something similar. I made a brief attempt but then other things came up so I shelved the idea for awhile. A few months after that I became interested in Genetic Algorithms/Genetic Programming and remembered the evolving warriors stuff and decided to try again. I based most of what I did on the Perry paper because that seemed as good as any place to start. This was about two months ago. I decided to use the proposed '94 standard in my system, I think that this was a good choice because it seems less restrictive about which addressing methods can be used with which instructions. The system was developed using VX-REXX on a 486 under OS/2. The system basically works like this: 0 Randomly generate the base generation 1 Rank the warriors based on their scores against some test programs 2 Apply a selection technique to chose parents 3 Use a genetic algorithm/operators on the parents to produce new programs 4 go back to step 1 To date I have made several runs with the system and while no "super-warriors" have evolved there have been some interesting results. None of the warriors evolved so far have been able to make it onto the the hill (pizza '94) but some have had limited success against certain warriors currently on the hill, unfortunately the ones that do well against several warriors get clobbered unmercifully against about 10 or 12 others so they end up scoring around 90 - 95. The following are the best results I have gotten so far they are for a warriors named G050W071 & G054W073 (50th generation, warrior 71 & 54th generation, warrior 71) These were from a few days ago: Opponent G054W073 G050W071 ======================================================== vs Torch 43/36/21* 69/19/12* vs Der Zweite Blitzkrieg - 94 04/71/25 04/66/30 vs Iron Gate 1.5 41/56/03* 50/50/00* vs Request v2.0 04/46/50 00/13/87 vs Blue Funk 00/30/70 00/21/79 vs Cannonade 08/84/08 22/58/20 vs Dragon Spear 49/51/00* 24/65/01 vs NC 94 05/52/43 05/38/57 vs Lucky 3 00/99/01 00/75/25 vs Twimpede+/Small-X 00/60/40 00/33/67 vs Christopher 34/28/38* 17/39/44 vs SJ-4 80/20/00* 76/24/00* vs Rave 4.1 08/88/04 19/81/00 vs ^C 00/95/05 01/73/26 vs Splash 07/90/03 11/57/32 vs Imperfection v3.4 03/36/61 00/12/88 vs Yop La Boum v2.1 06/87/07 06/71/23 vs Clown 69/31/00* 75/25/00* vs Jazz 01/34/65 00/29/71 vs self 00/00/100 00/00/100 81.09 94.57 The source for G050W071 is below. If anyone wants to analyze it and post a summary please do, I have never been very good at writing warriors myself so I have'nt really tried. Some general observations about evolved warriors: They like to use DJN and SPL (attack/stay alive?) If the run has evolved down the SPL line then they don't seem to be able to beat themselves which losses points on hill (I think) The choice of which warriors to use as opponents during fitness testing is important. If anyone has been saving the '94 regular hill warriors that have been posted I would very much appreciate it if you could mail them to me this could possibly provide for some interesting experiments. I hope that I have not rambled on to much. If anyone has any questions or would like more details let me know and I will post some more info. I apologize if this post has been confusing and choppy but I am in kind of a hurry today. Karl ;redcode-94 ;name G050W071 ;author RC94 Evolver ;Parents: G049W013 G049W062 org 2 JMN.AB >2383,$4229 DJN.F #0619,<0008 DJN.F #0684,<0002 DJN.X #0315,$0186 MOV.I >2123,@3078 ADD.F <1774,<0003 DJN.F #0558,<0024 MOV.I #2108,@1159 SPL.A #3608,@1547 MUL.I $0291,$1295 SPL.AB #8362,@2071 SPL.AB >2078,@1219 SPL.AB #2842,#2051 DAT.I #0043,<1039 SPL.AB #6172,@1089 MOV.F @0049,$4738 MUL.F $0581,<1035 SLT.F #0044,<0010 ADD.BA >3114,<2158 DJN.F #0687,<0000 SPL.AB #3624,@1035 CMP.AB #3892,#0519 JMN.F #0644,<2090 MOV.AB #2330,@3127 MOV.A @0303,<3151 MOD.F @3911,<3456 SPL.AB #2334,@1155 MUL.AB <4111,<0293 DJN.A #6162,>0517 JMP.A <0047,<0008 DAT.B @5134,#4167 ADD.BA @4157,$6400 DJN.AB $1410,$0551 ADD.F #1258,<0535 ADD.X >0153,@1344 DJN.AB $0154,<0018 JMZ.BA <8756,#1063 SLT.F <7107,<0522 JMZ.BA >2531,<0011 DJN.F #6089,<0520 ADD.F #0687,<2048 DAT.B @5134,#4211 DIV.X $2097,<2144 ADD.F #4650,<4112 MOV.B @0049,@0002 DAT.I $4119,>0044 MOD.I #0258,@0058 JMZ.F #0039,<0291 JMZ.F <0051,@0065 JMN.I <2178,<1189 MUL.F >4111,<0293 JMZ.AB #0523,$4121 ADD.I @6240,#0044 DJN.A @2057,<0610 CMP.A @8216,#0018 SLT.I @2586,@0060 DJN.BA <5447,>0006 JMP.A @0034,<4780 JMZ.F $0310,>1051 SPL.B #2078,@1223 ADD.F >0014,<4360 DJN.A #0060,<0159 DJN.F #1583,$0019 DAT.F @0126,<1085 MUL.B @2119,@2114 DAT.I $8956,@0375 JMZ.F #8879,<0170 MUL.A <0339,$0041 DJN.F #1039,<2574 JMP.AB $4138,<4174 SLT.AB #3129,$0032 MUL.AB $2594,#4142 DAT.X $0038,<1292 MOV.I @1027,>0224 JMZ.I $0008,#0594 SLT.I @2586,@0056 DAT.X <0102,@0012 JMN.I <2178,<1189 JMZ.F <0386,#0522 SLT.F @0045,<0106 JMZ.F >0507,<1035 DJN.B $0029,@1059 MOV.I <4143,<0232 DAT.F @0041,<4110 JMZ.X $0024,>2198 DAT.F >2347,<0538 DAT.I $8750,$6191 DAT.F @0104,<1279 DIV.A #2071,@1037 ADD.I <4685,<0005 MOV.BA @8305,>5280 -------END OF INCLUDED TEXT----------------- If you analyze this warrior, you'll notice it spends its entire time executing the second instruction (DJN.F #683,<2), which is a bit disappointing. In fact, many of his creations seem to converge to this one-liner. We're currently working together to make the evolving warriors more competitive by applying better selection rules. One idea is to initially select for complexity, favoring offspring that executes larger loops (this can be automated via cdb macros). Another idea is to exclude DJN from the primordial instruction soup, but have it appear later by chance mutation. Stay tuned. -Stefan (stst@vuse.vanderbilt.edu) From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: Scanning for Imps/Fangs (possible new '94 modifier?) Message-ID: Date: 12 May 1994 10:03:30 GMT In article <1994May11.014204.1059@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: [Says my idea of a nonfunctional modifier is not a good one. I agree.] > > Or perhaps adding DAT to any other opcode leaves the opcode intact; > whereas anything else to an opcode overwrites the target > opcode with the source opcode. This would make arithmetic sense if > one of the effective addresses is a DAT. > > > -Stefan (stst@vuse.vanderbilt.edu) Let's see, if we push the arithmetic bit some more, MULtiplying anything with DAT leaves a DAT, and MULtiplying a non-DAT with a non-DAT overwrites the op-code. So far so good. Then, DIViding anything by a DAT would result in a division by zero. Same with MOD by a DAT. If we ADD a DAT to anything, it should leave the target intact. Any other ADD would be an overwrite. The tricky bit would be SUB. SUBstracting a DAT from anything should leave the target intact. However, SUBstracting anything from the same thing should result in a DAT. How about SUBstracting a non-DAT from another non-DAT? Should this be an overwrite too, or should it result in a DAT? -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: mike@sna.co.umist.ac.uk (Mike Reddy) Subject: Genetic Algorithms (Update) Message-ID: <1994May12.163854.16958@nessie.mcc.ac.uk> Date: Thu, 12 May 1994 16:38:54 GMT Since there has been renewed interest in GAs for Corewar, I thought I would give you an update on our plans for implementation. I tend to agree that 100 battles may be excessive. However, the crucial point at the time I posted the message was that previous attempts had required 'fitness' to be determined manually - warriors generated then loaded in directly by the programmer - which was the principle slowing factor. My student is keen to either modify existing MARS simulation code or write his own so that the generation and selection of warriors can be speeded up. One factor which we hope to include is bit level rather than instruction level creation of code. Although we have not yet decided whether it is feasible in the time allowed for his project, my student is also interested in using population weighting to determine fitness (i.e. the more successful a warrior, the more copies exist to fight in the tournament, which would allow evolution of strategies which incorporated clones (cannibalism?) as well as providing for the existence of parasites). The long term goal is to provide a complete MARS environment simulation where multiple copies of imps could be seen sweeping majestically across the core (plain?). Something like Tierra (see Levy's book Artificial Life) I suppose. However, I am trying to keep his enthusiasm within realistic bounds. If anyone is still interested in developments (work starts next academic year full pace) then please email me. NOTE: do not use automatic replies, as this is not being posted from my full- time machine. Rather you should use the address below -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan and occassionally visit mike@uk.ac.umist.co.sna if you ever need me! From: psr@acsu.buffalo.edu (Strider) Subject: Re: help with writing a mars? Message-ID: Date: Thu, 12 May 1994 17:10:08 GMT Thanks. This clears things up alot. -S -- Strider | SUNY @ Buffalo | psr@acsu.buffalo.edu Lord Mayor, The Hill People | (716) 645 4167 | V127MHSK@ubvms.bitnet ------------------------------------------------------------------------------- "Son, I am able," she said, "though you scare me." "Watch," said I, "beloved." From: Dave Darling Subject: Re: mod m numbers Message-ID: <1994May12.171718.22960@riacs.edu> Date: Thu, 12 May 94 17:17:18 GMT In article <94130.102553AHNAS@ASUACAD.BITNET> , AHNAS@ASUACAD.BITNET writes: >Michael, now both of our O/optima programs are obsolate. This is the end of >the competition. It was fun :-) > >I'm just curious. Does anybody use pShell.exe ? Should we bother to create a >portable pShell ? > >Nandor. The Optima programs are obsolete? When did this happen? And what the heck is pShell? If it's going to replace the optima-number generators, I would definitely like to see a portable version. --DD 914 Addict GU d--@ -p+(p-) c+ !l(l--) u++(u--) e- m---@ s+/+ n+@ h+ f? g-(g+) w++ r++ r+@ y* HELP! I'm in TQM training, and I can't get up! From: mike@sna.co.umist.ac.uk (Mike Reddy) Subject: Genetic Algorithms (Update) Message-ID: <1994May12.174058.20619@nessie.mcc.ac.uk> Date: Thu, 12 May 1994 17:40:58 GMT Since there has been renewed interest in GAs for Corewar, I thought I would give you an update on our plans for implementation. I tend to agree that 100 battles may be excessive. However, the crucial point at the time I posted the message was that previous attempts had required 'fitness' to be determined manually - warriors generated then loaded in directly by the programmer - which was the principle slowing factor. My student is keen to either modify existing MARS simulation code or write his own so that the generation and selection of warriors can be speeded up. One factor which we hope to include is bit level rather than instruction level creation of code. Although we have not yet decided whether it is feasible in the time allowed for his project, my student is also interested in using population weighting to determine fitness (i.e. the more successful a warrior, the more copies exist to fight in the tournament, which would allow evolution of strategies which incorporated clones (cannibalism?) as well as providing for the existence of parasites). The long term goal is to provide a complete MARS environment simulation where multiple copies of imps could be seen sweeping majestically across the core (plain?). Something like Tierra (see Levy's book Artificial Life) I suppose. However, I am trying to keep his enthusiasm within realistic bounds. If anyone is still interested in developments (work starts next academic year full pace) then please email me. NOTE: do not use automatic replies, as this is not being posted from my full- time machine. Rather you should use the address below -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan and occassionally visit mike@uk.ac.umist.co.sna if you ever need me! From: mike@sna.co.umist.ac.uk (Mike Reddy) Subject: Genetic Algorithm (Update) REPOST 8-( Message-ID: <1994May12.174709.21002@nessie.mcc.ac.uk> Date: Thu, 12 May 1994 17:47:09 GMT Since there has been renewed interest in GAs for Corewar, I thought I would give you an update on our plans for implementation. I tend to agree that 100 battles may be excessive. However, the crucial point at the time I posted the message was that previous attempts had required 'fitness' to be determined manually - warriors generated then loaded in directly by the programmer - which was the principle slowing factor. My student is keen to either modify existing MARS simulation code or write his own so that the generation and selection of warriors can be speeded up. One factor which we hope to include is bit level rather than instruction level creation of code. Although we have not yet decided whether it is feasible in the time allowed for his project, my student is also interested in using population weighting to determine fitness (i.e. the more successful a warrior, the more copies exist to fight in the tournament, which would allow evolution of strategies which incorporated clones (cannibalism?) as well as providing for the existence of parasites). The long term goal is to provide a complete MARS environment simulation where multiple copies of imps could be seen sweeping majestically across the core (plain?). Something like Tierra (see Levy's book Artificial Life) I suppose. However, I am trying to keep his enthusiasm within realistic bounds. If anyone is still interested in developments (work starts next academic year full pace) then please email me. NOTE: do not use automatic replies, as this is not being posted from my full- time machine. Rather you should use the address below -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan and occassionally visit mike@uk.ac.umist.co.sna if you ever need me! From: Dave Darling Subject: Re: possible new '94 modifier? Message-ID: <1994May12.195339.25263@riacs.edu> Date: Thu, 12 May 94 19:53:39 GMT In article Jay, jayhan@cs.washington.edu writes: >I think that for those operations that don't make sense (MUL DIV MOD >ADD DJN), we should just make the modifier nonfunctional, i.e. it >doesn't do anything. > >This lack of consistency could be justified by the fact that for MOV >CMP JMN and JMZ, the modifier makes perfect sense, and could be >quite powerful. It seems that the .O would not be worth it if each modifier of each opcode were a separate number. It would just be too difficult to use effectively to read (scan) with, but would be fine for writes (bombs/etc). It would seem that the intstruction without modifier would be the most useful choice. There is also some "real world" justification for this, since in some architectures the opcodes are stored in different fields from the opcode modifiers. I would object to the "non-functional" opcodes, however. The modulo arithmetic does make some sense, but it seems (right now) to me to be too powerful. (I know, what does that mean?) I think that the standard '94 methodology of making a non-sensical operation behave like its next "closest" correct operation would be the way to go. My $00.02 worth. --DD 914 Addict GU d--@ -p+(p-) c+ !l(l--) u++(u--) e- m---@ s+/+ n+@ h+ f? g-(g+) w++ r++ r+@ y* HELP! I'm in TQM training, and I can't get up! From: al663@FreeNet.Carleton.CA (Chris Sibbitt) Subject: Confused..... Message-ID: Date: Thu, 12 May 1994 19:58:34 GMT I'm new to corewars, but with the knowledge and doc files that I have, I'm pretty good at creating battle progs. Unfortunately I don't have the latest version of redcode or mars, and I've seen command strings that I don't recognise for instance: Spl x,y I've seen and used (extensivly) spl but only with one variable, it doesn't even work with two.... I don't have telenet or ftp access to soda.berkley or whatever the address is, so if someone out there could send me the latest compiler and mars I'd very much appreciate it. Also, I've seen the files tutorial one and two, but haven't been able to retreive them, so if someone could maybe send those to me, again I'd very much appreciate it. Oh yeah, I run an IBM compatible with only CGA capability to speak of, so all those supped up Mars' may not work. -Chris -- | Name: Chris Sibbitt (a.k.a. Wanderer) |Burble............GAK! | | Address: al663@freenet.carleton.ca | It's spreading..... | | Signature: --Wan��� | It's spreading!!! | |-{without the signature.. it's a fake!}-|-----------------------------| From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: mod m numbers Date: 12 May 1994 20:24:31 GMT Message-ID: <2qu39v$rg0@agate.berkeley.edu> Dave Darling wrote: > Nandor Sieben writes: > >Michael, now both of our O/optima programs are obsolate. This is the end > >of the competition. It was fun :-) > > > >I'm just curious. Does anybody use pShell.exe ? Should we bother to > >create a portable pShell ? > > The Optima programs are obsolete? When did this happen? And > what the heck is pShell? > > If it's going to replace the optima-number generators, I would > definitely like to see a portable version. The Optima programs are obsolete because of Jay Han's new program, Corestep. Corestep is exactly like Optima except about 100 times faster :-) And yes, it is portable. You can get it by anon ftp to soda.berkeley.edu, as /pub/corewar/incoming/corestep.c (you have to compile it yourself). pShell has nothing to do with Optima. pShell is a menu-based front end for pMARS. Currently it is only available for DOS but it might become portable if there is enough demand. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: We have loops!!! Message-ID: <1994May12.210525.11917@news.vanderbilt.edu> Date: Thu, 12 May 1994 21:05:25 GMT >Stefan, > >I have started the new run. Most of the modifications we have came up with have >been included to some degree or another. I am heading out the door now so I >will go into more detail later. > >The base generation and the first generation have finished running. Here is a >summary of the results from those two > >Generation vs DerBlitz vs Paradox vs Pyramid vs Rave >0 02/2430/068 02/2436/062 00/2488/012 06/2491/03 >1 14/2318/168 01/2336/163 02/2463/035 06/2491/03 > >Here is the best of the first generation. > > >;redcode-94 >;name G001W054 >;author RC94 Evolover >;Parents: G000W085 G000W085 >org 7 >DAT.I $ 1,# 40 >DAT.I $ 35,> 45 >DAT.I < 35,> 32 >DAT.I $ 22,# 31 >DAT.I < 25,$ 7 >DAT.I $ 22,# 31 >SPL.AB # 12,> -10 >MOV.B $ 15,> -1 >JMP.I $ -2,> -6 >DAT.I < 38,@ 4 >DAT.I @ 49,< 1 >DAT.I $ 13,> 48 >DAT.I < 38,@ 4 >DAT.I @ 49,< 1 >DAT.I $ 13,> 48 >DAT.I # 43,$ 40 >DAT.I $ 50,@ 14 >DAT.I @ 5,< 49 >DAT.I @ 11,< 40 > > >Not that interesting but hey, we have a loop (I think) > > >I have the system running now. It is set to run through generation 20. I will >send you the results and such on monday when I get back. > > >Karl > >PS - I have uploaded the whole first three generations to soda as G1-3.zip if >you want to play around with them. > > >Karl From: pk6811s@acad.drake.edu Subject: vampire ideas Message-ID: <1994May12.171814.1@acad.drake.edu> Date: Thu, 12 May 1994 23:18:14 GMT Speaking of vamps, it is possible to use a fixed fang - which may find a use in someone's program. Here's one way: scan add #step,#0 jmz.f scan,@scan ; find a non-zero location mov fang,@scan ; move the fang sub.ba scan,@scan ; adjust the jump to the pit jmp next fang jmp pit-scan pit insert your favorite pit here Also, this pit is very effective in killing single-process programs: mov clear,<-clear spl #0 pit djn -2,#1 The first process that jumps to the pit will fall through the djn and die, so any single-process programs are killed immediately on being fanged - no messy, unreliable core-clears needed :-) Paul Kline pk6811s@acad.drake.edu From: uj211@freenet.Victoria.BC.CA (Ben Young) Subject: Re: Imp-gates Message-ID: <1994May13.013940.5929@freenet.victoria.bc.ca> Date: Fri, 13 May 1994 01:39:40 GMT In a previous article, fullanto@cwis.isu.edu (Antonette Nixon) says: >Which is better: > > SPL 0 > DJN 0,<-35 > or just > JMP 0,<-35 >? >The DJN imp needs a spl instruction, because it will die if it encounters >locations with Bfield of 1, correct? But, it also decrements in reverse >throughout core? (And wreaks havoc on anything that needs to point to a >specific place, including sometimes itself...) :-) > My first instinct is to say the DJN imp is more effective, since it >gets more chances to decrement an imp's instruction as the imp is >executing. Am I missing something? Please don't take what I say here to be the absolute irrefutable truth, as I haven't been playing around with corewar for a while, and a lot of things have probably changed. However, it seems to me that with the SPL gate, half the time is spent executing the SPL and the other half executing the DJN, since the programs take turns executing each process, and only one process can be executed at the same time. This gives some programs more of a chance to get by the gate, since the gate is only decrementing about 50% of the time. Yes? No? Where the SPL loop does have an advantage is that it simply has more processes. Depending on how many processes get started, and on the process limit that the MARS is using, it may take a very long time for all of the processes to die out. It only takes one time cycle for the JMP instruction to be clobbered, since it is only running one process. Another big problem with the DJN loop _is_ the fact that it decrements around the core. With an imp spiral, or whatever the name is now, the executing instructions are all in little clumps of memory locations. Suppose that there are, say, 200 processes executing within a 10 instruction block. The DJN gate will "sweep" through these instructions in between 10 and 20 time cycles, decrementing each instruction once. This allows for a maximum of 10 kills of enemy procesess. That still leaves 190 processes operating in the 10 address block... Ah well. Just some random thoughts. Questions? Comments? -- --Ben Young------UJ211@freenet.victoria.bc.ca------VE7AJT-- It is said that the Devil has all the best tunes. This is broadly true. But Heaven has the best choreographers. - Terry Pratchett & Neil Gaimann - Good Omens. From: wsheppar@sct.edu (Wayne Sheppard) Subject: Re: Imp-gates Date: 13 May 1994 03:17:50 -0400 Message-ID: <2qv9iu$216q@st6000.sct.edu> >In a previous article, fullanto@cwis.isu.edu (Antonette Nixon) says: > >>Which is better: >> >> SPL 0 >> DJN 0,<-35 >> or just >> JMP 0,<-35 Try this gate out: spl 0,<-2 mov 1,>-3 dat >-4,10 I haven't tested it fully, but it looks like it should be a %100 gate and also a repeating coreclear. It worked on my simple tests, but I could be missing something. Wayne sh -- Wayne Sheppard wsheppar@st6000.sct.edu From: mike@sna.co.umist.ac.uk (Mike Reddy) Subject: Genetic Algorithms (Update) APOLOGY 8-( Message-ID: <1994May13.090515.3541@nessie.mcc.ac.uk> Date: Fri, 13 May 1994 09:05:15 GMT My apologies for the multiple posts on this subject. There seems to be a nasty bug somewhere that allows messages to be posted, but does not tell me about it afterwards. In fact the machine hangs, when I try to send. Sorry for any inconvenience! Yours Mike -- P.S. I would have had a witty signature, but the Government put VAT on it! P.P.S. I live at mreddy@uk.ac.glamorgan and occassionally visit mike@uk.ac.umist.co.sna if you ever need me! From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Re: Imp-gates Date: 13 May 1994 11:07:41 -0600 Message-ID: <2r0c4t$9o2@cwis.isu.edu> In article <2qv9iu$216q@st6000.sct.edu>, Wayne Sheppard wrote: >Try this gate out: > > spl 0,<-2 > mov 1,>-3 > dat >-4,10 > >I haven't tested it fully, but it looks like it should be >a %100 gate and also a repeating coreclear. It worked on >my simple tests, but I could be missing something. Hmm...I'm programming for the 88 standard, and I don't have post-increment available. It looks like it should work, though. Here's something I devised that's similar, but without post-increment. dat #0,#-1 dat #0,#0 gate spl gate,<-2 mov 1,<-3 dat <-4,<-4 end gate This works as a mod 4 DAT bomber plus 100% gate, all for the cost of only one process. (well, actually, I guess at any one time, there are three processes running, right?) So, the ultimate corewars question. Is this useful? :-) From: ehope@cayenne.gac.edu (Eric A Hope) Subject: Re: EBS spring '94 tourney: round 3 results Date: 13 May 1994 14:22:37 GMT Message-ID: <2r02fdINNmv9@news.gac.edu> In article <1994May8.172700.11883@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: -> -> Much more diversity in the 3rd round of the EBS spring tourney than in -> the 1st round with "big core" rules: We had an anti-imp scanner -> (ivscan6), bombers (CG-X V, Riff, Blitz), and imps (Big again, -> Twister). If you're wondering why Mike Nonemacher is represented with -> _two_ warriors in this round, it's because his adversary Wayne Sheppard -> tried to defeat him with his own weapon. Should submitting somebody -> else's warrior be allowed in future tourney's? I actually think yes, -> because this is more honest than plagiarizing somebody else's code and -> submitting it as your own. [results deleted] It also forces continual innovation. You can't sit back and let a masterpeice reap the honors, because next week someone else will be winning with your code. This way there is another reason to try and find the flaws in your own programs. -Eric Hope ehope@gac.edu ----------------------------------------------- "I'll lick this redcode stuff yet!" -Famous Last Words From: pk6811s@acad.drake.edu Subject: Re: A better quick-cmp Message-ID: <1994May13.090848.1@acad.drake.edu> Date: Fri, 13 May 1994 15:08:48 GMT In article <2qnmuc$14ic@st6000.sct.edu>, wsheppar@sct.edu (Wayne Sheppard) writes: > > Now is the time for everyone to rewrite thier quick-cmp scanners. > I figured out several improvements that can be made. First is > the use of the new opcode SNE. Interleaved with SEQ, it is possible > to increase the density of your quick-cmp code. > > SNE 200,300 > SEQ 400,500 > MOV #200,loc > SNE ...... > SEQ ...... and so on. > This is for illustration only, right? The actual code might look more like: for 15 sne loc+loc*133,100+loc+loc*133 seq 200+loc+(loc+1)*133,300+(loc+1)*133 mov #(loc+2)*133,loc rof > My quick-cmp structure is only 54 lines long, leaving more room > for other code, and being less vulnerable to a lucky shot at > the beginning because my length is less. I'm not sure you are less vulnerable to a LUCKY shot, hey - what's the definition of lucky? :-) But I think you are just as likely to be killed by a RANDOM shot. Your code is more compact, but your process has to move through the same number of comparisons - 36 as a comparable old-style (yeesh -already old?) quick-cmp. A quick-bomb attack would launch 36 bombs, and maybe 36 inc/decs in the same time. The chances of hitting one of your 36 instructions is just as great as hitting one of someone else's 36 instructions. The main advantage is that you have more room for other code - or more quick-cmp's. Or you could just stay smaller and be harder to locate by the others. > Improvement #2: Out of all of the quick-cmps published, I have > yet to see one that doesn't waste half of its time bombing > the core that is known to be completely on the opposite side > of the core. The cmps are set up to check at X and X+4000. > If the enemy is known to be at X or X+4000, why waste your time > bombing both locations? I guess Plasma is a smart warrior cause > it checks to see which location needs to be bombed. > > SNE @loc,DAT0 ;test against a known DAT 0 location like start-1 > ADD #4000,loc When I wrote QuickFreeze I experimented with something like this, but discovered that a couple of authors were booting their active code exactly 4000 instructions away from source, apparently to protect them from some extinct on-axis scanners. So bombing both areas gave a LOT of easy wins. Of course, nobody is booting 4000 anymore, right :-) > Score results for Plasma-test-v5 > ... not-too-shabby score results deleted ... There are two other wrinkles that QuickFreeze incorporated that haven't appeared in any recent quick-cmps: Separate the cmps into two groups, then spl and run them in parallel. That way even if a lucky dat-bomb killed one of your comparisons you wouldn't lose. Execute a JMN halfway through the cmps to see if the opponent has already been found. In half the cases where you find the opponent you will start your attack that much sooner. ------------------------------------------------------------------------ Speaking of boots, gates, ... I went through a really perplexing series of tests with Keystone recently. It's basically the old '88 Keystone without the ring-launcher. It does a boot, leaving a decoy behind. While playing around with the decoy I kept getting wild shifts in the win/loss ratios against a couple of opponents - as much as 40 points! It didn't make sense, just moving the decoy from the front to the back, or dividing it equally - very strange. What I discovered was that my endgame gate was poorly positioned against 1143 imps. It stopped the spiral all right, but one of the imp-streams happened to be exactly positioned over my launch code. So of course it got new life by executing my own code! Changing the gated location eliminated that problem. Just one of those *fun* things. Paul Kline pk6811s@acad.drake.edu From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: corestep v3 Message-ID: Date: 13 May 1994 18:49:17 GMT Rejoice! Version 3 of corestep is here! soda.berkeley.edu:/pub/corewar/incoming/corestep.c This is a major revamping of corestep. Here's what it does: (this is an extract of the header comments in corestep.c). Usage ----- Run the program without arguments for a quick help. There are three possible uses: 1. Test a single step: -s # 2. Test all mod-N: -m # 3. Test all steps: (default) For each type, you may specify or not a selection criterion: -cc classic formula -ca alternate formula -cf find-X (with up to FINDS numbers) If a criterion is specified, you may choose how many will be shown: -b # shows the # best steps In any case, you may ask to display the scores and find number for the chosen numbers by using -dc show classic score -da show alternate score -df show find numbers for up to FINDS numbers Other options: -l # limit to steps <= # -v verbose -q quiet -o alternate output (don't know how to use this yet...) Notes ----- 1. Find-X numbers are displayed in percent. 100% is perfect, 200% means it takes twice as long as perfect (e.g. 1600 iterations to find 10 in small core). 2. If you specify two or more find-numbers as the criterion, the compound score is the average of the specified find-numbers. However, if you specify -df parameters, each find number will be dispayed separately. 3. All sorted scores (best scores) are displayed best-to-worst. For the classic formula, higher score is better. For the alternate formula and the find numbers, lower score is better. 4. In general, the display has been programmed to be tight, so as to give as much information as possible in the smallest space. However, the results are tabulated to allow easy browsing and character-based sorting. Examples -------- Find all mod-4 numbers: corestep -m 4 -c Find 5 best mod-4 numbers using classic formula: corestep -m 4 -cc Same, display their find-20 and find-100 numbers: corestep -m 4 -cc -f 20 100 Find 10 best mod-1 numbers for 10-sized opponents: corestep -m 1 -cf 10 -b 10 Same, display their find-50 and find-200: corestep -m 1 -cf 10 -b 10 -f 50 200 Find 20 best numbers for 10- and 20-sized opponents: (this takes some time, so we'll have the verbose mode on) corestep -cf 10 20 -b 20 -v Same, display their classic score: corestep -cf 10 20 -b 20 -dc Compiling --------- The program uses log(), which should be included in libm.a, the math library. Usually, it can be linked in with the compiler option -lm, as in: gcc -O2 -o corestep corestep.c -lm (Don't forget to turn on all optimization options!) This program should compile without problems on any OS with an ANSI C compiler, provided that uint is 16 bit wide. Feedback -------- I'd be happy to hear from you. Tell me if you find this program useful, interesting, or totally unsuited to your needs. Bug-reports are always welcome, even if they prove false! :-) If you have new ideas you'd like to see incorporated into the program, let me know also. I'm particularly looking for other alternate scoring formulas that give meaningful/useful results. -------------------------------------------------------------------- I won't include timing now. You know it's pretty fast. :-) Computing find numbers is also done with a non-simulating method, but it's somewhat slower than the simple classic formula. Also, be aware that if you ask for a compound find score with N find numbers, it will take about N times as long as with a single number. Well, that's about it. I'll think about Anders' suggestion. Otherwise, I'm working on a core simulator that knows about your program (what to avoid, what to hit when, etc.). I really should concentrate on writing Redcode though... Variation G-1 is being pushed farther and farther down! :-) -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: possible new '94 modifier? Message-ID: Date: Fri, 13 May 1994 19:09:40 GMT Don't we also need modifiers that operate on addressing modes? mov.am a, b ; move the a-field addressing mode of 'a' to 'b' cmp.amb a, b ; compare the a-field mode of 'a' to the b-field mode of 'b'. And then we could say that direct addressing ($) corresponds to 0, so add, sub, mul and div could be defined for addressing modes. But then, adding an addressing mode to an instruction would also make sense, so we'd need new modifiers: add.amo a, b ; add the a-field mode of 'a' to the operator of 'b'. Sounds interesting? No, it doesn't! :-) It's a joke. I hope. Don't take this post the wrong way, there's nothing wrong with trying out new things. But if we try to make Redcode completely orthogonal, it'll just turn into a mess of modifiers and whatever. And it still won't be orthogonal. Actually, I've thought of a Redcode-like language that has some interesting properties in this respect. It has only one instruction and only one addressing mode. SSS a, b, c, d Subtract b from a and store in c, Split to d if carry, else Skip. We'll have to say that the instruction behaves like a DAT if all fields are zero (or perhaps just the a-field). I think all redcode instructions can be simulated with this one instruction. For example JMN a,b would be SSS c_0, a, junk, b ;split if a > 0 c_0 SSS 0,0,0,0 ;kill if split Anders From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: EBS spring tourney round 4 results Message-ID: <1994May14.020136.8100@news.vanderbilt.edu> Date: Sat, 14 May 1994 02:01:36 GMT We're getting near the end of the EBS spring tourney. Jay Han submitted Aleph 0, a quick-scanning stone/imp combo, Brant Thomson entered Arson v2.1, a A/B-scanner with incinerary bombs, and Mike Nonemacher was represented with a B-scanning vampire, Squint. Here the results: Battle 1 of 3 (33%) is finished: Aleph 0 by Jay Han scores 160 (45 30 25) Arson v2.1 by Brant D. Thomsen scores 115 (30 45 25) Battle 2 of 3 (67%) is finished: Aleph 0 by Jay Han scores 150 (48 46 6) Squint by Mike Nonemacher scores 144 (46 48 6) Battle 3 of 3 (100%) is finished: Arson v2.1 by Brant D. Thomsen scores 130 (35 40 25) Squint by Mike Nonemacher scores 145 (40 35 25) Elapsed time: 163 seconds (00:02:43) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Aleph 0 Jay Han 47 38 16 310 2 Squint Mike Nonemacher 43 42 16 289 3 Arson v2.1 Brant D. Thomsen 33 43 25 245 Aleph 0 scored highest and qualifies Jay Han for the "big core" finale against James Layland, held coming Friday May 19th. -Stefan (stst@vuse.vanderbilt.edu) From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Rambling: a fast scanner using indirect-A Message-ID: Date: 14 May 1994 13:15:18 GMT The idea of the SNE/SEQ quickscanner had been jogging in my head for a while. Finally someone made it work (Plasma). Here's a new idea for a scanner that uses indirect-A addressing, and that has interesting properties. First, let me say that "slow" scanners scan at .66c (2 locations every 3 cycles) at best. Quickscanners (Pyramid or Plasma) scan at 2c, with Plasma begin more efficient in its space usage (4 locations per 3 instructions, vs. 2 per 2). The problem with both Qscanners is that they take a lot of space altogether. It's impossible to make a mod-200 scanner in the big core that way. Now suppose we had indirect-A addressing, denoted by ~ (tilde). Here's a piece of code: x SNE.I ~p, @p y DJN.F -1, -1 SNE.A #q+2, -2 JMP ... q DAT x, y ; this makes sure we break out of loop ... p DAT a, b Lines q to p hold pointers to locations to scan. This code scans at 1c (2 locations every 2 cycles), so it's slower than Qscanners, but still a little faster than "slow" scanners. However, it only takes 1 instruction for 2 pointers. Thus, a mod-200 scan in the big core will use up 138 instructions, with plenty left for elaborate response for both "found" and "not found" situations. You can even cram a mod-150 scan with enough left for a stone. The other advantage of this scanner is that unlike Qscanners, a very unlucky hit between q and p will only make you skip a scan, but won't kill you (unless you're *very* unlucky, and the hit makes that DAT point to yourself). At this point, I'm not sure if 1c is fast enough, i.e. is it worth it? Here are some figures showing how many cycles it takes to scan at a given mod: Mod Qscan Fscan scan 220 125 250 375 Best you can do with Qscan 200 *** 270 400 145 *** 380 570 Best you can do with Fscan I wish I had a MARS with indirect-A to test it out... -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: al663@FreeNet.Carleton.CA (Chris Sibbitt) Subject: Did I miss something? RND Message-ID: Date: Sat, 14 May 1994 20:20:56 GMT Sorry to bother you people with beginer questions, but I recently received a copy of pmars(v) and it works perfectly. I'm getting used to the '94 modifiers and I'm really impressed at how much better the new standars is.... unfortunatley, alot of my warriors involve random probing, bombing etc. and RND doesn't seem to work n the new code standard, for ex: RND #6000,-1 MOV #0,@-2 JMP -3 Used to send out 0 bombs at a randdom address upto 6000 adrresses above current, now it doensn't work at all.... Someone, help, please? Is there a no way to use random numbers, or is the format just drastically changed? The error message I got was something like: Token: #, unknown ormisplaced. I've tried moving around the A & B fields, and even using RNDas an addressing mode, nothing seems to work! -Chris (help) -- | Name: Chris Sibbitt (a.k.a. Wanderer) |Burble............GAK! | | Address: al663@freenet.carleton.ca | It's spreading..... | | Signature: --Wan��� | It's spreading!!! | |-{without the signature.. it's a fake!}-|-----------------------------| From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Did I miss something? RND Date: 14 May 1994 21:12:42 GMT Message-ID: <2r3esa$8b8@agate.berkeley.edu> Chris Sibbitt wrote: > [...] unfortunatley, alot of my warriors involve random probing, > bombing etc. and RND doesn't seem to work in the new code standard. That's because RND does not exist in the '94 (or even '88) standard. There is no way at all to generate a random number. However, it shouldn't be that hard to retrofit your programs to use non- random numbers. For example, a random dwarf: RND #7500, 3 MOV -2, @2 JMP -2 can be changed to a non-random dwarf pretty easily: ADD #3044, 3 MOV -2, @2 JMP -2 The only new thing in the non-random version is the number 3044 which seems to have appeared out of nowhere. Actually, 3044 is an optimum mod-4 step size for coresize 8000. The "mod-4" means that if you let the dwarf run long enough, it will eventually hit every fourth location. This is good, because the dwarf is 3 lines long, so we can make it so it never gets hit. Being an "optimum" step-size just means that the bombing pattern will approximate a binary search, with each bomb being as far as possible from any previously placed bombs. (Run the non-random dwarf in pmarsv and watch it; a picture is worth a thousand words.) So, the main problem in converting your random programs will be finding these optimal step sizes. Fortunately there is a program to help you -- Corestep v3, by Jay Han. Corestep will calculate optimal numbers for you if you tell it what mod number you want (actually this is only part of what Corestep can do, but it should be enough for you to start. Mail me or Jay (jayhan@cs.washington.edu) for more info.). You can get Corestep by anon ftp to soda.berkeley.edu as /pub/corewar/incoming/corestep.c (you have to compile it yourself.) If you have any other problems fixing your programs not to use random numbers, please post here or mail me. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: Archive Addition Date: 15 May 1994 00:20:10 GMT Message-ID: <2r3prq$our@magus.cs.utah.edu> I will be graduating in June, so I am putting some of my files out for public use before they get deleted. As I have read the rec.games.corewar newsgroup over the last couple of years, I have tried to save all the articles I felt (at the time) to be important. I was expecially interested early on in saving the entire text for published warriors and good hint ideas, but lately I have been saving just about everything that isn't covered in the FAQ or tutorials. (I don't usually save "newbie" questions, although I almost always save the responses to them.) These files are now in the /pub/corewar/incoming directory of soda.berkeley.edu as compressed text files, and will probably be moved to the newsgroup directory eventually. Since I have not been at school during the months of June to September each year, there are several gaps in the information. Last summer I tried to catch all the posted articles by calling the school on my modem, but probably missed several because of vacations (and our newserver only keeping articles for three days). If you have any past articles stored up that are not included, mail them to me and I will be glad to insert them. If you have any old warriors that are not included, please repost them to give me a chance to grab them again. (I believe all the warriors in the "warrior10" archive are included here. Let me know if I am mistaken.) If anyone out there has been archiving past articles from this newsgroup, please let me know so we can coordinate our efforts in the future. There have also been some requests to archive past editions of _The_'94_Warrior_. I believe every copy is included in the appropriate file, and plan to upload a collection of them after I have publised a couple more. -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: pk6811s@acad.drake.edu Subject: New contest idea Message-ID: <1994May14.195447.1@acad.drake.edu> Date: Sun, 15 May 1994 01:54:47 GMT > Steven C. Morrell wrote: >>Which brings up an idea that I've been kicking around for a while, but >>haven't mentioned before for fear of being laughed at. Wouldn't it be >>neat to have a Poor Sportsmanship Hill where you could submit multiple >>copies of the same program, and you win if all of the warriors on the >>hill are yours? This hill would probably have to be limited to 10 >>warriors to make winning feasable. What does everyone think? > I kind of like the idea too. Let's limit the hill to 3 warriors, and the first person to 'own' it for a whole week is declared the winner. Multiple submissions of the same warrior would be allowed - but since every program loses to somebody, it's not likely that a single program could hold all three spots for a week. You could submit someone else's code, but only under the author's name. That way you can't drive someone's program off by submitting the same thing under your name. Paul Kline pk6811s@acad.drake.edu From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: New contest idea Message-ID: Date: Sun, 15 May 1994 11:51:46 GMT In article <1994May14.195447.1@acad.drake.edu> pk6811s@acad.drake.edu writes: > Steven C. Morrell wrote: >>Which brings up an idea that I've been kicking around for a while, but >>haven't mentioned before for fear of being laughed at. Wouldn't it be >>neat to have a Poor Sportsmanship Hill where you could submit multiple >>copies of the same program, and you win if all of the warriors on the >>hill are yours? This hill would probably have to be limited to 10 >>warriors to make winning feasable. What does everyone think? > I kind of like the idea too. Let's limit the hill to 3 warriors, and the first person to 'own' it for a whole week is declared the winner. I think 3 is too few, we'll get a 'stone/paper/scissors' effect. Maybe 5 would be enough to give stability. Multiple submissions of the same warrior would be allowed - but since every program loses to somebody, it's not likely that a single program could hold all three spots for a week. You could submit someone else's code, but only under the author's name. That way you can't drive someone's program off by submitting the same thing under your name. What about making 'improvements'? Whose code is it then? I think this has been debated before... Paul Kline pk6811s@acad.drake.edu Anders From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: vampire ideas Message-ID: Date: 15 May 1994 15:26:15 GMT In article <1994May12.171814.1@acad.drake.edu> pk6811s@acad.drake.edu writes: > From: pk6811s@acad.drake.edu > Subject: vampire ideas > Date: 12 May 1994 23:18:14 PST-8 > > Speaking of vamps, it is possible to use a fixed fang - which may find > a use in someone's program. Here's one way: > > scan add #step,#0 > jmz.f scan,@scan ; find a non-zero location > mov fang,@scan ; move the fang > sub.ba scan,@scan ; adjust the jump to the pit > jmp next > > fang jmp pit-scan > > pit insert your favorite pit here > I used this in my Scanalyzer-W, published a while ago (only it was a CMP-scanner). > Also, this pit is very effective in killing single-process programs: > > mov clear,<-clear > spl #0 > pit djn -2,#1 > > The first process that jumps to the pit will fall through the djn and die, > so any single-process programs are killed immediately on being fanged - > no messy, unreliable core-clears needed :-) This is pretty cool! In general, I tend to favor backward core-clears, such as: spl #0 mov 2, >-3 pit djn -2, #1 The reason (which is not backed by measurements) is that if by bad luck your "pit" line gets bombed, you may end up with an ineffective pit (or at least one that doesn't gather processes anymore), which in addition doesn't clear core. With the backward core-clearing pit, even if the DJN gets bombed, the SPL keeps generating processes to feed to the core-clear... until it dies. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Aleph 0 [Re: A better quick-cmp] Message-ID: Date: 15 May 1994 16:02:28 GMT So I submitted a quickscanner to the EBS tournament and to my surprise I won round 4! If you've been watching the Pizza 94 hill, you must have noticed how my "greek letter" warriors behaved dismally. Go figure... Anyway, about quickscanners, I use a Plasma-style scanner. As Wayne pointed out (thanks Wayne!), the problem (especially with Plasma-style quickscan) is that each SNE/SEQ block covers a wide area (say 400 locations). You want to know where to concentrate your bombing. Let's assume that inside those 400 locations you have four scan points, at intervals of r locations. My scanner is structured like this: SNE a+0, a+2*r SEQ a+r, a+3*r SUB.X #test+2,@test ... JMN.B test, test ... test SEQ @-1, @0 y1 ADD.AB #2*r, @-1 x1 ADD.B test, fang x2 ADD.B @test, fang x3 SUB.BA fang, fang ... fang JMP.B pit, #test When something is found, I store into test.B the location of the corresponding SNE, and in test.A the location of the SEQ. The "test" line compares a+2*r and a+3*r. If they test equal, that means we want to bomb from a+2*r backwards. If they test different, we want to bomb from a+4*r backwards (that's what the line "y1" does). Next, "x1" puts the address of the original SNE into fang.B. Line "x2" puts the address of the final location (to be bombed) into fang.B. Line "x3" puts fang.A and fang.B in sync. Voila, now you only need to bomb 200 locations. There's some juggling being done, but hey, ain't that a neat piece of code? :-) Well, Aleph 0 has a bunch of other goodies, but I won't reveal them just yet, because I might (I said I *might* :-) ) re-use the strategy for the final EBS round. See you in a week! -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: bharat@shadow.Eng.Sun.COM (Bharat Mediratta) Subject: 94 simulator Date: 16 May 1994 05:09:32 GMT Message-ID: <2r6v6c$og2@engnews2.Eng.Sun.COM> I've seen a few references to SNE and SEQ in the past few weeks. My mars simulator (I'm using pmars-05s) won't handle those opcodes. Is there a newer version or a version that does handle them? Thanks, -Bharat --- Bharat Mediratta | Above opinions are mine and have bharat.mediratta@eng.sun.com | nothing to do with Sun Microsystems From: kdmiller@ATHENA.MIT.EDU (Kenneth D Miller) Subject: Re: vampire ideas Date: 16 May 1994 06:02:21 GMT Message-ID: <2r729d$s1g@senator-bedfellow.MIT.EDU> In article <1994May12.171814.1@acad.drake.edu> pk6811s@acad.drake.edu writes: >Speaking of vamps, it is possible to use a fixed fang - which may find >a use in someone's program. Here's one way: [mini-vamp deleted] ;redcode ;name The Little Screw ;author kdmiller@athena.mit.edu ;strategy Probably the smallest possible scanning slaver program ptr jmp zot, 0 inc dat #3044, #-3044 s add inc, ptr jmz s, @ptr slt ptr, #10 ;keeps it from zapping itself mov ptr, @ptr jmp s zot spl 0, ptr-1 k mov ptr-1, ;redcode ;name Wuss ;author kdmiller@athena.mit.edu ;strategy About the smallest program you can write that does anything djn 0, <-1 jmp -1 And another... ;redcode ;name Shrimp ;author kdmiller@athena.mit.edu spl 2 jmp 0, <-10 mov 0, 1 Surprisingly enough, they all scored similarly. Scary, eh? -- Ken! "Evil is afoot!" "Really, that's very philosophical, Tick. A foot? I always envisioned evil as a dark, brooding shape with sqinty eyes..." From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: optima again Message-ID: <1994May16.084645.14102@news.vanderbilt.edu> Date: Mon, 16 May 1994 08:46:45 GMT In article <1994May11.210217.18015@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: >Anders Ivner writes: >>What if your bombing pattern uses alternating steps? >>[..] >>So, is it possible to modify corestep's algorithm to handle this kind >>of multiple steps? >> >>/Anders > >I have written such a "multiple constant optimizer". [ .. ] >Mail me for a copy if you want it now; I was going to add a man page and >upload it to soda some time later next week. > >-Stefan (stst@vuse.vanderbilt.edu) Now available as soda.berkeley.edu:/pub/corewar/incoming/mopt1.zip The archive contains C source, documentation and DOS executable. It was made on a UNIX machine, so source and docs contain UNIX EOLs. From mopt.doc: NAME mopt - multiple constant optimizer SYNOPSIS mopt DESCRIPTION Mopt finds "optimal" combinations of scanning or bombing constants for corewar warriors. In contrast to other popular optimizers (optima, corestep) which optimize for a single step value, mopt is useful for optimizing complex bombing/scanning patterns of stones and cmp-scanners. The program asks for coresize and up to 10 increment/offset pairs. "Increment" is the distance between two consecutive bombs/scans; "offset" is the position of the first bomb/scan relative to zero. Increments and offsets can be simply numbers or "generators" that provide a stream of numbers. If at least one generator is specified, mopt will find the 20 best combinations of increment/offset pairs, otherwise it will report the score for the specified increment/offset combination. Generators have a syntax similar to for-loops in the C language (see examples below) and use single letter variables A through Z. You don't have to use them in sequence, i.e. A for increment generator #1, B for offset generator #2 etc.. EXAMPLES 1) Suppose we have a stone: spl #A, Increment value or generator #1: a=4,a<8000,a=a+4 Offset value or generator #2: 0 Increment value or generator #2: b=1,b<8000,b=b+2 Offset value or generator #3: 2) Now a carpet-bombing cmp-scanner: sub incr,1 cmp 0,C ... incr spl #-A,<-B ... Coresize: 8000 Increment value or generator #1: a=2,a<4000,a=a+4 Offset value or generator #2: c=10,c<15,c=c+1 Increment value or generator #2: b=a Offset value or generator #3: 3) Lastly, a spl/jmp bombing cmp-scanner: sub incr,1 cmp 0,C ;C is A/2 ... incr spl #-A,<-B ... Coresize: 8000 Increment value or generator #1: a=2,a<4000,a=a+4 Offset value or generator #2: c=a/2 Increment value or generator #2: b=a Offset value or generator #3: INSTALLATION Mopt uses the pMARS expression evaluator. To compile the program, copy mopt.c into a directory containing the pMARS sources and enter something like: cc -O -o mopt mopt.c eval.o ALGORITHM Scoring is based on Nandor Sieben's iterative optima algo- rithm with two modifications: the maximum gap size is 200 instructions and early gaps weigh more than late gaps. AUTHOR Stefan Strack (stst@vuse.vanderbilt.edu) From: g93h7334@alpha.ru.ac.za (Ray Heasman) Subject: Net Core - new idea 4 your perusal Message-ID: Date: Mon, 16 May 1994 09:13:56 GMT Hi all, this is a half formed idea that I had and I thought that I should throw it at you guys to help polish it, and perhaps goad someone into making it a reality. ( I can only hope ;) I apologise if this has been suggested before, but I've never seen anything myself... Why dont we try and implement some form of networked core? We could have a network of individual core emulators, all liked through a 'core wars' only protocol. A program would be judged by the amount of nodes that it currently has control of. A warrior would try to invade other cores, and protect its own. It would be a sort of 'Worm wars'. Obviously there are several considerations to be taken into account, defining how programs would interface with a link, search for more links etc.. An attacking program always has to have a chance of success. Also, the amount of bandwidth used would have to be limited (We dont want to use 50% of Internet BW for a game :) Well? Any ideas? Maybe not so practical, but I think it could be done, with some modification... Cheers Ray csrh@cs.ru.ac.za ray@rucus.ru.ac.za From: pk6811s@acad.drake.edu Subject: Re: Imp-gates Message-ID: <1994May16.084542.1@acad.drake.edu> Date: Mon, 16 May 1994 14:45:42 GMT >>In a previous article, fullanto@cwis.isu.edu (Antonette Nixon) says: >> >>>Which is better: >>> >>> SPL 0 >>> DJN 0,<-35 >>> or just >>> JMP 0,<-35 Both are 'perfect' gates, so whichever is more convenient to squeeze into your code should be your choice. A short test with RedCoder 2 shows 44 processes at the DJN after the first 1000 game cycles and 62 after 2000, so it doesn't appear you would have enough processes to drag the game out after being dat-bombed. Anyway, most programs are timed to do their core-clears early enough to allow all your processes to die no matter how many. Having two instructions which can survive independently may be a useful feature if your opponent is not going to execute a complete core-wipe or has been crippled and can't complete one. Keystone uses the DJN version as a backup strategy in the case where its core-clear is crippled. The stone eventually drops a DJN onto itself and proceeds as a core-decrementing gate as all the processes in the loop drop into the DJN. Paul Kline pk6811s@acad.drake.edu From: pk6811s@acad.drake.edu Subject: Re: Imp-gates Message-ID: <1994May16.124401.1@acad.drake.edu> Date: Mon, 16 May 1994 18:44:01 GMT > dat #0,#-1 > dat #0,#0 > gate spl gate,<-2 > mov 1,<-3 > dat <-4,<-4 > end gate > This works as a mod 4 DAT bomber plus 100% gate, all for the cost of only > one process. (well, actually, I guess at any one time, there are three > processes running, right?) > So, the ultimate corewars question. Is this useful? :-) Not too useful as a first phase routine. Not thorough enough for a final core-wipe. However, if you had previously cleared core with SPL-1's then it could be a very fast way to kill off the opponent. Or if you were a SPL-1 carpet-bombing scanner ... Paul Kline pk6811s@acad.drake.edu From: Dave Darling Subject: Re: Rambling: a fast scanner using indirect-A Message-ID: <1994May16.212412.28179@riacs.edu> Date: Mon, 16 May 94 21:24:12 GMT In article Jay, jayhan@cs.washington.edu writes: > >Now suppose we had indirect-A addressing, denoted by ~ (tilde). >Here's a piece of code: > Hmmmm... As long as we're discussing possible additions to the 94 standard, this one might be very worthwhile. Possibly even more so than the .O modifier. Other opinions? --DD --DD 914 Addict GU d--@ -p+(p-) c+ !l(l--) u++(u--) e- m---@ s+/+ n+@ h+ f? g-(g+) w++ r++ r+@ y* HELP! I'm in TQM training, and I can't get up! From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Re: vampire ideas Message-ID: Date: 17 May 1994 09:53:36 GMT In article <2r729d$s1g@senator-bedfellow.MIT.EDU> kdmiller@ATHENA.MIT.EDU (Kenneth D Miller) writes: > From: kdmiller@ATHENA.MIT.EDU (Kenneth D Miller) > Subject: Re: vampire ideas > Date: 16 May 1994 06:02:21 PST-8 > > In article <1994May12.171814.1@acad.drake.edu> pk6811s@acad.drake.edu writes: > >Speaking of vamps, it is possible to use a fixed fang - which may find > >a use in someone's program. Here's one way: > > [mini-vamp deleted] I used this technique in my Scanalyzer-W (it was pushed off the Hill a while back). > > ;redcode > ;name The Little Screw > ;author kdmiller@athena.mit.edu > ;strategy Probably the smallest possible scanning slaver program > > ptr jmp zot, 0 > inc dat #3044, #-3044 > > s add inc, ptr > jmz s, @ptr > slt ptr, #10 ;keeps it from zapping itself > mov ptr, @ptr > jmp s > > zot spl 0, ptr-1 > k mov ptr-1, jmp zot > > end s > > It's plain-old '88 code, just as fast, and only bombs when it has to (avoiding > anti-vamp tracer-type kills). Unfortunately, it does really poorly against > "real" corewar programs (the hill). It's amazing how similar our scanners > look. It seems your pit (zot) has a problem: it doesn't self-destruct! The loop will keep pushing some random instruction (hopefully a DAT) backward, until it overwrites "k", and then you're left with a SPL that keeps generating processes for your opponent! You need to at least: - Have the pit self-destruct (by moving "k" above "zot"), or - Provide a core-clear in your program. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Rambling: someting else indirect-A would be good for Message-ID: Date: 17 May 1994 16:38:01 GMT Well, in the course of writing my final round entry to the EBS tourney, I discovered another case where indirect-A would be nice to have: the 2-pass core-clear. Basically, here's how I would do a 2-pass core-clear: a SPL #-1, <-3 b MOV.I ~2, <2 c DAT <-4, -1 d DAT -3, -3 For the first pass, the MOV.I finds d.A to point to the SPL, and does a SPL core-clear. When that SPL hits d, d.A now points to c, so we have a DAT core-clear. When the DAT hits d, d.A points to another DAT (located at a-1), but d.B = -1, so the next MOV will move the DAT to b, which means we have a perfect gate. So there you have a 2-pass coreclear ending with a perfect gate, all in 4 instructions. Also, during the coreclears, we have a partial gate. Of course, you can have a variation of this: SPL #-1, <-3 MOV.I ~2, <2 DAT <-3, <-5 DAT -3, -3 This one is an alternating SPL/DAT core-clear with a better partial gate. -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jojaste@descartes.uwaterloo.ca (James Ojaste) Subject: Re: 94 simulator Message-ID: Date: Tue, 17 May 1994 22:29:16 GMT In article <2r6v6c$og2@engnews2.Eng.Sun.COM>, bharat@shadow.Eng.Sun.COM (Bharat Mediratta) writes: > > I've seen a few references to SNE and SEQ > in the past few weeks. My mars simulator > (I'm using pmars-05s) won't handle those > opcodes. Is there a newer version or a > version that does handle them? Thanks, PMars 5 is the latest, and it should handle SEQ/SNE just fine. How are you using them? -- Y James Ojaste (jojaste@descartes.uwaterloo.ca) | ,--- |/ "I said that you couldn't be both smooth and kinky at the +-----X same time, and then somebody put up his hand and asked, .sig graph '93 'What about whipped cream, sir?'" - Prof at UW From: kdmiller@athena.mit.edu (Kenneth D Miller) Subject: Re: vampire ideas Date: 18 May 1994 14:48:35 GMT Message-ID: <2rd9s3$9kf@senator-bedfellow.MIT.EDU> In article jayhan@cs.washington.edu (Jay "Thierry" Han) writes: >It seems your pit (zot) has a problem: it doesn't self-destruct! >The loop will keep pushing some random instruction (hopefully a DAT) >backward, until it overwrites "k", and then you're left with a SPL >that keeps generating processes for your opponent! D'oh! I knew something looked wrong! Maybe that's why I lost... B^> -- Ken! "Evil is afoot!" "Really, that's very philosophical, Tick. A foot? I always envisioned evil as a dark, brooding shape with sqinty eyes..." From: pk6811s@acad.drake.edu Subject: Re: Aleph 0 [Re: A better quick-cmp] Message-ID: <1994May18.122055.1@acad.drake.edu> Date: Wed, 18 May 1994 18:20:55 GMT In article <...> jayhan@cs.washington.edu (Jay "Thierry" Han) writes: < <... most of interesting article deleted... > > Next, "x1" puts the address of the original SNE into fang.B. Line > "x2" puts the address of the final location (to be bombed) into > fang.B. Line "x3" puts fang.A and fang.B in sync. Voila, now you > only need to bomb 200 locations. There's some juggling being done, > but hey, ain't that a neat piece of code? :-) It's one of the most compact, convoluted, hard-to-understand-let-alone-explain bits of code I've seen yet (but it IS a neat piece of code). Let's see your synopsis for the FAQ :-) All this work on quick-scans has some serious implications for 'the rest of us'. Just how quickly can a q-scan start its attack on a max-length opponent? A q-scan needs only 40 instructions to spot-check 80 locations (a complete mod-100 scan). Then say 5 instructions max before dropping the first bomb. If he uses a JMN test midway through, then half the time he will be bombing you 25 cycles into the battle. Even worse if he JMN tests after 13 and 26 scans. Then 33% of the time he will start bombing after 18 cycles, and another 33% of the time after 31 cycles. Jay and Wayne could probably give us some exact numbers, but I'd say that places an upper limit on decoy/boot startup times. However, if you CAN get yourself booted away you'll gain the advantage of time wasted by the q-scanner on bombing your decoy. Even so, Aleph plays Torch very closely and Torch has a fast boot. Q-scanning also impacts boot-distance. You don't want to be booting to a location that's going to be co-bombed with your decoy. Paul Kline pk6811s@acad.drake.edu From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Aleph 0 [Re: A better quick-cmp] Date: 18 May 1994 20:25:11 GMT Message-ID: <2rdtj7$o36@agate.berkeley.edu> In article <1994May18.122055.1@acad.drake.edu>, Paul Kline wrote: >In article <...> jayhan@cs.washington.edu (Jay "Thierry" Han) writes: >> Next, "x1" puts the address of the original SNE into fang.B. Line >> "x2" puts the address of the final location (to be bombed) into >> fang.B. Line "x3" puts fang.A and fang.B in sync. Voila, now you >> only need to bomb 200 locations. There's some juggling being done, >> but hey, ain't that a neat piece of code? :-) > >It's one of the most compact, convoluted, hard-to-understand-let-alone- >explain bits of code I've seen yet (but it IS a neat piece of code). >Let's see your synopsis for the FAQ :-) Hah! Wait till you see Pyramid v5.5... it uses a slightly different improvement on Plasma-type quick-scanning, and it's even *more* convoluted and hard to understand! I'll post it soon. >Jay and Wayne could probably give us some exact numbers, but I'd say that >places an upper limit on decoy/boot startup times. However, if you CAN get >yourself booted away you'll gain the advantage of time wasted by the >q-scanner on bombing your decoy. Even so, Aleph plays Torch very closely >and Torch has a fast boot. Yeah, Pyramid plays Torch very closely too... 40/37 (for Pyramid) the last time I checked. I don't understand it though -- Pyramid is fast but it's not *that* fast. I'd be interested in seeing the source for the new Torch when it gets posted... if Pyramid really is finding a program like Torch as it's bootstrapping (and it's not just Pyramid's regular vampire beating Torch) then this will place a *severe* limit on bootstrapping times. Just for comparison, Pyramid v5.5 gets beaten by the posted version of Torch (which doesn't bootstrap) 31/43. Hmmm... Maybe quick-scanners are really getting to the point where they will find *any* bootstrapping program. If so, this will lead to a reduction in the number of bootstrapping programs, and then an increase in the number of slow-scanners (which will be able to find the programs without decoys). Maybe a quick-scanner -> slow-scanner program would work well? -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Show of hands for/against indirect addressing off A-field Message-ID: <1994May19.054516.15440@news.vanderbilt.edu> Date: Thu, 19 May 1994 05:45:16 GMT There's been some discussion recently about adding three new addressing modes to the proposed ICWS'94 standard, namely: indirect off A-field (symbol * or ~) precrement indirect off A-field (symbol {) postincrement indirect off A-field (symbol }) (the current @,<,> modes are indirect, predecrement, and postincrement off _B_-field) We from the pMARS team are ready to implement these on a trial basis if there are more people in favor than against this addition, so send a "Yes" or "No" vote by replying to this post. -Stefan (stst@vuse.vanderbilt.edu) P.S.: keep in mind that while these new modes would probably make redcode more flexible and powerful, they would also make ICWS'94 more complex and difficult to learn for the corewar neophyte. From: jsk1652@u.cc.utah.edu (Jason Kohles) Subject: newbie Date: 19 May 1994 10:06:38 -0600 Message-ID: <2rg2qe$6jm@u.cc.utah.edu> I would like to get involved in corewars, but am having trouble figuring out the commands. I have the tutorials from the soda site, but they are a little vague. If anyone has better information, or would like to E-Mail me some examples, I would appreciate it. +---------------------+----------------------------+ | Jason Kohles | Jason.Kohles@m.cc.utah.edu | +---------------------+----------------------------+ From: Dave Darling Subject: Re: Show of hands for/against indirect addressing off A-field Message-ID: <1994May19.164147.27574@riacs.edu> Date: Thu, 19 May 94 16:41:47 GMT In article <1994May19.054516.15440@news.vanderbilt.edu> Stefan Strack, stst@vuse.vanderbilt.edu writes: > indirect off A-field (symbol * or ~) > precrement indirect off A-field (symbol {) > postincrement indirect off A-field (symbol }) Sure, what the heck. --DD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dave Darling, Cockpit Graphics Programmer GU d--@ -p+(p-) c+ !l(l--) u++(u--) e- m---@ s+/+ n+@ h+ f? g-(g+) w++ t++ r+@ y* HELP! I'm in TQM training, and I can't get up! From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: EBS spring '94 tourney: and the winner is ... Message-ID: <1994May21.032733.28112@news.vanderbilt.edu> Date: Sat, 21 May 1994 03:27:33 GMT The final round of the EBS spring tourney is over. But I'll keep the suspense up and won't tell you who won until the end of this post :-) I'll spare you with my comments on this battle and let Jay and James speak for themselves by reproducing the comments in their warriors. From Jay Han's "Aleph 1": ; James currently has two programs on the Hill, ivscan6 and BigImps. ; Although my "greek letters" series clobber BigImps big time, ; they're hopeless against ivscan6. The quickscan doesn't detect ; ivscan often enough, so the stone is activated, and I'm toast. ; This is basically another stone/spiral/wimp, like Variation, but: ; - the stone ends with a 2-pass core-clear then gate ; - the spiral's head is booted off the launch code ; - there's empty space between the stone and spiral ; The 2-pass core-clear seems fatal to ivscan6, because it's a paper. ; This beats ivscan6 50/10/40 and BigImps 30/10/60. ; It also beats all the warriors on the Hill, except Pyramid. ; I give away too many ties to be #1, though (i.e. I win with scores ; like 20/10/70 or 30/20/50). But that's OK for a one-on-one fight. James Layland's "rock": ; stone with endgame like Dan Nabutovsky's (sp) Moonstone, but gateless ; (a gate with a bomber can pick up ties on the hill, but that won't ; really help here... ; I'm not real happy with my current choice of stepsize and bombing ; locations-- I decrement and bomb the same spots. ; I tried mod-3 and mod-1 steps, and didn't find anything that fit well ; with my code. ; I don't feel good about this round. I won't beat anything with imps, ; but I hope I've scared them off. ; I know that Jay has developed an ivscan6-killer (which he ; cleverly removed from the big hill before I could get a clue. ; My guess is he has some kind of anti-replicator weapon (vamp or SPL-JMP ; bomber) which fakes me into running the anti-vamp paper (and if it's ; a vamp, it's immune to my brand of anti-vamp) ; ; My problem is that Jay's ivscan6 killer also kills all the other ; programs I had on the big hill (impscanner, stone/imp, stone, paper), ; which is basically all I have. ; I'm not quite sure what could do all of that-- any kind of split ; bombs would beat paper/ivscan, and my stone isn't very optimized. ; Perhaps a quickscan (to catch the imp) followed by a spl bomber?? ; Whatever it is, I'm hoping he submits something slow and complicated ; that a simple stone can take out. (I did try adding imps to this, ; but it didn't seem to be worthwhile. Maybe the big decoy can slow ; up a quickscanner if he has one. And here the results. Ready? Aleph 1 by Jay Han scores 193 rock by James Layland scores 67 Results: 51 9 40 So, the winner of the the EBS spring '94 tourney is: ************************************* * * *-----------> Jay Han <-------------* * * ************************************* Congratulations! Jay wins a one year ICWS membership including a subscription to The Core War Newsletter. Thanks to everyone for participating. The source for all submitted warriors including the results for each round will appear tomorrow as soda.berkeley.edu:/pub/corewar/incoming/sp94warriors.zip -Stefan (stst@vuse.vanderbilt.edu) From: pk6811s@acad.drake.edu Subject: Re: vampire ideas Message-ID: <1994May21.102727.1@acad.drake.edu> Date: Sat, 21 May 1994 16:27:27 GMT Actually Ken's mini-vamp can be shortened by one line, if he is willing to accept smaller step constants. The MOV line in the pit can serve double-duty as the increment constant: MOV STEP,<-STEP And still within '88 rules. Paul Kline pk6811s@acad.drake.edu From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: The '94 Warrior Date: 21 May 1994 19:08:53 GMT Message-ID: <2rlm85$ru7@magus.cs.utah.edu> Due to time constraints, I am finding it very difficult to work on the mid-May issue of _The_'94_Warrior_. As a result of this, I have decided to publish the next issue at the start of June, and make it twice as good. Hopefully, by then, pressures at work and to finish my final project for graduation will have subsided slightly. (Judging by Request's position on the hills, I desperately need to find the time to work on it as well.) Thank you for your understanding. -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: bdthomse@peruvian.cs.utah.edu (Brant Thomsen) Subject: New '94 Instruction Possibilities Date: 21 May 1994 23:31:54 GMT Message-ID: <2rm5la$3v@magus.cs.utah.edu> What is the general consensus out there of adding a new instruction to the current '94 instruction set that will compliment DJN. The addition of such an instruction (which I will call IJZ) would, I feel, be of great assistance to programs that want to duplicate the behavior of "stacks" in there programs. If the increment were to take place _after_ the testing, (similar to ">",) then it could also be useful for A and/or B field scanners. (e.g. add.AB #step, #init ijz.F -1, @-1 ) Also, as long as I'm on the topic, what about the instructions DJZ and IJN. While I definitely favor adding IJZ (or JZI, if that's less confusing,) I'm not as certain about the other two. Please post any opinions you may have on any extensions to the '94 instruction set. You may not have many more opportunities in the future! -- Brant D. Thomsen Man will occasionally stumble over the truth, (bdthomse@peruvian.cs.utah.edu) but most times he will pick himself up University of Utah and carry on. - Winston Churchill From: fullanto@cwis.isu.edu (Antonette Nixon) Subject: Pmars Date: 22 May 1994 07:17:41 -0600 Message-ID: <2rnm1l$fnm@cwis.isu.edu> Okay... I've been playing around a little with pmars, and am starting to like it. (just a little) There are a few problems though. You see, I just downloaded the pmars051 file, and discovered that the normal graphics output is not in color. Also, it looked like graphics were being done with XOR functions. The SVGA output was fine, except... well, I'm just a little bit blind. (I hate to admit it, but I failed the eyetest when I tried to go get my license a few days ago....I passed that dang eyetest last time I got my license renewed....a few years ago) The SVGA output is so SMALL! Personally, I'd rather be able to see what's going on graphically than have lots of room for cdb output. Which brings me to another point (suggestion). Is it possible in the lower portion of the screen maybe to have two windows, one for cdb commands, and one for looking at core locations? I've discovered that's the only thing (now, after playing around with pmars) that I like better about mars88. I'm also having confusion about setting the display speed, but that's probably just a case of laziness about documents... :-) Anyway...I would like to say one thing in favor of pmars. The graphic output runs MUCH faster than mars88. (like, fast enough on my computer that I can actually watch a round all the way through...EVEN if it's a TIE!!) :-) (slow computer...) From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: Show of hands for/against indirect addressing off A-field Message-ID: Date: Sun, 22 May 1994 12:50:36 GMT In article <1994May19.054516.15440@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: There's been some discussion recently about adding three new addressing modes to the proposed ICWS'94 standard, namely: indirect off A-field (symbol * or ~) precrement indirect off A-field (symbol {) postincrement indirect off A-field (symbol }) (the current @,<,> modes are indirect, predecrement, and postincrement off _B_-field) We from the pMARS team are ready to implement these on a trial basis if there are more people in favor than against this addition, so send a "Yes" or "No" vote by replying to this post. -Stefan (stst@vuse.vanderbilt.edu) P.S.: keep in mind that while these new modes would probably make redcode more flexible and powerful, they would also make ICWS'94 more complex and difficult to learn for the corewar neophyte. Does that mean it will become part of the proposed '94 standard? Instead of sneaking in one little addition at a time, why don't we make a second '94 proposal, with every extension we can think of? And then, after 'sufficient testing', we make a large poll to evaluate the different feaures. Other possible extensions: preincremental/postdecremental mode IJZ, IJN, DJZ and JZD, JND, JZI, JNI (post/pre-decr/incr) modifier to mov/cmp modifiers and addressing modes. SLE, SGT, SGE (Skip if Less or Equal/Greater Than/Greater or Equal) And, no, I'm not joking this time. If we're to extend the standard, we might as well do it thoroughly. Anders From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Show of hands for/against indirect addressing off A-field Message-ID: <1994May22.193411.22984@news.vanderbilt.edu> Date: Sun, 22 May 1994 19:34:11 GMT In article d91andiv@IDA.LiU.SE (Anders Ivner) writes: >Instead of sneaking in one little addition at a time, why don't we >make a second '94 proposal, with every extension we can think of? >And then, after 'sufficient testing', we make a large poll to >evaluate the different feaures. > I'll tell you why "we" don't: updating the draft and pMARS with every new opcode and addressing mode imaginable is a lot of work (and may not even be within the limits of the current implementation). I think it's only fair to ask you to discuss first what is sensible and useful. This discussion has taken place with SNE, NOP and now with *, { and }, and that's why the pMARS team has implemented them. Mind you, we're not payed for this. -Stefan (stst@vuse.vanderbilt.edu) From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Pmars Message-ID: <1994May22.201425.23388@news.vanderbilt.edu> Date: Sun, 22 May 1994 20:14:25 GMT In article <2rnm1l$fnm@cwis.isu.edu> fullanto@cwis.isu.edu (Antonette Nixon) writes: >Okay... I've been playing around a little with pmars, and am starting to >like it. (just a little) Glad you do :-) > There are a few problems though. > You see, I just downloaded the pmars051 file, and discovered that the >normal graphics output is not in color. This is odd. Even the character based textmode display should show up in color. What brand of VGA card do you have? > Also, it looked like graphics were being done with XOR functions. [..] No XOR functions anywhere. In fact the VGA and SVGA modes are identical except there's more room for the debugger at higher resolutions. > The SVGA output is so SMALL! Personally, I'd rather be able to see >what's going on graphically than have lots of room for cdb output. Try graphics mode "4" (-v 43). This lowers the resolution almost down to CGA and gives you very large pixels. >brings me to another point (suggestion). Is it possible in the lower >portion of the screen maybe to have two windows, one for cdb commands, >and one for looking at core locations? That's implemented. Press or "switch" and you divide the cdb display into two independently scrollable panels. You can use either one or both for cdb commands and looking at core addresses. E.g. if you want a mouse click to always display core on the right panel, edit the macro "mousel" (or mousem, or mouser = left, middle, right button) in "pmars.mac" to: mousel= switch 2~list .,LINES-4~switch 1 >I'm also having confusion about setting the display speed, but that's >probably just a case of laziness about documents... :-) Yes, reading the manual might help. -Stefan (stst@vuse.vanderbilt.edu) From: d91andiv@IDA.LiU.SE (Anders Ivner) Subject: Re: Show of hands for/against indirect addressing off A-field Message-ID: Date: Sun, 22 May 1994 22:25:04 GMT In article <1994May22.193411.22984@news.vanderbilt.edu> stst@vuse.vanderbilt.edu (Stefan Strack) writes: In article d91andiv@IDA.LiU.SE (Anders Ivner) writes: >Instead of sneaking in one little addition at a time, why don't we >make a second '94 proposal, with every extension we can think of? >And then, after 'sufficient testing', we make a large poll to >evaluate the different feaures. > I'll tell you why "we" don't: updating the draft and pMARS with every new opcode and addressing mode imaginable is a lot of work (and may not even be within the limits of the current implementation). I think it's only fair to ask you to discuss first what is sensible and useful. This discussion has taken place with SNE, NOP and now with *, { and }, and that's why the pMARS team has implemented them. Mind you, we're not payed for this. -Stefan (stst@vuse.vanderbilt.edu) Point taken. But I still think there's a problem with the current process of extending the standard. Someone says 'Hey, this new instruction/modifier/addressing mode would be neat.' After a while people conclude that, what the heck, there's no harm in trying it out. People can make more efficient programs. At this point, who's going to reject the new whatever? Either A. It is useless. But then, what's the harm in keeping it? B. It is useful at times. People get used to it, and noone wants to lose an interesting tool. C. It enables a new strategy to form. Several programs on the hill use it, and everyone has to take it into consideration when making programs. If it is banned, a lot of code is suddenly made useless. And, no, I _don't_ think there's anything wrong with trying out new things, but as it is now, trying something seems to be equivalent to adding it to the '94 standard. Anders From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Show of hands for/against indirect addressing off A-field Message-ID: <1994May23.062110.461@news.vanderbilt.edu> Date: Mon, 23 May 1994 06:21:10 GMT In article d91andiv@IDA.LiU.SE (Anders Ivner) writes: >Point taken. But I still think there's a problem with the current process >of extending the standard. > My point is: the current standard still is ICWS'88. And it will be until the ICWS'94 _draft_ is formally approved. Only because an opcode/modifier/ addressing mode is mentioned in icws94.0202 or implemented in pMARS doesn't make it part of any standard yet. So, by adding new features to pMARS, we are not _extending_ the standard, we are merely supplying the tool for you to find out whether it's worth including them in the proposal. Let's take MUL and DIV for example, currently in icws94.0202. I have yet to see a single warrior on the '94 hills that uses them. Chances are we'll drop them unless someone finds a use for them. Then we have SNE, currently not part of icws94.0202 but supported by pMARS. SEQ(CMP)/SNE forms the basis of a very successul quick-scanning class of warriors that keep slow-booting imp-spirals in check, which makes SNE worth including in the proposal. ICWS'94 is still evolving. All I am asking is that we discuss first whether a new addition has the potential of enriching the game before we implement it in pMARS (and fire up the text editor to add it to icws94.0202). >At this point, who's going to reject the new whatever? Either >A. It is useless. But then, what's the harm in keeping it? Useless features make simulators bigger and slower, and add complexity that might deter newbies from learning redcode. -Stefan (stst@vuse.vanderbilt.edu) From: jlayland@kilroy.jpl.nasa.gov (James Layland) Subject: Re: EBS spring '94 tourney: and the winner is ... Date: 23 May 1994 16:17:07 GMT Message-ID: <2rqku3$j5i@elroy.jpl.nasa.gov> In article <1994May21.032733.28112@news.vanderbilt.edu>, Stefan Strack wrote: > >The final round of the EBS spring tourney is over. But I'll keep the >suspense up and won't tell you who won until the end of this post :-) >From Jay Han's "Aleph 1": > ; James currently has two programs on the Hill, ivscan6 and BigImps. > ; Although my "greek letters" series clobber BigImps big time, > ; they're hopeless against ivscan6. The quickscan doesn't detect > ; ivscan often enough, so the stone is activated, and I'm toast. > > ; This is basically another stone/spiral/wimp, like Variation, but: > ; - the stone ends with a 2-pass core-clear then gate > ; - the spiral's head is booted off the launch code > ; - there's empty space between the stone and spiral > > ; The 2-pass core-clear seems fatal to ivscan6, because it's a paper. > > ; This beats ivscan6 50/10/40 and BigImps 30/10/60. > ; It also beats all the warriors on the Hill, except Pyramid. > ; I give away too many ties to be #1, though (i.e. I win with scores %!%!^@!^?* Y^Hiya I'm new to corewars & assembly programming. I've read the FAQ and the tutorials on soda (didn't understand them completely, but I did RTFM). My question is how to stop an IMP. If you have a program tossing out DAT bombs (like Dwarf), the IMP just overwrites the bomb and continues to execute. So how does one kill an Imp? Confused, but learning, Dave Magnenat scorpion@connected.com From: jojaste@descartes.uwaterloo.ca (James Ojaste) Subject: Re: New '94 Instruction Possibilities Message-ID: Date: Mon, 23 May 1994 20:37:08 GMT In article <2rm5la$3v@magus.cs.utah.edu>, bdthomse@peruvian.cs.utah.edu (Brant Thomsen) writes: > What is the general consensus out there of adding a new instruction > to the current '94 instruction set that will compliment DJN. Sounds good to me - I'd like a more flexible language, and there's no reason why certain instructions should be penalized for simplicity. > Please post any opinions you may have on any extensions to the '94 instruction > set. You may not have many more opportunities in the future! Well, it's a minor thing, but I'd like to see both pre AND post dec/increment indirect... The problem is you'd need 2 chars to represent it (like <@, @<, <~, ~< etc.), and it might complicate things too much... -- Y James Ojaste (jojaste@descartes.uwaterloo.ca) | ,--- |/ "I said that you couldn't be both smooth and kinky at the +-----X same time, and then somebody put up his hand and asked, .sig graph '93 'What about whipped cream, sir?'" - Prof at UW From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Show of hands for/against indirect addressing off A-field Date: 23 May 1994 22:22:11 GMT Message-ID: <2rraaj$ksk@agate.berkeley.edu> Stefan Strack wrote: > d91andiv@IDA.LiU.SE (Anders Ivner) writes: > >Point taken. But I still think there's a problem with the current process > >of extending the standard. > > My point is: the current standard still is ICWS'88. And it will be until > the ICWS'94 _draft_ is formally approved. Only because an opcode/modifier/ > addressing mode is mentioned in icws94.0202 or implemented in pMARS doesn't > make it part of any standard yet. So, by adding new features to pMARS, we > are not _extending_ the standard, we are merely supplying the tool for > you to find out whether it's worth including them in the proposal. I agree with Stefan. I am all for adding new features to the '94 draft -- but I think we should discuss each proposed feature thoroughly before trying to add it to the draft (or the simulator!). For example, I think that the .O discussion was fruitful in that we found several problems with including a .O modifier in the draft, *before* we went to the trouble of modifying the draft, and *before* we asked the pmars team to modify the simulator (and I may be wrong, but I think extensive changes would have been necessary). That discussion saved a lot of work, and I think we should do the same for each proposed addition to the '94 draft. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: New '94 Instruction Possibilities Date: 23 May 1994 22:37:45 GMT Message-ID: <2rrb7p$l4k@agate.berkeley.edu> James Ojaste wrote: > Well, it's a minor thing, but I'd like to see both pre AND post dec/increment > indirect... The problem is you'd need 2 chars to represent it (like <@, @<, > <~, ~< etc.), and it might complicate things too much... Here's one extension I *don't* like. I like the difference between < and >, because it makes them useful for different things. If we had all 4 possible modifiers, then there would be no difference between, say, a forward coreclear and a backward coreclear, except for direction. I like the fact that you have to initialize a forward DJN-stream or forward coreclear, because it keeps the forward motion as something special. Besides, the two-character addressing is pretty scary... :-) -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Help the idiot, please! Date: 24 May 1994 16:17:44 GMT Message-ID: <2rt9b8$4ul@agate.berkeley.edu> David E. Magnenat wrote: >My question is how to stop an IMP. If you have a program tossing out >DAT bombs (like Dwarf), the IMP just overwrites the bomb and continues >to execute. So how does one kill an Imp? By repeatedly bombing (or even decrementing) the same instruction. The only way to kill an imp is to hit its instruction just before it executes, and this is very hard for a bomber. However, if you pick a location right behind your program and repeatedly bomb that location, you will kill the imp as it tries to pass. For example, this 1-line program called a "gate" will always defeat an imp (or even an imp-spiral): JMP 0, <-20 To learn more about imps and imp-spirals, you should read Steven Morrell's "chapter1.Z" on soda.berkeley.edu, in /pub/corewar/incoming/. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: scorpion@hebron.connected.com (David E. Magnenat) Subject: Help the idiot, please! Date: 24 May 1994 20:31:56 -0700 Message-ID: <2rugrc$5kn@hebron.connected.com> Thanks very much....I'm getting it, albeit slowly. I just got Mr. Morrell's tutorial in email today so I'll be studying that carefully. I look forward to someday actually writing a program that DOES something!! Dave Magnenat scorpion@connected.com From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 25 May 1994 02:17:20 GMT Message-ID: Archive-name: games/corewar-faq Last-modified: 1994/04/11 Version: 2.2.1 These are the Frequently Asked Questions (and answers) from the USENET newsgroup rec.games.corewar. This FAQ list is also available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z. TABLE OF CONTENTS Line ------------------------------------------------------------------------ 1. What is Core War? 69 2. Is it Core War or Core Wars? 82 3. Where can I find more information about Core War? 90 4. Core War has changed since Dewdney's articles. Where do I get 108 a copy of the current instruction set? 5. What is this ICWS'94? 126 6. What is the ICWS? 143 7. What is TCWN? 153 8. How do I join? 161 9. Are back issues of TCWNs available? 178 10. What is the EBS? 185 11. Where are the Core War archives? 201 12. Where can I find a Core War system for . . . ? 219 13. I do not have ftp. How do I get all of this great stuff? 268 14. I do not have access to Usenet. How do I post and receive news? 275 15. When is the next tournament? 293 16. What is KotH? How do I enter? 304 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 466 18. How does SLT (Skip if Less Than) work? 478 19. What does (expression or term of your choice) mean? 490 20. Other questions? 633 --------------------------------------------------------------------- Q 1: What is Core War? A 1: Core War is a game played by two or more programs (and vicariously by their authors) written in an assembly language called Redcode and run in a virtual computer called MARS (for Memory Array Redcode Simulator). The object of the game is to cause all of the opposing programs to terminate, leaving your program in sole posession of the machine. There are Core War systems available for most computer platforms. Redcode has been standardized by the ICWS, and is therefore transportable between all standard Core War systems. ---------------------------------------------------------------------- Q 2: Is it "Core War" or "Core Wars"? A 2: Both terms are used. Early references were to Core War. Later references seem to use Core Wars. I prefer "Core War" to refer to the game in general, "core wars" to refer to more than one specific battle. ---------------------------------------------------------------------- Q 3: Where can I find more information about Core War? A 3: Core War was first described in the "Core War Guidelines" of March, 1984 by D. G. Jones and A. K. Dewdney of the Department of Computer Science at The University of Western Ontario (Canada). Dewdney wrote several "Computer Recreations" articles in "Scientific American" which discussed Core War, starting with the May 1984 article. Those articles are contained in an anthology: Author: Dewdney, A. K. Title: The Armchair Universe: An Exploration of Computer Worlds Published: New York: W. H. Freeman (c) 1988 ISBN: 0-7167-1939-8 Library of Congress Call Number: QA76.6 .D517 1988 The Redcode language has changed somewhat since; see Q 4. --------------------------------------------------------------------- Q 4: Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A 4: A draft of the official standard (ICWS'88) is available by anonymous FTP from the Core War archives (soda.berkeley.edu) as pub/corewar/documents/standards/redcode-icws-88.Z This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at pub/corewar/documents/tutorial.1.Z tutorial.2.Z (See also Q11) Steven Morrell (morrell@math.utah.edu) is preparing a more pratically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. --------------------------------------------------------------------- Q 5: What is this ICWS'94? A 5: There is an ongoing discussion about future enhancements to the Redcode language. A proposed new standard, dubbed ICWS'94, is currently being evaluated. A major change is the addition of "instruction modifiers" that allow instructions to modify A-field, B-field or both. Also new is a post-increment indirect addressing mode and unrestricted opcode and addressing mode combination ("no illegal instructions"). ICWS'94 is backwards compatible; i.e. ICWS'88 warriors will run correctly on an ICWS'94 system. Take a look at the ICWS'94 draft for more information (soda.berkeley.edu pub/corewar/documents/icws94.0202.Z). You can try out the new standard by submitting warriors to the '94 hills of the KotH servers (see Q16). Two corewar systems currently support ICWS'94, pMARS (various platforms) and Redcoder (Mac), both available at soda (see Q12). --------------------------------------------------------------------- Q 6: What is the ICWS? A 6: About one year after Core War first appeared in Sci-Am, the "International Core War Society" (ICWS) was established. Since that time, the ICWS has been responsible for the creation and maintenance of Core War standards and the running of Core War tournaments. There have been six annual tournaments and two standards (ICWS'86 and ICWS'88). --------------------------------------------------------------------- Q 7: What is TCWN? A 7: Since March of 1987, "The Core War Newsletter" (TCWN) has been the official newsletter of the ICWS. It is published quarterly and recent issues are also available as Encapsulated PostScript on soda.berkeley.edu (see Q9). --------------------------------------------------------------------- Q 8: How do I join? A 8: For more information about joining the ICWS (which includes a subscription to TCWN), or to contribute an article, review, cartoon, letter, joke, rumor, etc. to TCWN, please contact: Jon Newman 13824 NE 87th Street Redmond, WA 98052-1959 email: jonn@microsoft.com (Note: Microsoft has NO affiliation with Core War. Jon Newman just happens to work there, and we want to keep it that way!) Current annual dues are $15.00 in US currency. ---------------------------------------------------------------------- Q 9: Are back issues of TCWN available? A 9: Recent issues can be found on soda.berkeley.edu (see Q11). Older issues (up to Winter 1991) are also available (see the next TCWN for details). --------------------------------------------------------------------- Q10: What is the EBS? A10: The Electronic Branch Section (EBS) of the ICWS is a group of Core War enthusiasts with access to electronic mail. There are no fees associated with being a member of the EBS, and members do reap some of the benefits of full ICWS membership without the expense. For instance, the ten best warriors submitted to the EBS tournament are entered into the annual ICWS tournament. All EBS business is conducted in the rec.games.corewar newsgroup. The current goal of the EBS is to be at the forefront of Core War by writing and implementing new standards and test suites in preparation for the tenth anniversary of Core War in May of 1994 (see Q 5). Its immediate business will be to set up a Charter and establish its officers. ---------------------------------------------------------------------- Q11: Where is the Core War archive? A11: Many documents such as the guidelines and the ICWS standards along with previous tournament Redcode entries and complete Core War systems are available via anonymous ftp from soda.berkeley.edu (128.32.149.19) in the /pub/corewar directories. Also, most of past rec.games.corewar postings (including Redcode source listings) are archived there. Jon Blow (blojo@soda.berkeley.edu) is the archive administrator. When uploading to /pub/corewar/incoming, ask Jon to move your upload to the appropriate directory and announce it on the net. Much of what is available on soda is also available on the German archive at iraun1.ira.uka.de (129.13.10.90) in the /pub/X11/corewars directory. This FAQ is automatically archived by news.answers. See the header for the current archive name and news.answers for how to get it. ---------------------------------------------------------------------- Q12: Where can I find a Core War system for . . . ? A12: Core War systems are available via anonymous ftp from soda.berkeley.edu in the pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. CAUTION! There are many, many Core War systems available which are NOT ICWS'88 (or even ICWS'86) compatible available at various archive sites other than soda.berkeley.edu. Generally, the older the program - the less likely it will be ICWS compatible. Reviews of Core War systems would be greatly appreciated in the newsgroup and in the newsletter. Below is a not necessarily complete or up-to-date list of what's available at soda: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-20.hqx - corewar for the Mac, supports ICWS'88 and '94 core-11.hqx - corewar for the Mac core-wars-simulator.hqx - same as core-11.hqx? corewar_unix_x11.tar.Z - corewar for UNIX/X-windows, ICWS'86 but not ICWS'88 compatible koth31.tar.Z - corewar for UNIX/X-windows. This program ran the former KotH server at intel.com koth.shar.Z - older version kothpc.zip - port of older version of KotH to the PC deluxe20c.tar.Z - corewar for UNIX (broken X-windows or curses) and PC mars.tar.Z - corewar for UNIX, likely not ICWS'88 compatible icons.zip - corewar icons for MS-Windows macrored.zip - a redcode macro-preprocessor (PC) c88v49.zip - PC corewar, textmode display mars88.zip - PC corewar, graphics mode display corwp302.zip - PC corewar, textmode display, slowish mercury2.zip - PC corewar written in assembly, fast! mtourn11.zip - tournament scheduler for mercury (req. 4DOS) pmars05s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars05s.tar.Z - same as above pmars05.zip - 16-bit PC executables, graphics display version pmars05g.zip - 32-bit PC execs (djgpp, large core) macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincore.zip - MS-Windows system, shareware ($35) ---------------------------------------------------------------------- Q13: I do not have ftp. How do I get all of this great stuff? A13: There is an ftp email server at ftpmail@decwrl.dec.com. Send email with a subject and body text of "help" (without the quotes) for more information on its usage. ---------------------------------------------------------------------- Q14: I do not have access to Usenet. How do I post and receive news? A14: To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com ListProcessor. To join, send: SUB COREWAR-L FirstName LastName to: LISTPROC@STORMKING.COM You can send mail to corewar-l@stormking.com to post even if you are not a member of the list. Responsible for the listserver is Scott J. Ellentuch (tuc@stormking.com). Another server that allows you to post (but not receive) articles is available. Email your post to rec-games-corewar@cs.utexas.edu and it will be automatically posted for you. ---------------------------------------------------------------------- Q15: When is the next tournament? A15: The ICWS holds an annual tournament. Traditionally, the deadline for entering is the 15th of December. The EBS usually holds a preliminary tournament around the 15th of November and sends the top finishers on to the ICWS tournament. Informal double-elimination tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. ---------------------------------------------------------------------- Q16: What is KotH? How do I enter? A16: King Of The Hill (KotH) is an ongoing Core War tournament available to anyone with email. You enter by submitting via email a Redcode program with special comment lines. You will receive a reply indicating how well your program did against the current top twenty programs "on the hill". Your program will play 100 battles against each of the 20 other programs currently on the Hill. You receive 3 points for each win and 1 point for each tie. (The existing programs do not replay each other, but their previous battles are recalled.) All scores are updated to reflect your battles and all 21 programs are ranked from high to low. If you are number 21 you are pushed off the Hill, if you are higher than 21 someone else is pushed off. The original KotH was developed and run by William Shubert at Intel, and discontinued after almost three years of service. Currently, KotHs based on Bill's UNIX scripts but offering a wider variety of hills are are running at two sites: "koth@stormking.com" is maintained by Scott J. Ellentuch (tuc@stormking.com) and "pizza@ecst.csuchico.edu" by Thomas H. Davies (sd@ecst.csuchico.edu). Both KotHs provide very similar services and are therefore covered together. The principal difference is that "pizza" has a much faster internet connection than "stormking". Entry rules for King of the Hill Corewar: 1) Write a corewar program. KotH is fully ICWS '88 compatible, EXCEPT that a comma (",") is required between two arguments. 2) Put the line ";redcode" at the top of your program. This MUST be the first line. Anything before it will be lost. If you wish to receive mail on every new entrant, use ";redcode verbose". Otherwise you will only receive mail if a challenger makes it onto the hill. Use ";redcode quiet" if you wish to receive mail only when you get shoved off the hill. (Also, see 5 below). Additionally, adding ";name " and ";author " will be helpful in the performance reports. Do NOT have a line beginning with ";address" in your code; this will confuse the mail daemon and you won't get mail back. In addition, it would be nice if you have lines beginning with ";strategy" that describe the algorithm you use. There are currently six separate hills you can select by starting your program with ;redcode, ;redcode-x, ;redcode-icws, ;redcode-b, ;redcode-94, or ;redcode-94x. More information on these hills is listed below. 3) Mail this file to "koth@stormking.com" or "pizza@ecst.csuchico.edu". "Pizza" requires a subject of "koth" (use the -s flag on most mailers). 4) Within a few minutes (or the next day for "stormking") you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so (or the next day for "stormking") you should get more mail telling you how your program performed against the current top 20 programs. If no news arrives during that time, 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. SAMPLE ENTRY: ;redcode ;name Dwarf ;author A. K. Dewdney ;strategy Throw DAT bombs around memory, hitting every 4th memory cell. ;strategy This program was presented in the first Corewar article. bomb DAT #0 dwarf ADD #4, bomb MOV bomb, @bomb JMP dwarf END dwarf ; Programs start at the first line unless ; an "END start" pseudo-op appears to indicate ; the first logical instruction. Also, nothing ; after the END instruction will be assembled. Here are the Specs for the various hills: ICWS'88 Standard Hill Specs: (Accessed with ";redcode", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '88 ICWS Annual Tournament Hill Specs: (Accessed with ";redcode-icws", available at "stormking" only) coresize: 8192 instructions max. processes: 8000 per program duration: After 100,000 cycles, a tie is declared. max. entry length: 300 minimum distance: 300 instruction set: ICWS '88 ICWS'88 Experimental (Small) Hill Specs: (Accessed with ";redcode-x", available at "pizza" only) coresize: 4096 max. processes: 32 duration: after 65,536 cycles, a tie is declared. max. entry length: 64 minimum distance: 64 instruction set: ICWS '88 ICWS'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "stormking" and "pizza") coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza" only) coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: ICWS '94 Draft ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "stormking" and "pizza") coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: ICWS '94 Draft If you just want to get a status report without actually challenging the hills, send email with ";status" as the message body (and don't forget "Subject: koth" for "pizza"). If you send mail to "pizza" with "Subject: koth help" you will receive instructions that may be more up to date than those contained in this document. All hills run portable MARS (pMARS) version 0.5, a platform-independent corewar system available at soda (see Q12). The '94 and '94x hills allow three experimental opcodes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) ---------------------------------------------------------------------- Q17: Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? A17: Core is initialized to DAT 0, 0. This is an "illegal" instruction under ICWS'88 rules and strictly compliant assemblers (such as KotH or pmars -8) will not let you write a DAT 0, 0 instruction - only DAT #0, #0. So this begs the question, how to compare something to see if it is empty core. The answer is, most likely the instruction before your first instruction and the instruction after your last instruction are both DAT 0, 0. You can use them, or any other likely unmodified instructions, for comparison. Note that under ICWS'94, DAT 0, 0 is a legal instruction. ---------------------------------------------------------------------- Q18: How does SLT (Skip if Less Than) work? A18: SLT gives some people trouble because of the way modular arithmetic works. It is important to note that all negative numbers are converted to positive numbers before a battles begins. Example: (-1) becomes (M - 1) where M is the memory size. Once you realize that all numbers are treated as positive, it is clear what is meant by "less than". It should also be clear that no number is less than zero. ---------------------------------------------------------------------- Q19: What does (expression or term of your choice) mean? A19: Here is a selected glossary of terms. If you have a definition and/or term you wish to see here, please send it to me. (References to an X-like program mean that the term X is derived from the specific program X and has become a generic term). Bootstrapping - Strategy of copying the active portion of the program away from the initial location, leaving a decoy behind and making the relocated program as small as possible. B-Scanners - Scanners which only recognize non-zero B-fields. example add #10,scan scan jmz example,10 C - Measure of speed, equal to one location per cycle. Speed of light. CMP-Scanner - A Scanner which uses a CMP instruction to look for opponents. example add step,scan scan cmp 10,30 jmp attack jmp example step dat #20,#20 Color - Property of bombs making them visible to scanners, causing them to attack useless locations, thus slowing them down. example dat #100 Core-Clear - code that sequentially overwrites core with DAT instructions; usually the last part of a program. Decoys - Bogus or unused instructions meant to slow down Scanners. Typically, DATs with non-zero B-fields. DJN-Stream (also DJN-Train) - Using a DJN command to rapidly decrement core locations. example . . . . . . djn example,<4000 Dwarf - the prototypical small bomber. Gate-busting - (also gate-crashing) technique to "interweave" a decrement-resistant imp-spiral (e.g. MOV 0, 2668) with a standard one to overrun imp-gates. Hybrids - warriors that combine two or more of the basic strategies, either in sequence (e.g. stone->paper) or in parallel (e.g. imp/stone). Imp - Program which only uses the MOV instruction. example MOV 0, 1 or example MOV 0, 2 MOV 0, 2 Imp-Gate - A location in core which is bombed or decremented continuously so that an Imp can not pass. Also used to describe the program-code which maintains the gate. example ... ... SPL 0, Could someone please uncompress the tutorials and send them to my mailbox? I am on an DOS-based machine and the .Z file format is a UNIX uncompress. Thanks. :) :) :) From: fd () Subject: Question about Mac Redcoder 2.0 Date: Wed, 25 May 1994 17:01:42 +0000 Message-ID: Redcoder 2.0 gives me compiler errors unless the two operands are separated by commas. I've got a zillion redcode programs, but in accordance with 88 standards, none of them have commas b/w operands. Is this just tough luck or am I doing something wrong? The About Redcoder 2.0 file says commas are optional-- but I keep getting errors. Any ideas? thanks, usman From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Question about Mac Redcoder 2.0 Date: 26 May 1994 01:05:23 GMT Message-ID: <2s0skj$27t@agate.berkeley.edu> In article , wrote: > Redcoder 2.0 gives me compiler errors unless the two operands are > separated by commas. I've got a zillion redcode programs, but in > accordance with 88 standards, none of them have commas b/w operands. I haven't used Redcoder much, but I would say that chances are you'll have to convert them all to use commas. For one thing, KotH requires commas in programs you submit, so you should probably use commas anyway. You could make the conversion process much easier by uploading all your programs to your local Unix machine and running them through an appropriate awk program. (I could probably write it for you if you want.) BTW, your address seems to have been mangled by the news-poster... all I got was "fd" -- no machine name, etc. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Rambling: imp with MOV 0 or MOV #0 Message-ID: Date: 26 May 1994 09:56:59 GMT I have to admit, my final round entry to the tourney included some amount of abfuscation... Anyway, here's why I decided to change my MOV #0 imps to MOV 0. The advantage of MOV #0 are: - It's more durable: a decrement of A-field doesn't harm the imp - It's more versatile: you can put stuff in the A-field - It's more confusing: A-field has non-zero, which fools some scanners. It turns out there aren't any A-field-only gating warriors, because that would be useless against MOV #0 style imps. So if you want to gate, you either B-decrement, of F-decrement. In both cases MOV #0 is just as vulnerable than a MOV 0. What happened was that: - I didn't need that A-field - I couldn't think of a good reason to put a non-zero A-field So I decided to confuse MOV #0 scanners by reverting to MOV 0. I didn't even realize ivscan "cheated" like James said. I though it did test both cases... -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: EBS Spring tourney conclusion Message-ID: Date: 26 May 1994 10:07:12 GMT You didn't want a speech, but you'll get it anyway :-) I'm really happy! :-) First of all, thanks to Stefan for organizing the whole thing! Second, a word to all the beginners out there. Participate! This was the first time I entered an EBS tourney. It's a lot of fun! The double-elimination system insures that you get to fight at least twice. But since it's an elimination-tournament, the motivation is greater to put out your best possible warrior. Also, having to understand your opponents' past warriors is very educational. Participating to the newsgroup is easy: rec.games.corewar is by far the friendliest and most helpful and polite newsgroup I know. The worst that can happen here is that people like me go rambling on and on... :-) Tackling the Hill is next. Remember that nobody will blame you for submitting a weak warrior. It only increases the challenge-count of the warriors that are already there. And if you're really too shy, there's the Beginner's Hill. Once you've had a program on the Hill, entering an EBS tourney comes next. It's fun, and I definitely will participate in future tourneys whenever I can! -=<| Jay "Thierry" Han |>=- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Aleph 0 Message-ID: Date: 26 May 1994 10:29:11 GMT So here's some comments on Aleph 0, my round 4 entry. As I said, it's a SNE/SEQ quickscan vampire, followed by either a core-clear (if something is found) or a stone/spiral. Note that this is *not* the exact code of the Aleph 0 that's sitting on the Hill. ;redcode-94 ;name Aleph 0 ;author Jay Han ;macro org entry ; These are the parameters for the quick-scan. The quick-scan scans ; every q locations by groups of 4 (SNE/SEQ). With this setup, q is ; 86. j equ 6 n equ 22 s equ (((CORESIZE-(2*MINDISTANCE)-MAXLENGTH)*4)/((4*n)+1)) q equ (s/4) h equ (q/2) a equ (head-MINDISTANCE) l equ ((2*q)+MAXLENGTH) k equ (l/j+1) d equ 1000 head ; Here's the code for testing where in the group of four locations ; the enemy lies. test seq.i @-1, @0 add.ab #2*q, @-1 add.b test, bite add.b @test, bite ; At this point, bite.B points to the start of the bombing zone. ; First, transport the pit there mov.i pit, >bite mov.i mega, >bite ; Then vampirize, moving backward stun mov.i bite, @bite add.f vamp, bite djn.b stun, #k ; Now copy the core-clear to the end of the bombing zone copy mov.i >ptr1, -1 ; This is for the imp-launch adder add.a #step, jumper ; This is my own core-clear/gate, reversed for technical reasons ; (namely, have the DAT to kill off imp-launch processes above) bomb dat.f <-j-2, <-j-1 jmp.b -1, <-j-2 mov.i 2, <-j+1 vamp spl.b #j, <-j ; This is the fang bite jmp.b -2, #test ; Stone, if nothing is found, this is activated. ; It's a self-destructing stone p2 equ -73+(972*s2) s2 equ -74 p1 equ 75+(972*s1) s1 equ 74 cast mov.i =- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: jayhan@cs.washington.edu (Jay "Thierry" Han) Subject: Aleph 1 Message-ID: Date: 26 May 1994 10:37:03 GMT Here are some comments on Aleph 1, which is really another Variation. ;redcode-94x ;name Aleph 1 ;author Jay Han ;macro org entry ; Avoid quickscanners for 15 dat.f 0, 0 rof ; Modified constants: more thorough bombing (Mod-2) p1 equ 8751 s1 equ 17498 p2 equ 46693 s2 equ -17498 gate equ inc-28 offset equ inc-18 ; This stone ends with a two-pass (SPL/DAT) core-clear and gate inc dat.f s1, s2 top dat.f 0, patch+1 ; pointer loop add.f inc, cast stone spl.b loop, =- e-mail: jayhan@cs.washington.edu Dept. of Computer Science and Engineering, FR-35. Fax: (206)543-2969 U. of Washington. Seattle, WA 98195, USA. [Sieg 230] (206)685-1224 Personal: 4820 Burke Ave N. Seattle, WA 98103, USA. (206)547-8559 From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Tutorials at soda Message-ID: <1994May26.183918.20877@news.vanderbilt.edu> Date: Thu, 26 May 1994 18:39:18 GMT In article <2s0220$mpn@omnifest.uwm.edu> ratzburg@omnifest.uwm.edu (Linda Ratzburg) writes: > Could someone please uncompress the tutorials and send them to my >mailbox? I am on an DOS-based machine and the .Z file format is a UNIX >uncompress. >Thanks. :) :) :) Most UNIX utilities have been ported to DOS (including tar and compress): oak.oakland.edu: Directory SimTel/msdos/compress/ Filename Type Length Date Description ============================================== comp430d.zip B 20241 901013 Unix-compatible 16bit compress/uncompress/zcat decomp2.zip B 17384 900430 Unix-compatible 16 bit uncompress, w/C source gzip124.zip B 116919 930915 GNUzip: Unix compress/uncompress replacement -Stefan (stst@vuse.vanderbilt.edu) From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Test Stability Date: 26 May 1994 19:42:38 GMT Message-ID: <2s2u3e$fnn@agate.berkeley.edu> Michael Roca wrote: >Now, I want to get the battles finished as quickly as possible, but I need >enough rounds to smooth out randomness in the results. Has anybody tried >figuring out how few rounds you can get away with? Clearly trying all >possible starting positions (~7700 in the small core, I think) is >impractical. I know tournaments and koth use 100 rounds. Was this number >just picked from the air? I don't know how the mathematics work... all I can say is that I use 30 rounds for preliminary testing, and after that I usually just submit it to the hill. 30 rounds will tell you if your program is much better than, about the same as, or much worse than the other program; I find that this is usually enough when I'm just testing a program. As far as I know, 100 rounds for koth was just picked because it produces reasonably accurate results and it's pretty quick. There's nothing special about the number 100. BTW, there are twice as many possible starting positions as you thought, because either warrior can go first. I can't think of any situation in which you would actually want to run all of the possible battles. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Re: Test Stability Message-ID: <1994May26.215839.24547@news.vanderbilt.edu> Date: Thu, 26 May 1994 21:58:39 GMT In article roca_michael@tandem.com (Michael Roca) writes: >Now, I want to get the battles finished as quickly as possible, but I need >enough rounds to smooth out randomness in the results. Has anybody tried >figuring out how few rounds you can get away with? Clearly trying all >possible starting positions (~7700 in the small core, I think) is >impractical. I know tournaments and koth use 100 rounds. Was this number >just picked from the air? > >Mike Roca These values are empirically determined by running a low-ties scanner against itself: Rounds Standard Deviation (% of mean score) 20 27 100 9.5 250 5.7 This can be fitted by inverse regression (r > 0.99): S.D. = 4.4 + 454/Rounds Under koth conditions, this means that a score change of less than 10% is likely due to chance alone. -Stefan (stst@vuse.vanderbilt.edu) From: roca_michael@tandem.com (Michael Roca) Subject: Test Stability Message-ID: Date: Thu, 26 May 1994 23:29:30 GMT Maybe some of the veterans can answer this. For testing my programs, I run them against a set of the best opponents I have available (thanks to whoever put together the tournament code!) Now, I want to get the battles finished as quickly as possible, but I need enough rounds to smooth out randomness in the results. Has anybody tried figuring out how few rounds you can get away with? Clearly trying all possible starting positions (~7700 in the small core, I think) is impractical. I know tournaments and koth use 100 rounds. Was this number just picked from the air? As an added complication, I suspect that the number will vary depending on the warriors. For example, I would expect a quick scanner's results could change dramatically depending on how lucky it got in the starting positions. An imp spiral, on the other hand, would pretty much give the same results each time. Enough rambling. Any ideas/suggestions? Mike Roca From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: Newbie help needed. Date: 27 May 1994 03:26:42 GMT Message-ID: <2s3p9i$bu2@oak.oakland.edu> Hi! All I know is the basic concept behind corewars...so I'd appreciate a pointer on how to get started! -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: pk6811s@acad.drake.edu Subject: 2/98/0 Message-ID: <1994May27.081449.1@acad.drake.edu> Date: Fri, 27 May 1994 14:14:49 GMT Several submissions to the Standard Koth Hill recently got the infamous score - 2/98/0 - which almost certainly means they are self-destructing. The most likely cause for this is not designating your first line of code to be executed correctly. Use the END statement like this: .... .... firstl .... .... .... end firstl END must be the last line in the program, but firstl can be anywhere. If you don't use END, the very first line in the program is the first one to be executed. Since a lot of programs have DAT's at the top 'dat' would be fatal. Paul Kline @c@ pk6811s@acad.drake.edu - ignorance exceeded only by inquisitance - From: chaos@yar.cs.wisc.edu (Mostly Harmless [Alan De Smet]) Subject: Re: Newbie help needed. Date: 28 May 1994 03:18:47 GMT Message-ID: <2s6d6n$isc@spool.cs.wisc.edu> Jered Floyd wrote: >Hi! All I know is the basic concept behind corewars...so I'd appreciate >a pointer on how to get started! First of all ftp over to soda.berkeley.edu as anonymous ASAP and get the FAQ (which should be hiding under /pub/corewar somewhere). Other good things to get (While you're there) include tutorial.1.Z and tutorial.2.Z under /pub/corewar/documents. Start reading. (Good luck, it's fairly cryptic, especially the `88 and `94 drafts. I'm still learning.) By the way, someone promised to start working on a tutorial teaching redcode to suppliment Morrell's chapter1. How is it coming. (And for that matter, will we be seeing more of Morrell's My First Corewars Book? Chapter 1 was great!) -- Alan De Smet chaos@yar.cs.wisc.edu Mostly (But not entirely) Harmless [Expect to see fearsome programs on the hill from me, just as soon as I write one which beats imp more than half the time.:-] From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Newbie help needed. Date: 28 May 1994 20:42:32 GMT Message-ID: <2s8abo$dki@agate.berkeley.edu> Alan De Smet wrote: >By the way, someone promised to start working on a tutorial teaching redcode >to suppliment Morrell's chapter1. How is it coming. That would be me. It's coming, although slowly... the two-week estimate I gave was overly optimistic, especially with all these pesky final exams right about now (that's also why I haven't posted the current version of Pyramid yet -- and why it *still* doesn't have a clear lead over Keystone on the small hill :-) ). -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: NEEDED IMMEDIATELY:: Date: 29 May 1994 05:33:53 GMT Message-ID: <2s99g1$ahh@oak.oakland.edu> I believe that I can extend the Genetic Algorithm describe in the Evolving-Warriors.txt document to a more useable level easily. For my project, I need the following: A number of warriors to use in my fitness routines (moderate to high performing ones, please. I can write poorly performing ones myself. :-p ) A better description of the ICWS '88 standards (especially data handling and instruction syntax/usage) than the rather obscure TUTORIAL.[1,2] files provide. This is for the MARS implementation in my (hopefully) optimized fitness routine. I think that I will be able to acheive the rate of 1 generation / 2hours on an Intel 486DX2/66. I would like to do the coding of the MARS implementation this Memorial Day weekend, so please send me the above, or pointers to the above, ASAP. THANKS! I will post results and make the program fully available once I complete my project! -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: morrell@math.utah.edu (Steven C. Morrell) Subject: Re: Newbie help needed. Date: Sun, 29 May 1994 06:17:59 GMT Message-ID: In article <2s8abo$dki@agate.berkeley.edu> mconst@soda.berkeley.edu (Michael Constant) writes: Alan De Smet wrote: >By the way, someone promised to start working on a tutorial teaching redcode >to suppliment Morrell's chapter1. How is it coming. That would be me. It's coming, although slowly... the two-week estimate I gave was overly optimistic, especially with all these pesky final exams right about now I also seem to be in the habit of underestimating the amount of time my tutorial is taking. But good redcode is so complex! Chapter 2 on bombers is almost done. I just have to work through the core-clear on Winter Werewolf and write some closing remarks about Corestep, and then it will be ready. So, do I put it on soda under a seperate cover, or do I wait until I finish the whole tutorial and put it there as an amalgam? And when I'm done with Chapter 2, I will post my code to Blue Funk, which has been in the top ten on the 94 hill for quite some time now. Steven Morrell morrell@math.utah.edu From: mconst@soda.berkeley.edu (Michael Constant) Subject: Re: Newbie help needed. Date: 29 May 1994 16:33:35 GMT Message-ID: <2sag4v$lrf@agate.berkeley.edu> Steven C. Morrell wrote: >[...] So, do I put it on soda under a seperate cover, or do I wait >until I finish the whole tutorial and put it there as an amalgam? I'd like it one chapter at a time -- that way we can use all that you've written at any given time. Maybe when you're done then you could stick all the chapters into one file. -- Michael Constant (mconst@soda.berkeley.edu) GM/CS d? p c++++ l u++ e(*) m++ s--/- h f+(++) g++ w++ t+++ r+@ !y From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: UPDATE:Genetic Evolution Date: 30 May 1994 03:44:46 GMT Message-ID: <2sbnfe$gn6@oak.oakland.edu> I just posted yesterday that I am working on furthering the work of John Perry using Genetic Algorithms to evolve Core Warriors. I am happy to say that I now feel that I have the resources necessary to begin. Today I started coding the fitness routine, which is currently being developed as a standalone DOS MARS unit. I have completed the intialization routines for a standard '88 core, loading of warriors (with 100 minimum spacing in accordance to ICWS '88), and the frist few instructions (considering there are 11 instructions in the '88 set, this shouldn't take _too_ long. I hope.). If I didn't have finals, this would be done this week. Due to finals, I probably will not be able to finish it until the middle of June. As soon as it is complete, I will release it as a standalone MARS unit for DOS compliant to ICWS '88, 8000 instruction core, 8000 process max (per program), adjustable duration, max. entry length of 100, and min. distance of 100. In other words, the Standard '88 Hill as used on stormking and pizza. As freeware. I'd try porting it to other platforms or release the code, but I don't think anyone's very much interested in Turbo PASCAL. (I know, I should do it in C, but I'm currently more comfortable in PASCAL.) Support and kind words welcome. :-) Jered -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger. From: jjfloyd@vela.acs.oakland.edu (Jered Floyd) Subject: Another update & questions Date: 30 May 1994 21:02:06 GMT Message-ID: <2sdk8e$cld@oak.oakland.edu> Arrrgh. Oh, I _think_ I finally have the addressing modes programmed properly. I think. It all make so much sense until you try to figure it out. So, I think this is right for the pre-dec indirect (<) I take the field, and look at the B-Field at that relative location. I subtract one of this B-Field (in registers, don't write this to the core memory until AFTER both fields are evaluated.) I take that value (BField-1), and I use that a an offset (relative memory location from original instruction.) That location (CurrentPointer+(BField-1) is the location refernced by that field. If it is being used as a value, I use the B-Field value of that location. I hope. As soon as I get the rest of the commands in, I will run the VALIDATE warrior. Also, I have another question. I ran the VALIDATE warrior in WinCore, and it committeed suicide, leading me to believe that WinCore is not ICWS '88 compliant. Is that true? And, if someone has the time, can they trace the execution of VALIDATE for me? I have included it at the end of this post. Thanks again, Jered . ;redcode ;name Validate 1.1R ;author Stefan Strack ;strategy System validation program - based on Mark Durham's validation suite ; ; This program tests your corewar system for compliance with the ICWS88- ; standard and compatibility with KotH. It self-ties (i.e. loops forever) ; if the running system is ICWS88-compliant and uses in-register evaluation; ; suicides (terminates) if the interpreter is not ICWS compliant and/or uses ; in-memory evaluation. A counter at label 'flag' can be used to determine ; where the exception occured. ; ; Tests: ; -all opcodes and addressing modes ; -ICWS88-style ADD/SUB ; -ICWS88-style SPL ; -correct timing ; -in-memory vs. in-register evaluation ; -core initialization ; ; Version 1.1: added autodestruct in case process gets stuck start spl l1,count+1 jmz Date: Tue, 31 May 1994 05:31:04 GMT In article <2sdk8e$cld@oak.oakland.edu> jjfloyd@vela.acs.oakland.edu (Jered Floyd) writes: >So, I think this is right for the pre-dec indirect (<) > [...] Yes. >Also, I have another question. I ran the VALIDATE warrior in WinCore, >and it committeed suicide, leading me to believe that WinCore is not >ICWS '88 compliant. Is that true? > Wincore may very well be ICWS'88 compliant, but the unregistered copy has in-memory evaluation hard-wired, which makes it incompatible with koth and pMARS. >And, if someone has the time, can they trace the execution of VALIDATE >for me? I have included it at the end of this post. On its way under separate cover. -Stefan (stst@vuse.vanderbilt.edu) From: ratzburg@omnifest.uwm.edu (Linda Ratzburg) Subject: One Pass Core Clear Date: 31 May 1994 15:53:16 -0500 Message-ID: <2sg83t$oqn@omnifest.uwm.edu> I am having some trouble with a one-pass core clear system written in ICWS '88. Here is the code: bomb DAT #0 local DAT #0, #7998 kill MOV bomb, @local test JMZ npass, @local-3 nkil JMP kill, For the ICWS tourney and the EBS tourney, what size core is used, 8000 instruction or 8K (8192) instruction? Thanks. -- Jered Floyd jjfloyd@vela.acs.oakland.edu Geek Code: GAT d? -p+ c++++ l+ u++ e*@ m++ s/-- n--- h++ f? g- w++ t+++ r++ PGP Public key, Geek Code, picture, and assorted humor available by finger.