From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Round 4 - the end is coming Date: 1995/11/01 Message-ID: <1995Nov1.153409.3014@rhodes>#1/1 newsgroups: rec.games.corewar Well, I finally finished my round 4 entry. I am still trying to optimize it. I have good performance on random and in order data sets, but reverse order sets kill my time (and you better believe there will be a set in fully reversed order - probably a large one). I think I can shave on more instruction off my comparison routine to decided whether or not to switch data around. That should knock 15% or more off my run time. Just wondering if anyone else is having any success or trouble. Just a tip to those still working. Here are the data sets I am using. A set of completely ordered data, a set of completely reversed, a set of all data identical except one instruction, "random" data, a set of all identical instructions, a sets of instructions identical except for the modifiers, a set of nearly in order, and a set of nearly reversed order. If anyone can think of others to test against, I'd love to know. Anyway, try all these types of sets sorting ascending and descending, with and without deleting duplicates. Any tips anyone can share with me? Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Yet another '94 draft question Date: 1995/11/01 Message-ID: <1995Nov1.160018.3015@rhodes>#1/1 newsgroups: rec.games.corewar I nkow everyone is tired of answering my questions about the draft, but I want to make sure I am clear on how things work here. In the sample MARS in the draft, it looks like SLT.F will skip the next instruction only if the .a- and .b-fields are less. This makes sense to me, but I want to make sure that this is correct. I can envision people wanting to make it skip if a- and b-fileds are less, or a-filed is less and b-field is equal. This is what I expected, but I can understand why it is done the other way. I just want to make sure I understand correctly. Randy From: Beppe Bezzi Subject: Re: Core_Warrior_ Date: 1995/11/01 Message-ID: <199511011523.QAA17161@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar It may look strange but I read but now Core Warrior n.2, I had a preview from Myers but never the release. My mailer is chocking a bit and my news server got this article but today :-( >Paul responds: > >Another tidbit about Die Hard. He starts with a very brief quick-scan >and vamp. The pit does a one-pass suicidal clear incorporating a brainwash >which, when it works forces programs like Jack in the Box to revert from >paper to something which Die Hard can kill. Instead of going 1/0 >he now goes about 12/0 against JitB :-) > I guessed something like that, beaten by one my favourite weapon :-( Jack is too old to kill him and insert some Brainwash defence and the (in)famous anti_Die_ Hard_ line, that I know from the moment Magnus gave me to put in Brain Vamp About Die Hard, I guess it's an improvement of a program you had on the Multi hill some time ago, how you improved it I don't know. The concept should be to have many spirals, with their tails well separated, to reduce effeectiveness of spl clears, and many process in them to make them go very slow and not reach gates in 80000 rounds. The attack part should be a process eating stone, like Cannonade's one, to keep spirals starved and slowly moving. Right ? I think not too far. >Paul > -Beppe From: pk6811s@acad.drake.edu Subject: Re: Help with Round 4 Date: 1995/11/01 Message-ID: <1995Nov1.182545@acad.drake.edu>#1/1 references: <1995Oct31.090503.3008@rhodes> newsgroups: rec.games.corewar (Randy Graham) writes: [nice test routines] Also consider: large random array containing a big block of identical instructions array contains every possible opcode and modifier combination (you can't depend on using a 'unique' combination as a marker :-) (though 1000 is not enough to hold every opcode, modifier, and A-B #'s) Anyway, every sort technique has its Achille's heel, so we'll all be living with tradeoffs. BTW, does the scoring algorithm give half the credit to program size? So the shortest program is guaranteed to score at least in the middle of all competitors. And the longest can't go any higher than middle :-( What happens if two competitors are the same length? Do they get the higher or lower values - or an average? Same for equal (but highly unlikely) cycle times. During testing your sort program could do a quick sequence check after the sort pass, to verify that you have it right - assuming you have worked out how to compare two instructions :-) -- Paul Kline pk6811s@acad.drake.edu From: John K W Subject: Re: Help on imp-rings! Date: 1995/11/01 Message-ID: <478rn1$635@geraldo.cc.utexas.edu>#1/1 references: <467jf1$1of@newsbf02.news.aol.com> <468g16$pae@geraldo.cc.utexas.edu> <46cp3n$mtu@agate.berkeley.edu> <46e3be$hr6@geraldo.cc.utexas.edu> <46h0e3$ji9@agate.berkeley.edu> <46htcm$3fg@nuscc.nus.sg> <46kcvi$l4l@nuscc.nus.sg> newsgroups: rec.games.corewar >: Banzai0.2 is still there, despite losing more than it wins :) >Just died today:( Luck finally ran out. >Can someone tell me how to make the above imp ring interleaved? I >can't figure it out. >I know that a 2 point ring is weak, but I want to master the 2 pointer >before going on to the 3 pointer, etc. A three point ring is much easier to envision than a two point. The reason being that the previous instruction always creates the instruction that you are currently executing. Try this: spl 1, 0 spl 1, 0 spl 2, 0 jmp 2, 0 add #2667, -1 mov 0, 2667 Assuming I did that right, it should make a four-process, three-point ring. :) Add another 10 "spl 1, 0"'s and you've got a big-ass imp spiral... (this will take a wee bit of time to boot, however.) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: NSFCWT - Rules for round 4 Date: 1995/11/01 Message-ID: <1995Nov1.140923.3012@rhodes>#1/1 references: <199510311247.NAA02206@iol-mail.iol.it> newsgroups: rec.games.corewar Beppe Bezzi (bezzi@iol.it) wrote: : I agree with that, it's a difficult technical problem, something that prof. : Stefan :-) could propose to its students in a university exam on assembly : language. Oh no, I have written a similar program in assembly and found it MUCH easier in assembly :) : BTW what does EGAD means ? Just a declaration like wow, oh my goodness, or some such. I was merely SHOUTING when I capitalized it. : I like the hill so tough, and I like making something that will go against : something unknown, if not imediatly, sure in future. I like the tradeoff : beetween scoring high now and trying to forecast hill changes to live longer. I like it tough too. I just get tired of the same challenges every day. : This is your opinion, Randy, and that's mine. Yes, but I'm always right (just seeing if the logic that works for my wife in our house works for me in r.g.c). But seriously, I understand. : >: Jack an Tornado have sort of a 'soul', sort programs don't. : >Sure they do, but they have the soul of real-life paper pusher rather : >than a real-life warrior. : I work every day with paper pushers, corewar is a game, let me play with : _warriors_. I live in Washington, D.C. I deal with all kinds of warriors every day. It is nice for me to deal with paper pushers for a while. : P.S. : Sorry for long and maybe unrelated posting, I just wished to express my : opinion and I think I have nothing else to add. : Discussing personal tastes may be fun but not on a public forum. : I'm not alway sure of my english so I want to say I have _nothing_ against : anyone, Randy or others, that likes this round and _nothing_ against a round : so many people like; just I don't like it too much. I agree. I know I shoudln't have even replied, but the warriors vs. paper pushers thing seemed funny enough to me that I replied anyway. I'll shut up now (sighs from the audience). : B. Randy From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: Round 4 Question Date: 1995/11/01 Message-ID: <9511012052.AA00262@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Just to resolve a possible misunderstanding about the treatment of negative numbers in round 4, I am reposting this exchange with Karl Lewin. -Stefan >And I went to the trouble to write a compare routine that deals with >"negative" numbers. (ie- DAT 1,-1 is less than DAT 1,0) > >Oh well, I'm glad I asked because my sorter would have bee terribly wrong >otherwise :) > > >On Wed, 1 Nov 1995, Stefan Strack wrote: > >> There are no negative numbers in corewar; "-1" is just a convenient way to >> write "7999". >> >> I.e. >> dat -1,-1 is the largest possible data element. >> >> -Stefan >> > From: Beppe Bezzi Subject: Re: Sorts Date: 1995/11/02 Message-ID: <199511022328.AAA02453@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar Paul Kline wrote: >(Randy Graham) writes: > >> But size is just another weight in the scoring. Putting in multiple >> sorts and using different ones based on the array can give a huge >> performance increase (I'm doing this based on what I expect the data >> to be). > >If you know something about the order of the list like: > it is mostly in order already > it is mostly backwards > it is short > it is long >then you can take advantage of that knowledge and choose an appropriate >algorithm. Gaining that knowledge costs something in startup time but >may be worthwhile. > I hope not even Stefan knows that :-) i.e. I hope all data will be random. A fixed data set can advantage am alghorythm over the others too much. My sorter if small, simple and, should Stefan choose an inverted order, 1000 elements array, we won't have results till next week :-) >This scoring system creates an interesting dilemma. The shortest program >will be the shortest program in all 10 tests, so can't do worse than >middle overall score. An ideally fast program would win all 10 speed >trials (highly unlikely), but if he happens to be the longest he can't >do better than the middle overall score. So the advantage is to be very >short and maybe optimized for one kind if list. But if everyone goes for >the smallest position you might find yourself beat out by someone(s) just >one instruction smaller and that could be disaster. > If I understood well the scoring system, it's not so. If your sorter is 10 lines long and sorts data in 1000 cycles you'll have a great advantage on an average set 9 lines long sorting in average 10000 cycles. Scoring should be: lenght/average lenght + time/average time not lenght rating (1st, 2nd ...) + speed rating This encourage to improve each component if this penalize the other not too much. >So I encourage everyone to go for large and fast. Cause I'm large and fast. >In fact I'm huge - scores and scores of instructions (well 2.5-score anyway). > I encourage everyone to go for large and slow. Cause I'm large (if a score is 20 I'm as large as you are) and slow :-) > >Hey Beppe - if you don't want to write a sorter, just submit a small paper, >maybe you will get lucky :-) > I made the sorter; I'm not at all satisfied of what I did, but I did something working. I was to submit an excellent sorter i made. It terminates with a dat as required. It finishes in 1 (one) cycle with all data set It is very, very short; one line long When I was near to improve it removing another line, I was sad to find a small and maybe unimportant bug; it does'n sort unordered arrays; a very special case indeed. :-) About Fibonacci sort: (double 'c', pronunced something like fee-bon-at-cy [not really sure on how you may pronouce it :-], Italian matematician of the Renaissance period, not sure of the age, sure it was Italian) It uses the Fibonacci serie 1,1,2,3,5...n = n-1 + n-2 to allocate records when merge sorting tapes. This allocation allows it to use but three tape recorder, and less tape movements than a linear allocation one. Obviouly _heard_of_it_once_; I remember that when I heard of it I understood it, now I'm not more able to reconstruct how it functions :-( I still don't like too much this round, but sure I improved my knowledge on sort algorythms. >Paul Kline >pk6811s@acad.drake.edu > >(Paul's son the 'small' not Paulson the 'great') > > -Beppe Bezzi From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: Sorts Date: 1995/11/02 Message-ID: <9511022123.AA00643@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Paul Kline wrote: >This is the way I understand the scoring formula: > > cycles1/avg1 + cycles2/avg2 + .. + cycles10/avg10 > Speed Index= -------------------------------------------------- > 10 > > Speed Rank = position of Speed Index in inverse-sorted Speed Index array > > Speed Rank + Size Rank > Score = ---------------------- > 2 > >So if my Size Rank is 10th out of 10 (I'm the longest) and my Speed Rank >is 1st out of 10 (I'm the fastest) my score will be (1+10)/2 = 5.5. > >And if my Size Rank is 1st out of 10 (I'm the shortest) and my Speed Rank >is 10th out of 10 (I'm the slowest) my score will be (10+1)/2 = 5.5. >I can do better if I'm faster than at least one other program, but >I can't do worse than that. > >Much ado about nothing, maybe, only that from a strategy standpoint a person >might go for small and slow as a viable option. Which is viable unless >several people do the same. There can only be one smallest program :-) > >Things will be much clearer on Monday. Trying to make things clearer before monday :) Ok, the speed index is calculated as you describe, but we also use a *size* index: size index = size/avgsize Programs are then ranked by their size and speed indices, but the rank does not go into the final score calculation, instead we use overall = size index * speed index Example: your program is twice as large as the average, but also twice as fast: 2 * 0.5 = 1 You get the same score if your program is half the size but also half the speed of the average program. The player with the lowest "overall" index wins. -Stefan From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: Help with Round 4 Date: 1995/11/02 Message-ID: <9511021725.AA00588@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Randy Graham wrote: >Well, whenever I try to set max length to > 500, I get a pmars message >"option '-l' value must be in the range 1 - 500" Oops, hadn't thought of that. Guess I'll have to change MAXINSTR to 1000 and recompile. You can still fill core using cdb like so: (cdb) ca x=4000,y=1~!!~@edit x~dat y=y+1,y~if x=x+1<5000~! -Stefan From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: Help with Round 4 Date: 1995/11/02 Message-ID: <9511021707.AA00566@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Paul Kline wrote: >BTW, does the scoring algorithm give half the credit to program size? >So the shortest program is guaranteed to score at least in the middle of all >competitors. And the longest can't go any higher than middle :-( We're using values normalized to the average performance, so you could win with the longest program as long as it is also the fastest. -Stefan From: mpn@ifm.liu.se (Magnus Paulsson) Subject: Strategy Date: 1995/11/02 Message-ID: <199511021118.MAA23122@ifm.liu.se>#1/1 newsgroups: rec.games.corewar 1 38/ 37/ 25 myZizzor Paulsson 138 58 Thought I would brag a bit. No, serious when I thought up myZizzor I thought it would be a sorry loser that would drop off the hill faster than light. (that's why I published it) I think it is boring when such a unsofisticated warior can stay on the hill for such a long time. I mean compare myZizzor with Agony which warrior would you be proud of writing? A question to the oldtimers, was it better or worse in the 88' days? I want more complex warriors. - Magnus Paulsson From: pk6811s@acad.drake.edu Subject: Re: Sorts Date: 1995/11/02 Message-ID: <1995Nov2.155402@acad.drake.edu>#1/1 references: <199510291210.NAA08764@iol-mail.iol.it> <1995Oct31.130037.3009@rhodes> <1995Nov2.112117@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu (me) writes: > This scoring system creates an interesting dilemma. The shortest program > will be the shortest program in all 10 tests, so can't do worse than > middle overall score. An ideally fast program would win all 10 speed > trials (highly unlikely), but if he happens to be the longest he can't > do better than the middle overall score. So the advantage is to be very > short and maybe optimized for one kind if list. But if everyone goes for > the smallest position you might find yourself beat out by someone(s) just > one instruction smaller and that could be disaster. Stefan has corrected my understanding of the scoring system. Please ignore the preceding gibberish :-) Paul Kline pk6811s@acad.drake.edu From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Help with Round 4 Date: 1995/11/02 Message-ID: <1995Nov2.072948.3016@rhodes>#1/1 references: <1995Oct31.090503.3008@rhodes> <1995Nov1.182545@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu wrote: : Also consider: : large random array containing a big block of identical instructions Yes, I added that one after my posting. : array contains every possible opcode and modifier combination : (you can't depend on using a 'unique' combination as a marker :-) : (though 1000 is not enough to hold every opcode, modifier, and A-B #'s) Well, whenever I try to set max length to > 500, I get a pmars message "option '-l' value must be in the range 1 - 500" So, I have tested against up to 500 line array. I can sort a random array of 450 in < 60000 cycles. In order data I can sort and delete in about 8 to 10 * DATASIZE. Reverse data kills me though. I am trying to find a way around that this morning. : BTW, does the scoring algorithm give half the credit to program size? I was under the impression it was 1/11th of the score (if there are 10 data blocks to sort). : So the shortest program is guaranteed to score at least in the middle of all : competitors. And the longest can't go any higher than middle :-( Yes, this wouldn't be good for me either. As of right now, I am 130 instructions. I have found a couple I can eliminate, and my be able to optimize away a couple more. But I doubt I'll get under 125 - probably one of the longer ones. : What happens if two competitors are the same length? Do they : get the higher or lower values - or an average? Same for equal (but : highly unlikely) cycle times. Based on previous rounds, I'm guessing an average. : During testing your sort program could do a quick sequence check after : the sort pass, to verify that you have it right - assuming you have : worked out how to compare two instructions :-) Still considering this one. I already have the routine in to test it, I just need to decide if I want to spend the extra cycles. Suppose we have a 1000 line data array, no duplicates. How long would yours take to verify completeness? Mine is about 4 * DATASIZE. That's a lot of time. Then, if it is wrong, what do you do? Re-sort? If you didn't get it right the first time, what makes it any more likely to get it the second time? And comparing two instructions to find which is less or greater was the hard part of this exercise. Sorting was easy, but my first three attempts at comparing were wrong. The fourth time I got it right (I hope ;), and it is 2 instructions shorter than my best incorrect attempts. Anyway, thanks for the input. : -- : Paul Kline : pk6811s@acad.drake.edu Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Help with Round 4 Date: 1995/11/02 Message-ID: <1995Nov2.110507.3018@rhodes>#1/1 references: <1995Oct31.090503.3008@rhodes> <1995Nov1.182545@acad.drake.edu> newsgroups: rec.games.corewar In a fit of digital ink overflow, I (graham@hal.mathcs.rhodes.edu) wrote: : pk6811s@acad.drake.edu wrote: : : BTW, does the scoring algorithm give half the credit to program size? : I was under the impression it was 1/11th of the score (if there are 10 : data blocks to sort). I re-read the rules, and it seems very clear to me the half the score comes from size, and half from speed. I have to re-think my algorithm now. I can eliminate 30-40 lines (putting me in the 80 line area), and only suffer about 10-15% speed penalty. If only I had an idea how long others took, I could decide. Randy P.S. I swear some day will come when I don't post 15 new messages every week ("Oh, how soon?" the crowd says). From: akemi@netcom.com (David Boeren) Subject: Re: Strategy Date: 1995/11/03 Message-ID: #1/1 references: <199511021118.MAA23122@ifm.liu.se> newsgroups: rec.games.corewar Magnus Paulsson (mpn@ifm.liu.se) wrote: : 1 38/ 37/ 25 myZizzor Paulsson 138 58 It may be that myZizzor is doing so well because of the mix of other programs. Everyone here knows that once a hill starts to get a lot of programs of type X on it, then if you submit a program that does well against type X (no matter how poorly it does against other types) then it will probably do well on the hill. Look and see if there are lots of replicators or other natural prey of a scissors on the hill... "What is most important is to attack the opponent's strategy". - Sun Tzu From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: My entry Date: 1995/11/03 Message-ID: <1995Nov3.152538.3024@rhodes> newsgroups: rec.games.corewar Well, here is my sorter. I figure it is too late for anyone to make use of this competitively, so I can post it, even though the deadline for today's entries isn't past. Truth be told, I am not certain this will work for all cases. I haven't been able to get it to fail, but I didn't code C to redcode exactly from the algorithm I had. Then, when optimizing it, I really let loose and cut things out that seemed unnecessary to me. So, if this doesn't get everything right in the tournament, you know I won't be surprised. What I did was put a bubble sort like pass at the beginning. If there are no swaps, I immediately go to see if I need to delete duplicate. If there are swaps, then I fall through to my quicksort. Within the qsort, I use a lot of old instructions that won't ever be used again as my temporary storage spots. Also, I use pointers to things when possible so I can remove duplicate code and instead swap a- and b-numbers. Anyone who is familiar with quick sorts might have trouble figuring out how this code is tied to a quick sort, but that's why your cc compiler won't let you use -O and -g. That is, optimized code is often hard to detangle into the original. This started out at 129 instructions. It ended up being 96. For this particulr problem, my worst case extra memory use is 10 cells. On all my tests (up to 450 data cells), I have not used more than 4 cells, so I think I didn't have the best test arrays. I learned a good bit about optimization while doing this, but I expect there may be more to do. Especially if anyone could share a better way to test for "less then." I don't know that anyone will want to see this, but I am posting it with hopes of getting others to post their warriors, which I certainly want to see. Now that I am looking at this, I see at least one more line I can remove. But, it will only improve the speed a couple of cycles, so I am not going to try do it. I guess I'll leave that as an exercise for the reader. Later, Randy ----------------------------------------------------------------- ;redcode-94 ;name Consortium ;kill Consortium ;author Randy Graham ;contact hp715!rgraham@peridot.spawar.navy.mil ;NSFCWT round 4 ;assert 1 ;strategy Use an iterative (non-recursive) quicksort to sort data ;strategy Uses lg n stack space and O(n lg n) average run-time ;strategy To speed up on sorted list, do a one pass bubble. Skip ;strategy to delete routine if no swaps or qsort if there are swaps. FLAGS equ (first+4000) DATA equ (FLAGS+1) STACK equ first CLEAROUT equ fini+1 first dat.f 0, DATA ;a - stack pointer, b - end of data dat_ptr dat.f DATA, first-1 ;contains start & end of partition bubl_ptr dat.f DATA, DATA-1 bubl_new sne.i (CLEAROUT-bubl_dwn2), @(bubl_ptr-bubl_dwn2) ;first get our data list size, then sort begin seq.i CLEAROUT, @first ;once we find end, don't change it bloop jmp.a begin, >first ;bubble sort check is written assuming a decreasing sort sortbubl jmn.b bubl_dwn, FLAGS mov.x bubl_ptr, bubl_ptr ;got to change - sort increasing ptr2 mov.i bubl_new, bubl_dwn2 bubl_dwn nop.a }bubl_ptr, >bubl_ptr bubl_dwn2 sne.i CLEAROUT, *bubl_ptr ptr1 jmp.a chk_del, bubl_new ;we got here if there were no swaps slt.b @bubl_ptr, *bubl_ptr jmp_bubl jmp.a 2, 0 jmp_bubl2 jmp.a qsort, 0 sne.b @bubl_ptr, *bubl_ptr slt.a @bubl_ptr, *bubl_ptr jmp.a bubl_dwn, 0 qsort add.b first, dat_ptr qsetup mov.i dat_ptr, {first ;start our stack jmn.b sorter, FLAGS mov.x checkline check_end sne.ab checkline, counter ;make sure not at end of list jmp.a setup, >checkline check_emp sne.i CLEAROUT, *checkline ;don't compare blank lines jmp.a check_end, }checkline check_dif seq.f *checkline,chk_del ;make sure still could match jmp.a setup, >checkline seq.i *checkline,chk_del ;clear out duplicates jmp.a check_end, }checkline matches mov.i CLEAROUT, *checkline jmp.a check_end, }checkline ;now close up holes in data closedat dat.f DATA, DATA closeup sub.ab #(closedat-checkline), counter ;pointer to end chk_close sne.ab closedat, counter ;end on time at_last jmp.a fini, 0 seq.i CLEAROUT, *closedat mov.i *closedat, >closedat jmp.a chk_close, }closedat fini mov.i CLEAROUT, @closedat end begin From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: round 4 Date: 1995/11/03 Message-ID: <47dq2c$ml5@mozo.cc.purdue.edu>#1/1 newsgroups: rec.games.corewar Greetings. I suppose the reason we're not suppose to sort the flag at location 4000 is that the enemy process will be executing there? like jmp #0, 1 or something. Correct? My sorter overwrites it ( sometimes ) temporarily. And then replaces it. ( Hey--it works, okay. ) I'm going to have to fix this little quirk, aren't I? M R Bremer From: Gus Bazos Subject: C-Robots code available? Date: 1995/11/03 Message-ID: <47druo$61q@ionews.io.org>#1/1 newsgroups: rec.games.corewar Is anybody here familiar with C-Robots by Tom Poindexter (c1985) on SIMTEL? It is a game based on programing robots in 'C' to outlast competing robots on a battlefield. I wanted to register with him so that I can get a copy of the source code. Unfortunately the address is not current, and I can't contact him. Anyoone know where I can reach him, or where I can get the source code from? From: spotter@netcom.com (Steve Potter) Subject: Call 1-800-856-2469, LIVE LIVE LIVE 809-474-7588 code1158 Date: 1995/11/03 Message-ID: #1/1 newsgroups: rec.games.corewar 18+, 24hours, rates as low as $0.38/min Hot, Young women want it NOW ----011-592-247-681 Gay, Bi, Bi-curious guys at -----809-474-7604 ************************************************ ************************************************ ************************************************ ************************************************ rec.games.corewar From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Finished Round 4 Date: 1995/11/03 Message-ID: <1995Nov3.121139.3021@rhodes>#1/1 newsgroups: rec.games.corewar Well, I finally gave up hopes of making my warrior shorter of faster. I submitted it this morning. I end up with 96 instructions. From my first working copy to my submitted program, I trimmed over 25% of the code and 5% of the runtime off. Unfortunately, I doubt I'll do as well as I had hoped. I thought I would be on the large end, but what I have read from others' posts makes me believe I AM the large end. I don't expect anyone has a longer "warrior." As for speed, I expect to be in the middle of the pack. I ended up using a Quick-sort. And it has poor performance on nearly sorted and nearly reverse sorted arrays. If we had a RAND command in redcode, I would have randomized the data before sorting (did that per author's suggestion from an algorithm book once and got about 20% speed improvement). That is, the more random the data, the better the qsort does. Plus, I added a small optimization to give good results for a certain data set I am expecting. But, if I am wrong, I pay for it with 10 lines of extra size. If it is there, the speed improvement will cover that. On a data set of 450 elements, thrown together at random, I need ~55,000 cycles to sort it. Of course, a different set could be more or less depending on how mixed up it is. But overall, I would guess this to be competitive, but not great. Never heard of the sort P.Kline is using, but I am planning on getting Knuth's Sorting book, so I'll learn about it then. I'll post my sorter at the end of the business day (I don't have a working machine at home yet, so I only connect from work during breaks). I hope round 5 rules com out before the end of the day, too. Otherwise I can't start working until Monday after work. Randy P.S. Paul, I found info about the Fibonacci sort in an algorithm book I have. Looks really neat. The crazy thing is, I think I understand it, based on the description they give. In fact, if I had seen it earlier, I might have tried using it. It is VERY efficient speed-wise, but it might take a goood bit of code to execute. From: mconst@OCF.Berkeley.EDU (Michael Constant) Subject: Re: Sorts Date: 1995/11/03 Message-ID: <47cfil$i8p@agate.berkeley.edu>#1/1 references: <199511022328.AAA02453@iol-mail.iol.it> newsgroups: rec.games.corewar Beppe Bezzi wrote: >My sorter is small, simple and, should Stefan choose an inverted order, >1000 elements array, we won't have results till next week :-) Well, when I ran my prime-number round, there was an entry like that... my memory is a little fuzzy, but I believe that one of the entries was awfully inefficient for large primes. I cut it short at 1.5 million cycles :-) Perhaps Stefan and Nandor will be as kind. Someone posted a few days ago asking what my prime-number round was. The challenge was to write a program to factorize a single input into primes. As with Stefan and Nandor, the entries were evaluated on speed and size. I used a really complicated scoring mechanism, though (anyone remember those pages and pages of statistics calculations?). I'm glad to see that the current competition uses a simpler scoring system. If nothing else, it means people probably won't have to wait as long to get their scores as they did in my contest... :-) Oh, and I'm going to enter this round. Really. I've almost got my computer working again, and I don't have *that* much homework... -- Michael Constant (mconst@soda.csua.berkeley.edu) From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: NSFCWT - rules for round 5 Date: 1995/11/03 Message-ID: <9511040005.AA01717@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar *********************************************** * NSFCWT - Rules for round 5 * *********************************************** Relax. After sorting our opponent thoroughly, we're back to killing :-) This is a "random" round, where you get to write a warrior that works in an unknown core size and with an unknown process limit. The match consists of a round-robin with 100 rounds per challenge; those 100 rounds are broken up into 10 sets of 10 rounds with different parameters: Core size: 1000 .. 20000 Process limit: 10 .. 10000 Max. cycles: 10 * core size Max. length: 100 Min. distance: 100 P-space size: core size/16 Core size and process limit are chosen randomly and independently in the given interval, i.e. without human bias (let's see how this paper works with 100 processes :). All warriors fight with the same 10 sets of rules. To make things a little more challenging, you cannot use the predefined variables CORESIZE, MAXPROCESSES, etc. (there are ways to find out what the core size is in a few instructions). Nandor is running the next two rounds, so mail your warrior to sieben@imap1.asu.edu by Friday, Nov. 10, 20:00, MST. Good luck, Nandor and Stefan From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: impsize.c Date: 1995/11/03 Message-ID: <1995Nov3.213349.3025@rhodes>#1/1 references: <1995Oct26.151224.2985@rhodes> <46plpq$1d6@nuscc.nus.sg> newsgroups: rec.games.corewar Loh Weng Keong Calvin (lohwengk@iscs.nus.sg) wrote: : I don't understand what it is supposed to do. Does it make an imp ring? I used it for an idea I was working on. All it does is give you all possible imp sizes for a given range of cores. For example, if you run it with impsize 8000 8010 9 a it lists all imp sizes of 9 or less for coresizes 8000, 8001, 8002, ... , 8010. If you want to actually make imps, you need Jay Han's makeimp.c. Run it for a coresize and imp number you want, and his program will make the imp. Mine just prints out what imps are possible. : Calvin Loh Randy From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: round 4 Date: 1995/11/03 Message-ID: <9511032242.AA01516@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar M R Bremer wrote: >I suppose the reason we're not suppose to sort the flag at location >4000 is that the enemy process will be executing there? like jmp #0, 1 >or something. Correct? My sorter overwrites it ( sometimes ) temporarily. >And then replaces it. ( Hey--it works, okay. ) I'm going to have to >fix this little quirk, aren't I? > > That wasn't in the rules, so we'll allow overwriting the flag as long as you replace it. It makes it a little harder to check results, but we can work around it. -Stefan From: Beppe Bezzi Subject: Re: Sorts Date: 1995/11/03 Message-ID: <199511031111.MAA07020@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 03.14 03/11/95 -0500, you wrote: >Beppe Bezzi wrote: >>My sorter is small, simple and, should Stefan choose an inverted order, >>1000 elements array, we won't have results till next week :-) > >Well, when I ran my prime-number round, there was an entry like that... >my memory is a little fuzzy, but I believe that one of the entries was >awfully inefficient for large primes. I cut it short at 1.5 million >cycles :-) Perhaps Stefan and Nandor will be as kind. > A factoring program testing every number till finds a factor can be made in few lines num dat num fact dat 0, #2 loop mov.b fact,num mod.ab num,num jmz.b stop,num jmp loop,>fact stop .... and will take num*4/2 cycles to factorize; I cannot think at nothing slower, without stranges loops around. My sorter is much worst :-((( 1.5 millions cycle are _nothing_ for my program, against a 500 inverse order array with dulpicate deletion requireded, (the worst case I can reproduce without recompiling pmars). Execution time is not really bad. In less than a minute it sorts 500 lines on my 486. If results are late it's not my fault :-) >-- > Michael Constant (mconst@soda.csua.berkeley.edu) > > -Beppe Bezzi From: spotter@netcom.com (Steve Potter) Subject: 809-474-7607 ! Local Voice Personals/Live Chat! Code1158 Date: 1995/11/03 Message-ID: #1/1 newsgroups: rec.games.corewar You must be 18 years of age or older. As low as $0.23/min Available 24 hours a day! ALL LIFESTYLES welcome rec.games.corewar From: morrell@math.utah.edu (Steven C. Morrell) Subject: Re: Strategy Date: 1995/11/04 Message-ID: #1/1 references: <199511021118.MAA23122@ifm.liu.se> newsgroups: rec.games.corewar In article <199511021118.MAA23122@ifm.liu.se> mpn@ifm.liu.se (Magnus Paulsson) writes: > A question to the oldtimers, was it better or worse in the 88' days? > I want more complex warriors. > - Magnus Paulsson It was worse. There was no such thing as silk paper, so even Agony was too complex to stay on the hill for as long as Agony II did. Imp-stones seemed to dominate, and anything else had to be pretty good against imp-rings. Since I started playing, in the days of Flash Paper, there has been lots of complaining about dumb programs that beat up on intelligent ones. Complexity doesn't seem to work, unless what you have a *very* effective way of killing most programs. Fighting against stones tends to keep things really small. And since MyZizzor beats up on all the new paper-imp combo's very effectively, there really isn't much of a need for complexity right now, is there? :-) MyZizzor is actually *very* sophisticated overall. It's just that most of its components have been around for a long time. - Steven Morrell From: tpoindex@nyx10.cs.du.edu (Tom Poindexter) Subject: Re: C-Robots code available? Date: 1995/11/04 Message-ID: <47h4sv$jd7@nyx10.cs.du.edu>#1/1 references: <47druo$61q@ionews.io.org> newsgroups: rec.games.corewar In article <47druo$61q@ionews.io.org>, Gus Bazos wrote: >Is anybody here familiar with C-Robots by Tom Poindexter (c1985) on >SIMTEL? It is a game based on programing robots in 'C' to outlast >competing robots on a battlefield. I wanted to register with him so that I >can get a copy of the source code. Unfortunately the address is not >current, and I can't contact him. > >Anyoone know where I can reach him, or where I can get the source code >from? I'm here! Actually, I'm in the Denver area. Feel free to drop an email. -- Tom Poindexter tpoindex@nyx.cs.du.edu http://nyx10.cs.du.edu:8001/~tpoindex/ From: Derek Ross Subject: Re: Another sorter... Date: 1995/11/04 Message-ID: <288@arbroath.win-uk.net> newsgroups: rec.games.corewar >Here is another entry for your amusement...short but gets real (and i >mean REAL) slow for long datasets. (45 instructions I think) > >;name Points is Points >;author Karl Lewin >;assert 1 >;strategy A simple selection sort. Not real efficient >;strategy but kinda small so maybe it won't end up losing >;strategy me too many points this round :) >;strategy >;strategy (That is if it really does work) >;strategy >;strategy I'm pretty sure that as the size of the data block >;strategy being sorted goes up, my program gets rapidly slower >;strategy so be patient if many of the samples are towards the >;strategy large end of the range :) > Hey, I entered a selection sort too! I didn't mean to. I intended to enter a fast binsort variant, comparable to quicksort on small input and faster on large input. Unfortunately I discovered - on Thursday evening - that the integer division that redcode offers wasn't suitable for the data scaling operation this binsort variant requires to calculate the approximate position of the data. I know that a Real Programmer would have smiled jauntily, knocked up a quick floating point division routine and carried on to complete the duplicate stripper. Call me a wimp if you like but I didn't think I could produce a redcode floating point division routine and get my duplicate stripper working in the time I had left. Not unless I stayed up all night and didn't bother going in to work the next day. Not a serious option. Luckily I had prepared a selection sort earlier just in case of any hitches with the binsort which I knew would be tricky to implement. So that's what got submitted. I think the binsort is of interest in itself as it is a pretty fast algorithm - O(n) with a good constant - and it is easy to implement in any language with 'floating point' division and arrays. I have posted it below in QBASIC rather than redcode as that makes it easier to follow! If anybody is interested in the redcode, just ask. It does work. Just not very well ... REM Pigeonhole sort - a binsort variant. REM Allocate storage areas for M values. REM Info holds the data, Index holds indices to the data. DIM Info(M), Index(M, 2) REM Calculate the domain of the data keys and make sure that it's not zero LET Least = Info(1): Most = Least FOR J = 2 TO M IF Info(J) < Least THEN Least = Info(J) IF Info(J) > Most THEN Most = Info(J) NEXT LET Domain = (Most - Least): IF Domain = 0 THEN Domain = 1 REM Calculate initial array indices from the data keys ... REM ... by adjusting the key domain to match the array range. REM Count duplicate indices which exist or are created by the adjustment. REM If there are no duplicates the data is ready to sort. LET Unsorted = 0: Range = (M - 1) FOR J = 1 TO M LET K = (Info(J) - Least) / Domain * Range + 1:REM This is the problem line for redcode. LET Index(J, 1) = K LET Index(K, 2) = Index(K, 2) + 1 IF Index(K, 2) > 1 THEN Unsorted = 1 NEXT REM Convert duplicate counts into pigeonhole start indices. IF Unsorted > 0 THEN LET K = 1 FOR J = 1 TO M IF Index(J, 2) > 0 THEN Most = Index(J, 2): Index(J, 2) = K: K = K + Most NEXT END IF REM Calculate unique final array indices for each key. IF Unsorted > 0 THEN FOR J = 1 TO M LET K = Index(J, 1) LET Index(J, 1) = Index(K, 2) LET Index(K, 2) = Index(K, 2) + 1 NEXT END IF REM Move the data to its 'approximately sorted' position. FOR J = 1 TO M WHILE J <> Index(J, 1) SWAP Info(J), Info(Index(J, 1)): SWAP Index(J, 1), Index(Index(J, 1), 1) WEND NEXT REM Sort the 'approximately sorted' data. REM This part of the sort is still very fast on average even though Bubblesort REM is used since, on average, the data is either sorted or nearly sorted. REM Of course there are pathological cases ... REM However the routine *could* recursively call itself a la quicksort REM since the first part of the sort is basically a multiway partition. REM This would handle some of the pathological cases but if they're unlikely it's REM not worth it. IF Unsorted > 0 THEN LET Least = 1: LET Most = M WHILE Least < Most LET Unsorted = Most - 1: Most = Least FOR J = Least TO Unsorted IF Info(J) > Info(J + 1) THEN SWAP Info(J), Info(J + 1): Most = J NEXT LET Unsorted = Least + 1: Least = Most FOR J = Most TO Unsorted STEP -1 IF Info(J) < Info(J - 1) THEN SWAP Info(J), Info(J - 1): Least = J NEXT WEND END IF MicroSoft Network may not carry this message without license to do so. License to carry this message requires a fee of $1000, payable within 30 days to Derek Ross. Appearance of this message on MicroSoft Network constitutes an agreement to terms. From: Derek Ross Subject: Re: Call 1-800-***-****, LIVE LIVE LIVE 809-***-**** code**** Date: 1995/11/04 Message-ID: <287@arbroath.win-uk.net>#1/1 newsgroups: rec.games.corewar >18+, 24hours, rates as low as $0.38/min > > > > >Hot, Young women want it NOW ----011-***-***-*** >Gay, Bi, Bi-curious guys at -----809-***-**** >************************************************ >************************************************ >************************************************ >************************************************ > > >rec.games.corewar > Ha! They do NOT want it. When I tried discussing the merits of 3 point versus 7 point imp rings the 'hot, young' woman lost interest faster than my wife does !! You're better off reading this newsgroup for real thrills, spills and no holds barred out-and-out excitement. Cheers Derek MicroSoft Network may not carry this message without license to do so. License to carry this message requires a fee of $1000, payable within 30 days to Derek Ross. Appearance of this message on MicroSoft Network constitutes an agreement to terms. From: mpn@ifm.liu.se (Magnus Paulsson) Subject: Re: Strategy Date: 1995/11/04 Message-ID: <199511050010.BAA14273@ifm.liu.se>#1/1 newsgroups: rec.games.corewar >In article <199511021118.MAA23122@ifm.liu.se> mpn@ifm.liu.se (Magnus Paulsson) >writes: > >> A question to the oldtimers, was it better or worse in the 88' days? >> I want more complex warriors. > >> - Magnus Paulsson > >It was worse. There was no such thing as silk paper, so even Agony was too >complex to stay on the hill for as long as Agony II did. Imp-stones seemed >to dominate, and anything else had to be pretty good against imp-rings. > >Since I started playing, in the days of Flash Paper, there has been lots of >complaining about dumb programs that beat up on intelligent ones. >Complexity doesn't seem to work, unless what you have a *very* effective >way of killing most programs. Fighting against stones tends to keep things >really small. > >And since MyZizzor beats up on all the new paper-imp combo's very >effectively, there really isn't much of a need for complexity right now, >is there? :-) > >MyZizzor is actually *very* sophisticated overall. It's just that most of >its components have been around for a long time. > >- Steven Morrell I've thought a bit about why some strategys work and some don't. Long programs don't work unless they are fast, and you can't get above 0.8c (about) and still have a good spread of the bombing/scaning. This gives something of a limit for scanners of (about) 15 bytes at 0.67 c, depends on what kind of bombs that you use and soforth. (Stones use weaker bombs and have to be shorter to make up for it (but multiple processes can survive a paper sometimes)) Now I thought that a 0.5 c scanner should be competetive if it's length is shorter than (about) 10 bytes, now the bomb should be a spl carpet to be realy effective (a scanning vamp is no use for 0.5 c). Then a two pass coreclear to finish of would make it a real pain for most of the warriors on the hill. Then after a couple of tries I got it working, but only 100 points on the hill. :-( and a few hours wasted. - Magnus Paulsson enjoy, if you can understand this easily, send a mail and you mighy win a ..... color radio! And if you can get it to skip it's own bombs, change the author line and send it to Pizza. ;redcode-94 ;name myTiny ;author Paulsson ;strategy Carpet bomber, 11'th try. ;strategy Have you ever seen a mod 8 carpet bomber with ;strategy spl/dat coreclear in 8 bytes? ;strategy To bad it get's stuck on decoys and djn strams :-( ;strategy and it's own bombs :-( ;strategy Submitted: 5 November 95 ;assert CORESIZE > 1 ;kill myTiny org st st add.a #8*3,*b1 jmz.f st,*ptr ptr mov.ab #-1,1 spl st,0 clear mov.i @st,>ptr+1 jmn.f clear,@ptr+1 dat.f <2667,6 b1 spl #ptr,6 From: morrell@math.utah.edu (Steven C. Morrell) Subject: Status on My First Corewar Book Date: 1995/11/04 Message-ID: #1/1 newsgroups: rec.games.corewar It's been a few months since I mentioned my tutorial and all the support surrounding it. So, here is the new message sent out to everybody who mails me for a preliminary version of my practically oriented redcode tutorial. If you haven't got a reply from me in the last two months, you will soon, and it will say: My corewar tutorial presently only consists of Chapters 1 and 2, which have a link to them (along with a lot of other stuff) at http://www2.ecst.csuchico.edu/~pizza/koth/index.html Use the plaintext links, which point to ftp://ftp.csua.berkely.edu/pub/corewar/incoming/chapter1 ftp://ftp.csua.berkely.edu/pub/corewar/book/chapter2 These files are compressed (.Z) but should decompress automatically if you use the above URL's. If they don't please tell me. !!!!! The links at www.stormking.com and the standard ones at csuchico.edu are broken. Steven Beitzel made HTML versions of chapter 1 and chapter 2 and put them on his Unofficial Core War Home Page, but this seems to have been deleted a couple of months ago. If someone has a copy of the HTML formats, please send a copy to me or find a web page for them and tell me about it. Barring this, they will have to be re-decorated some time soon. If you can wait for a month (more) for the HTML versions, I can point you to them when they are available. Chapter 3 is being written, slowly. Expect it out some time in late January, or earlier depending on help. If you want a (plain text) copy of it sent to you when it is released, send me a message, and I will put you on the mailing list for new chapters. So far, no mailings have gone out to this list. If you don't have FTP or WWW access, please tell me and I will mail you chapters 1 and 2 (plain text) quickly. I am also starting an informal mailing list (translated: file of e-mail addresses) dealing with the HTML issues. Drop me a line if you want to join. I expect there will be about 10 mailings in the next month, after which things will calm down, once a web site for these things has been established. !!!!! If you reply. *please* indicate whether you want to -receive chapters 1 and 2 in plaintext -subscribe to the subsequent chapters mailing list -help with the HTML version of this book -get notification of web sites with HTML versions of this book (by mail; I will also post to rec.games.corewar) If you are not specific, I may not know what needs to be done and sit on your request for weeks, days, or months, until I get around to it. I do not know what the status is on M.Constant's Redcode Language Tutorial that is mentioned in the Corewar FAQ. As I learn what is happening here, I will mail references to document locations to the subsequent chapters mailing list. Thank you for your time and patience. -- Steven Morrell morrell@math.utah.edu From: lewin@netcom.com (Karl Lewin) Subject: Another sorter... Date: 1995/11/04 Message-ID: #1/1 newsgroups: rec.games.corewar Here is another entry for your amusement...short but gets real (and i mean REAL) slow for long datasets. (45 instructions I think) ;name Points is Points ;author Karl Lewin ;assert 1 ;strategy A simple selection sort. Not real efficient ;strategy but kinda small so maybe it won't end up losing ;strategy me too many points this round :) ;strategy ;strategy (That is if it really does work) ;strategy ;strategy I'm pretty sure that as the size of the data block ;strategy being sorted goes up, my program gets rapidly slower ;strategy so be patient if many of the samples are towards the ;strategy large end of the range :) ORG startup empty EQU last+1 INPUT EQU 4000-44 reset dat #last+INPUT+1-comploc,#last+INPUT+2-comploc comploc dat #last+INPUT+1, #last+INPUT+2 ;----------- Selection Sort (Kind of) ---------------- loop1b slt.b comploc,#last+INPUT+2-loop1b insptr jmp fndmax, #last+INPUT+1 ;---this next section is the compare routine inlined start mov.ab #0, compare sne.i @comploc,empty a_or_d jmp compare,>compare sne.b *comploc,@comploc jmp gt_a slt.b *comploc,@comploc jmp compare,>compare jmp compare gt_a sne.a *comploc,@comploc jmp.a compare slt.a *comploc,@comploc jmp compare,>compare ;---end compare routine compare sne.ab #0, #0 mov.ba comploc,comploc jmp loop1b, >comploc fndmax sne.ab reset,loop1b sorted jmp setupcp,#last+INPUT+1+2000 mov.i *comploc,>sorted mov.i @insptr,*comploc mov.i empty, @insptr nop }reset, >reset mov.i reset, comploc jmp loop1b, >insptr ;---------- Startup Section ------------------------- startup seq @loop1b,empty jmp startup,>loop1b add.ab #loop1b-comploc,loop1b sne #0, last+INPUT mov.a #1, compare jmp start ;---------- Copy & Remove Duplicates ---------------- curp dat #last+INPUT+1+2000,#last+INPUT+1 keepdup seq #0, #0 setupcp sne.a #0, last+INPUT mov.i keepdup,cpybck cpybck sne.i *curp, @curp jmp next, }curp seq.i @curp, empty jmp cpybck, >curp mov }curp, @curp next mov.ab #last+INPUT+1-curp,curp seq.i *curp,empty last jmp cpybck -- From: Beppe Bezzi Subject: My sorter Date: 1995/11/05 Message-ID: <199511051329.OAA27180@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar For you to enjoy my entry for round 4; so everyone will be able to know how not to do a paper pusher in Redcode :-) (Maybe some comment lines are wrong or unrelated (related to lines I deleted) ignore them) -Beppe Instructions: 1-Load warrior in core with data to be sorted 2-start sorting 3-take a lunch 4-check if sort is finished 5-take a coffee 6-check if sort is finished 7-take a nap 8-check if sort is finished 9-repeat 7-8 until 8 = true ;-) 10- read score m pmars -e -c 100000 -F 4000 < data.txt~& go~m lunch~m look~m coffee~m look~!!~m sleep~m look~if sort_end~! ;redcode-94 ;name sort of sorter ;author Beppe Bezzi ;contact bezzi@iol.it ;NSFCWT round 4 ;strategy enter the core in battle lust and, if the enemy is at ;strategy location 4001+, sorts it according to cell 4000 ;strategy if cell 4000 has an a-field diffrent from zero ;strategy gets enraged and kill off its duplicate cells ;assert CORESIZE > 4002 ;-) org sortem void equ start-1 moves equ start-5 buf1 equ start-10 buf2 equ start-15 start point dat 4001,4002 point1 dat 4001,4002 point2 dat 4001,4002 ;part 1 sort 'em, ascending end1 mov point1, point mov #0, moves sortem slt.b *point, @point ;x.b < x+1.b jmp lookeqb ;no look if equal .b next add.f incr, point ;yes next pair seq.i void, @point ;last pair jmp sortem ;no continue jmz.b readflb,moves ;yes no moves pass => finish jmp end1 ;repeat loop lookeqb seq.b *point, @point jmp swap ;non< non= => > => swap looka slt.a @point, *point ;x+1.a < x.a jmp next ;yes next couple jmp swap lookeqa swap mov *point, buf1 mov @point, *point mov buf1, @point jmp next, >moves readflb jmz.b readfla,4000+start ;part 2 invert order swapem sub.ab point1, point mov.b point, swloop div.ab #2, swloop sub.a #1, point1 ;point1.a points first data sw0 mov *point, buf1 ;last in buf mov *point1,*point ;first in last mov buf1, }point1 ;buf in first - incr first jmp 1, {point ;decr last swloop djn.b sw0, #0 readfla ;part 3 delete doubles jmz.a buf1, 4000+start ; here I'm jmn.b newloop-1,start+4000 ;just calculated when inverting sub.ab point1, point mov.b point, djnrem ;n. of compares newloop mov.a point2, point ;reset poin.a to first mov.i point, buf1 ;save pointer to compare mov.i }point, buf2 ;instr. to compare -> buf2 incr pointer remloop sne.i }point, buf2 ;compare and increment jmp remove, {point ;remove line seq.i void, *point ;end? jmp remloop ;no compare to same mov.a point2, point ;yes update point add.i incr, point2 ; djnrem djn newloop,#0 ;repeat to the end incr dat 1, 1 ;here to stop ;remove instruction and move block up ;data to remove is pointed by *buf1 ;neext instruction in @point remove mov.i point, point1 mov.b djnrem, djnrem1 ;set cycles mov.ab buf1, point mov.a buf1, point ;pointer at to be removed add.ab #1, point ;@point ->*point rmloop mov @point,*point add incr, point djnrem1 djn rmloop, #0 mov.i point1, point jmp newloop,#1/1 references: newsgroups: rec.games.corewar Steven C. Morrell wrote: >I do not know what the status is on M.Constant's Redcode Language Tutorial >that is mentioned in the Corewar FAQ. As I learn what is happening here, >I will mail references to document locations to the subsequent chapters >mailing list. This is what I've been mailing to everyone who asks: Sorry, the tutorial I was working on was lost when my hard drive crashed several months ago [well, at this point it's probably more like a year, but I haven't edited the form letter yet :-)]. I will probably start work on it again sometime, but I have been busy recently and it may be a while before I have recreated what I had before. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: NSFCWT - rules for round 5 Date: 1995/11/06 Message-ID: <9511061552.AA02710@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Anders Ivner wrote: >What will happen to Pspace between round 10*n and 10*n+1 ? After the end of each set of 10 rounds, P-space is cleared. This is more by neccessity than by choice, because pmars needs to be started up for each set. -Stefan From: Anders Ivner Subject: Re: NSFCWT - rules for round 5 Date: 1995/11/06 Message-ID: <9511061419.AA09011@su7-1.ida.liu.se>#1/1 newsgroups: rec.games.corewar > Relax. After sorting our opponent thoroughly, we're back to killing :-) > This is a "random" round, where you get to write a warrior that works > in an unknown core size and with an unknown process limit. The match > consists of a round-robin with 100 rounds per challenge; those 100 rounds > are broken up into 10 sets of 10 rounds with different parameters: > > Core size: 1000 .. 20000 > Process limit: 10 .. 10000 > Max. cycles: 10 * core size > Max. length: 100 > Min. distance: 100 > P-space size: core size/16 > > Core size and process limit are chosen randomly and independently in the > given interval, i.e. without human bias (let's see how this paper works with > 100 processes :). All warriors fight with the same 10 sets of rules What will happen to Pspace between round 10*n and 10*n+1 ? Secondly, may I propose a nonlinear random function for cosesize and process limit? Preferably an exponential like e^[ln1000...ln20000]. The reason for this is that the difference between a coresize of 1000 and 2000 is much bigger than between 19000 and 20000. /Anders From: Robert Macrae Subject: Re: Sorts Date: 1995/11/06 Message-ID: <47m41r$af9@soap.news.pipex.net>#1/1 references: <1995Nov5.221647@acad.drake.edu> <47l6j7$ls0@news-rocq.inria.fr> newsgroups: rec.games.corewar I agree this is a Shell sort (and I have Numerical Recipes as my guide, so it must be true) but they quote order n^1.25 for n<60 000. I guess the numbers may not be too different... They suggest using the largest value from the recursion K = 3xK + 1 which is smaller than N for the first step, and decreasing K by a factor of 3 each pass. Planar wrote: >>In general terms, a quick-sort works thusly: >> >> 1. subdivide the list by taking every Nth element >> 2. sort each sublist >> 3. reduce N >> 4. if N is greater than zero, go to 1 >> 5. when N equals zero, you are done > >This is known as Shell sort, not quicksort. Shell sort is a good >sort, quite fast (n*log(n)*log(n) asymptotic time with a well-chosen >sequence of values for N), and with small code (in C, 8 lines, while >bubble-sort takes 6 lines). (And I've just discovered another oddity of my newsreader, which is why the comment precedes the quoted text. Coming soon, a description of the recently-departed Thermite -- as soon, that is, as I can import the text of the code to said blessed newsreader.) From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: Core_Warrior_ #4 Date: 1995/11/06 Message-ID: <47lk61$aji@mozo.cc.purdue.edu> newsgroups: rec.games.corewar .xX$$x. .x$$$$$$$x. d$$$$$$$$$$$ ,$$$$$$$P' `P' , . $$$$$$P' ' .d b $$$$$P b ,$$x ,$$x ,$$x ,$$b $$. Y$$$$' `$. $$$$$$. $$$$$$ $$P~d$. d$$$b d d$$$ `$$$$ ,$$ $$$$$$$b $$$P `$ $$$b.$$b `Y$$$d$d$$$' . . a . a a .aa . a `$$$ ,$$$,$$' `$$$ $$$' ' $$P$XX$' `$$$$$$$$$ .dP' `$'$ `$'$ , $''$ `$'$ `Y$b ,d$$$P `$b,d$P' `$$. `$$. , `$$P $$$' Y $. $ $ $ Y..P $ `$$$$$$$' $$$P' `$$b `$$$P `P `$' `Y'k. $. $. $. $$' $. Issue 4 Nov 6, 1995 ______________________________________________________________________________ Core_Warrior_ is a weekly newsletter promoting the game of corewar. Emphasis is placed on the most active hills--currently the '94 draft hill and the beginner hill. Coverage will follow where ever the action is. If you have no clue what I'm talking about then check out these five-star internet locals for more information: FAQs are available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z FTP site is: ftp.csua.berkeley.edu /pub/corewar Web pages are at: http://www.stormking.com/~koth http://www.ecst.csuchico.edu/~pizza/koth ______________________________________________________________________________ Greetings. It's been two weeks since I've last forced you to read my rantings. I suppose it's time to impose my will once again. I'm happy to announce that this week's Extra Extra is written by 'guest columnist' Damien Doligez a.k.a. Planar. Thought you knew a lot about imps? Check out his thoughts on Impfinity--a continously launching imp SPIRAL ( no wimpy series of imp rings here ). As always, contributions are welcome becuase it means I don't have to write as much. 8-) ______________________________________________________________________________ Tournament Time (details at http://www.stormking.com/~koth/nsfcwt.html) Round 5 is over, and boy was it a pain to score. We had 5 fast sorters (quick-, shell-) and 8 slower bubble/insertion sorters. The fast sorters ended up holding the top 4 positions in the overall rank. The smallest sorter was Magnus Paulsson's myKindOfSort with 33 instructions; the fastest sorter was Robert Macrae's Shell Sort; and the best overall was Steven Morrell's Sort of, which ranked #6 in size and #2 in speed. Data sets: Sets ranged from 20 to 854 instructions in length (average: 409); 5 had to be sorted in ascending, 5 in descending order; duplicates had to be deleted in 6 sets. Data set 1,2,8,9 were for/rof generated; set 7 was pseudo-random number generated; the remaining sets were concatenated pre-assembled warrior codes in various pre- sort stages. An interesting set is #6 which is strongly presorted and highly redundant, taxing the deletion routines. Drop a note if you want a copy of the test sets. Sorted by length: ----------------- Length index: Program "myKindOfSort" (length 33) by "Paulsson" 0.53 Program "Mister Understudy" (length 39) by "Derek Ross" 0.626 Program "Points is Points" (length 45) by "Karl Lewin" 0.723 Program "PaulSort" (length 50) by "P.Kline" 0.803 Program "bubble gum" (length 51) by "M R Bremer" 0.819 Program "Sort of" (length 54) by "Steven Morrell" 0.867 Program "Bubble-Sort" (length 54) by "G. Eadon" 0.867 Program "SnafSort v0.5" (length 54) by "anders scholl" 0.867 Program "sort of sorter" (length 56) by "Beppe Bezzi" 0.899 Program "Shell Sort" (length 60) by "Robert Macrae" 0.964 Program "SnailSort" (length 61) by "Maurizio Vittuari" 0.98 Program "Consortium" (length 96) by "Randy Graham" 1.542 Program "Kurt's Qsort" (length 156) by "Kurt Franke" 2.506 average length: 62.23, index = length/62.23 Cycles required: set(len) P.Kline K.Franke B.Bezzi M.Bremer ---------------------------------------------------------------------------- 0 (525) 180,134 0.17 68,362 0.06 2,572,613 2.55 848,917 0.84 1 (300) 41,647 0.18 130,561 0.56 581,159 2.52 325,876 1.41 2 (300) 37,684 0.15 28,330 0.11 442,350 1.78 233,273 0.94 3 (178) 47,857 0.49 15,110 0.15 203,804 2.09 92,156 0.94 4 (854) 475,822 0.20 98,277 0.04 5,347,465 2.31 2,561,037 1.10 5 (268) 77,508 0.33 32,379 0.14 611,536 2.64 238,839 1.03 6 (401) 80,204 0.20 27,064 0.06 1,215,022 3.05 541,308 1.35 7 (499) 233,783 0.29 64,632 0.08 1,759,465 2.25 686,847 0.87 8 (20) 624 0.57 1,118 1.02 754 0.69 211 0.19 9 (750) 200,345 0.11 89,910 0.05 3,535,038 2.05 2,078,960 1.20 --------------------------------------------------------------------------- Avg. index 0.27357668 0.23163087 2.19801421 0.99347397 R.Macrae R.Graham S.Morrell M.Paulsson ---------------------------------------------------------------------------- 0 (525) 64,221 0.06 55,898 0.05 39,789 0.03 920,836 0.91 1 (300) 25,475 0.11 36,610 0.15 19,515 0.08 97,355 0.42 2 (300) 20,751 0.08 33,550 0.13 19,082 0.07 295,648 1.19 3 (178) 15,439 0.15 14,308 0.14 12,268 0.12 107,230 1.10 4 (854) 110,751 0.04 96,670 0.04 85,497 0.03 2,691,899 1.16 5 (268) 56,023 0.24 27,615 0.11 20,602 0.08 195,258 0.84 6 (401) 27,837 0.06 154,935 0.38 124,374 0.31 29,740 0.07 7 (499) 61,767 0.07 46,844 0.05 38,149 0.04 811,726 1.03 8 (20) 519 0.47 408 0.37 646 0.59 1,240 1.13 9 (750) 85,285 0.04 73,101 0.04 60,245 0.03 2,092,599 1.21 --------------------------------------------------------------------------- Avg. index 0.13824197 0.15245615 0.14426386 0.91166251 G.Eadon D.Ross K.Lewin M.Vittuari ---------------------------------------------------------------------------- 0 (525) 1,711,257 1.70 1,241,525 1.23 1,528,707 1.51 1,648,478 1.63 1 (300) 32,628 0.14 131,559 0.57 416,132 1.80 619,280 2.68 2 (300) 303,303 1.22 316,321 1.27 499,758 2.02 383,131 1.54 3 (178) 104,887 1.07 112,616 1.15 178,306 1.83 175,408 1.80 4 (854) 2,641,569 1.14 2,575,723 1.11 4,045,693 1.75 4,688,083 2.03 5 (268) 178,923 0.77 255,462 1.10 397,633 1.72 471,450 2.04 6 (401) 45,728 0.11 40,272 0.10 698,546 1.75 858,134 2.15 7 (499) 947,669 1.21 1,120,708 1.43 1,377,600 1.76 1,187,956 1.52 8 (20) 629 0.57 1,957 1.79 2,436 2.23 307 0.28 9 (750) 1,882,398 1.09 1,969,529 1.14 3,107,832 1.80 3,694,820 2.15 --------------------------------------------------------------------------- Avg. index 0.90663812 1.09411928 1.82153461 1.78592881 A.Scholl ---------------------- 0 (525) 2,204,582 2.19 1 (300) 535,834 2.32 Numbers are given as: 2 (300) 601,235 2.43 Cycles Index 3 (178) 184,700 1.89 where Index is Cycles/AvgCycles 4 (854) 4,589,327 1.98 5 (268) 548,652 2.37 6 (401) 1,335,274 3.35 7 (499) 1,820,651 2.33 8 (20) 3,321 3.04 9 (750) 3,470,048 2.01 ---------------------- Avg. index 2.39604507 Sorted by speed: ---------------- Program "Shell Sort" (length 60) by "Robert Macrae" 0.13824197 Program "Sort of" (length 54) by "Steven Morrell" 0.14426386 Program "Consortium" (length 96) by "Randy Graham" 0.15245615 Program "Kurt's Qsort" (length 156) by "Kurt Franke" 0.23163087 Program "PaulSort" (length 50) by "P.Kline" 0.27357668 Program "Bubble-Sort" (length 54) by "G. Eadon" 0.90663812 Program "myKindOfSort" (length 33) by "Paulsson" 0.91166251 Program "bubble gum" (length 51) by "M R Bremer" 0.99347397 Program "Mister Understudy" (length 39) by "Derek Ross" 1.09411928 Program "SnailSort" (length 61) by "Maurizio Vittuari" 1.78592881 Program "Points is Points" (length 45) by "Karl Lewin" 1.82153461 Program "sort of sorter" (length 56) by "Beppe Bezzi" 2.19801421 Program "SnafSort v0.5" (length 54) by "anders scholl" 2.39604507 Overall rank (length index * speed index): ------------- pts. Program "Sort of" (length 54) by "Steven Morrell" 0.12507677 13 Program "Shell Sort" (length 60) by "Robert Macrae" 0.13326526 12 Program "PaulSort" (length 50) by "P.Kline" 0.21968207 11 Program "Consortium" (length 96) by "Randy Graham" 0.23508738 10 Program "myKindOfSort" (length 33) by "Paulsson" 0.48318113 9 Program "Kurt's Qsort" (length 156) by "Kurt Franke" 0.58046696 8 Program "Mister Understudy" (length 39) by "Derek Ross" 0.68491867 7 Program "Bubble-Sort" (length 54) by "G. Eadon" 0.78605525 6 Program "bubble gum" (length 51) by "M R Bremer" 0.81365518 5 Program "Points is Points" (length 45) by "Karl Lewin" 1.31696952 4 Program "SnailSort" (length 61) by "Maurizio Vittuari" 1.75021023 3 Program "sort of sorter" (length 56) by "Beppe Bezzi" 1.97601477 2 Program "SnafSort v0.5" (length 54) by "anders scholl" 2.07737108 1 Name pts for round 1 2 3 4 5 6 7 8 | Total so far ________________________________________________________________________ Beppe Bezzi 7 7 13 2 | 29 M R Bremer 7 4 3.6 5 | 19.6 G. Eadon 1.5 2 5 6 | 14.5 Randy Graham - - 8 10 | 18 Anders Ivner 5.5 8 4 - | 17.5 P.Kline 7.5 9 7 11 | 34.5 Karl Lewin - - 10 4 | 14 John Lewis - - 3 - | 3 Calvin Loh - - 1 - | 1 Steven Morrell 5 10 9 13 | 37 Paulsson 7.5 11 11 9 | 38.5 Derek Ross 3.5 3 3.3 7 | 16.8 Anders Scholl - 1 2 1 | 4 Maurizio Vittuari 6.5 5 6 3 | 20.5 John K. Wilkinson 4 6 12 - | 22 Robert Macrae - - - 12 | 12 Kurt Franke - - - 8 | 8 Good luck for round 5, Nandor & Stefan ______________________________________________________________________________ Current Status of the Internet Pizza Server ICWS '94 Draft Hill: Hill Specs: coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 rounds fought: 250 instruction set: ICWS '94 Draft Last challenge: Mon Nov 6 09:53:41 PST 1995 # %W/ %L/ %T Name Author Score Age 1 40/ 41/ 19 Porch Swing + Randy Graham 140 38 2 41/ 43/ 15 Frontwards Steven Morrell 139 272 3 37/ 36/ 28 endpoint . M R Bremer 138 18 4 33/ 28/ 39 Phq Maurizio Vittuari 138 439 5 31/ 26/ 42 Jack in the box Beppe Bezzi 136 325 6 36/ 35/ 29 Armory 6.1 Wilkinson 136 6 7 34/ 32/ 34 Torch t18 P.Kline 136 337 8 40/ 45/ 15 Leprechaun on speed Anders Ivner 135 133 9 36/ 39/ 25 myZizzor Paulsson 134 68 10 36/ 38/ 25 myVamp v3.7 Paulsson 134 305 11 26/ 19/ 55 Impfinity v3e7 Planar 132 2 12 33/ 35/ 32 Armory - A5 Wilkinson 132 476 13 39/ 46/ 15 Leprechaun deluxe Anders Ivner 132 242 14 29/ 26/ 45 .Brain Vamp. B.Bezzi, M.Paulsson 131 39 15 24/ 19/ 57 Tican John Wilkinson 130 31 16 32/ 35/ 32 Tornado 1.8 Beppe Bezzi 129 191 17 24/ 19/ 57 paper01o Beppe Bezzi 129 15 18 18/ 7/ 75 Chugging Along Karl Lewin 128 22 19 37/ 47/ 16 Anti Die-Hard Bevo (3c) John Wilkinson 127 142 20 28/ 33/ 40 test ss04 Beppe Bezzi 123 1 It's been a sloooooooowwwww week for the '94 draft hill. I suspect most authors are polishing up their more benign programming skills by writing sorting algorithms instead of blood thirsty warriors. Beppe Bezzi has been testing away giving all the warriors on the hill some easy 'age'. A new version of Father and Son appeared and that's about it. ( The real action is on the beginner's hill this week! ) ______________________________________________________________________________ 94 - What's New 3 37/ 36/ 28 endpoint . M R Bremer 138 18 6 36/ 35/ 29 Armory 6.1 Wilkinson 136 6 11 26/ 19/ 55 Impfinity v3e7 Planar 132 2 17 24/ 19/ 57 paper01o Beppe Bezzi 129 15 20 28/ 33/ 40 test ss04 Beppe Bezzi 123 1 Seems John decided to polish up Armory and resubmit it. You ARE going to kill off your old version, right? 8) Congratulations to Planar for getting a warrior on the '94 draft hill. ______________________________________________________________________________ 94 - What's No More 21 23/ 66/ 10 Tornado 1.9a Beppe Bezzi 80 0 Bezzi pushes off his own warrior with a test. I guess there are worse ways to go. . . ______________________________________________________________________________ HALL OF FAME * means the warrior is still running; > score isn't exact Pos Name Author Age Strategy 1 Iron Gate 1.5 Wayne Sheppard 926 CMP scanner 2 Agony II Stefan Strack 912 CMP scanner 3 Blue Funk Steven Morrell 869 Stone/ imp 4 Thermite 1.0 Robert Macrae 802 Qscan -> bomber 5 Blue Funk 3 Steven Morrell 766 Stone/ imp 6 HeremScimitar A.Ivner,P.Kline 666 Bomber 7 B-Panama X Steven Morrell 518 Stone/ replicator 8 Armory - A5 Wilkinson 476 * P-warrior 9 Phq Maurizio Vittuari 439 * Qscan -> replicator 10 NC 94 Wayne Sheppard 387 Stone/ imp 11 Cannonade P.Kline 382 Stone/ imp 12 Torch t17 P.Kline 378 Bomber 13 Lucky 3 Stefan Strack 355 Stone/ imp 14 Request v2.0 Brant D. Thomsen 347 Qvamp -> vampire 15 Dragon Spear c w blue 346 CMP scanner 16 Torch t18 P.Kline 337 * Bomber 17 juliet storm M R Bremer 333 Stone/ imp 18 Jack in the box Beppe Bezzi 325 * P-warrior 19 TimeScape (1.0) J. Pohjalainen 322 Replicator 20 Rave 4.1 Stefan Strack 320 CMP scanner Torch t18 moves up to number 16 from number 19. Jack in the Box also moves up this week. myVamp is next in line to enter the HALL OF FAME. Thanks to Steven Morrell for providing missing data. ______________________________________________________________________________ Current Status of the Internet Pizza Server Beginner's Hill: Hill Specs: coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 maximum age: At age 100, warriors are retired. rounds fought: 250 instruction set: ICWS '94 Draft Last challenge: Mon Nov 6 07:08:38 PST 1995 # %W/ %L/ %T Name Author Score Age 1 42/ 27/ 31 Lurker 1.1 Kurt Franke 156 28 2 29/ 11/ 60 juliet storm M R Bremer 148 67 3 39/ 31/ 29 Test-Fc G. Eadon 147 53 4 28/ 13/ 59 Trapper 1.1 Kurt Franke 143 3 5 38/ 40/ 22 Searching Kurt Franke 135 34 6 39/ 44/ 17 Heatseek2 Phil Whineray 135 45 7 31/ 32/ 37 Hint Test v4 M R Bremer 131 1 8 20/ 10/ 71 Impfinity v3c11 Planar 130 10 9 17/ 9/ 74 Sheet 1.0 J. Doster 125 8 10 16/ 10/ 74 Paper8 G. Eadon 123 29 11 11/ 5/ 84 Impfinity v1 Planar 117 42 12 13/ 11/ 76 RingWorm_v1.0 Calvin Loh 114 14 13 12/ 10/ 78 RingWorm_v1.4 Calvin Loh 114 12 14 16/ 20/ 63 NewPaper Kurt Franke 112 15 15 15/ 21/ 64 Paper Dragon Kurt Franke 110 24 16 20/ 31/ 49 Morgenshtern II+ Don Julian 108 4 17 23/ 37/ 40 Weasel Kurt Franke 108 59 18 11/ 16/ 73 P_Banzai_v1.2 Calvin Loh 105 16 19 11/ 20/ 69 Cyclone Scott Manley 103 55 20 20/ 40/ 40 Forked Lite Ning 4.02 Ansel Greenwood Serm 101 19 The beginner hill has been active. Since I've last wrote, the hill as aged by approximately 37 warriors. And most of these weren't repeated tests, either. Kurt Franke decided he didn't like the rankings on the hill, so he went about changing them. First came the scanners: Weasel, Lurker, Searching. That was all good for juliet's reign. Unsatisfied, Franke probed juliet's weaknesses with Paper Dragon and NewPaper. Coupled with papers from G. Eadon ( Paper8 ) and J. Doster ( Sheet 1.0 ), Lurker was able to claim the top slot. Congratulations. Phil Whineray has been quiet ever since the introduction of Heatseek 2. Heatseek has hung around on the top despite the efforts of Franke and others. Hopefully, he'll have something ready before his warrior dies of old age. Speaking of which, two programs--Mythicon and Shadow Imp--proved to be too tough to kill in 100 challenges. I hope to see new and improved versions soon. ______________________________________________________________________________ The Hint Core_Warrior_ #2 contained some improvements to Scott Manley's Mutagen. We are going to continously improve this warrior until it reaches the top of the beginner hill. Daunting challenge? We'll see. The code that _was_ residing on the beginner hill is included below: ;redcode-b ;name Hint Test v2 ;author M R Bremer ;strategy Original code based on Scott Manley's Mutagen ;strategy Once through scan --> spl spl dat dat coreclear ;strategy Core_Warrior_ #2: compressed code ;kill Hint ;assert CORESIZE==8000 step EQU 11 begin SPL a1+2 jmp start for 20 dat 0, 0 rof start add.f split, scan scan sne.i 112, 113 djn.f -2, <-400 ;djn.f will decrement both the a and b field mov.i split, *scan mov.i jump, @scan jmn.b -5, scan jmp a1 split spl #step, #step ;try to find other uses for these jump jmp -1 ;can be anywhere in code DAT 0 , 0 DAT 0 , 0 DAT 0 , 0 ptr1 dat a1, out+200 a4 dat 0, out+2+1 a3 dat 1, out+2+2 a2 spl #2, out+2+3 a1 spl #3, out+2+4 mov *ptr1, >ptr1 mov *ptr1, >ptr1 mov *ptr1, >ptr1 out djn.f -3, <4000 END begin Hint Test was introduced onto the hill at #7. All the replicators that have landed on the hill ( thanks to Beppe Bezzi's hints I believe ) have pushed it even higher. Unless you're in a coma, you may have figured out that papers are going to be a lot tougher in the future due to the optimization procedures Bezzi wrote about. For Mutagen to survive, we are going to have to improve its scanner element. And you other scanner boys have been scoring way too many points against Mutagen. Time for that to end. A pspaced bomber should do the trick. Lucky for you, we'll save that step until Bezzi presents a The Hint on bombers next week. SCANNERS: That's a big topic. There are two general types of scans--jmz scanners and cmp scanners. A jmz scanner is very small but only scans core at 1 scan in a two instruction loop or .5c. A simple jmz scanner could look something like this: inc add.ab #8, scan ;set up location to scan scan jmz.f -1, 100 ;if both value at b-field = 0, goto inc attack mov bomb, @-1 ;attack jmn.a -3, -2 ;check to see if done bomb spl #0, <-10 mov 1, -1 bombs for additional stun power. myZizzor by Paulsson uses a once through jmz scan with variable length spl 0 carpet to great effect. One version is published. Get your copy today. Cmp scanners are bigger, but faster. They can scan 2 locations in a three instruction loop for a speed of .66c. The basic scan engine looks something like this: inc add step, scan scan cmp 100, 112 ;remember that cmp is the same is seq! slt.ab #special_value, scan ;we'll talk about the value later djn.f inc, check clear step dat X, X Since most of core is filled with dat 0, 0's, the cmp instruction will most likely being comparing these empty core locations. Therefore it will skip the slt instruction. The add/cmp/djn cycle will repeat until either the a or b operand point to different instructions. One of these locations ( a or b ) may have the enemy code. When the cmp finds something, the slt instruction is executed. This instruction is used to protect the scanning code from bombing itself. When the scan finds itself, the slt checks one of the pointers and makes sure that it is greater than the last instruction in the scanner. If it is, it will skip the djn instruction and do the attack routine. Otherwise the djn will be executed and it will continue to scan. Notice that the first two instructions are not protected. We can use this fact to determine when to start the coreclear. This will become more clear later with some examples I hope. Although cmp scanners are faster, we have to have some way of checking or attacking _both_ the a and b targets. Afterall, the enemy code can potentially be at a or b ( or maybe both ). I know of two approaches. Attack the b value and then add a special offset to the scan to make the last scan's a value be the b value. That way, if there is something there, it will get attacked on the second 'special' scan. Iron Gate uses this approach and is included below ( I hope the author doesn't mind ): ;redcode ;name Iron Gate ;author Wayne Sheppard ;strategy CMPscanner dist equ 98 scan equ dist*2 a add d,@x c cmp a+dist,a slt #20,@x djn a,<7000 mov j,@c x mov s,-IVAL+1 mov incr,<-2 incr dat >-IVAL,>-IVAL Agony compares location N and N+12. Its scan phase operates much the same as Iron Gate. However, it has a completely different method of attacking both the a and b pointers. If it finds something, it will bomb locations N, N+1, N+2, . . . N+12, N+13, N+14, and N+15 with spl 0's. Again, the coreclear is started ( the jmn drops through ) when Agony attack its own code that is not protected. We are going to utilize Iron Gate's constants and basic structure, but attack the a and b locations specifically. dist equ 98 scan equ dist*2 a add d,c c cmp a+2*dist,a+dist slt.a #dist+m-a, c djn.f a,<7000 mov s, *c x mov m, @c jmn a,a s spl #-dist+1, <0 mov 1, <-3 d dat spl spl dat dat coreclear ;strategy Core_Warrior_ #2: compressed code ;strategy Core_Warrior_ #4: improved scanner ;kill Hint ;assert CORESIZE==8000 dist equ 98 scan equ dist*2 begin SPL b1+2 jmp a for 20 dat 0, 0 rof a add d,c c cmp a+2*dist,a+dist slt.a #dist+ptr2-a, c djn.f a,<7000 mov s, *c x mov m, @c jmn a,a s spl #-dist+1, <0 mov *ptr2, . ______________________________________________________________________________ Extra Extra: This is Impfinity v1. Seeing how Imp Craze did well (but it's falling off the beginner hill even as I'm writing this), I started thinking harder about imp spirals. I was dreaming of an spiral with an ever-growing number of processes. This would be very hard to kill. It turns out this can be done by continuously launching the spiral. I started with the standard binary launch. In a binary launch, you draw a binary tree of SPLs, and you put jumps to the imp processes at the leaves. For a 3-process spiral, you have this tree: A / \ B C / \ | D E F And here is the corresponding redcode: A spl C B spl E D jmp imp E jmp imp+step C nop F jmp imp+2*step imp mov 0, step Here is what happens when you launch it. I'll represent the run queue as a list of labels. We start with only A in the run queue: [A]. We execute the first instruction in the run queue (instruction at A). This is an spl, so it will push back at the end of the queue, first its following instruction (B), then its target (C): [B C]. We then execute the next instruction: B. It is also an spl, so it pushes back D and E: [C D E]. Then we execute C. It does nothing and pushes the next instruction (F) into the queue: [D E F]. We now execute D, E, and F which jump to the three parts of the ring: [imp imp+step imp+2*step]. Now the imp ring is launched. So we see that the program will execute the tree in top-to-bottom order: A then B, C then D, E, F. Let's add an instruction at the start: Z spl Z This adds a loop at the top of the tree (not easy to draw): +-+ | | Z-+ | A ... etc. This spl-loop will send processes down the tree, one after the other: [Z] [A Z] [B C A Z] [D E F B C A Z] [imp imp+step imp+2*step D E F B C A Z] etc. I'll call "rounds" the lines in this sequence: one round is executing all the processes in the process queue. (This is what the cdb command "thread" does: execute one round.) So we can launch imp ring after imp ring. This is not a true spiral because the process queue after the next round is: [imp+1 imp+step+1 imp+2*step+1 imp imp+step imp+2*step D E F B C A Z] A true imp spiral would be: (imp+2 is the same as imp+3*step+1) [imp+1 imp+step+2 imp+2*step+1 imp+2 imp+step+2 imp+2*step+2 ...] So we need to add 2 to each JMP instruction in each round. We can do this with a-field postincrement addressing mode, because we have six nodes in our tree, and each node is executed once in each round. A spl C, }D B spl E, }E D jmp imp, }D E jmp imp+step, }E C nop }F F jmp imp+2*step, }F imp mov 0, step This is almost working code. We now have to adjust the JMPs to compensate for the incrementations during the first few rounds, and we get the code to launch a continously-growing imp spiral: Z spl Z A spl C, }D B spl E, }E D jmp imp-2, }D E jmp imp+step-1, }E C nop }F F jmp imp+2*step-1, }F imp mov 0, step And this is all there is to Impfinity. I have used the idle cycle at C to launch a bombing process. This is not nearly enough bombing to do much difference. Impfinity wins mostly by overrunning the opponent with its spiral. It resists anti-imp programs thanks to its unorthodox spiral size. This is the code: ;redcode-b ;name Impfinity v1 ;author Planar ;strategy continuous-launching 13-point imp spiral + a few incendiary bombs ;assert CORESIZE == 8000 step equ 3077 bstep equ -50 binit equ -200 org a bomb1 spl #6, <2667 bomb2 mov.i -1, {-1 a spl #binit, }z0 b spl d, }z1 c spl f, }z2 e spl j, }z4 i spl z1, }z8 z0 jmp imp-5, }z0 z1 jmp imp+step-4, }z1 j spl z3, }z9 z2 jmp imp+2*step-3, }z2 z3 jmp imp+3*step-3, }z3 f spl l, }z5 k spl z5, }z10 z4 jmp imp+4*step-2, }z4 z5 jmp imp+5*step-2, }z5 l spl z7, }z11 z6 jmp imp+6*step-2, }z6 z7 jmp imp+7*step-2, }z7 d spl h, }z3 g spl n, }z6 m spl z9, }z12 z8 jmp imp+8*step-1, }z8 z9 jmp imp+9*step-1, }z9 n mov.i bomb1, }a z10 jmp imp+10*step-1, }z10 h spl p, }z7 o mov.i bomb2, *a z11 jmp imp+11*step-1, }z11 p add.a #bstep-1, a z12 jmp imp+12*step-1, }z12 imp mov.i #1, step end I'd like to add a word about the choice of a spiral size. There is one warrior on the beginner hill with a 9-point spiral. I think this is a bad idea. Because 2667 is a multiple of 889, an anti-3-point-imp bomb (dat <2667, <5334) will also cause a 9-point spiral to decrement its own instructions. (The same is true for any multiple of 3.) Against myZizzor, for example, a 9-point version of Impfinity get very bad scores compared to a 7-point version or an 11-point version. So if you choose a big size for your spiral, make it a prime number. Finally, you may want to know if there's a way of doing an SPL/ADD continuous launch. Yes. That's what Impfinity v3 uses (soon on a hill near you--I hope). A vector launch is also possible, but I haven't written the code yet. My warriors are not very good, but they are fun to write. http://pauillac.inria.fr/~doligez/corewar/ EDITOR'S NOTE: Damien is much too modest. Imp spirals are one of the most difficult subjects to understand. Impfinity missed the '94 draft hill by only a fraction of a point. I'm sure he'll breach the hill very soon. Spoke too soon. Impfinity has just entered the hill as I am posting. ______________________________________________________________________________ Questions? Concerns? Comments? Complaints? Mail them to: Beppe Bezzi or Myer R Bremer From: Planar Subject: Re: Sorts Date: 1995/11/06 Message-ID: <47l6j7$ls0@news-rocq.inria.fr>#1/1 references: <1995Nov5.221647@acad.drake.edu> newsgroups: rec.games.corewar >In general terms, a quick-sort works thusly: > > 1. subdivide the list by taking every Nth element > 2. sort each sublist > 3. reduce N > 4. if N is greater than zero, go to 1 > 5. when N equals zero, you are done This is known as Shell sort, not quicksort. Shell sort is a good sort, quite fast (n*log(n)*log(n) asymptotic time with a well-chosen sequence of values for N), and with small code (in C, 8 lines, while bubble-sort takes 6 lines). Quicksort is asymptotically better and has a good constant, but it is really messy to implement, especially in redcode, because it's recursive (and it has quadratic worst-case). -- Planar P.S. I can describe Fibonacci-sorting without looking in my books first. Ha ! From: John K W Subject: Re: Strategy Date: 1995/11/06 Message-ID: <47jkcf$cft@geraldo.cc.utexas.edu>#1/1 references: <199511021118.MAA23122@ifm.liu.se> newsgroups: rec.games.corewar >And since MyZizzor beats up on all the new paper-imp combo's very >effectively, there really isn't much of a need for complexity right now, >is there? :-) It doesn't beat -my- papers! :P >MyZizzor is actually *very* sophisticated overall. It's just that most of >its components have been around for a long time. Yeah, I like it... I think there might be one improvement too, I've been working on it... :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Finished Round 4 Date: 1995/11/06 Message-ID: <47jj8s$cft@geraldo.cc.utexas.edu>#1/1 references: <1995Nov3.121139.3021@rhodes> newsgroups: rec.games.corewar graham@hal.mathcs.rhodes.edu (Randy Graham) wrote: >Randy > >P.S. Paul, I found info about the Fibonacci sort in an algorithm book >I have. Looks really neat. The crazy thing is, I think I understand >it, based on the description they give. In fact, if I had seen it >earlier, I might have tried using it. It is VERY efficient >speed-wise, but it might take a goood bit of code to execute. I would be very happy if you would describe that one to me... It sounds interesting... -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: "Andersen F. Scholl" Subject: Re: NSFCWT round 4: the good, the bad and the ugly Date: 1995/11/07 Message-ID: #1/1 newsgroups: rec.games.corewar On Tue, 7 Nov 1995 pk6811s@acad.drake.edu wrote: > OK, all in favor of repeating this round hold up your hands! Next time i am very much in favor of repeating this round (i want to see how i would do if i didn't have to invent my own algorithm ;) .....if it's repeated, though, i think it would be interesting to have the second flag be something other than deleting like instructions.....or perhaps have 4 flags as paramaters instead of two... From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: P-space Date: 1995/11/07 Message-ID: <9511080001.AA03075@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar dweezil@alpha1.csd.uwm.edu (Andrew S Mehlos) wrote: >Where can I find a summary/tutorial type thing for P-space? Heck, even an >explanation of how it works would be great. (specifically, how does one go >about writing a warrior that changes strategies based on the last round?) > This will eventually go into the FAQ list, but for now you can get some info from the file whatsnew.080 in the pMARS distribution. For online reading: http://www.stormking.com/~koth/pmars.html (the pmars.html at pizza is outdated). Many of the recently posted warriors use P-space. Planar's web-page (URL in the last CoreWarrior issue) has them within easy reach. -Stefan P.S.: Round 6 of NSFCWT will be all about P-space. You'll get to write warriors that consist entirely of P-switching code, nothing else. Stay tuned .. From: dweezil@alpha1.csd.uwm.edu (Andrew S Mehlos) Subject: P-space Date: 1995/11/07 Message-ID: <47odjr$98t@uwm.edu>#1/1 newsgroups: rec.games.corewar Where can I find a summary/tutorial type thing for P-space? Heck, even an explanation of how it works would be great. (specifically, how does one go about writing a warrior that changes strategies based on the last round?) -- -[ "Pfftkammmmreow...mrrrrrrrrrriow..mew..meeeeeowmeow.."-- My cat ]- -[ Finger for PGP key | Mmmmmmmmmmmm... Doughhhhhnuts! ]- -["I'm told it [superstition] works whether you believe in it or not. " ]- -[ --N. Bohr ]- From: pk6811s@acad.drake.edu Subject: Re: NSFCWT round 4: the good, the bad and the ugly Date: 1995/11/07 Message-ID: <1995Nov7.121152@acad.drake.edu>#1/1 references: <9511062254.AA02816@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) writes: > Actually, it's more like the smallest, the fastest, and the best overall :-) [three nice sorts] OK, all in favor of repeating this round hold up your hands! Next time I'm going to look something up in a book (only to make sure I get the name right, of course :-) Paul Kline pk6811s@acad.drake.edu From: John K W Subject: Re: Defence in Redcode Date: 1995/11/07 Message-ID: <47o5dp$d49@geraldo.cc.utexas.edu>#1/1 references: <47nu72$hce@griffin.ccc.nottingham.ac.uk> newsgroups: rec.games.corewar >For example, if p-space could hold complete instructions >then it would be possible to hold a programs own code >(or even the enemy!) in memory for use in repairing bombed >instructions quickly. This method would still allow p-space >to be used as it is now (although I think a few >addressing modes may change...), but at the same time add >a huge amount of flexibility to corewar. That's a good question... why DOESN'T pspace hold complete instructions? The only thing I can think of is that LDP.I could be used for bombing like a MOV.I... would that be a problem? I dunno, using LDP.I for bombing could be really useful for stones and scanners (cut off one length of size) or papers (allow ALL of the the paper to simultaneously switch from SPL bombing to DAT bombing!) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: psyktpc@unix.ccc.nottingham.ac.uk (Timothy Chapman) Subject: Defence in Redcode Date: 1995/11/07 Message-ID: <47nu72$hce@griffin.ccc.nottingham.ac.uk>#1/1 newsgroups: rec.games.corewar I was just thinking the other day about corewar, and it occured to me that there is actually no practical way to add a defensive element to a static program. All strategies involve a kill-them-before-they-get-you approach. Paper warriors are one alternative, but it's hardly as if they are "defensive". Self-repair programs are just too hard to implement in Redcode as it stands and so are virtually non-existant. So what can be done? One thing would be to extend Redcode in some way, perhaps using the new p-space techniques. For example, if p-space could hold complete instructions then it would be possible to hold a programs own code (or even the enemy!) in memory for use in repairing bombed instructions quickly. This method would still allow p-space to be used as it is now (although I think a few addressing modes may change...), but at the same time add a huge amount of flexibility to corewar. Another alternative would be to have a small private stack (LIFO?) for each program that could store whole instructions. This method would be more complex though, and would require new psh and pop instructions. So what do you think? Tim Chapman ps. Although I'm only spectating, I think this current tournament is excellent... here's looking forward to the next round! :-) From: pk6811s@acad.drake.edu Subject: Re: myZizzor Date: 1995/11/07 Message-ID: <1995Nov7.091944@acad.drake.edu>#1/1 newsgroups: rec.games.corewar myZizzor is a very nice, simple warrior with a nice, simple solution that goes back to the earliest days of core wars. First there were bombers, then there was... Gemini! The first bombers used small, positive increments, and did not use a djn stream. Gemini's strategy was to copy itself forward and jump to the new copy at a rate that kept just ahead of the bombing run. Evenually it would overwrite the bomber and kill it. The same strategy works against myZizzor with this more modern, redundant version: ;redcode-94m quiet ;name test ;kill test ;strategy gemini - jump ahead of scanning/bombing run ; start spl 1 ; spl 1 ; make 8 processes spl 1 ; spl g2 g1 spl @0,43 ; jump to next location mov }g1,>g1 ; move code there mov 2,>1 ; little bombing dat 1,28 for 4 dat 1,1 rof for 50 dat 1,1 rof g2 spl @0,43 ; jump to next location mov }g2,>g2 ; move code there mov 2,>1 ; little bombing dat 1,28 for 4 dat 1,1 rof end start myZizzor forward scans with a step of 8 which is faster than we are jumping, but once he finds the first abandoned copy he is reduced to a .3c carpet bomber with which we can keep up. Hopefully one of the two copies will overrun myZizzor before he goes into the sweep/djn process. Once he starts clearing we do keep ahead of the forward clear, but that backward djn sometimes gives trouble. Once people starting experimenting with larger bomb steps, Gemini was doomed. And then came mice... There are other solutions to myZizzor such as backward scanning with a step of 9. In general when two opponents are of similar size and scanning with small step sizes in opposite directions (one backward, the other forward) the one with the larger step will always win. Future pspacers might find it useful to include a combination forward/ backward scanner using a medium step size as a sort of anti-body mechanism against this class of opponents. Just run it until it loses. Paul Kline pk6811s@acad.drake.edu From: Planar Subject: Re: Sorts Date: 1995/11/07 Message-ID: <47nlkd$6kr@news-rocq.inria.fr>#1/1 references: <1995Nov5.221647@acad.drake.edu> <47l6j7$ls0@news-rocq.inria.fr> <47m41r$af9@soap.news.pipex.net> newsgroups: rec.games.corewar Warning: I'm going to pedantic mode here, and this doesn't have much to do with Core War. In article <47m41r$af9@soap.news.pipex.net>, Robert Macrae writes: >I agree this is a Shell sort (and I have Numerical Recipes as my guide, >so it must be true) but they quote order n^1.25 for n<60 000. I guess the >numbers may not be too different... > >They suggest using the largest value from the recursion K = 3xK + 1 which >is smaller than N for the first step, and decreasing K by a factor of 3 >each pass. That's right, and it's the most common implementation of Shell sort. But Vaughn Pratt earned a PhD by proving that you can get O(n*logn*logn) by using the numbers of the form (2**n * 3**p) (in decreasing order, starting with the largest one that is smaller than n). There is a small and simple algorithm for generating the numbers in increasing order. Store them in an array, and you're all set. >>> 1. subdivide the list by taking every Nth element >>> 2. sort each sublist >>> 3. reduce N >>> 4. if N is greater than zero, go to 1 >>> 5. when N equals zero, you are done Actually, this is Shell sort only if you use insertion sort in step 2 above. If you use bubble sort, this was published in Byte a few years ago. I forget the name of the algorithm. >Coming soon, a description of the >recently-departed Thermite -- as soon, that is, as I can import the text >of the code to said blessed newsreader.) I say the sooner the better. -- Planar From: John K W Subject: (no subject) Date: 1995/11/07 Message-ID: <47mvin$mql@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar So, did anyone ever heavily consider the ";fight" option? You know, to allow a warrior to just fight against one (or more) other warriors on the hill? Also, is Pizza still using the -F option? Also also, is Pizza ever gonna get a "Warriors about to be played" thingie on the web page? Also also also, can the one of the 94 hills be moved to Stormking in order to even things out? Comments and answers welcome. Thanks for readin'. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: rognlie@lute.gcr.com (Richard W. Rognlie) Subject: Richard's C++Robots Server -- Monthly Post Date: 1995/11/07 Message-ID: <47miep$6gu@ukelele.qnet.com> newsgroups: rec.games.programmer,comp.lang.c,comp.lang.c++,rec.games.corewar,comp.ai.games,comp.programming.contests Richard's C++Robots Server Monthly Posting A generic Play-By-eMail Server has been set up at pbmserv@vtsu.prc.com. It currently supports a variety of games. Of particular interest to this forum is C++Robots. Abalone Ataxx Backgammon C++Robots Connect4 Connect4x4 Gomoku Hex Jungle Lines-of-Action Neutron Othello Pente Philosopher's Football Plotto Qubic Score4 Survival Tanbo & Tanbo3D Terrace Trax & StdTrax Twixt To get more information send mail to pbmserv@vtsu.prc.com with 'help' as the subject line. Or connect to my WWW page at: http://140.188.198.26:8080/~pbmserv Games Currently Supported C++Robots (Copyright (c) 1994 Richard Rognlie) An ongoing "King of the Hill" (KotH) tournament in which players use ANSI C or C++ to create a control program for a robot. Your robot then fights each of the other robots "on the hill". If you do well enough, your robot will "make the hill", bumping the lowest robot from the hill. Robots have the ability to scan for opponents, fire a cannon, move, and determine current position and status. Conceptually based on C-Robots written for the IBM PC by Tom Pointdexter. Abalone On a hexagonal board (radius 5) two to six players have armies of marbles. Players take turns "pushing" 1, 2 or 3 linearly connected marbles, attempting to push their opponents' marbles off the board. Ataxx On a 7x7 board, the two players of ataxx fight to controll a majority of the board via growth and jumps that flip opponents pieces to their color. Backgammon A classic. Connect4 On a 7x6 board, two players alternate dropping their pieces from the top of the board, down a column, attempting to form four in a row. Connect4x4 On an 8x8 board, two players alternate inserting their pieces from the edges of the board, across a row or up/down a column, attempting to form four in a row. Gomoku On a 15x15 board, the two players of gomoku try to be the first to create a line of 5 or more stones in a row of their color. Hex On a 11x11 diamond board, players take turns placing stones of their color on the board. The object is to connect your sides of the board while preventing your opponent from doing the same. Jungle Jungle is sort of a cross between Chinese chess and Stratego. It's popular in China as a children's "stepping-stone" to Chinese chess. It's also an interesting game in its own right. Lines-of-Action The object of the game is to move all your pieces into a configuration where they are in a single group connected horizontal, vertically, or diagonally. Pieces may move horizontally, vertically, or diagonally, but they must move exactly the number of spaces as there are pieces on the row they are moving in. You may not jump over opponent's pieces, nor may you land on your own piece. If you land on an opponent's piece, it is captured and removed from the game. Neutron (Copyright (c) 1978 Charles Wetherell) On a 5x5 board, the two players of neutron fight to either move the neutron to their back row or trap it so the opponent cannot move it. The winner is the player who is able to trap the neutron or gets the neutron to his or her own back row. It does not matter if it is your opponent who moves the neutron to your back row -- you still win. Othello (Copyright (c) 1973,1990 Pressman Toy Co.) On a 8x8 board, the two players of othello fight to control the majority of the board by outflanking and flipping their opponents pieces. Pente On a 19x19 board, the two players of pente try to be the first to create a line of 5 or more stones in a row of their color *or* try to capture 5 pairs of their opponents stones. You capture a pair of stones any time you sandwich the stones between a pair of your stones. Philosopher's Football On a 19x19 board, players take turns either adding men to the field, or moving the football. The football moves by jumping lines of adjacent men (and removing them from the board). The object is to move the football to (or past) your goal line. Plotto (Copyright (c) 1995 David Smith) The players take turns placing one hex shaped piece in turn onto an open space (no board). Pieces are numbered either 1, 2, 3 or 4 and you may play a piece of any number at each turn. The object is to place a pair of pieces with your number in a straight line with two pieces in between. Qubic On a 4x4x4 grid, two players alternate placing their pieces, attempting to form four in a row in any direction. Score4 On a 4x4 grid of pegs, two players alternate dropping their pieces from the top of a peg, down a column, attempting to form four in a row in any direction. Survival (Copyright (c) 1995 David Smith)) Survival is played on a hexagonal board made up of 19 numbered hexagons. Two players take turns placing pieces on the board with the "arrow" of the piece dictating the direction in which the next piece played by that player must be played. The first player who can not move loses the game. Tanbo & Tanbo3d (Copyright (c) 1995 Mark Steere) Played on a Go board, Tanbo crudely models a system of plant roots. Roots which are growing, competing for space, and dying. In beginner play, the roots grow much as the roots in a garden. Over time, the roots become shrewd and calculating. To win, a player must eliminate all eight of his opponent's roots. One player will always win. It's impossible to repeat a board configuration in Tanbo. Therefore a game cannot result in a draw. Tanbo3d extends the game of Tanbo into three dimensions. Terrace (Copyright (c) 1995 by Siler/Siler Ventures. All Rights Reserved) Terrace is played on an 8x8 board consisting of 16 'L' shaped terraces. Two corners of the board are "High" and the other corners are "Low". Each player has pieces of 4 sizes ('A', 'B', 'C' and 'D'). 'A' pieces are the smallest, 'D' pieces are the largest. 'T' pieces are the same size as 'A' pieces and are each player's "key" piece. The object of the game is to capture your opponent's "T" or move your "T" to the lowest square on your opponent's side of the board. Trax & StdTrax (Copyright (c) 1983 David Smith) Trax is a game played with square tiles. Each tile is identical to all other tiles, one side has a white line connecting opposite edges and a black line connecting the other edges, and the other side has a white line connecting 2 adjacent edges and a black line connecting the other edges. The object of the game is to create a loop of your color while preventing your opponent from doing the same. An alternate winning condition is to create a line extending from one edge of the board to the opposite edge of the board when the board is at least 8 tiles wide (or tall). StdTrax limits the board to an 8x8 area. Normal Trax allows to board to grow to whatever size is necessary. Normal Trax is also known as SuperTrax. TwixT (Copyright (c) Avalon Hill) On a 24x24 board, players take turns placing pegs of their color on the board. Any time a peg is placed a "knight's move" from another peg of the same color, a strut is placed, connecting them. A strut can not cross over (through) another strut. The object is to connect your sides of the board while preventing your opponent from doing the same. -- /\/\/\ | Richard Rognlie / Pr. Computer Analyst / PRC Inc. / McLean, VA / \ \ \ | E-Mail: rrognlie@qnet.com rrognlie@vtsu.prc.com \ / / / | Phone: (Home) (703) 361-4764 (Office) (703) 556-2458 \/\/\/ | (Fax) (703) 556-1174 From: lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) Subject: Re: Core_Warrior_ #4 Date: 1995/11/08 Message-ID: <47p2rt$e3q@nuscc.nus.sg>#1/1 references: <47lk61$aji@mozo.cc.purdue.edu> newsgroups: rec.games.corewar : I'd like to add a word about the choice of a spiral size. There is : one warrior on the beginner hill with a 9-point spiral. I think this : is a bad idea. Because 2667 is a multiple of 889, an anti-3-point-imp : bomb (dat <2667, <5334) will also cause a 9-point spiral to decrement : its own instructions. (The same is true for any multiple of 3.) : Against myZizzor, for example, a 9-point version of Impfinity get very : bad scores compared to a 7-point version or an 11-point version. : So if you choose a big size for your spiral, make it a prime number. I see. That explains why my RingWorm series can't seem to go beyond the beginner's hill :( Keep up the good work:) -- Calvin Loh From: Planar Subject: Re: Core_Warrior_ #4 - Die Hard Date: 1995/11/08 Message-ID: <47qcj5$n3a@news-rocq.inria.fr>#1/1 references: <47lk61$aji@mozo.cc.purdue.edu> <1995Nov7.085146@acad.drake.edu> newsgroups: rec.games.corewar In article <1995Nov7.085146@acad.drake.edu>, pk6811s@acad.drake.edu writes: >Die Hard is based on a continuous 3-point launcher [...] > spl #0 > spl imp+5334 > spl imp+2667 >imp mov #0,2667 This is not a true spiral, but a "wimpy series of imp rings" :-) (interleaved imp rings, actually) The big advantage, of course, is that this piece of code is very small. -- Planar From: sieben@imap1.asu.edu Subject: whites for round 6 Date: 1995/11/08 Message-ID: <47qqs5$h51@news.asu.edu> newsgroups: rec.games.corewar These are the white warriors for round 6. A ziped version is available on the tournaments homepage at stormking. ;redcode-94 ;name Paper-Scissors-Stone #1 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- start mov PAPER,my_hand ;play PAPER no matter what ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #2 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- start mov SCISSORS,my_hand ;play SCISSORS no matter what ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #3 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- start mov STONE,my_hand ;play STONE no matter what ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #4 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- RESULT equ #0 ;last result STRAT equ #1 start res ldp RESULT,#res strgy ldp STRAT,#strgy sub #1,res jmz store,res ;win -> use last strategy add #2,strgy ;tie,loss -> next strategy mod #3,strgy stp strgy,STRAT store add.ab #1,strgy mov.b strgy,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #5 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- STRAT equ #1 start strgy ldp STRAT,#strgy add #1,strgy ;next strategy no matter what mod #3,strgy ;123123.. stp strgy,STRAT store add.ab #1,strgy mov.b strgy,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #6 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- STRAT equ #1 start strgy ldp STRAT,#strgy add #1,strgy ;next strategy no matter what stp strgy,STRAT ;but slowly div #5,strgy mod #3,strgy ;1111222223333311111.. store add.ab #1,strgy mov.b strgy,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #7 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- COUNT1 equ #1 COUNT start strgy ldp STRAT,#strgy add #1,strgy stp strgy,STRAT div #501,strgy STRAT jmz store, strgy mov PAPER,my_hand jmp wait store mov STONE,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #8 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- COUNT1 equ #1 COUNT start strgy ldp STRAT,#strgy add #1,strgy stp strgy,STRAT div #501,strgy STRAT jmz store, strgy mov STONE,my_hand jmp wait store mov SCISSORS,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #9 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- COUNT1 equ #1 COUNT start strgy ldp STRAT,#strgy add #1,strgy stp strgy,STRAT div #501,strgy STRAT jmz store, strgy mov STONE,my_hand jmp wait store mov PAPER,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== ;redcode-94 ;name Paper-Scissors-Stone #10 ;author Nandor Sieben & Stefan Strack ;White warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- RESULT equ #0 ;last result STRAT equ #1 start res ldp RESULT,#res strgy ldp STRAT,#strgy ;paradoxical adapter jmz store,res ;loss -> use last strategy add #1,strgy ;tie,win -> next strategy mod #3,strgy stp strgy,STRAT store add.ab #1,strgy mov.b strgy,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end ===================================================================== From: John K W Subject: Re: nobody special? Date: 1995/11/08 Message-ID: <47r3mr$e07@geraldo.cc.utexas.edu>#1/1 references: <47qr4p$h51@news.asu.edu> newsgroups: rec.games.corewar sieben@imap1.asu.edu wrote: > >All of us should learn from this and make warriors public :-/ I just use a floppy disk, pkzip, and a nifty little batch file called BACKUP. Anyone want me to post the source code to BACKUP.BAT? :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: P-space Date: 1995/11/09 Message-ID: <1995Nov9.075146.3037@rhodes>#1/1 references: <47odjr$98t@uwm.edu> newsgroups: rec.games.corewar Andrew S Mehlos (dweezil@alpha1.csd.uwm.edu) wrote: : Where can I find a summary/tutorial type thing for P-space? Heck, even an : explanation of how it works would be great. (specifically, how does one go : about writing a warrior that changes strategies based on the last round?) Well, I thought the pMars 0.8 docs were a good start. Then, the sample warrior pspace.red that came in that archive. Then, go to Planar's home page (forgot the site, but I'm sure he'll post it - or you can follow it from http://www.stormking.com/~koth). There are several good pspace warrior source files there (and a lot of good non-pspace warriors too. Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: NSFCWT round 4: the good, the bad and the ugly Date: 1995/11/09 Message-ID: <1995Nov9.074846.3036@rhodes>#1/1 references: <9511062254.AA02816@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar pk6811s@acad.drake.edu wrote: : OK, all in favor of repeating this round hold up your hands! Next time : I'm going to look something up in a book (only to make sure I get the : name right, of course :-) Repeating it? Shoot, I want it to become a regular hill. I bet that running it would be difficult to impossible though. I have been working on some improvements to my sorter. I shaved of 14 more instructions and a little bit of execution time. And, I am getting ready to make a quick-sort optimization I found that could more than double the speed on mostly sorted or mostly reverse sorted lists (but that will put back in more than the 12 lines I've removed so far. I am also working on making it a single index scan perhaps, but I'm not sure. That would eliminate 7 lines. And then, of course, I want to see if I can figure out how to fibonnaci sort in redcode. It is just a specialized version of a merge, so it may be difficult. But I believe the recursion can be unrolled and done manually with the same results. Well, just wishing this could be a long running thing. : Paul Kline : pk6811s@acad.drake.edu Randy From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Away Date: 1995/11/09 Message-ID: <9511092139.AA03591@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar I'll be out of town for a week and won't be able to answer my email. Please remember to send your round 5 and 6 entries to Nandor. Good luck, Stefan From: sieben@IMAP1.ASU.EDU Subject: Verification of round 6 Date: 1995/11/09 Message-ID: #1/1 newsgroups: rec.games.corewar > A million questions pop into my mind... Wow.. > What about scoring? 3/0/1? > And Pspace size? Still 500? Can't we have more? Does the score against > oneself count? And, if so, can we use PIN-numbers? Since we told you the exact parameters to use for pmars, everything is determined by the parameters and the default values of the current version of pmars. Self fights included. PIN #'s ok. > Sounds like a really fun round! We hope so. There are some typo errors in the white warriors for round 6 ( the names of warriors 2 and 3, round 5 is mentioned in the comment ). Please fix these. We hope this won't cause any trouble. Godd look, Nandor, Stefan. From: Anders Ivner Subject: Re: round6 Date: 1995/11/09 Message-ID: <9511091507.AA07244@su9-8.ida.liu.se>#1/1 newsgroups: rec.games.corewar A million questions pop into my mind... What about scoring? 3/0/1? And Pspace size? Still 500? Can't we have more? Does the score against oneself count? And, if so, can we use PIN-numbers? Sounds like a really fun round! /Anders From: John K W Subject: Re: Help on imp-rings! Date: 1995/11/09 Message-ID: <47u2l0$h51@geraldo.cc.utexas.edu>#1/1 references: <467jf1$1of@newsbf02.news.aol.com> <468g16$pae@geraldo.cc.utexas.edu> <46cp3n$mtu@agate.berkeley.edu> <46e3be$hr6@geraldo.cc.utexas.edu> <46h0e3$ji9@agate.berkeley.edu> <46htcm$3fg@nuscc.nus.sg> <46kcvi$l4l@nuscc.nus.sg> <478rn1$635@geraldo.cc.utexas.edu> <479k15$rak@nuscc.nus.sg> newsgroups: rec.games.corewar lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) wrote: >: Try this: > >: spl 1, 0 >: spl 1, 0 >: spl 2, 0 >: jmp 2, 0 >: add #2667, -1 >: mov 0, 2667 > >: Assuming I did that right, it should make a four-process, three-point ring. :) > >Thanks. What is the fourth process for? What is it for? Well it's not FOR anything... I mean, it can be left off. In general, the most efficient spiral is the 3 point spiral. However, the more processes, the better (in general). It's hard to say specifically which is better in which occasion... If you are trying to avoid a gate, you just want processes, it doesn't matter where they are. But if you're trying to keep yourself from being bombed to death, efficiency is more important. It's tough to bomb or scan a three process spiral... -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: P-space Date: 1995/11/09 Message-ID: <47u2ia$64b@agate.berkeley.edu>#1/1 references: <9511080045.AA03086@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar David Boeren wrote: >P-Space is pretty limited even if you CAN store instructions. All you >can do is MOV to and from it. You can't add to P-Space, you can't Jump >to or based on P-Space, your addressing modes can't inc/dec P-Space, and >you can't split to P-Space. Hmm, but consider this: paper is already strong right now, and if you could store instructions in P-space you could make paper stronger by storing a complete copy of the paper in P-space, and copying from that instead of from the currently executing copy. Scanners and stones can benefit from a little added robustness, but nothing major. How will full- instruction P-space make warriors more *intelligent*, as opposed to just making standard warrior types more robust? -- Michael Constant (mconst@soda.csua.berkeley.edu) From: akemi@netcom.com (David Boeren) Subject: Ideas for new instructions Date: 1995/11/09 Message-ID: #1/1 newsgroups: rec.games.corewar I'd like to start a thread up for discussion of anyone's ideas for new instructions which might contribute to the writing of more intelligent programs. I do not claim to know the answer to this problem, but I'd like to hear ideas and input from anyone who is willing to share their thoughts. I'll get the ball rolling with some things I was thinking about last night related to process control. I do not claim these are GOOD ideas, but there is probably some germ of a good idea hidden within somewhere. One thing that would help us write smarter programs is the ability to coordinate the activity of multiple threads. This is currently not viable except in a very simple system. In addition, it is currently fairly difficult to have threads change behavior except by counting loop iterations or the limited fashion of self-bombing, which is tricky and depends on rigging a lot of factors correctly to work. I ended up thinking about the possibility of adding some extra thread control instructions, and I'd like to hear what anyone thinks of these. The instruction names and abbreviations are just conjectural... SLP - Sleep. Causes that thread to pause for a specified number of cycles. reason: By sleeping threads you can implement delayed activity to change the behavior of a program at a later time without paying a penalty by needing to constantly check a value. This will encourage people to write more adaptive programs. BLK - Block. Causes a thread to pause on a semaphore. explain: I figured that teh semaphore can be a location in P-Space. The thread would pause and wake up once the P-Space location it was paused on contained a non-zero value. reason: This provides something similar to an interrupt style facility, and can be used also for communication. I envision the possiblity of using this capability to launch scout processes which will locate the enemy and return his location in the semaphore, thus bringing to life a dispatch process that will direct an assault. Previously any such strategy would slow down a program by having the extra thread that idle looped or each scout would have to carry extra baggage to locate the "base camp" One additional point. If all active threads (not sleeping or blocking) are killed, we would probably have to make it so that the next sleeping thread woke or the next blocking thread woek (if no sleepers). This is to prevent an unkillable program like the following: STP #0, #42 BLK #42 This would otherwise never die because its one thread would be blocked on a location that will never become nonzero. Anyway, that's my idea for the day. Anyone is welcome to give their opinions, comments, criticisms, etc... From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: P-space Date: 1995/11/09 Message-ID: <47t746$ebo@lastactionhero.rs.itd.umich.edu>#1/1 references: <9511080045.AA03086@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar I would also like to see a warrior that has the ability to repair itself. Your entire code in P-Space would make this possible. Checking and loading code would still take a long time, so that would'nt give repair programs that much of an advantage. We need more options. I am in favor of keeping the number of instructions in Corewars down to a resonable level, but even adding two or three new ones would increase the total number of strategies. One of the main concerns when changing the standard is that old programs should still run and have a chance of winning. Adding new instructions give the best possible chance of doing just that. David Boeren (akemi@netcom.com) wrote: : Stefan Strack (stst@idnsun.gpct.Vanderbilt.Edu) wrote: : : ... and about storing *instructions* in P-space: : : P-space was designed as a non-volatile memory that would enable warriors : : to learn from the results of previous battles, but *not* as a general- : : purpose set of registers that could be used to decrease a warrior's footprint : : in core. That's why we have LDP,STP to make access deliberately expensive. : P-Space is pretty limited even if you CAN store instructions. All you : can do is MOV to and from it. You can't add to P-Space, you can't Jump : to or based on P-Space, your addressing modes can't inc/dec P-Space, and : you can't split to P-Space. : I think limiting P-Space to only storing data from previous battles really : makes the idea less useful. I would like to see P-Space become something : that encourages communication/coordination between processes, something : that I think everyone here has wanted to be able to do for a long time as : a means of increasing intelligence of the warriors. I agree that it's : not supposed to be there to decrease footprint, but I really don't see : that it can do much for that unless you want to waste half your execution : time fetching stuff from P-Space so you can execute it. : If P-Space isn't going to be able to give us anything like communication : or other intelligence-boosting abilities without carrying other unwanted : effects, then that's fine. But then we have to think about adding : something else to give these abilities. Any ideas? From: rschuler@iastate.edu (Rodney Schuler) Subject: Re: Sorts Date: 1995/11/09 Message-ID: <47ru7v$215@news.iastate.edu>#1/1 references: <1995Nov5.221647@acad.drake.edu> <47l6j7$ls0@news-rocq.inria.fr> <47m41r$af9@soap.news.pipex.net> <47nlkd$6kr@news-rocq.inria.fr> newsgroups: rec.games.corewar In article <47nlkd$6kr@news-rocq.inria.fr>, >Planar wrote: [much removed] >>>> 1. subdivide the list by taking every Nth element >>>> 2. sort each sublist >>>> 3. reduce N >>>> 4. if N is greater than zero, go to 1 >>>> 5. when N equals zero, you are done > >Actually, this is Shell sort only if you use insertion sort in step 2 >above. If you use bubble sort, this was published in Byte a few years >ago. I forget the name of the algorithm. It was called combsort. Kind of a cool algorithm. Give O(n*log(n)) performance in very few lines of code. Unfortunately the constant `out front' is rather large. Real world performance is about that of heapsorts, about 3-4 times slower that a quicksort. Is this heaven? No, its Iowa rschuler@iastate.edu From: John K W Subject: Re: Ideas for new instructions Date: 1995/11/10 Message-ID: <480h4t$fnr@geraldo.cc.utexas.edu>#1/1 references: <47vtbp$drv@lastactionhero.rs.itd.umich.edu> <4808vi$s5i@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar wrote: >Homemade Ice Cream, Der Zweite Blitzkrieg - 94, and SJ-4a (for >example). Would you call these warriors too simple ? > >None of the programs currently on the hill does as good as Homemade >Ice Cream against Impfinity v3e7. Really, what's it get against Impfinity? I didn't ever set out to beat that warrior, but I think Bevo 3.f gets something like 50/5/45... >We have almost a dozen basic strategies (OK, only 8, sorting and >factoring are not really acts of war). The combinations are infinite. >Right now, Core War is a very rich game in which intelligent players >write dumb programs that are quite complex and highly optimized. You >don't want to upset the delicate balance between the basic strategies. Delicate balance? :) I don't know if I would go that far. However, everyone should definately wait until we think we've got pspace "figured out" before changing it again. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Defence in Redcode Date: 1995/11/10 Message-ID: <4802tn$1gn@geraldo.cc.utexas.edu>#1/1 references: <47nu72$hce@griffin.ccc.nottingham.ac.uk> <47o5dp$d49@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar morrell@math.utah.edu (Steven C. Morrell) wrote: >> That's a good question... why DOESN'T pspace hold complete >> instructions? > >Well, a stupid answer to this is the way PSpace is addressed. What exactly >would STP.a #100,#20 mean? Would it store 100 in the A-field of PSpace >location 20? Or would it store 100 in the B-field of PSpace location 100? I don't know. I don't see how that's a valid reason for not allowing it, though. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Promoting Intelligent Warriors Date: 1995/11/10 Message-ID: <480156$drv@lastactionhero.rs.itd.umich.edu>#1/1 newsgroups: rec.games.corewar From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: Ideas for new instructions Date: 1995/11/10 Message-ID: <47vtbp$drv@lastactionhero.rs.itd.umich.edu>#1/1 references: newsgroups: rec.games.corewar David Boeren (akemi@netcom.com) wrote: : SLP - Sleep. Causes that thread to pause for a specified number of cycles. : BLK - Block. Causes a thread to pause on a semaphore. The basic idea here seems to be that a decision branch should have a reduced cost in processor time. This would produce more "intelligent" programs. I am curious what people think an "intelligent" program should be capable of. Are we attempting to get to a point where programs send volleys at other programs. Intelligent programs, to me, don't just blindly destroy the core, but this is a thought for another post. From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: Defence in Redcode Date: 1995/11/10 Message-ID: <47vs76$drv@lastactionhero.rs.itd.umich.edu>#1/1 references: <47nu72$hce@griffin.ccc.nottingham.ac.uk> newsgroups: rec.games.corewar Pspace would have to become an OpCode in order for the Pspace as instruction holder to work. John Lewis Steven C. Morrell (morrell@math.utah.edu) wrote: : In article <47o5dp$d49@geraldo.cc.utexas.edu> John K W writes: : > That's a good question... why DOESN'T pspace hold complete : > instructions? : Well, a stupid answer to this is the way PSpace is addressed. What exactly : would STP.a #100,#20 mean? Would it store 100 in the A-field of PSpace : location 20? Or would it store 100 in the B-field of PSpace location 100? : -- : Steven Morrell morrell@math.utah.edu From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: NSFCWT sort data up for grabs Date: 1995/11/10 Message-ID: <1995Nov10.071750.3043@rhodes>#1/1 references: <9511072159.AA03047@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar Stefan Strack (stst@idnsun.gpct.Vanderbilt.Edu) wrote: : Two people requested the sort data from round 4, and I can't reach one of : them (Derek), so I put the data up for ftp: : ftp://stormking.com/pub/incoming/data.zip : Since I don't think this is of lasting interest, I asked that this file be : removed after a week. And since I was one of them, I will have a copy for a while. It is small (about 13k zipped), so I will hold on to it for a while. Anyone wanting a copy that can't get it from stormking can email me and I will uuencode it and mail it. Also, if you want it compressed or gzipped instead of pkzipped, let me know and I'll send it however you want. : -Stefan Randy From: akemi@netcom.com (David Boeren) Subject: Re: Defence in Redcode Date: 1995/11/10 Message-ID: #1/1 references: <47nu72$hce@griffin.ccc.nottingham.ac.uk> newsgroups: rec.games.corewar Steven C. Morrell (morrell@math.utah.edu) wrote: : In article <47o5dp$d49@geraldo.cc.utexas.edu> John K W writes: : > That's a good question... why DOESN'T pspace hold complete : > instructions? : Well, a stupid answer to this is the way PSpace is addressed. What exactly : would STP.a #100,#20 mean? Would it store 100 in the A-field of PSpace : location 20? Or would it store 100 in the B-field of PSpace location 100? I assume that STP would act just like MOV, with the only difference beig that it accessed an absolute location in P-Space rather than a relative location in core. From: Planar Subject: Re: Ideas for new instructions Date: 1995/11/10 Message-ID: <4808vi$s5i@news-rocq.inria.fr>#1/1 references: <47vtbp$drv@lastactionhero.rs.itd.umich.edu> newsgroups: rec.games.corewar In article <47vtbp$drv@lastactionhero.rs.itd.umich.edu>, jklewis@stimpy.us.itd.umich.edu (John K. Lewis) writes: >I am curious what people think an "intelligent" program should be capable >of. Are we attempting to get to a point where programs send volleys at >other programs. Intelligent programs, to me, don't just blindly destroy >the core, but this is a thought for another post. [I'm not addressing John here, but all the people who want to change Core War to make more "intelligent" programs:] Before you ask for changes to Core War, try your own programs against Homemade Ice Cream, Der Zweite Blitzkrieg - 94, and SJ-4a (for example). Would you call these warriors too simple ? None of the programs currently on the hill does as good as Homemade Ice Cream against Impfinity v3e7. We have almost a dozen basic strategies (OK, only 8, sorting and factoring are not really acts of war). The combinations are infinite. Right now, Core War is a very rich game in which intelligent players write dumb programs that are quite complex and highly optimized. You don't want to upset the delicate balance between the basic strategies. -- Planar From: Derek Ross Subject: Re: Ideas for new instructions Date: 1995/11/10 Message-ID: <303@arbroath.win-uk.net>#1/1 newsgroups: rec.games.corewar John K. Wilkinson noted: >Planar wrote: >>We have almost a dozen basic strategies (OK, only 8, sorting and >>factoring are not really acts of war). The combinations are infinite. >>Right now, Core War is a very rich game in which intelligent players >>write dumb programs that are quite complex and highly optimized. You >>don't want to upset the delicate balance between the basic strategies. > >Delicate balance? :) I don't know if I would go that far. However, >everyone should definately wait until we think we've got pspace >"figured out" before changing it again. > You both make good points here. I still haven't got the 1988 standard totally figured out in the last seven years, never mind P-space in the last seven months. I'm sure I'm not alone . There's plenty of new ground to cover at the moment. Two other things people should bear in mind. Firstly every feature added makes the learning curve for novices a little steeper. Some features more than others. Secondly the nature of Core War programs is governed by their purpose not the code they're written in. I have a feeling that if we were using one of the standard machine codes rather than Redcode, we would *still* be writing short, fast, specialised programs for scanning, bombing, replication, etc. and grumbling that there was no room for more 'intelligent' programs. If more 'intelligent' programs are wanted then the process of winning has to become a lot more subtle than it is just now. Round 6 of the current tournament gives a fine example of how it could be done. I gave another couple of suggestions the last time this question was discussed. But if the object remains 'destroy the enemy before it destroys you' then the best strategy will remain 'shoot first, ask questions later' - Hey that's the way I like it!. Cheers Derek MicroSoft Network may not carry this message without license to do so. License to carry this message requires a fee of $1000, payable within 30 days to Derek Ross. Appearance of this message on MicroSoft Network constitutes an agreement to terms. From: Michael Constant Subject: Re: P-space Date: 1995/11/10 Message-ID: <199511102024.MAA00394@soda.CSUA.Berkeley.EDU>#1/1 newsgroups: rec.games.corewar > What about all the things that have already been mentionned, like Self > Repairing programs and coordination of multi-processes bombs? An imp-spiral is the ultimate self-repair program. It is very effective and it is the epitome of simplicity. More complicated self-repair programs wouldn't work even with a more powerful P-space -- the problem with a self- repair program is not that it doesn't have a clean copy of its own code, but rather that it is too slow to be effective. Multi-process bombs can be coordinated perfectly well by storing simple numbers in P-space. Full instructions are not required, and I can't even see how they would help. > Also, how about copying the ENEMY program into your own p-space for > analysis at the start of the next battle? That's a pretty cool idea, but how is it different from simply scanning for the enemy program, analyzing it on the spot, and storing the *result* of the analysis in P-space? > or bombing with the enemy program? What do you mean by this? > P-space is also very vulnerable to brainwashing (as recent programs have > shown)... that makes using it as a storage place for paper pretty risky. Actually, the idea I had was that the paper would be re-stored each round, and only half the copies would be made from P-space (the other half would be made normally). The idea would be to prevent a small error in one paper from affecting all of its descendants. - Michael Constant From: sieben@IMAP1.ASU.EDU Subject: Re: Verification of round 6 Date: 1995/11/10 Message-ID: #1/1 newsgroups: rec.games.corewar > Ok, next question(s): > How will you check that the routines are guaranteed not to exceed 1000 > cycles? I mean, have a worst case time over 1000 cycles, although this Of course we cannot check for worst case time. That would take forever. > case does not occur during the tournament? Or, if this is allowed, what > will happen to those programs that are unlucky enough to get one really > slow case? Will they be disqualified? Or will it just count as though > they lost that single point? And, thirdly, how will you check that no Hopefully this won't be an issue. 1000 cycles should be enough. No disqualification. It will be a lost round. I don't think anybody wants to be over the time limit since this could make the info stored in pspace kind of meaningless. > program exceeds its 1000 cycles? What cdb-macro does this? Well, some of my professors would say this is a standard exercise in cdb theory :-) Why don't we make it a mutual effort. Please send me your solution for this problem. One way to make a not foolproof check is to write a checking warrior that actually cheats. It waits for his opponent to move and then replies with the winning answer. If this warrior doesn't win 100% then the opposing warrior went over the cycle limit. Nandor. From: Tim Chapman Subject: Re: Defence in Redcode Date: 1995/11/10 Message-ID: #1/1 newsgroups: rec.games.corewar On Fri, 10 Nov 1995, Steven C. Morrell wrote: > In article <47o5dp$d49@geraldo.cc.utexas.edu> John K W writes: > > > That's a good question... why DOESN'T pspace hold complete > > instructions? > > Well, a stupid answer to this is the way PSpace is addressed. What exactly > would STP.a #100,#20 mean? Would it store 100 in the A-field of PSpace > location 20? Or would it store 100 in the B-field of PSpace location 100? > > -- > Steven Morrell morrell@math.utah.edu > > If p-space was to hold complete instructions, then STP and LDP would have to change their meanings slightly to become more like MOV. In this way, STP.a #100,#20 would be a bit like MOV.a #100,#20. This would copy the a field of the mov instruction (since the #100 would revert to 0) to the a field of p-space location #20. In other words p-space location 20 would have it's a-field set to #100. -Tim Chapman From: Tim Chapman Subject: Re: P-space Date: 1995/11/10 Message-ID: #1/1 newsgroups: rec.games.corewar On Thu, 9 Nov 1995, Michael Constant wrote: > David Boeren wrote: > >P-Space is pretty limited even if you CAN store instructions. All you > >can do is MOV to and from it. You can't add to P-Space, you can't Jump > >to or based on P-Space, your addressing modes can't inc/dec P-Space, and > >you can't split to P-Space. > > Hmm, but consider this: paper is already strong right now, and if you > could store instructions in P-space you could make paper stronger by > storing a complete copy of the paper in P-space, and copying from that > instead of from the currently executing copy. Scanners and stones can > benefit from a little added robustness, but nothing major. How will full- > instruction P-space make warriors more *intelligent*, as opposed to just > making standard warrior types more robust? > -- > Michael Constant (mconst@soda.csua.berkeley.edu) > What about all the things that have already been mentionned, like Self Repairing programs and coordination of multi-processes bombs? Also, how about copying the ENEMY program into your own p-space for analysis at the start of the next battle? or bombing with the enemy program? P-space is also very vulnerable to brainwashing (as recent programs have shown)... that makes using it as a storage place for paper pretty risky. -Tim Chapman From: Beppe Bezzi Subject: Re: round6 Date: 1995/11/10 Message-ID: <199511101129.MAA27922@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 04.02 10/11/95 -0500, you wrote: >In article sieben@IMAP1.ASU.EDU writes: > >> ;---BEGIN-VARIABLE-PART----------------------------------------------------- > >> Don't change any code outside this area. See the white warriors below for >> examples what could go in here. Do not bomb your opponent or peak at >> your_hand before making your move or do anything else unfair, we're >> watching your code with eagle's eyes :-). > >> ;---END-VARIABLE PART------------------------------------------------------- > >Just for clarity's sake, is commiting suicide before you get to the >bookkeeping section fair? > >-- I don't know if it's fair or unfair, but if you commit suicide you'll be punished with the loss of the round :-) What kind of advantage can you get committing suicide ? >Steven Morrell morrell@math.utah.edu > > -Beppe Bezzi From: Anders Ivner Subject: Re: Verification of round 6 Date: 1995/11/10 Message-ID: <9511101200.AA16438@su9-1.ida.liu.se>#1/1 newsgroups: rec.games.corewar (I hope noone minds my excessive mailing, my newsfeed is a little nondeterminisic ) Ok, next question(s): How will you check that the routines are guaranteed not to exceed 1000 cycles? I mean, have a worst case time over 1000 cycles, although this case does not occur during the tournament? Or, if this is allowed, what will happen to those programs that are unlucky enough to get one really slow case? Will they be disqualified? Or will it just count as though they lost that single point? And, thirdly, how will you check that no program exceeds its 1000 cycles? What cdb-macro does this? /Anders From: John K W Subject: Pizza's Dead Again? Date: 1995/11/10 Message-ID: <480h9v$fvh@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar Is Pizza down? I never got replies from my warriors, and I noticed the status of the hill hasn't changed in two days or so... :/ Maybe it's just the 94 Hill? -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Round 5 entry Date: 1995/11/11 Message-ID: <1995Nov11.090044.3047@rhodes> newsgroups: rec.games.corewar OK, since the deadline is past, here is my entry. I don't know how well it will do, but I figure I should get neatness points just for what I pulled off (although somebody else probably did the same in fewer lines). What I do is find the smallest imp spiral for the given core size. Then, I try to find a stone step size between mod-4 and mod-7 (inclusive). I store all that info in pSpace so next round I can launch more quickly. Then, I start an gate-crashing imp spiral, copy my stone away, and start a mod-4, 5, 6, or 7 stone with a core clear. In the event I can't find a suitable step size fairly quickly, I just use 7 and hope I get a couple of times through core before self destructing. In the event someone is using a brainwasher, I test my saved values at startup. If they work out tight, I use what I have. If not, I go through the calulations again. So, here is fully commented source for my Rand-Man entry, along with notes on the one change I wish I had made before submitting. Randy ----------------------------------------------------------------- ;redcode-94 ;name Rand-Man ;kill Rand-Man ;author Randy Graham ;contact hp715!rgraham@peridot.spawar.navy.mil ;NSFCWT round 5 ;assert 1 ;strategy Fight in a random core size. Move weak stone away from decoy ;strategy and launch gate-crashing imp spiral. Use pspace to save time ;strategy on later boots (but protect against brainwashing). IMPOFF equ (imp+500) IMPSIZE equ #3 ;what step size we think we need PDATPTR equ #2 ;save # of points to verify step size STONESAVE equ #1 ;what stone step we want STONESTEP equ 36 ;what to start check at STONEMAX equ 50 ;what to stop at imp mov.i #3044, -1 imp2 mov.i #1143, 1 launch3 spl.a adder3, <-330 jmpto3 jmp.a IMPOFF+6, <-91 adder3 add.ba imp2, jmpto3 datptr dat.f 13, getptr dat.f 11, 0 dat.f 7, 0 dat.f 5, 0 getsize ldp.ab IMPSIZE, #0 ;these 2 lines double as data getptr ldp.ab PDATPTR, datptr ;statements mul.ab @datptr, getsize seq.ab #1, getsize counter jmp.a starter-1, 0 getstone ldp.a STONESAVE, setstone ldp.ab IMPSIZE, imp ;restore location jmp.a postsave, <-431 mov.ab #(getptr-datptr), datptr starter div.ab #2, imp add.ab #1, imp ;set imp.b to CORESIZE/2 moder mod.ba #-1, #2 jmz.a psave, moder ;make 2-point imp if odd core check mov.a R=m%p ; I can't do Coresize % Points, but I can do (Coresize-1)%points ; Then, add one to make up for the one we subtracted. Finally, mod ; that with points again to make sure we have the real mod. setup mod.ab @datptr, skipper add.ab #1, skipper skipper mod.ab @datptr, #0 ;after this, we have our mod ;The next part is a hybrid of Brant D. Thomsen's Imp-Spiral Finder in ; the May 4, 1994 issue of The 94 Warrior and Jay Han's routine in ; makeimp.c. This calculates the N value for Jay's ; ImpStep = (CoreSize * N + 1) / ImpSize ---> x=(m*n+1)/p ;The idea for only looping through ImpSize-1 times and checking is ; from Brant's program's data lines (get the program and see it) ;Now, to actually check if our attempted point size is an impstep, we ; use Jay's lines ; Counter = 0 ; if (Counter+R) % Points == Points - 1 --> if ((c=(c+r)%p) == p-1) ; until we have checked Points-1 times or we get the match mov.ab gotit, loop check2 mov.ab #0, gotit setN add.ab #1, counter add.b skipper, gotit mod.ab @datptr, gotit gotit sne.ab #0, #0 jmp.a sizer, <-100 loop djn.b setN, #loop jmn.b check, datptr ;in case this fails, at least stone ;Here was the hard part. Given the number of points we can theoretically ; run in this core size, and knowing Coresize/2, figure out the correct ; step size. In Jay's program, he used ; ImpStep = (CoreSize * N + 1) / ImpSize ---> x=(m*n+1)/p ; as noted above. We have the N now, but how to do the math in a ; modular world. Well, I finally decided to give up on getting it right, ; and just get close. Then I can find the exact amount. So, throw ; away the +1, combine the terms, and remember that you know CoreSize/2 ; Use the above ImpStep equation, modified for what you have ; ImpStep = (CoreSize / 2 / ImpSize * N) * 2 (approximately) ;By doing the division first, then multiplying, we don't have the ; wraparound effect of the Modular world mess us up. And, we get ; pretty close to the correct value. Also, since we are using integer ; division and we ignored the +1 above, we know we will be slightly ; BELOW the correct value. So, add one, multiply it by the number of ; points. If it is equals 1 (in a modular world), then it is correct. ; If not, loop back, add one more, multiply again, and go until you get ; a 1. Then, you have what you need, so move your imp out and launch ; it (using a jmp/add launch which let's you add in your step as you go) ;As for why this works, I don't exactly know. You have to ask Jay for ; details. I just converted his C code to Redcode. ;-) sizer div.ab @datptr, imp ;approximate the step size mul.ab #2, imp mul.b counter, imp exact mov.b imp, #0 mul.ab @datptr, -1 seq.ab #1, -2 jmp.a exact, >imp psave stp.b datptr, PDATPTR stp.b imp, IMPSIZE ;Ffrom Jay Han's corestep, find a number from mod-4 to mod-7. If no ;number is usable, then use 7 (per moonstone). C code was: ; uint modsize (uint s) ; { ; uint r, b=s, a=coresize; ; if (s == 0 || s == 1) return s; ; while (r=a%b) ; { ; a=b; ; b=r; ; } ; return b; ; } ; ;where uint is an unsigned integer, and s is the number to find the ; modsize for ;I used from 36 to 51 as my s. ;I only stopped on s == 0 (save 2 instructions, waste 5 cycles - but ; those two instructions would be executed every time otherwise). ;When I found a modsize between 4 and 7 (inclusive) I used it ;Man I like Jay's code. Helped a lot on this round ;I just hope I do OK. I am REALLLLLY slow launching because of finding ; my stone step size - especially in prime size cores setstone mov.a #STONESTEP, findstone mov.ab #-1, findstone mod.ab setstone, findstone add.ab #1, findstone findstone mod.ab #0, #-1 jmz.b keepstone, findstone mov.b findstone, a mov.ab findstone, findstone mov.ba a, findstone a jmp.a findstone, 0 ;man I wish I had used the following for findstone: ; findstone mod.ab #0, #-1 ; mov.x findstone, findstone ; jmn.a findstone, findstone ;then used .b instead of .a below keepstone slt.ab findstone, #8 ;want at most mod-7 jmp.a keepstone+4,0 slt.ab findstone, #4 ;keep it if mod4-mod7 jmp.a psave2, 0 slt.a #STONEMAX, setstone ;found nothing, work with what we jmp.a setstone, }setstone ;have mov.a #7, setstone ;use some small step psave2 stp.ab setstone, STONESAVE postsave add.b imp, imp2 mov.a @datptr, build ;build up processes add.a build, build mul.ab #2, enough build slt.ab #0, enough jmp.a -2, <-300 mov.i imp, IMPOFF spl.a l_stone, launch1 ;set up gate crashing imps threeway spl.a launch1, <-190 spl.a launch3, <-150 launch2 spl.a adder2, <-135 jmpto2 jmp.a IMPOFF+4, #1/1 newsgroups: rec.games.corewar hella i need that program, but i'm wondering whether there is a DOS version of that beauty... and what about a little corewar-ftp-site.... thanks From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Theme (round 5 entry) Date: 1995/11/11 Message-ID: <481en1$qrn@agate.berkeley.edu> references: <1995Nov9.142248.3038@rhodes> newsgroups: rec.games.corewar Randy Graham wrote: >Well, I have finally gotten something written that will work in round >5. Hopefully it is a unique idea, but I somehow doubt it. Anyway, >I'm not really happy with my entry, but since I couldn't come up with >a good idea, I decided to use what I could come up with. So, has >anyone got any ideas that think could be done but aren't pursuing >themselves? Yup, that would be me. I came up with a neat idea, but didn't have time to implement it properly. Basically, I spent all my time on the imp code and I had to write the paper at the very last minute. I would love it if someone could take Theme and rewrite the paper code -- the imp stuff is awesome IMHO, but the paper was very much rushed and it shows. But before I show you just how horrible the paper is, let me tell you about the imps :-) Given any coresize not divisible by 30030, Theme can find an imp-number that will work -- not only that, the spiral it creates will always have <= 13 points. (The number 30030 can be raised to 510510 with a trivial addition, which adds only one line of code and doesn't slow the program at all.) Not only that, it's *fast* -- the entire imp-number calculation takes an average of about 30 cycles (and it takes none at all once the result is stored in P-space, after the first round!). It uses lots of number theory, though, which is not made any simpler to understand by all my optimizations :-) But since it's really a pretty cool algorithm, I'll explain it if anyone wants (post here if you want me to explain it). A side note: Theme seems to me to be a step towards the "intelligent" warriors that all the changes in corewar are designed to promote. It uses quite a bit of math, which alone justifies the label "intelligent". But more interesting is the fact that it uses some of the new corewar features to very good effect: the much-maligned mul/div/mod instructions are absolutely crucial for Theme, and it uses P-space to save ~30 cycles of computation (more in certain coresizes). For me, the fact that Theme uses P-space to save time in calculations rather than to simply switch between standard strategies is evidence that P-space can be used to write more intelligent warriors. And Theme would simply not be possible without the mul, div and mod instructions, which is evidence that those instructions are useful to help create more complex warriors. Finally, the idea of combing paper with an imp is due to Mike Nonemacher, who used it quite successfully some time ago in a warrior whose name I have forgotten. Thus, any weaknesses in Theme are most likely due to my implementation, rather than to the original idea. Without further ado: Theme. ;redcode-94 ;name Theme ;author Michael Constant ;strategy silk paper and dynamically launched imp-spiral ;strategy based on a wonderful idea by Mike Nonemacher ;assert CORESIZE % 30030 MAGIC equ 42 magicp ldp.ab #1, #0 seq.b magicp, #MAGIC ; is the magic number there? jmp calc ; ... nope, we have to recalculate ldp.ab #2, imp ; ... yup, we can start immediately launch spl setup spl 1 spl 1 spl 1 spl 1 spl 1 spl 2 jmp imp ; a fast imp-launcher would have been a add.ba imp, -1 ; real pain to do dynamically magic1 dat 0, 13 magic2 dat 0, 11 which dat endp+1, 7 sign dat 1, 5 dat 0, 3 endp dat 0, 2 setup spl 1 spl 1 spl 1 spl paper2 spl paper3 paper1 spl -11751, 0 mov.i >-1, }-1 mov.i <-2, {1 jmp -12015 paper2 spl -11560, 0 mov.i >-1, }-1 mov.i <-2, {1 jmp -12351 paper3 spl -11301, 0 mov.i >-1, }-1 mov.i <-2, {1 jmp -12511 calc mod.b {which, #-1 ; take CORESIZE-1 % p, where p is prime add.ab #1, calc ; ... but we really wanted CORESIZE % p seq.b calc, *which ; is p relatively prime with CORESIZE? jmp euclid ; ... yes, we have a winner! mov.ab #-1, calc ; ... no, restore calc and try again jmp calc euclid div.b *which, #-1 ; this works out to CORESIZE / p mov.ba imp, magic2 ; store imp for later reuse mul.b euclid, imp ; apply the inverse Euclidean algorithm add.ab magic1, imp ; ... storing partial results in imp mov.a magic2, magic1 ; magic1 is now the old value of imp mov.b *which, euclid mov.b calc, *which mov.b euclid, calc mod.b *which, calc ; apply the standard Euclidean algorithm mul.a #-1, sign ; sign is the parity of the total pass count jmn.b euclid, calc ; is the remainder zero yet? mul.ab sign, imp ; ... yes, we're done -- prepare the imp stp.b imp, #2 ; we've found the imp-number, let's store it stp.ab #MAGIC, #1 ; ... and store MAGIC so we know it's real jmp launch imp mov.i #-5, 1 ; the -5 is to help against anti-vamps -- Michael Constant (mconst@soda.csua.berkeley.edu) From: sieben@IMAP1.ASU.EDU Subject: Re: Verification of round 6 Date: 1995/11/12 Message-ID: #1/1 newsgroups: rec.games.corewar > > Well, some of my professors would say this is a standard exercise in cdb > > theory :-) Why don't we make it a mutual effort. Please send me your > > solution for this problem. One way to make a not foolproof check is to > > write a checking warrior that actually cheats. It waits for his opponent > > to move and then replies with the winning answer. If this warrior doesn't > > win 100% then the opposing warrior went over the cycle limit. > > One solution might be to make the following addition to the skeleton: > > ORG timeout > TIMEOUT equ #1 > > timeout ldp TIMEOUT, #timeout > jmn lose, timeout ;if last round timeout, lose this round > ok stp #1, TIMEOUT > ;---BEGIN-VARIABLE-PART--- > ... > ;---END-VARIABLE-PART--- > ... > stp #0, TIMEOUT > > Simple, but maybe unfair since it could confuse the opponent. It would be > better to simply keep count of the number of timeouts. Yes it's simple and elegant but this could add an extra flavor to the game. Someone could create a timeout just to confuse the opponent. So I'd rather not make having a timeout official. Let's try to avoid timeouts completely if possible and hope nobody will have a timeout. I'll probably make the checking program I was talking about public, and then everybody can check his warrior out with it. If anybody already has this warrior or any other testing warrior then please send it to me because I didn't write it yet. I can distribute it and we can make passing these tests an official requirement for a submission. Nandor. From: sieben@IMAP1.ASU.EDU Subject: NSFCWT Veification of Round 6 Date: 1995/11/12 Message-ID: #1/1 newsgroups: rec.games.corewar I had the following question: > Round 6 question: > > Is it fair to read your_hand just to save it in my pspace, without taking > advantage of having read it; only to save som calculations in my next round? I understand that this only saves calculation. On the other hand it's not very clean. The calculation is not hard knowing the previous choice and result. Also in a real life application (switching mechanism in a warrior) you don't have this opportunity. So please do not access your opponents hand at all. Nandor. From: Anders Ivner Subject: Re: Verification of round 6 Date: 1995/11/12 Message-ID: <9511121356.AA21173@su9-7.ida.liu.se>#1/1 newsgroups: rec.games.corewar > Well, some of my professors would say this is a standard exercise in cdb > theory :-) Why don't we make it a mutual effort. Please send me your > solution for this problem. One way to make a not foolproof check is to > write a checking warrior that actually cheats. It waits for his opponent > to move and then replies with the winning answer. If this warrior doesn't > win 100% then the opposing warrior went over the cycle limit. One solution might be to make the following addition to the skeleton: ORG timeout TIMEOUT equ #1 timeout ldp TIMEOUT, #timeout jmn lose, timeout ;if last round timeout, lose this round ok stp #1, TIMEOUT ;---BEGIN-VARIABLE-PART--- ... ;---END-VARIABLE-PART--- ... stp #0, TIMEOUT Simple, but maybe unfair since it could confuse the opponent. It would be better to simply keep count of the number of timeouts. /Anders From: lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) Subject: Re: Ideas for new instructions Date: 1995/11/13 Message-ID: <486j3g$8rn@nuscc.nus.sg>#1/1 references: newsgroups: rec.games.corewar How about allowing pre-increment and post-decrement? -- Calvin Loh From: pan0178@comune.bologna.it (MV) Subject: Question about Round6 Date: 1995/11/13 Message-ID: <199511132239.RAA20143@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Just one question... Am I allowed to look at any cell (except your_hand, of course) in the core ? In example can I "peep" at enemy code? Maurizio Vittuari From: sieben@IMAP1.ASU.EDU Subject: NSFCWT round 5 result Date: 1995/11/13 Message-ID: newsgroups: rec.games.corewar NSFCWT round 5 is over. Good news. Michael Constant joined our tournament ( better late than never :-) There were 10 battles of 10-round round robins. The battles run for Elapsed time: 292 seconds (00:04:52) Elapsed time: 231 seconds (00:03:51) Elapsed time: 327 seconds (00:05:27) Elapsed time: 234 seconds (00:03:54) Elapsed time: 153 seconds (00:02:33) Elapsed time: 338 seconds (00:05:38) Elapsed time: 369 seconds (00:06:09) Elapsed time: 77 seconds (00:01:17) Elapsed time: 163 seconds (00:02:43) Elapsed time: 214 seconds (00:03:34) respectively. The tournament was run on a 100 Mhz Pentium. The random parameters were generated by the following program written in Turbo Pascal. ------------------8<---------------- const nsets=10; nrounds=10; var go,mts:text; round:integer; size,proc:longint; begin randomize; assign(go,'go.bat'); rewrite(go); writeln(go,'dir /b *.red >names.txt'); for round:=0 to nsets-1 do begin assign(mts,chr(ord('0')+round)+'mts.cmd'); rewrite(mts); writeln(mts); writeln(mts); size:=1000+random(20000-1000+1); proc:=10+random(10000-10+1); writeln(go,'rem size-processes ',size,'-',proc); writeln(go,'mts <',chr(ord('0')+round)+'mts.cmd'); writeln( mts,'pmars -bfr ',nrounds, ' -s ',size, ' -p ',proc, ' -c ',10*size); writeln(mts); writeln(mts,chr(ord('0')+round)+'scores.cmd'); writeln(mts); writeln(mts,'@names.txt'); writeln(mts); close(mts); end; close(go); end. ------------------------------8<------------------ The program generated the following parameters: Battle Coresize-Processes 1. 12164-4245 2. 9414-5576 3. 13230-1033 4. 12016-72 5. 6280-1164 6. 13810-6126 7. 14599-9549 8. 2798-5242 9. 6483-1330 10 .8597-2180 The detailed scores are: Battle 1. 1 Simple Scissors John K. Wilkinson 58 33 9 275 2 Frontwards Steven Morrell 49 30 21 253 3 Perspire Robert Macrae 44 23 33 248 4 WT-Round5 P.Kline 47 35 18 240 5 Mr Dumb Maurizio Vittuari 38 25 37 226 6 black & white Anders Ivner 41 33 25 224 7 Rubber wall Beppe Bezzi 30 17 53 214 8 Rand-Man Randy Graham 15 12 73 178 9 A Quick Hack Karl Lewin 16 16 68 174 10 blah blah blah M R Bremer 15 17 67 170 11 Miss Careworn Derek Ross 30 47 23 169 12 Theme Michael Constant 13 15 71 167 13 myImp Paulsson 8 30 62 129 14 Multi-Stone G. Eadon 12 84 4 60 Battle 2. 1 Simple Scissors John K. Wilkinson 57 29 13 278 2 Frontwards Steven Morrell 55 29 16 270 3 WT-Round5 P.Kline 49 33 17 248 4 Perspire Robert Macrae 44 26 30 243 5 Mr Dumb Maurizio Vittuari 40 25 35 232 6 black & white Anders Ivner 39 29 32 225 7 Rubber wall Beppe Bezzi 29 17 53 212 8 blah blah blah M R Bremer 23 13 65 199 9 Theme Michael Constant 11 10 79 169 10 A Quick Hack Karl Lewin 13 16 71 164 11 Miss Careworn Derek Ross 28 49 23 161 12 myImp Paulsson 9 25 66 138 13 Rand-Man Randy Graham 6 41 53 106 14 Multi-Stone G. Eadon 15 75 9 83 Battle 3. 1 Simple Scissors John K. Wilkinson 53 26 21 269 2 Perspire Robert Macrae 45 22 33 251 3 Frontwards Steven Morrell 50 35 15 248 4 black & white Anders Ivner 41 27 32 234 5 WT-Round5 P.Kline 46 41 13 227 6 Rubber wall Beppe Bezzi 28 11 61 218 7 Mr Dumb Maurizio Vittuari 28 20 52 204 8 blah blah blah M R Bremer 21 10 69 197 9 Theme Michael Constant 12 7 81 175 10 A Quick Hack Karl Lewin 11 11 78 168 11 Miss Careworn Derek Ross 29 51 20 162 12 Rand-Man Randy Graham 11 23 66 150 13 Multi-Stone G. Eadon 16 65 19 101 14 myImp Paulsson 0 45 55 83 Battle 4. 1 Perspire Robert Macrae 49 21 30 267 2 Rubber wall Beppe Bezzi 37 5 58 252 3 Mr Dumb Maurizio Vittuari 43 21 35 248 4 A Quick Hack Karl Lewin 32 2 66 243 5 blah blah blah M R Bremer 34 13 53 233 6 black & white Anders Ivner 37 30 33 215 7 Theme Michael Constant 27 15 59 208 8 Rand-Man Randy Graham 19 5 76 198 9 Simple Scissors John K. Wilkinson 37 52 11 182 10 Frontwards Steven Morrell 32 51 17 169 11 myImp Paulsson 13 17 70 165 12 WT-Round5 P.Kline 31 57 12 159 13 Miss Careworn Derek Ross 17 61 22 111 14 Multi-Stone G. Eadon 16 75 9 86 Battle 5. 1 Frontwards Steven Morrell 50 28 22 258 2 Perspire Robert Macrae 47 24 29 254 3 WT-Round5 P.Kline 47 34 19 241 4 black & white Anders Ivner 39 28 33 226 5 Simple Scissors John K. Wilkinson 45 39 16 225 6 blah blah blah M R Bremer 25 10 65 211 7 Rand-Man Randy Graham 22 10 68 201 8 Rubber wall Beppe Bezzi 27 21 52 201 9 Mr Dumb Maurizio Vittuari 29 25 46 198 10 A Quick Hack Karl Lewin 15 19 66 165 11 Theme Michael Constant 9 8 83 164 12 Miss Careworn Derek Ross 23 55 23 136 13 myImp Paulsson 9 27 65 136 Battle 6. 14 Multi-Stone G. Eadon 16 74 10 87 1 Frontwards Steven Morrell 57 23 21 286 2 WT-Round5 P.Kline 51 27 23 262 3 Simple Scissors John K. Wilkinson 49 37 13 242 4 black & white Anders Ivner 45 29 27 241 5 Perspire Robert Macrae 36 25 39 221 6 Mr Dumb Maurizio Vittuari 34 26 40 213 7 Rubber wall Beppe Bezzi 27 30 43 185 8 blah blah blah M R Bremer 19 17 65 181 9 Theme Michael Constant 12 9 79 173 10 Rand-Man Randy Graham 15 17 69 169 11 A Quick Hack Karl Lewin 11 15 73 161 12 myImp Paulsson 11 21 68 150 13 Miss Careworn Derek Ross 23 53 23 140 14 Multi-Stone G. Eadon 17 77 6 84 Battle 7. 1 Simple Scissors John K. Wilkinson 63 29 7 296 2 Frontwards Steven Morrell 55 24 21 278 3 Perspire Robert Macrae 40 27 33 229 4 WT-Round5 P.Kline 41 33 26 225 5 black & white Anders Ivner 39 31 29 221 6 Rubber wall Beppe Bezzi 28 11 61 217 7 blah blah blah M R Bremer 18 13 69 184 8 Mr Dumb Maurizio Vittuari 25 30 45 179 9 Theme Michael Constant 15 15 70 171 10 Miss Careworn Derek Ross 28 45 27 166 11 A Quick Hack Karl Lewin 14 20 66 162 12 Rand-Man Randy Graham 11 17 72 156 13 myImp Paulsson 5 21 75 133 14 Multi-Stone G. Eadon 17 80 3 80 Battle 8. 1 Frontwards Steven Morrell 65 23 13 310 2 black & white Anders Ivner 46 21 33 256 3 WT-Round5 P.Kline 49 29 22 255 4 Perspire Robert Macrae 38 29 33 221 5 Simple Scissors John K. Wilkinson 43 42 15 217 6 Rubber wall Beppe Bezzi 31 22 47 211 7 blah blah blah M R Bremer 25 15 59 203 8 A Quick Hack Karl Lewin 18 11 71 187 9 Miss Careworn Derek Ross 35 45 21 187 10 Mr Dumb Maurizio Vittuari 21 27 52 171 11 Theme Michael Constant 10 23 67 145 12 Rand-Man Randy Graham 10 26 64 141 13 myImp Paulsson 7 23 70 138 Battle 9. 14 Multi-Stone G. Eadon 16 79 5 80 1 Frontwards Steven Morrell 54 31 15 266 2 WT-Round5 P.Kline 51 32 17 254 3 Mr Dumb Maurizio Vittuari 34 17 49 227 4 Simple Scissors John K. Wilkinson 44 42 14 219 5 blah blah blah M R Bremer 25 9 67 211 6 Perspire Robert Macrae 36 33 31 209 7 Rubber wall Beppe Bezzi 25 15 59 203 8 black & white Anders Ivner 35 35 30 201 9 Theme Michael Constant 15 5 79 188 10 A Quick Hack Karl Lewin 15 14 71 175 11 Miss Careworn Derek Ross 26 49 25 155 12 Rand-Man Randy Graham 8 21 71 143 13 myImp Paulsson 9 23 69 142 14 Multi-Stone G. Eadon 20 72 8 102 Battle 10. 1 Simple Scissors John K. Wilkinson 57 25 17 284 2 WT-Round5 P.Kline 49 33 18 249 3 black & white Anders Ivner 45 28 27 242 4 Frontwards Steven Morrell 47 34 19 239 5 Mr Dumb Maurizio Vittuari 41 23 35 239 6 Perspire Robert Macrae 37 28 35 218 7 blah blah blah M R Bremer 21 9 71 199 8 Rubber wall Beppe Bezzi 21 18 61 187 9 A Quick Hack Karl Lewin 15 13 73 175 10 Theme Michael Constant 13 11 77 172 11 myImp Paulsson 9 23 68 144 12 Rand-Man Randy Graham 8 23 69 140 13 Miss Careworn Derek Ross 20 52 28 132 14 Multi-Stone G. Eadon 15 79 5 77 Here are the total scores of the 10 battles: Name Scores G. Eadon 840 Paulsson 1358 Derek Ross 1519 Randy Graham 1582 Michael Constant 1732 Karl Lewin 1774 M R Bremer 1988 Beppe Bezzi 2100 Maurizio Vittuari 2137 Anders Ivner 2285 P.Kline 2360 Robert Macrae 2361 John K. Wilkinson 2487 Steven Morrell 2577 The overall rank after round 5: Name 1 2 3 4 5 total Steven Morrell 5 10 9 13 14 51 P.Kline 7.5 9 7 11 11 45.5 Paulsson 7.5 11 11 9 2 40.5 Beppe Bezzi 7 7 13 2 8 37 John K. Wilkinson 4 6 12 - 13 35 Maurizio Vittuari 6.5 5 6 3 9 29.5 Anders Ivner 5.5 8 4 - 10 27.5 M R Bremer 7 4 3.6 5 7 26.6 Robert Macrae - - - 12 12 24 Randy Graham - - 8 10 4 22 Karl Lewin - - 10 4 6 20 Derek Ross 3.5 3 3.3 7 3 19.8 G. Eadon 1.5 2 5 6 1 15.5 Kurt Franke - - - 8 - 8 Michael Constant - - - - 5 5 Anders Scholl - 1 2 1 - 4 John Lewis - - 3 - - 3 Calvin Loh - - 1 - - 1 Good luck for round 6. Nandor & Stefan. From: Beppe Bezzi Subject: Core warrior n.5 Date: 1995/11/13 Message-ID: <199511132147.WAA31025@iol-mail.iol.it> newsgroups: rec.games.corewar .xX$$x. .x$$$$$$$x. d$$$$$$$$$$$ ,$$$$$$$P' `P' , . $$$$$$P' ' .d b $$$$$P b ,$$x ,$$x ,$$x ,$$b $$. Y$$$$' `$. $$$$$$. $$$$$$ $$P~d$. d$$$b d d$$$ `$$$$ ,$$ $$$$$$$b $$$P `$ $$$b.$$b `Y$$$d$d$$$' . . a . a a .aa . a `$$$ ,$$$,$$' `$$$ $$$' ' $$P$XX$' `$$$$$$$$$ .dP' `$'$ `$'$ , $''$ `$'$ `Y$b ,d$$$P `$b,d$P' `$$. `$$. , `$$P $$$' Y $. $ $ $ Y..P $ `$$$$$$$' $$$P' `$$b `$$$P `P `$' `Y'k. $. $. $. $$' $. Issue 5 13/11/95 ______________________________________________________________________________ Core_Warrior_ is a weekly newsletter promoting the game of corewar. Emphasis is placed on the most active hills--currently the '94 draft hill and the beginner hill. Coverage will follow where ever the action is. If you have no clue what I'm talking about then check out these five-star internet locals for more information: FAQs are available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z FTP site is: ftp.csua.berkeley.edu /pub/corewar Web pages are at: http://www.stormking.com/~koth http://www.ecst.csuchico.edu/~pizza/koth http://pauillac.inria.fr/~doligez/corewar/ ______________________________________________________________________________ Hi people, this one is quick scanners week. We have two real scoops for you: Thermite, n. 4 in hall of fame, and never published before, with comments of its author, Robert Mcrae, and Phq by Maurizio Vittuari, second old warrior in 94 hill, also with author's comments. Planar, our free lance columnist has a short hint, on equ behaviour, and a call for volunteer. We also have to report of great battles in 94 hill, after a couple of quiet weeks, a p-space hint, and a lot more for you dear readers. _____________________________________________________________________________ Tournament Time (details at http://www.stormking.com/~koth/nsfcwt.html) NSFCWT round 5 is over. Good news. Michael Constant joined our tournament ( better late than never :-) There were 10 battles of 10-round round robins. A turbo Pascal program generated the following parameters: Battle Coresize-Processes 1. 12164-4245 2. 9414-5576 3. 13230-1033 4. 12016-72 5. 6280-1164 6. 13810-6126 7. 14599-9549 8. 2798-5242 9. 6483-1330 10 .8597-2180 The detailed scores are: Battle 1. 1 Simple Scissors John K. Wilkinson 58 33 9 275 2 Frontwards Steven Morrell 49 30 21 253 3 Perspire Robert Macrae 44 23 33 248 4 WT-Round5 P.Kline 47 35 18 240 5 Mr Dumb Maurizio Vittuari 38 25 37 226 6 black & white Anders Ivner 41 33 25 224 7 Rubber wall Beppe Bezzi 30 17 53 214 8 Rand-Man Randy Graham 15 12 73 178 9 A Quick Hack Karl Lewin 16 16 68 174 10 blah blah blah M R Bremer 15 17 67 170 11 Miss Careworn Derek Ross 30 47 23 169 12 Theme Michael Constant 13 15 71 167 13 myImp Paulsson 8 30 62 129 14 Multi-Stone G. Eadon 12 84 4 60 Battle 2. 1 Simple Scissors John K. Wilkinson 57 29 13 278 2 Frontwards Steven Morrell 55 29 16 270 3 WT-Round5 P.Kline 49 33 17 248 4 Perspire Robert Macrae 44 26 30 243 5 Mr Dumb Maurizio Vittuari 40 25 35 232 6 black & white Anders Ivner 39 29 32 225 7 Rubber wall Beppe Bezzi 29 17 53 212 8 blah blah blah M R Bremer 23 13 65 199 9 Theme Michael Constant 11 10 79 169 10 A Quick Hack Karl Lewin 13 16 71 164 11 Miss Careworn Derek Ross 28 49 23 161 12 myImp Paulsson 9 25 66 138 13 Rand-Man Randy Graham 6 41 53 106 14 Multi-Stone G. Eadon 15 75 9 83 Battle 3. 1 Simple Scissors John K. Wilkinson 53 26 21 269 2 Perspire Robert Macrae 45 22 33 251 3 Frontwards Steven Morrell 50 35 15 248 4 black & white Anders Ivner 41 27 32 234 5 WT-Round5 P.Kline 46 41 13 227 6 Rubber wall Beppe Bezzi 28 11 61 218 7 Mr Dumb Maurizio Vittuari 28 20 52 204 8 blah blah blah M R Bremer 21 10 69 197 9 Theme Michael Constant 12 7 81 175 10 A Quick Hack Karl Lewin 11 11 78 168 11 Miss Careworn Derek Ross 29 51 20 162 12 Rand-Man Randy Graham 11 23 66 150 13 Multi-Stone G. Eadon 16 65 19 101 14 myImp Paulsson 0 45 55 83 Battle 4. 1 Perspire Robert Macrae 49 21 30 267 2 Rubber wall Beppe Bezzi 37 5 58 252 3 Mr Dumb Maurizio Vittuari 43 21 35 248 4 A Quick Hack Karl Lewin 32 2 66 243 5 blah blah blah M R Bremer 34 13 53 233 6 black & white Anders Ivner 37 30 33 215 7 Theme Michael Constant 27 15 59 208 8 Rand-Man Randy Graham 19 5 76 198 9 Simple Scissors John K. Wilkinson 37 52 11 182 10 Frontwards Steven Morrell 32 51 17 169 11 myImp Paulsson 13 17 70 165 12 WT-Round5 P.Kline 31 57 12 159 13 Miss Careworn Derek Ross 17 61 22 111 14 Multi-Stone G. Eadon 16 75 9 86 Battle 5. 1 Frontwards Steven Morrell 50 28 22 258 2 Perspire Robert Macrae 47 24 29 254 3 WT-Round5 P.Kline 47 34 19 241 4 black & white Anders Ivner 39 28 33 226 5 Simple Scissors John K. Wilkinson 45 39 16 225 6 blah blah blah M R Bremer 25 10 65 211 7 Rand-Man Randy Graham 22 10 68 201 8 Rubber wall Beppe Bezzi 27 21 52 201 9 Mr Dumb Maurizio Vittuari 29 25 46 198 10 A Quick Hack Karl Lewin 15 19 66 165 11 Theme Michael Constant 9 8 83 164 12 Miss Careworn Derek Ross 23 55 23 136 13 myImp Paulsson 9 27 65 136 Battle 6. 14 Multi-Stone G. Eadon 16 74 10 87 1 Frontwards Steven Morrell 57 23 21 286 2 WT-Round5 P.Kline 51 27 23 262 3 Simple Scissors John K. Wilkinson 49 37 13 242 4 black & white Anders Ivner 45 29 27 241 5 Perspire Robert Macrae 36 25 39 221 6 Mr Dumb Maurizio Vittuari 34 26 40 213 7 Rubber wall Beppe Bezzi 27 30 43 185 8 blah blah blah M R Bremer 19 17 65 181 9 Theme Michael Constant 12 9 79 173 10 Rand-Man Randy Graham 15 17 69 169 11 A Quick Hack Karl Lewin 11 15 73 161 12 myImp Paulsson 11 21 68 150 13 Miss Careworn Derek Ross 23 53 23 140 14 Multi-Stone G. Eadon 17 77 6 84 Battle 7. 1 Simple Scissors John K. Wilkinson 63 29 7 296 2 Frontwards Steven Morrell 55 24 21 278 3 Perspire Robert Macrae 40 27 33 229 4 WT-Round5 P.Kline 41 33 26 225 5 black & white Anders Ivner 39 31 29 221 6 Rubber wall Beppe Bezzi 28 11 61 217 7 blah blah blah M R Bremer 18 13 69 184 8 Mr Dumb Maurizio Vittuari 25 30 45 179 9 Theme Michael Constant 15 15 70 171 10 Miss Careworn Derek Ross 28 45 27 166 11 A Quick Hack Karl Lewin 14 20 66 162 12 Rand-Man Randy Graham 11 17 72 156 13 myImp Paulsson 5 21 75 133 14 Multi-Stone G. Eadon 17 80 3 80 Battle 8. 1 Frontwards Steven Morrell 65 23 13 310 2 black & white Anders Ivner 46 21 33 256 3 WT-Round5 P.Kline 49 29 22 255 4 Perspire Robert Macrae 38 29 33 221 5 Simple Scissors John K. Wilkinson 43 42 15 217 6 Rubber wall Beppe Bezzi 31 22 47 211 7 blah blah blah M R Bremer 25 15 59 203 8 A Quick Hack Karl Lewin 18 11 71 187 9 Miss Careworn Derek Ross 35 45 21 187 10 Mr Dumb Maurizio Vittuari 21 27 52 171 11 Theme Michael Constant 10 23 67 145 12 Rand-Man Randy Graham 10 26 64 141 13 myImp Paulsson 7 23 70 138 Battle 9. 14 Multi-Stone G. Eadon 16 79 5 80 1 Frontwards Steven Morrell 54 31 15 266 2 WT-Round5 P.Kline 51 32 17 254 3 Mr Dumb Maurizio Vittuari 34 17 49 227 4 Simple Scissors John K. Wilkinson 44 42 14 219 5 blah blah blah M R Bremer 25 9 67 211 6 Perspire Robert Macrae 36 33 31 209 7 Rubber wall Beppe Bezzi 25 15 59 203 8 black & white Anders Ivner 35 35 30 201 9 Theme Michael Constant 15 5 79 188 10 A Quick Hack Karl Lewin 15 14 71 175 11 Miss Careworn Derek Ross 26 49 25 155 12 Rand-Man Randy Graham 8 21 71 143 13 myImp Paulsson 9 23 69 142 14 Multi-Stone G. Eadon 20 72 8 102 Battle 10. 1 Simple Scissors John K. Wilkinson 57 25 17 284 2 WT-Round5 P.Kline 49 33 18 249 3 black & white Anders Ivner 45 28 27 242 4 Frontwards Steven Morrell 47 34 19 239 5 Mr Dumb Maurizio Vittuari 41 23 35 239 6 Perspire Robert Macrae 37 28 35 218 7 blah blah blah M R Bremer 21 9 71 199 8 Rubber wall Beppe Bezzi 21 18 61 187 9 A Quick Hack Karl Lewin 15 13 73 175 10 Theme Michael Constant 13 11 77 172 11 myImp Paulsson 9 23 68 144 12 Rand-Man Randy Graham 8 23 69 140 13 Miss Careworn Derek Ross 20 52 28 132 14 Multi-Stone G. Eadon 15 79 5 77 Here are the total scores of the 10 battles: Name Scores G. Eadon 840 Paulsson 1358 Derek Ross 1519 Randy Graham 1582 Michael Constant 1732 Karl Lewin 1774 M R Bremer 1988 Beppe Bezzi 2100 Maurizio Vittuari 2137 Anders Ivner 2285 P.Kline 2360 Robert Macrae 2361 John K. Wilkinson 2487 Steven Morrell 2577 The overall rank after round 5: Name 1 2 3 4 5 total Steven Morrell 5 10 9 13 14 51 P.Kline 7.5 9 7 11 11 45.5 Paulsson 7.5 11 11 9 2 40.5 Beppe Bezzi 7 7 13 2 8 37 John K. Wilkinson 4 6 12 - 13 35 Maurizio Vittuari 6.5 5 6 3 9 29.5 Anders Ivner 5.5 8 4 - 10 27.5 M R Bremer 7 4 3.6 5 7 26.6 Robert Macrae - - - 12 12 24 Randy Graham - - 8 10 4 22 Karl Lewin - - 10 4 6 20 Derek Ross 3.5 3 3.3 7 3 19.8 G. Eadon 1.5 2 5 6 1 15.5 Kurt Franke - - - 8 - 8 Michael Constant - - - - 5 5 Anders Scholl - 1 2 1 - 4 John Lewis - - 3 - - 3 Calvin Loh - - 1 - - 1 Paulsson, previous leader, had a flop in this round, losing the head. Now Steven Morrell is the new leader with 5.5 points over Paul Kline, that seems the only one able to contend him first place, and more than 10 over other contenders. The fight is open for third position, with three players in near five points. _____________________________________________________________________________ 94 Hill - Standings # %W/ %L/ %T Name Author Score Age 1 41/ 23/ 36 La Bomba Beppe Bezzi 158 8 2 42/ 38/ 20 Derision M R Bremer 145 9 3 43/ 44/ 13 Leprechaun on speed Anders Ivner 141 165 4 35/ 32/ 32 Phq Maurizio Vittuari 138 471 5 35/ 32/ 33 Torch t18 P.Kline 137 369 6 37/ 38/ 25 endpoint . M R Bremer 137 14 7 40/ 43/ 17 Porch Swing + Randy Graham 137 70 8 37/ 39/ 24 myVamp v3.7 Paulsson 135 337 9 33/ 32/ 35 Father & Son Maurizio Vittuari 135 19 10 34/ 35/ 32 Thieves Like Us M R Bremer 133 27 11 33/ 34/ 33 Son & Father Maurizio Vittuari 132 20 12 30/ 28/ 41 Jack in the box Beppe Bezzi 132 357 13 39/ 46/ 15 Leprechaun deluxe Anders Ivner 132 274 14 26/ 20/ 54 Impfinity v3e7 Planar 132 34 15 39/ 47/ 14 Frontwards Steven Morrell 131 304 16 18/ 6/ 76 Chugging Along Karl Lewin 130 54 17 34/ 38/ 28 Armory - A5 Wilkinson 130 508 18 28/ 29/ 43 .Brain Vamp. B.Bezzi, M.Paulsson 128 71 19 38/ 48/ 15 Anti Die-Hard Bevo (3c) John Wilkinson 127 174 20 29/ 30/ 42 nobody special Schitzo 127 1 Revolution may be the theme word this week, the 94 hill has awaken after some sleep. Bezzi's La Bomba exploded on the hill, taking strongly the head; new Bremer's warrior in not worth Derision indeed: now and we have new n. 1 and n. 2 _____________________________________________________________________________ 94 - What's new 1 40/ 24/ 36 La Bomba Beppe Bezzi 156 1 2 42/ 38/ 20 Derision M R Bremer 145 1 5 34/ 28/ 38 Father & Son Maurizio Vittuari 139 1 7 37/ 38/ 24 endpoint . M R Bremer 136 1 9 34/ 33/ 33 Thieves Like Us M R Bremer 135 1 9 33/ 32/ 35 Son & Father Maurizio Vittuari 133 1 20 29/ 30/ 42 nobody special Schitzo 127 1 Just a few ;-) a new King, a new n. 2 some new entries in the middle. Welcome back to Mike 'Schitzo' Nonemacher with his improved version of an old King. _____________________________________________________________________________ 94 - What's no more 21 32/ 36/ 32 Tornado 1.8 Beppe Bezzi 129 203 21 34/ 43/ 23 myZizzor Paulsson 126 75 21 22/ 18/ 59 paper01o Beppe Bezzi 126 18 A veteran, Tornado 1.8, leaves us at 203 age :-( a younger but rather famous warrior, myZizzor, the Die Hard killer, is out too. _____________________________________________________________________________ What's old 17 34/ 38/ 28 Armory - A5 Wilkinson 130 508 4 35/ 32/ 32 Phq Maurizio Vittuari 138 471 5 35/ 32/ 33 Torch t18 P.Kline 137 369 12 30/ 28/ 41 Jack in the box Beppe Bezzi 132 357 8 37/ 39/ 24 myVamp v3.7 Paulsson 135 337 15 39/ 47/ 14 Frontwards Steven Morrell 131 304 13 39/ 46/ 15 Leprechaun deluxe Anders Ivner 132 274 Armory passed age 500 and Frontwards 300, congratulations. No new entry in the over 200, the only one went out at 203, see above. Some veteran begins having problems; Torch and Phq keep positions, Jack in the Box and myVamp lose a few places, Armory and Frontward begin to risks being pushed off. _____________________________________________________________________________ HALL OF FAME * means the warrior is still running. Pos Name Author Age Strategy 1 Iron Gate 1.5 Wayne Sheppard 926 CMP scanner 2 Agony II Stefan Strack 912 CMP scanner 3 Blue Funk Steven Morrell 869 Stone/ imp 4 Thermite 1.0 Robert Macrae 802 Qscan -> bomber 5 Blue Funk 3 Steven Morrell 766 Stone/ imp 6 HeremScimitar A.Ivner,P.Kline 666 Bomber 7 B-Panama X Steven Morrell 518 Stone/ replicator 8 Armory - A5 Wilkinson 508 * P-warrior 9 Phq Maurizio Vittuari 471 * Qscan -> replicator 10 NC 94 Wayne Sheppard 387 Stone/ imp 11 Cannonade P.Kline 382 Stone/ imp 12 Torch t17 P.Kline 378 Bomber 13 Torch t18 P.Kline 369 * Bomber 14 Jack in the box Beppe Bezzi 357 * P-warrior 15 Lucky 3 Stefan Strack 355 Stone/ imp 16 Request v2.0 Brant D. Thomsen 347 Qvamp -> vampire 17 Dragon Spear c w blue 346 CMP scanner 18 myVamp v3.7 Paulsson 337 * Vampire 19 juliet storm M R Bremer 333 Stone/ imp 20 TimeScape (1.0) J. Pohjalainen 322 Replicator my Vamp enters the elite, pushing Rave off. Torch and Jack gain a few positions. Armory is now very near B-Panama X. _____________________________________________________________________________ Beginner's Hill standings # %W/ %L/ %T Name Author Score Age 1 41/ 29/ 30 Lurker 1.1 Kurt Franke 152 36 2 30/ 12/ 58 juliet storm M R Bremer 147 75 3 37/ 34/ 29 Test-Fc G. Eadon 140 61 4 25/ 11/ 64 Schizo J. Doster 139 6 5 27/ 16/ 57 Trapper 1.1 Kurt Franke 139 11 6 39/ 41/ 20 Look J. Doster 137 3 7 38/ 41/ 21 Searching Kurt Franke 136 42 8 32/ 33/ 35 Hint Test v4 M R Bremer 132 7 9 21/ 11/ 68 Impfinity v3c11 Planar 131 18 10 16/ 8/ 75 Sheet 1.0 J. Doster 124 16 11 17/ 9/ 74 Paper8 G. Eadon 124 37 12 35/ 47/ 18 Heatseek2 Phil Whineray 123 53 13 16/ 11/ 72 RingWorm_v2.4 Calvin Loh 122 4 14 32/ 45/ 24 Recon V7.0 A. Nevermind 119 1 15 12/ 6/ 81 Impfinity v1 Planar 118 50 16 15/ 15/ 70 P_Banzai_v2.1 Calvin Loh 114 5 17 12/ 13/ 75 RingWorm_v1.0 Calvin Loh 112 22 18 11/ 11/ 78 RingWorm_v1.4 Calvin Loh 111 20 19 14/ 19/ 66 Paper Dragon Kurt Franke 109 32 20 12/ 16/ 72 P_Banzai_v1.2 Calvin Loh 109 24 Not too much movement here; less than 10 new warriors. I cannot say more because I haven't got my test warrior's results. _____________________________________________________________________________ The hint P-space Hi, this time we'll speak of p-space, the last tool, implemented by pmars08, that allows our warrior to change strategy according to the history of the match. P-space is a protected area of memory, i.e. every warrior has its own p-space and cannot read or write opponent's one. P-space hold but values, not whole instructions, and is accessed by two specific instructions LDP and STP load and store Pspace. At the beginning of every round p-space cell 0 holds the result of previous round, -1 at the very beginning, others cells hold the value they had at the end of previous round, 0 at the start of the match. The value is 0 if we lose, and the number of alive warriors if we survive; in standard one against one matches those values are 1 for the win and 2 for the tie. Warriors using p-space are called p-warriors or p-switchers; they store in a location of p-space informations on the strategy they are using, at the end of the round they evaluate the result of prvious round and, according to it and, sometimes, the result of others rounds, continue with current strategy or change to another, in the hope of doing better. In practice, if you are a general, planning long term strategies, the switcher is your colonel, deciding on battlefield what to use against your opponent. It's important to say that even the best switching routine is worthless if you don't have sound combat routines; if all you components lose against your enemy, the mix will lose too, sometimes even worst because you lose some time at the beginning to pplan the round, and to boot components away from the big warrior body. P-space is a tool for intermediate players, not for beginners; until you don't have at least two average level different warriors, a stone and a paper for example, you cannot get anyhing good from it. Now let's see how to assemble a p-warrior; first we need good components, able to score points against different kind of enemies; we have them: Paper01, to score against enemy bombers, juliet storm, to kill enemy scanners; against enemy paper we are not defenceless, a paper usually cannot beat another paper, so we should score: Well against bombers, thanks Paper01 Well against scanners, thanks juliet Ties against replicators, thanks Paper01. Once chosen our hands, we have to assemble the brain; unless you want to do something very complex, the switcher is not a difficult thing to do. Let's give a look at a very simple one, and BTW successful, the switcher of Jack in the Box, for three main reasons: it's one of my warriors, is doing well, is the only one published :-) Jack's has two components, a very heavy replicator, four times Paper01, and a very fast bomber, Tornado. Its strategy is simple: the replicator scores lots of points against enemy bombers but, because of the size, is rather vulnerable to scanners; well if we are winning or tieing all right, we continue with the same strategy; if a bad scanners happens to kill the paper, BOOH, Tornado pop up and with its high speed and colored bombs kill him. Here it's, very simple indeed. _RES equ 0 ;here pmars loads results _STR equ 1 ;here I store my strategy res ldp.ab _RES, #0 ;load result last match str ldp.a _STR, str1 ;load strategy in use sne.ab #0, res ;check result, win or tie OK lost add.a #1, str1 ;lost change mod.a #2, str1 ;secure jump win stp.ab str1, _STR ;save strategy str1 jmp @0, juliet dat 0, paper We load in res.b the result of last match, in str1.a the strategy we used, then we compare res to 0, if it's zero we add one to the strategy, if it's different, tie or win, we don't. The mod instruction assure us to have a value of 0 or 1. At last we save new strategy for the round, and we jump at bomber or paper, according to str1.a In 7 cycles we have finished, so even a Qscan has hard times to hang on. Now the code, nothing more than taking the waariors, the switcher an putting all together. Last note, near to forget it, P-space has a 'dark side', brainwashing. You cannot access your opponent p-space, but if you mage to force your opponent, with a vampire attack, to execute these lines of code, or something similar: bwash spl 0,>1 stp.ab #0,#0 jmp -2,{-1 (usually this code is together with others spl and a core clear) its p-space will soon fill of garbish and it's rather difficult that, in the following round, its switcher will found what it needs to make a correct decision. So, when you make your switcher, don't forget to think at what will happens if something goes wrong in your p-space, and, _most_important_, never forget to mod you STR value before executing the jump. mod #2, 1 str jmp @0, paper ;a field holds strategy dat 0, juliet If you forget it, may happens your warrior will have to execute something like str jmp @1234,paper and you will score something like 0/249/1 :-( Here is the code. I submitted the warrior at both -94 and beginners hill, if you have any question, or you are interested in results, mail me ------------------------------ ;redcode-b quiet ;name juliet and paper ;author M R Bremer, B. Bezzi ;strategy p-warrior for C.W. n.5 hint ;strategy switches juliet storm and Paper01 ;kill juliet and paper ;assert CORESIZE == 8000 ptr EQU -1333 dest0 equ 2200 dest1 equ 3740 dest2 equ -1278 range equ 933 RES equ 0 ;here pmars loads results STR equ 1 ;here I store my strategy imp_sz equ 2667 org start gate dat <-445, <-446 s spl #445, <-445 spl #0, <-446 mov {445-1, -445+2 add -3, -1 djn.f -2, <-2667-500 mov 32, <-20 go dat #0, #ptr juliet mov {-1, <-1 mov {-2, <-2 mov {-3, <-3 mov {-4, <-4 mov {-5, <-5 mov {-6, <-6 mov gate, ptr+24 mov gate, ptr+24 spl @go, <4000 jmp boot, <4013 start res ldp.ab RES, #0 ;load result last match str ldp.a STR, str1 ;load strategy in use sne.ab #0, res ;check result, win or tie OK lost add.a #1, str1 ;lost change mod.a #2, str1 ;secure jump win stp.ab str1, _STR ;save strategy str1 jmp @0, juliet dat 0, paper paper spl 1, <300 ;\ spl 1, <400 ;-> generate 8 consecutive processes spl 1, <500 silk spl @0, {dest0 mov.i }-1, >-1 silk1 spl @0, -1 ;copy self to new location mov.i bomba, }range mov {silk1, dest2 bomba dat <2667, <1 for MAXLENGTH-CURLINE-9 dat 0,0 rof boot spl 1 ,#0 spl 1 ,#0 spl <0 ,#vector+1 djn.a @vector,#0 imp mov.i #0,imp_sz jmp imp+imp_sz*7,imp+imp_sz*6 jmp imp+imp_sz*5,imp+imp_sz*4 jmp imp+imp_sz*3,imp+imp_sz*2 vector jmp imp+imp_sz ,imp end ______________________________________________________________________________ Planar's corner: Next week, you'll get the sequel to my article about imp spirals. Today, I have a short hint for beginners and a call for volunteers. The short hint: --------------- I have written the following program: ;redcode foo equ 1+2 nop foo*2 Giving it to pMARS, I get this load file: START NOP.F $ 5, $ 0 Hey ! What's going on here ? If foo is 1+2 and the argument to NOP is foo*2, then it must be 6, right ? Wrong. The argument is 1+2*2 = 5, because EQU does a textual replacement of the label with its argument, not a numerical evaluation of its argument (there is a good reason for this). The solution is the same as in the C language: use parentheses generously: foo equ (1+2) Now the argument to NOP is (1+2)*2 and I'm happy. Maybe this was the reason why my warrior failed on the hill. But then again, maybe not. The call for volunteers: ------------------------ I have started updating the ICWS'94 draft standard. My new version includes the new addressing modes and opcodes we are all using every day. Who will add p-space into it ? We have missed the '94 deadline by a long time now, and I think it's time to turn the draft into a standard (does the ICWS still exist, by the way ?) Or at least the draft should describe the language that we are using. Before we start discussing read/write limits, Stefan asked that I post a summary of all the good arguments against them, so I have to find the postings of one and a half year ago (does anybody know where to find an archive of recent postings to r.g.cw ?) Please no flame war before I declare the season open. The new version of the ICWS'94 draft standard is available at http://pauillac.inria.fr/~doligez/corewar/icws94.95 ______________________________________________________________________________ Extra Extra: Thermite With impeccable timing I re-arrive on the internet just as Thermite is knocked off the hill, appropriately enough by Michael Constant. I don't think I ever published the code, so here it is with explanations as accurate as the mists of time permit. I'm not really sure why it worked for so long, but I guess it was a lack of decisive weaknesses rather than any single strength. Maybe P-space even helped, making targets bigger... Thermite was standard quickscan, followed by a Torch-like incendiary bomber. The quickscan was originally developed from Michael Constant's Sauron (94 tournament) and ended up almost exactly like his Pyramid. I experimented with various warriors to follow the scanning stage: a vampire, Midge, sadly couldn't bite as fast as Silks could grow, and Queasy (4-word Mod-1 MOV incendiary bomber. ;assert CORESIZE == 8000 ; Since I don't launch phosphorus, vulnerable to carpet bombers. May ; pay to put it at start? I should make better use of DJN stream ; (nascent). Either use <, or else start it somewhere which gets bombed ; by mov fairly quickly. What happens if I fall through early, due to ; DAT 1,1s? Should check this doesn't hurt... SPC equ 7700 ; (CORESIZE-MAXLENGTH-MINDISTANCE*2) STP1 equ 81 ; (SPC / (RAM/2) / 2) Lookat equ look+237+8*(qscan-1)*STP1 ; First scan at 237; last at -67? traptr dat #0, #trap bite jmp @traptr, 0 ; Vampire bite. ; Lots of pointers to these, so keep them away from trap! look qscan for 6 sne.i Lookat+0*STP1, Lookat+2*STP1 seq.i Lookat+4*STP1, Lookat+6*STP1 mov.ab #Lookat-bite-2*STP1, @bite rof jmn test+1, bite ; Save a few cycles qscan for 6 sne.i Lookat+48*STP1, Lookat+50*STP1 seq.i Lookat+52*STP1, Lookat+54*STP1 mov.ab #Lookat-bite+46*STP1, @bite rof jmn test+1, bite ; Save a few cycles qscan for 6 sne.i Lookat+1*STP1, Lookat+3*STP1 seq.i Lookat+5*STP1, Lookat+7*STP1 mov.ab #Lookat-bite-STP1, @bite rof jmn test+1, bite ; Save a few cycles qscan for 6 ; Should be 7 if I had space... sne.i Lookat+49*STP1, Lookat+51*STP1 seq.i Lookat+53*STP1, Lookat+55*STP1 mov.ab #Lookat-bite+47*STP1, @bite rof ; Intention is to place points evenly through the target area. test jmz.b blind, bite ; if no address stored, no hit. add #STP1*2, bite ; Smaller than pyramid, as fast. jmz.f -1, @bite ; find nonzero element. mov spb, @bite ; Quick pre-bomb... add #49, bite ; aim 51 past the hit attack sub.ba bite, bite ; bite(b) contains target-bite loop mov bite, @bite ; (a) contains the bite addr. add.f step, bite djn loop, #24 ; 6 spacing => 72 cycles... ; Incendiary bomber based on Phosphorus 1.0 (from Torch). bstp equ 155 ; Mod 5, as too big for mod 4 to miss! gap equ 15 ; Gap between mov and spl. offset equ 130 ; Chosen with step and gap to give long bombing run. count equ 1500 blind spb spl #0, <-gap+1 ; spl half of the incendiary add #bstp, 1 mov spb, @tgt-offset ; Gives longest run, given gap & step. mov mvb, @-1 tgt djn.f -3, >300 ; gets bombed with spl to start clear mov ccb, >spb-1 ; Uses copied mvb for CC. djn.f -1, gap ; mov half of the incendiary ccb dat 0, 10 ; Core Clear. ; Bit worried about having trap so close to my code... trap spl 0, >-200 ; Lackadaisical attempt at gates. spl -1, >-200+2667 ; Each increments many times between jmp -2, >-200+2*2667 ; imp steps, but then the whole imp ; moves! I only blow away rings... step dat #6, #-6 ; QS step size. Up from 5 for speed. end look (Editor note: I had to change it a little, because Robert used STP as a label, and now it's not allowed being it an opcode. Just hope I didn't introduce bugs; I tested it and all seems OK. - B.B.) ______________________________________________________________________________ Extra Extra Extra: Phq Well! I have received lots of requests about Phq so I have decided to publish it... (in other words CoreWarrior' staff has payed me enough ! ;-) Phq is one of my first programs written in 94 standard (I have started redcoding with the 86 standard...) First of all two words about the name... Phq recalls a formula of quantum mech: the original name had been Emc2 (reference to 2c initial qscan) but Emc2 was also the name of another my QScan-->Stone warrior that never worked very fine... When I began making Phq, another program behaved very well: Marcia Trionfale of our friend Beppe Bezzi; so I decided that my warrior should contain a paper module! At those times most of the programs on the hill reached the limit of 100 istructions, this made me choose for the initial QScan pass. The initial QScan is also very useful to solve (without any PSpace routines) the problem of papers in gaining points during self fighting: QScan makes Phq able to kill itself in self fighting about 83% times. So I took the decision: my program will have to be a Qscan --> Paper ! Well! At this point I had to decide what could I do if QScan found an enemy, or simple a decoy :( ! The first attempt was to bomb the neighborhood of the cell differing from dat.f 0,0 (blank) with simple dat bombs, using a series of "mov bomb,-1, }-1 mov.i bomb, }1942 s2 spl step2, #0 mov.i >-1, }-1 mov.i bomb, }1842 ;I've changed > with } so many times mov.i bomb, >1900 ;that I can't remember if this version mov.i bomb, }2000 ;is the one actually on the hill... mov.i , flame Myer or if you think it's of general interest post to rec.games.corewar Anyone with hints or warriors to publish is welcome. From: st56x@jane.uh.edu Subject: Internet Survye Date: 1995/11/13 Message-ID: <13NOV199521063194@jane.uh.edu>#1/1 newsgroups: rec.games.corewar Hello, I am conducting a survey on the internet. Those who respond are eligible for a complimentary. Please send your answers to the questions below to the address: st56x@jetson.uh.edu Thank you. 1) Besides from work, how often do you spend time on the computer for hobby and leisure (in hours/week)? 2) Is it better to buy or rent CD-ROMs software or games? 3) Do you consider yourself a "cyberpunk" given the definition that you understand? 4) Are PC games better to play: i) against the computer, ii) against head-to-head with another opponent, or iii) in a networked group of 4 or more other people. 5) Which, if any, cyber-culture magazines do you like to read? Feel free to elaborate on any of your answers in your return email. If there are any interests in the results, I will post it after the survey is completed. Thank you for your consideration and understanding. From: graham@harlie.mathcs.rhodes.edu (Randy Graham) Subject: Re: djn.x behavior Date: 1995/11/13 Message-ID: <1995Nov13.074905.3049@rhodes>#1/1 references: <1995Oct30.101251.2997@rhodes> <47454b$t1r@nuscc.nus.sg> newsgroups: rec.games.corewar Loh Weng Keong Calvin (lohwengk@iscs.nus.sg) wrote: : : org code : : djn_2 dat.f 5, 10 : : djn_1 dat.f 52, 1 : : djn_ptr dat.f 0, 0 : : code djn.x 0, <-1 : : other ... do something here : Is this what you got after the first time? : djn_1 dat.f 51, 1 No, I got djn_1 dat.f 51, 0 but I expected to get djn_1 dat.f 0, 51 However, I finally got the '94 draft and saw that what I got was indeed the intention according to the draft. : -- : Calvin Loh Randy From: Michael N Nonemacher Subject: Re: Theme (round 5 entry) Date: 1995/11/13 Message-ID: #1/1 references: <1995Nov9.142248.3038@rhodes> newsgroups: rec.games.corewar Excerpts from netnews.rec.games.corewar: 11-Nov-95 Theme (round 5 entry) by Michael Constant@soda.CS > Finally, the idea of combing paper with an imp is due to Mike Nonemacher, > who used it quite successfully some time ago in a warrior whose name I > have forgotten. Thus, any weaknesses in Theme are most likely due to my > implementation, rather than to the original idea. Hehe... I'd have to disagree with you here. :) The original was called Paradox something-or-other, and I seem to remember there being a version of it on Planar's home page. In its final form, it combined a gate-crashing spiral with a highly tweaked paper (which combined anti-imp, anti-vamp, and vampiric elements). The gate-crashing spiral is what made it effective. It'd be interesting to see how it works when it involves silk paper (the original was stuck using the old copy *then* split paper). Eventually, its Achilles' heel was the fact that, against scanners, the gate-crashing spiral was the only thing that kept it from losing miserably. It never could beat spl-carpet scanners, and when Iron Gate went from mod-2 to mod-1, Paradox couldn't beat it consistently, either. Interesting, though. I wonder how the addition of an imp would affect a modern paper... Anyway, (surprised to see anyone actually read that long thru all my nostalgic ramblings) I'm glad someone found a use for it. Glad to hear it didn't fall on the dustbin of CoreWar history... Schitzo From: sieben@imap1.asu.edu Subject: Re: Question about Round6 Date: 1995/11/14 Message-ID: <48953l$od4@news.asu.edu>#1/1 references: <199511132239.RAA20143@valhalla.stormking.com> newsgroups: rec.games.corewar MV (pan0178@comune.bologna.it) wrote: : Just one question... : Am I allowed to look at any cell (except your_hand, of course) in the core ? : In example can I "peep" at enemy code? : Maurizio Vittuari Of course not. We won't be able to check every warrior for this but the warriors will be published after the round so anybody can check why his warrior lost so frequently against a particular opponent :-) Nandor. From: sieben@IMAP1.ASU.EDU Subject: NSFCWT round 6 tester Date: 1995/11/14 Message-ID: #1/1 newsgroups: rec.games.corewar Karl Lewin sent me a tester program that implement my cheating idea. Please test your warriros against this tester. Your warrior should lose against it 100 % . We are going to test all submissions with this so now it's an official requirement to pass this test. There is one more thing. You shouldn't look at your enemy's code. I think would only be usefull against the whites anyway. Nandor. ;redcode-94 ;name Test for Timeouts ;author Karl Lewin ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in he ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- start jmz.b start, your_hand sne.ab STONE, your_hand mov.ab PAPER, my_hand sne.ab SCISSORS,your_hand mov.ab STONE, my_hand sne.ab PAPER, your_hand mov.ab SCISSORS,my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end From: Beppe Bezzi Subject: Re: P-space Date: 1995/11/14 Message-ID: <199511141842.TAA09955@iol-mail.iol.it> newsgroups: rec.games.corewar Tim Chapman wrote: >On Fri, 10 Nov 1995, Michael Constant wrote: > >> > What about all the things that have already been mentionned, like Self >> > Repairing programs and coordination of multi-processes bombs? >> >> An imp-spiral is the ultimate self-repair program. It is very effective >> and it is the epitome of simplicity. More complicated self-repair programs >> wouldn't work even with a more powerful P-space -- the problem with a self- >> repair program is not that it doesn't have a clean copy of its own code, but >> rather that it is too slow to be effective. > >Tell me about it....! :) I believe that a self repair warrior isn't feasible, using or not -space; when you check or repair yourself you have to do it in all your warrior lenght, while an enemy dropping a single spl-jmp bomb can disable you. The defence in corewar is done with boot and decoy, adding imps to stones, using colored bombs etc. All those things are well known and maybe some other will come up. > >> >> Multi-process bombs can be coordinated perfectly well by storing simple >> numbers in P-space. Full instructions are not required, and I can't even >> see how they would help. > >If the bomb itself was stored in p-space, a single command program could >rewrite the bomb in p-space, and all of the sub-process bomb routines >would instantly change to the new bomb. This p-space method makes these >sorts of ideas feasible, when they would be either too long, or too slow >in normal redcode. I don't think that using full p-space one can do faster than that: silk spl @0, away mov }-1,>-1 stp.a #BOMB,1 ;BOMB may hold 2 or 3 mov.i 0, target jmp silk,{silk bomb1 dat 1,1 bomb2 dat <2667,<5334 Sure with full p-space you can use a line less, but this is the 'reduced footprint' problem. Keeping but the scanner in core and the clear part in p-space one can make a very deadly guy. > >> >> > Also, how about copying the ENEMY program into your own p-space for >> > analysis at the start of the next battle? >> >> That's a pretty cool idea, but how is it different from simply scanning for >> the enemy program, analyzing it on the spot, and storing the *result* of the >> analysis in P-space? > >Very few small, fast, warriors would have time in their main program >loops to perform this analysis. This way you can wait until the start >of the next battle (when you have a little breathing space and boot >up code) to do the analysis. There is nothing to stop you then storing >the result of the analysis as a number. > I don't think there is so much time at startup; just adding a dumb p-space switcher (switching always to the same component) degrade performances of 5-10 points. >> >> > or bombing with the enemy program? >> >> What do you mean by this? > >Well, it was just an idea that sprang to mind, (so is probably not good), >but I thought that, if the enemy was beating you a lot you could copy it >to p-space (during a battle) and then at the start of the next battle >download it from p-space to use instead of one of your own components. > To copy it you have to find it, so why not to kill. And how to be sure of not copying the enemy _decoy_ to use as a component. >> >> > P-space is also very vulnerable to brainwashing (as recent programs have >> > shown)... that makes using it as a storage place for paper pretty risky. >> >> Actually, the idea I had was that the paper would be re-stored each round, >> and only half the copies would be made from P-space (the other half would >> be made normally). The idea would be to prevent a small error in one paper >> from affecting all of its descendants. > >oh I see. :) fair enough, but doing this might slow down the paper's rate >at actually overwriting core (which is it's main function) and thus >balance the advantage out a bit. I think that rather than strengthening >papers, it would simply allow more *species* of papers - surely not a bad >thing? > Too risky, IMO, should the enemy brainwash me, filling my p-space with spl 0 About the more species of papers, I cannot see how. >> >> - Michael Constant >> > >-Tim Chapman > > -Beppe Bezzi From: Tim Chapman Subject: Re: P-space Date: 1995/11/14 Message-ID: #1/1 newsgroups: rec.games.corewar On Fri, 10 Nov 1995, Michael Constant wrote: > > What about all the things that have already been mentionned, like Self > > Repairing programs and coordination of multi-processes bombs? > > An imp-spiral is the ultimate self-repair program. It is very effective > and it is the epitome of simplicity. More complicated self-repair programs > wouldn't work even with a more powerful P-space -- the problem with a self- > repair program is not that it doesn't have a clean copy of its own code, but > rather that it is too slow to be effective. Tell me about it....! :) > > Multi-process bombs can be coordinated perfectly well by storing simple > numbers in P-space. Full instructions are not required, and I can't even > see how they would help. If the bomb itself was stored in p-space, a single command program could rewrite the bomb in p-space, and all of the sub-process bomb routines would instantly change to the new bomb. This p-space method makes these sorts of ideas feasible, when they would be either too long, or too slow in normal redcode. > > > Also, how about copying the ENEMY program into your own p-space for > > analysis at the start of the next battle? > > That's a pretty cool idea, but how is it different from simply scanning for > the enemy program, analyzing it on the spot, and storing the *result* of the > analysis in P-space? Very few small, fast, warriors would have time in their main program loops to perform this analysis. This way you can wait until the start of the next battle (when you have a little breathing space and boot up code) to do the analysis. There is nothing to stop you then storing the result of the analysis as a number. > > > or bombing with the enemy program? > > What do you mean by this? Well, it was just an idea that sprang to mind, (so is probably not good), but I thought that, if the enemy was beating you a lot you could copy it to p-space (during a battle) and then at the start of the next battle download it from p-space to use instead of one of your own components. > > > P-space is also very vulnerable to brainwashing (as recent programs have > > shown)... that makes using it as a storage place for paper pretty risky. > > Actually, the idea I had was that the paper would be re-stored each round, > and only half the copies would be made from P-space (the other half would > be made normally). The idea would be to prevent a small error in one paper > from affecting all of its descendants. oh I see. :) fair enough, but doing this might slow down the paper's rate at actually overwriting core (which is it's main function) and thus balance the advantage out a bit. I think that rather than strengthening papers, it would simply allow more *species* of papers - surely not a bad thing? > > - Michael Constant > -Tim Chapman From: Tim Chapman Subject: Re: Ideas for new instructions/Defence in redcode Date: 1995/11/14 Message-ID: #1/1 newsgroups: rec.games.corewar On Fri, 10 Nov 1995, Derek Ross wrote: > > You both make good points here. I still haven't got the 1988 > standard totally figured out in the last seven years, never mind > P-space in the last seven months. I'm sure I'm not alone . > There's plenty of new ground to cover at the moment. But don't you think we should keep the range of approaches as wide as possible? > > Two other things people should bear in mind. > > Firstly every feature added makes the learning curve for novices a > little steeper. Some features more than others. (with regards to full instruction p-space) I think that making p-space hold full instructions would actually make it more uniform with core, and therefore easier for beginners. > > Secondly the nature of Core War programs is governed by their > purpose not the code they're written in. I have a feeling that if > we were using one of the standard machine codes rather than > Redcode, we would *still* be writing short, fast, specialised > programs for scanning, bombing, replication, etc. and grumbling that > there was no room for more 'intelligent' programs. If more > 'intelligent' programs are wanted then the process of winning has > to become a lot more subtle than it is just now. Round 6 of the > current tournament gives a fine example of how it could be done. I > gave another couple of suggestions the last time this question was > discussed. But if the object remains 'destroy the enemy before it > destroys you' then the best strategy will remain 'shoot first, ask > questions later' - Hey that's the way I like it!. With modifications like full instruction p-space other methods for doing this are opened up, which can only be a good thing in corewar. Two of the languages best features are its simplicty and flexiblity, and this change would hurt neither. We could at least try it out before the standard is confirmed? > > Cheers > > Derek > -Tim Chapman From: sieben@imap1.asu.edu Subject: Re: (no subject) Date: 1995/11/14 Message-ID: <48aphb$96b@news.asu.edu>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: : I figure if I'm annoying enough, then someone will take me seriously. :) : So I'll keep asking this every week or so... : Why can't Pizza and Stormking send out the current score of your warrior : against EVERY other warrior, whenever your warrior is challenged on the Hill? I requested a command to get detailed scores and I have a promise for it. Nandor. From: Planar Subject: New version of the ICWS'94 draft Date: 1995/11/14 Message-ID: <48a7bm$nnq@news-rocq.inria.fr> newsgroups: rec.games.corewar This is the draft that is available from my Web page. Do not send detailed comments yet, we need somebody to write the pspace stuff (and the multi-line EQU and FOR/ROF as well). I'll try to post a summary of past debates on read/write distance before the end of the week. ____________ cut here ________________ Annotated Draft of the Proposed 1994 Core War Standard. Version 3.3 Annotated Draft Last Modified: November 8, 1995 Last modified by: Damien Doligez Base draft by: Mark Durham [Planar's intro to ver. 3.3] This is a list of what I've changed from version 3.2: + Changed "pointer counter" to "program counter" in Mark's intro. + Changed "A-pointer" and "B-pointer" to "A-number" and "B-number" in Mark's intro + Added A-number indirect, A-number predecrement, and A-number postincrement to the description of addressing modes. Changed "indirect", "predecrement", and "postincrement" to "B-number indirect", etc. + Clarified the fact that newlines are not considered whitespace. + Added the SEQ, SNE, and NOP opcodes + Changed a reference to "load file" into "assembly file" in section 2.3 + Simplified the grammar entries for label_list and newline. + Removed the grammar entries for list, simplified those for files. + Stop parsing (not simply assembling) after the END. + Added predefined labels. + Added ";assert" comment convention. + Specified the behaviour of {DIV,MOD}.{I,F,X} when a component of the A-value is 0. + Fixed a discrepancy between the text and the sample code on the behavior of JMN and DJN, >>>BY CHANGING THE TEXT<<<. The old version would not jump (for JMN.F and DJN.F) if either field of the target was zero. + Added SEQ as a synonym to CMP (in description and code) + Added SNE (in description and code) + Added NOP (in description and code) + Specified the behavior of SLT.F + Fixed the bug with label "noqueue" in the ARITH_DIV macro. + Updated the conversion tables. + Updated the list of new opcodes and addressing modes. This is a list of things to do: + Decide on whether to remove read/write distance. + Add ROUNDS and PSPACE and LDP and STP. + Define "battle" and "rounds" in the glossary. + The assembler and run-time environment must agree on the value of predefined labels. Make this fact explicit. + Add CURLINE and VERSION. + Decide which one takes precedence if the description and code disagree and write this decision explicitely in the standard. + Add the comparison and logical operators to the description and to the grammar of expressions. + Specify the operator precedence for expressions (if only by saying it's the same as in the C language). + Add multi-line EQUs and FOR/ROF macros. [Stefan's intro to ver. 3.2] The sample simulator was rewritten extensively based on suggestions by Damien Doligez ("Planar") and on our experience implemementing the pMARS, the first ICWS'94 simulator. Thanks to Planar and also Steven Morrell for pointing out many omission and ambiguities in the previous revision. Other readers of rec.games.corewar have also provided many helpful comments. Changes incorporated since last revision: Text: - corrected various typos - clarified behaviour of JMN, JMZ and DJN with .F modifier - defined behavior for division by zero - incorporated EOF in grammar, eliminated "empty" expression - limited definition of whitespace to and - labels are case sensitive - "pointer counter" -> "program counter" - added default modifier rules (A.2.1.1-2) Sample code: - macro'ized ADD/SUB/MUL/DIV code - test for division by zero - .AB in JMZ, JMN, DJN works now like .B; .BA like .A - fixed DJN.F, JMN.F To do for next revision: - fix formal grammar (still flaky) - exclude/redefine read/write limits, add jump limit? [Mark's intro to ver. 3.1] The information presented here is not part of the Draft proper. The Draft proper immediately follows these annotations, beginning with the line "0001 Draft of Proposed 1994 Core War Standard". The content lines of the Draft proper are numbered for easy reference. The numbers may or may not be included in the final Draft. Internal annotations were removed to clean-up the draft for presentation to the ICWS for comment. These annotations which precede the draft take their place. Open-ended references were removed to clean-up the draft for presentation to the ICWS for comment. The question of the inclusion or exclusion of various opcodes, modes, etc. has not been closed as of yet. Such additions or deletions should be finalized by the next draft however. Previously speculative references were either included or removed to clean-up the draft for presentation to the ICWS for comment. See above. The Load File section was rewritten to aid in the readability of load files. It was deemed best that Load Files be a subset of Assembly Files; therefore Load Files should logically follow the Assembly File section. For that reason, the two sections have been swapped. Example MARS code is now included. Other parts of the standard, such as validation, remain incomplete. The remaining incomplete sections do not impact on the other sections of the standard and so can be completed even after consideration of the rest of the draft by the ICWS. Alternatively, they could be issued as separate documents. The MARS code is specifically designed to mirror the draft as closely as possible. There is a multitude of optimizations which could have been made but were not in order that the example code could serve as a possible clarification of obscure parts of the draft. Do not suggest changes to the example code which speed up processing at the expense of mirroring the draft. Several changes have been made with the goal of expanding the flexibility of Core War without compromising backwards compatibility and without seriously altering the nature of the game. In that vein: The modulus '%' operator was added to the Assembly File section. Read and Write limitations with folding have been clarified. These limits allow the possibility of warriors essentially running in a mini-core inside core, folding out-of-bounds access attempts back into accessible memory. The main advantages to folding are: old-style bombers like Dwarf do not unfairly and unknowingly spend cycles doing nothing, and movement to seek and destroy enemy warriors is still encouraged by the limits. The main disadvantage is that limits which are not factors of the size of core lead to unexpected results. Example: a reference to address location -1 is adjusted to M-1 when loaded into core and will not fold to R-1 and/or W-1 if R or W are not factors of M (M is size of core, R is the read limit, and W is the write limit). Of course, if R = W = M, then play is equivalent to ICWS'88 without limits. In the 5.MARS section of the draft, many of the terms such as A-operand were used both as containers ("Writes to the A-operand") and the contents of those containers ("Compare the A-operand to ..."). Such ambiguous terms and references have hopefully been eradicated. Although such eradication eliminates ambiguity, it encourages obfuscation and/or the proliferation of terms. A delicate balance has, perhaps, been struck between the two. The following are terms which are new or may be used differently than in the past. All terms are contents (not containers). opcode modifier : Removes mode-specific behaviour from opcodes by explicitly stating whether an instruction uses just one number, two numbers, or a whole instruction. A-number : Replaces A-field/A-value/A-term, etc. A general term, not tied to any specific instruction. B-number : Replaces B-field/B-value/B-term, etc. A general term, not tied to any specific instruction. current instruction : Specifically means the instruction in the instruction register. Does NOT mean the instruction in core pointed to by the program counter. (That instruction may have changed since the current instruction was copied from there). A-instruction : Specifically means the copy of the instruction in core (at the time of A-operand evaluation) pointed to by the A-number. B-instruction : Specifically means the copy of the instruction in core (at the time of B-operand evaluation) pointed to by the B-number. A-value : Now refers to the object(s) (A/B-number(s) of the A-instruction or the A-instruction) referenced by the A-operand (as selected by the opcode modifier). B-value : Now refers to the object(s) (A/B-number(s) of the B-instruction or the B-instruction) referenced by the B-operand (as selected by the opcode modifier). B-target: The object(s) (A/B-number(s) of the instruction in core [at the time of opcode execution] or the instruction) pointed to by the B-number. Six opcode modifiers have been added to the Draft. Modifiers are appended to the opcodes with a dot. Example: "MOV.A". The modifiers are: .A Instructions use and write A-numbers. .B Instructions use and write B-numbers. .AB Instructions use the A-numbers of the A-instructions and the B-numbers of the B-instructions and write B-numbers. .BA Instructions use the B-numbers of the A-instructions and the A-numbers of the B-instructions and write A-numbers. .F Instructions use both the A-numbers and the B-numbers, using and writing A-to-A, B-to-B. .X Instructions use both the A-numbers and the B-numbers, using and writing A-to-B, B-to-A. .I Instructions use and write entire instructions. See Section 5.4 for more information (especially the examples). There could be modifiers (other than .I) which take the modes into account, but their utility may not warrant their inclusion. The advantages of opcode modifiers include: greatly expanding the function of opcodes without greatly expanding the number of opcodes, separating opcode evaluation from operand evaluation (i.e. the behaviours of the opcodes no longer depend on the modes), rendering moot questions about whether ADD, SUB, etc. should use one or two fields (and if one field, whether to use the A-field or the B-field), adding versatility to the order of task splitting, and providing a "Skip if greater than" equivalent to SLT. In addition, backwards compatibility with ICWS'88 (and even ICWS'86) is easily accomplished at the assembly level. Any instructions with opcodes without modifiers would be translated to the appropriate opcode.modifier pair. Examples: "MOV #a, B", which only moves the A-field of the current instruction to the B-field of the instruction pointed to by B, would be translated to "MOV.AB #a, B". Similarly, "MOV a, b", which moves an entire instruction from A to B, becomes "MOV.I a, b". Instructions which were previously impossible, such as moving a B-field to an A-field, are now very simple and intuitive with "MOV.BA A, B". Another example, "MOV.X target, target" takes the place of "XCH target", exchanging fields. Finally, "ADD a, b" would translate to "ADD.F a, b" for ICWS'88 and "ADD.B a, b" for ICWS'86. There is one negative to one opcode modifier. ".I" only really makes sense for MOV and CMP. It would be possible to define results for arithmetic manipulation and ordinal comparison of opcodes and modes, but it would be very artificial. As an alternative, .I falls back to .F functionality (for opcodes other than MOV and CMP) in this document. Things which absolutely must be done before final consideration for adoption by the ICWS: 1. Complete incomplete sections or remove references to them 2. Add typographic distinctions to grammars To aid in completion of the draft, all suggested revisions of the draft should consist of explicit remarks such as: Delete lines xxxx to yyyy Add the following after line zzzz .... Replace lines vvvv to wwww with .... Please individually explain why each revision is necessary. The maximal verbosity of the draft is intentional. Each sentence either presents a new item, a clarification of an item, or an old item in a new context. The goal is that no two reasonable people could arrive at two different interpretations of the draft. \start numbering 0001 Draft of Proposed 1994 Core War Standard 0002 Version 3.3 0003 Draft Last Modified: November 8, 1995 0004 Last modified by: Damien Doligez 0005 Base draft by: Mark Durham 0006 i. Contents 0007 1. Introduction 0008 1. Purpose 0009 2. Overview 0010 3. Acknowledgements 0011 2. Redcode Assembly File Format 0012 1. Purpose 0013 2. Description 0014 3. Grammar 0015 4. Assembly To Object Code Conversion 0016 5. Pseudo-instructions 0017 6. Comment Conventions 0018 7. Example Assembly File 0019 3. Load File Format 0020 1. Purpose 0021 2. Description 0022 3. Grammar 0023 4. Comment Conventions 0024 5. Example Load File 0025 4. Run-time Variables 0026 1. Purpose 0027 2. Predefined Labels 0028 3. Variables 0029 4. Standard Variable Sets 0030 5. MARS 0031 1. Purpose 0032 2. Description 0033 3. Address Modes 0034 1. Immediate 0035 2. Direct 0036 3. A-number Indirect 0037 4. B-number Indirect 0038 5. A-number Predecrement Indirect 0039 6. B-number Predecrement Indirect 0040 7. A-number Postincrement Indirect 0041 8. B-number Postincrement Indirect 0042 4. Modifiers 0043 1. A 0044 2. B 0045 3. AB 0046 4. BA 0047 5. F 0048 6. X 0049 7. I 0050 5. Instruction Set 0051 1. DAT 0052 2. MOV 0053 3. ADD 0054 4. SUB 0055 5. MUL 0056 6. DIV 0057 7. MOD 0058 8. JMP 0059 9. JMZ 0060 10. JMN 0061 11. DJN 0062 12. SEQ and CMP 0063 13. SNE 0064 14. SLT 0065 15. SPL 0066 16. NOP 0067 6. Example MARS interpreter 0068 6. Validation Suite 0069 1. Purpose and Requirements 0070 2. Tests 0071 1. Assembly to Load File Test 0072 2. MARS Tests 0073 1. DAT Tests 0074 2. MOV Tests 0075 3. ADD Tests 0076 4. SUB Tests 0077 5. MUL Tests 0078 6. DIV Tests 0079 7. MOD Tests 0080 8. JMP Tests 0081 9. JMZ Tests 0082 10. JMN Tests 0083 11. DJN Tests 0084 12. SEQ/CMP Tests 0085 13. SNE Tests 0086 14. SLT Tests 0087 15. SPL Tests 0088 16. NOP Tests 0089 7. Glossary and Index 0090 A. Differences Between Standards 0091 1. Purpose 0092 2. Changes 0093 1. Assembly Files 0094 1. ICWS'88 conversion 0095 2. ICWS'86 conversion 0096 2. Load Files 0097 3. MARS 0098 1. Introduction 0099 1.1 Purpose 0100 This standard seeks to fully define and describe the game of Core War. 0101 1.2 Overview 0102 Core War is a game in which programs compete for control of a computer 0103 called MARS (for Memory Array Redcode Simulator). Redcode is the name 0104 of the assembly language in which Core War programs, called warriors, 0105 are written. 0106 In order to play Core Wars, access to a Core War system is required. 0107 A Core War system at a minimum must have a MARS executive function 0108 (interpreter) and a way to load warriors into core (the MARS memory). 0109 Most systems include a Redcode assembler, either separately or as part 0110 of the loader. Also, many systems include a graphical interface and 0111 code debugging features. Some systems have the ability to run 0112 automated tournaments. 0113 1.3 Acknowledgements 0114 This document is the fourth standard for Core War, the first three 0115 being "Core War Guidelines" (March 1984) by D. G. Jones and 0116 A. K. Dewdney, the International Core War Society standard of 1986 - 0117 "Core Wars" (May 1986), principally authored by Graeme McRae and the 0118 "Core Wars Standard of 1988" (Summer 1988), principally authored by 0119 Thomas Gettys. The latter two standards are often referred to as 0120 ICWS'86 and ICWS'88, respectively. 0121 People who contributed to this document (in alphabetical order): 0122 Scott W. Adkins 0123 Mark A. Durham 0124 Anders Ivner 0125 Morten Due Joergensen 0126 Paul Kline 0127 Scott Nelson 0128 Jon Newman 0129 John Perry 0130 Andy Pierce 0131 Planar 0132 Wayne Sheppard 0133 William Shubert 0134 Nandor Sieben 0135 Stefan Strack 0136 Mintardjo Wangsaw 0137 Kevin Whyte 0138 2. Redcode Assembly File Format 0139 2.1 Purpose 0140 A Redcode assembly file consists of the information necessary for a 0141 Redcode assembler to produce a load file. A standard assembly file 0142 format allows programmers to exchange warriors in a more meaningful 0143 format than load files. An assembly file, through the use of labels, 0144 arithmetic expressions, and macros can also greatly reduce the work 0145 necessary to produce a particular warrior while enhancing code 0146 readability. 0147 2.2 Description 0148 Each Redcode warrior consists of one or more lines of Redcode. Each 0149 line of Redcode consists of a string of alphanumerals and special 0150 characters. Special characters in Redcode are the addressing mode 0151 indicators for immediate '#', direct '$', A-number indirect '*', 0152 B-number indirect '@', A-number predecrement indirect '{', B-number 0153 predecrement indirect '<', A-number postincrement indirect '}', and 0154 B-number postincrement indirect '>' modes, the field separator 0155 (comma) ',', the comment indicator (semicolon) ';', the arithmetic 0156 operators for addition '+', subtraction '-', multiplication '*', 0157 division '/', and modulus '%', and opening '(' and closing ')' 0158 parentheses for precedence grouping. 0159 A line may be blank or consist of an instruction, a 0160 pseudo-instruction, a comment, or an instruction or 0161 pseudo-instruction followed by a comment. Each line is terminated 0162 with a newline. All comments begin with a semicolon. Each 0163 instruction consists of these elements in the following order: a 0164 label, an opcode, an A-operand, a comma, and a B-operand. Each 0165 element may be preceded and/or followed by whitespace (newline is 0166 not considered whitespace). The label is optional. If either 0167 operand is blank, the comma may be omitted. The operands may not 0168 be both blank. 0169 Pseudo-instructions appear just like instructions but are directives 0170 to the assembler and do not result in object code as an instruction 0171 would. Each pseudo-instruction has a pseudo-opcode which appears 0172 where an opcode would appear in an instruction. The format of the 0173 remainder of the pseudo-instruction depends on which pseudo-opcode is 0174 used. For the remainder of this section (2.2) and the next (2.3), 0175 references to "opcode" include "pseudo-opcode" assembler directives. 0176 A label is any alphanumeric string other than those reserved for 0177 opcodes. Labels are case sensitive, i.e. "start" is different from 0178 "Start". An opcode is any of the following: DAT, MOV, ADD, SUB, MUL, 0179 DIV, MOD, JMP, JMZ, JMN, DJN, CMP, SEQ, SNE, SLT, SPL, and NOP. 0180 Opcodes may be in upper or lower case or any combination. An opcode 0181 may be followed by a modifier. A modifier always begins with a dot. 0182 A modifier is any of the following: .A, .B, .AB, .BA, .F, .X, or .I. 0183 Modifiers may be in upper or lower case or any combination. 0184 Each operand is blank, contains an address, or contains an addressing 0185 mode indicator and an address. An address consists of any number of 0186 labels and numbers separated by arithmetic operators and possibly 0187 grouped with parentheses. All elements of an address may be separated 0188 by whitespace. 0189 2.3 Grammar 0190 Tokens are separated by whitespace (space and tab) exclusive of 0191 newline characters, which are used for line termination. End-of-file 0192 should occur only where newline could logically occur, otherwise the 0193 assembly file is invalid. 0194 In the following, 'e' is the "empty" element, meaning the token may be 0195 omitted, a caret '^' means NOT, an asterisk '*' immediately adjacent 0196 means zero or more occurrences of the previous token, and a plus '+' 0197 immediately adjacent means one or more occurrences of the previous 0198 token. The vertical bar '|' means OR. 0199 assembly_file: 0200 line+ EOF 0201 line: 0202 comment | instruction 0203 comment: 0204 ; v* newline | newline 0205 instruction: 0206 label_list operation mode expr comment | 0207 label_list operation mode expr , mode expr comment 0208 label_list: 0209 label newline* label_list | e 0210 label: 0211 alpha alphanumeral* 0212 operation: 0213 opcode | opcode.modifier 0214 opcode: 0215 DAT | MOV | ADD | SUB | MUL | DIV | MOD | 0216 JMP | JMZ | JMN | DJN | CMP | SEQ | SNE | 0217 SLT | SPL | NOP | ORG | EQU | END 0218 modifier: 0219 A | B | AB | BA | F | X | I 0220 mode: 0221 # | $ | * | @ | { | < | } | > | e 0222 expr: 0223 term | 0224 term + expr | term - expr | 0225 term * expr | term / expr | 0226 term % expr 0227 term: 0228 label | number | ( expression ) 0229 number: 0230 whole_number | signed_integer 0231 signed_integer: 0232 +whole_number | -whole_number 0233 whole_number: 0234 numeral+ 0235 alpha: 0236 A-Z | a-z | _ 0237 numeral: 0238 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 0239 alphanumeral: 0240 alpha | numeral 0241 v: 0242 ^newline 0243 newline: 0244 LF | CR | LF CR | CR LF 0245 e: 0246 2.4 Assembly To Load File Conversion 0247 A Redcode program can be assembled into a list of MARS instructions. 0248 (When assembled to a file instead of directly to core, the list is 0249 called a load file. See Section 3). Each Redcode instruction 0250 assembles into a MARS instruction of five fields: an opcode.modifier 0251 field, the A-mode field, the A-address field, the B-mode field, and 0252 the B-address field. A missing (null or blank) mode assembles as '$' 0253 does. 0254 If no modifier is present in the assembly instruction, the appropriate 0255 modifier is appended to the opcode. The appropriate modifier depends 0256 upon the opcode, the modes, and which standard (ICWS'86 or ICWS'88) to 0257 consider (ICWS'88 by default). See Appendix A for the appropriate 0258 translations. 0259 The address field values are derived from the numbers, labels, and 0260 arithmetic operators contained in the addresses. Labels are 0261 converted to an address relative to the current instruction. Then 0262 the arithmetic operations are carried out according to the 0263 appropriate operator and parenthetical precedence to determine the 0264 final value. If there is only one operand associated with a DAT 0265 instruction, this operand is assembled into the B-mode and B-address 0266 fields, while #0 is assembled into the A-mode and A-address fields. 0267 For all other instructions with only one operand, this operand is 0268 assembled into the A-mode and A-address fields and #0 is assembled 0269 into the B-mode and B-address fields. 0270 2.5 Pseudo-instructions 0271 Pseudo-opcodes are "ORG", "EQU", and "END". 0272 "ORG" ("ORiGin") is a way for the assembly file to indicate the 0273 logical origin of the warrior. The A-operand contains an offset to 0274 the logical first instruction. Thus "ORG 0" means execution should 0275 start with the first instruction (the default) whereas "ORG 6" means 0276 execution should start with the seventh instruction. Although multiple 0277 ORG instructions are of no additional benefit to the programmer, they 0278 are allowed. When there is more than one ORG instruction in a file, 0279 the last ORG instruction encountered will be the one that takes 0280 effect. 0281 "EQU" ("EQUate") is a simple text substitution utility. Instructions 0282 of the form "label EQU text" will replace all occurrences of "label" 0283 with the (probably longer and more complicated) "text" before any 0284 actual assembly takes place on the file. Some labels are predefined 0285 with the value of run-time variables as if they were defined with 0286 EQU at the start of the program (see section 4.2 for the list of 0287 predefined labels). 0288 "END" indicates the logical end of the assembly file. If END has an 0289 A-operand, then the A-operand indicates the logical origin of the 0290 warrior in the same manner as ORG does. The rest of the file (after 0291 the end of the line containing END) is ignored. 0292 2.6 Comment Conventions 0293 ";redcode" as a first line identifies the file as a Redcode 0294 assembly file. The "" is optional and implementation 0295 dependent. 0296 ";strategy " indicates a comment for "public" consumption. 0297 ";name ", ";author ", 0298 ";version ", and ";date " 0299 offer uniform ways of presenting this information. 0300 ";kill " is for removing warriors from ongoing 0301 tournaments. If no is supplied, all of the author's 0302 previous submissions will be removed. 0303 ";assert " will evaluate the expression and trigger 0304 an error if it is 0. In conjunction with predefined labels (see 0305 section 4.2), this provides a way of specifying the conditions under 0306 which a warrior is supposed to run. 0307 2.7 Example Assembly File 0308 ;redcode 0309 ;name Dwarf 0310 ;author A. K. Dewdney 0311 ;version 94.1 0312 ;date April 29, 1993 0313 ;strategy Bombs every fourth instruction. 0314 ;assert CORESIZE % 4 == 0 0315 ORG start ; Indicates the instruction with 0316 ; the label "start" should be the 0317 ; first to execute. 0318 step EQU 4 ; Replaces all occurrences of "step" 0319 ; with the character "4". 0320 target DAT.F #0, #0 ; Pointer to target instruction. 0321 start ADD.AB #step, target ; Increments pointer by step. 0322 MOV.AB #0, @target ; Bombs target instruction. 0323 JMP.A start ; Same as JMP.A -2. Loops back to 0324 ; the instruction labelled "start". 0325 END 0326 3. Load File Format 0327 3.1 Purpose 0328 A load file represents the minimum amount of information necessary for 0329 a warrior to execute properly and is presented in a very simple format 0330 which is a subset of the assembly file format presented in Section 2. 0331 A standard load file format allows programmers to choose assemblers 0332 and MARS programs separately and to verify assembler performance and 0333 MARS performance separately. Not all Core War systems will necessarily 0334 write load files (for example, those which assemble directly to core), 0335 but all systems should support reading load files. 0336 3.2 Description 0337 Each load file will consist of one or more lines of MARS 0338 instructions or comments. Each line is terminated with a newline. 0339 All comments start with with a semicolon. Each MARS instruction 0340 consists of five fields: an opcode.modifier pair, an A-mode, an 0341 A-field, a B-mode, and a B-field. The A-mode is separated from the 0342 opcode.modifier pair by whitespace and the B-mode is separated from 0343 the A-field by a comma and additional whitespace. Each MARS 0344 instruction may be followed by extraneous information, which is 0345 ignored. Note that the instruction format for load files is more 0346 rigid than for assembly files to simplify parsing. No blank modes or 0347 operands are allowed. 0348 3.3 Grammar 0349 Tokens are separated by whitespace (non-marking characters such as 0350 SPACE and TAB) exclusive of newline characters, which are used for 0351 line termination. End-of-file should occur only where newline could 0352 logically occur, otherwise the load file is invalid. 0353 load_file: 0354 line+ EOF 0355 line: 0356 comment | instruction 0357 comment: 0358 ; v* newline | newline 0359 instruction: 0360 opcode.modifier mode number , mode number comment 0361 opcode: 0362 DAT | MOV | ADD | SUB | MUL | DIV | MOD | 0363 JMP | JMZ | JMN | DJN | CMP | SEQ | SNE | 0364 SLT | SPL | NOP | ORG 0365 modifier: 0366 A | B | AB | BA | F | X | I 0367 mode: 0368 # | $ | @ | * | < | { | > | } 0369 number: 0370 whole_number | signed_integer 0371 signed_integer: 0372 +whole_number | -whole_number 0373 whole_number: 0374 numeral+ 0375 numeral: 0376 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 0377 v: 0378 ^newline 0379 newline: 0380 LF | CR | LF CR | CR LF 0381 3.4 Comment Conventions 0382 Comment conventions for load files are the same as for assembly files. 0383 Of particular note are the "; name " and "; author 0384 " comments. These comments provide a more suitable 0385 identification of programs to the MARS than "Warrior #1", "Warrior #2", 0386 etc. It also allows for less cryptic identification than by filename. 0387 3.5 Example Load File 0388 ;redcode 0389 ;name Dwarf 0390 ;author A. K. Dewdney 0391 ;version 94.1 0392 ;date April 29, 1993 0393 ;strategy Bombs every fourth instruction. 0394 ;assert CORESIZE % 4 == 0 0395 ORG 1 ; Indicates execution begins with the second 0396 ; instruction (ORG is not actually loaded, and is 0397 ; therefore not counted as an instruction). 0398 DAT.F #0, #0 ; Pointer to target instruction. 0399 ADD.AB #4, $-1 ; Increments pointer by step. 0400 MOV.AB #0, @-2 ; Bombs target instruction. 0401 JMP.A $-2, #0 ; Loops back two instructions. 0402 4. Run-time Variables 0403 4.1 Purpose 0404 This section describes those variables which are determined just prior 0405 to running a battle by the person running the battle. It also 0406 enumerates some of the standardized sets of variables used for 0407 tournaments. 0408 4.2 Predefined Labels 0409 Most of the run-time variables are available to the programmer as 0410 predefined labels. The purpose of these labels is twofold: first, 0411 to parameterize the warriors with the characteristics of their 0412 run-time environment; second, to check (with the ";assert" comment) 0413 that the warrior is run in an environment that makes sense for it. 0414 The next section gives a list of the run-time variables. When 0415 a predefined label takes the value of the variable, the label is 0416 given between parentheses after the name of the variable. 0417 4.2 Variables 0418 Run-time variables consist of the following: 0419 Core Size: (CORESIZE) 0420 Core size is the number of instructions which make up core 0421 during the battle. 0422 Cycles Before Tie: (MAXCYCLES) 0423 In each cycle, one instruction from each warrior is executed. 0424 This variable determines how many cycles without a winner 0425 should be executed before declaring a tie. 0426 Initial Instruction: 0427 The initial instruction is that instruction which is preloaded 0428 into core prior to loading warriors. In addition to loading 0429 an instruction such as "DAT #0, #0" into all of core, the 0430 initial instruction could be set to "NONE", meaning core should 0431 not be cleared between battles, or "RANDOM", meaning core 0432 instructions are filled with randomly generated instructions. 0433 Instruction Limit: (MAXLENGTH) 0434 The maximum number of instructions allowed per load file. 0435 Maximum Number of Tasks: (MAXPROCESSES) 0436 Each warrior can spawn multiple additional tasks. This 0437 variable sets the maximum number of tasks allowed per warrior. 0438 In other words, this is the size of each warrior's task queue. 0439 Minimum Separation: (MINDISTANCE) 0440 The minimum number of instructions from the first instruction 0441 of one warrior to the first instruction of the next warrior. 0442 Read Distance: 0443 This is the range available for warriors to read information 0444 from core. Attempts to read outside the limits of this range 0445 result in reading within the local readable range. The range 0446 is centered on the current instruction. Thus, a range of 0447 500 limits reading to offsets of (-249 -> +250) from the 0448 currently executing instruction. The read limit can therefore 0449 be considered a mini-core within core. An attempt to read 0450 location PC+251 reads location PC-249 instead. An attempt to 0451 read location PC+500 reads location PC instead. 0452 Read distance must be a factor of core size, otherwise the 0453 above defined behaviour is not guaranteed. 0454 Separation: 0455 The number of instructions from the first instruction of one 0456 warrior to the first instruction of the next warrior. 0457 Separation can be set to "RANDOM", meaning separations will be 0458 chosen randomly from those larger than the minimum separation. 0459 Warriors: 0460 The initial number of warriors to battle simultaneously in 0461 core. 0462 Write Distance: 0463 This is the range available for warriors to write information 0464 to core. Attempts to write outside the limits of this range 0465 result in writing within the local writable range. The range 0466 is centered on the current instruction. Thus, a range of 500 0467 limits writing to offsets of (-249 -> +250) from the 0468 currently executing instruction. The write limit can 0469 therefore be considered a mini-core within core. An attempt 0470 to write location PC+251 writes to location PC-249 instead. 0471 An attempt to write to location PC+500 writes to location PC 0472 instead. 0473 Write distance must be a factor of core size, otherwise the 0474 above defined behaviour is not guaranteed. 0475 4.3 Standard Variable Sets 0476 ICWS86: 0477 Core Size: 8192 0478 Cycles Before Tie: 100000 0479 Initial Instruction: DAT.F #0, #0 0480 Instruction Limit: 300 0481 Maximum Number of Tasks: 64 0482 Minimum Separation: 300 0483 Read Distance: 8192 0484 Separation: RANDOM 0485 Warriors: 2 0486 Write Distance: 8192 0487 KOTH: 0488 Core Size: 8000 0489 Cycles Before Tie: 80000 0490 Initial Instruction: DAT.F $0, $0 0491 Instruction Limit: 100 0492 Maximum Number of Tasks: 8000 0493 Minimum Separation: 100 0494 Read Distance: 8000 0495 Separation: RANDOM 0496 Warriors: 2 0497 Write Distance: 8000 0498 5. MARS 0499 5.1 Purpose 0500 The Memory Array Redcode Simulator (MARS) is the computer in which 0501 Core War warriors do combat. 0502 5.2 Description 0503 A minimally-complete MARS consists of a core, a loader, task queues, 0504 the MARS executive function, and a way to present the final results of 0505 a battle. Additionally, many MARS provide a "real-time" battle 0506 display and various debugging tools. 0507 The core consists of a cyclic list (0, 1, 2, ..., M-2, M-1, 0, 1, ...) 0508 of M MARS instructions. The integer M is referred to as "core size". 0509 All operations are performed modulo M. Core initialization (the 0510 initial instructions placed in core before loading warriors) is a 0511 run-time variable (see Section 4). 0512 The loader loads warriors into core, converting each negative field 0513 value N to the positive field value P such that 0 <= P < M and P = kM 0514 + N where k is a positive integer (P = N modulo M). Each field value 0515 G greater than or equal to M is converted to the field values L such 0516 that 0 <= L < M and L = kM + G where k is a negative integer (L = G 0517 modulo M). The loader also initializes each warrior's task queue with 0518 the appropriate task pointer. 0519 There is a task queue for each warrior loaded into core. Each task 0520 queue can hold a limited number of task pointers. The "task limit" 0521 (number of tasks an individual warrior's task queue can hold) is a 0522 run-time variable. The task queues are FIFOs (First In, First Out). 0523 Each warrior consists of one task initially. Subsequent tasks are 0524 added to the warrior's task queue using the SPL instruction. Attempted 0525 execution of a DAT instruction by a task effectively removes that task 0526 from the warrior's task queue. 0527 Warriors execute for a specified number of cycles ("time limit", see 0528 Section 4) or until only one warrior is still executing, whichever 0529 occurs first. Each cycle, one instruction from each warrior is 0530 executed. The instruction to execute is the instruction pointed to by 0531 the next task pointer in the warrior's task queue. A warrior is no 0532 longer executing when its task queue is empty. 0533 The following expressions are used in describing the MARS executive 0534 function's operation. 0535 General Definitions: 0536 An instruction consists of an opcode, a modifier, an A-operand, 0537 and a B-operand. 0538 An A-operand consists of an A-mode and an A-number. 0539 An A-mode is the addressing mode of an A-operand. 0540 An A-number is an integer between 0 and M-1, inclusive. 0541 A B-operand consists of a B-mode and a B-number. 0542 A B-mode is the addressing mode of a B-operand. 0543 A B-number is an integer between 0 and M-1, inclusive. 0544 Specific Definitions: 0545 The program counter (PC) is the pointer to the location in core of 0546 the instruction fetched from core to execute. 0547 The current instruction is the instruction in the instruction 0548 register, as copied (prior to execution) from the PC 0549 location of core. 0550 The A-pointer points to the instruction the A-operand of the 0551 current instruction references in core. 0552 The A-instruction is a copy of the instruction the A-pointer 0553 points to in core (as it was during operand evaluation). 0554 The A-value is the A-number and/or the B-number of the 0555 A-instruction or the A-instruction itself, whichever are/is 0556 selected by the opcode modifier. 0557 The B-pointer points to the instruction the B-operand of the 0558 current instruction references in core. 0559 The B-instruction is a copy of the instruction the B-pointer 0560 points to in core (as it was during operand evaluation). 0561 The B-value is the A-number and/or the B-number of the 0562 B-instruction or the B-instruction itself, whichever are/is 0563 selected by the opcode modifier. 0564 The B-target is the A-number and/or the B-number of the instruction 0565 pointed to by the B-pointer or the instruction itself, 0566 whichever are/is selected by the opcode modifier. 0567 All MARS instructions are executed following the same procedure: 0568 1. The currently executing warrior's current task pointer is 0569 extracted from the warrior's task queue and assigned to the 0570 program counter. 0571 2. The corresponding instruction is fetched from core and stored in 0572 the instruction register as the current instruction. 0573 3. The A-operand of the current instruction is evaluated. 0574 4. The results of A-operand evaluation, the A-pointer and the 0575 A-instruction, are stored in the appropriate registers. 0576 5. The B-operand of the current instruction is evaluated. 0577 6. The results of B-operand evaluation, the B-pointer and the 0578 B-instruction, are stored in the appropriate registers. 0579 7. Operations appropriate to the opcode.modifier pair in the 0580 instruction register are executed. With the exception of DAT 0581 instructions, all operations queue an updated task pointer. 0582 (How the task pointer is updated and when it is queued depend on 0583 instruction execution). 0584 All pointers are PC-relative, indicating the offset from the source of 0585 the current instruction to the desired location. All arithmetic is to 0586 be done modulo M, with negative values converted in the same manner as 0587 during loading as discussed above (P = M + N). Additionally, all 0588 reads of core are done modulo the read limit (R) and all writes of 0589 core are done modulo the write limit (W). Read offsets O greater than 0590 R/2 from the current instruction are converted to backwards offsets of 0591 O = O - R. A comparable conversion occurs for write offsets greater 0592 than W/2. 0593 5.3 Address Modes 0594 5.3.1 Immediate 0595 An immediate mode operand merely serves as storage for data. An 0596 immediate A/B-mode in the current instruction sets the A/B-pointer to 0597 zero. 0598 5.3.2 Direct 0599 A direct mode operand indicates the offset from the program counter. 0600 A direct A/B-mode in the current instruction means the A/B-pointer is 0601 a copy of the offset, the A/B-number of the current instruction. 0602 5.3.3 A-number Indirect 0603 An A-number indirect mode operand indicates the primary offset 0604 (relative to the program counter) to the secondary offset (relative to 0605 the location of the instruction in which the secondary offset is 0606 contained). An A-number indirect A/B-mode indicates that the 0607 A/B-pointer is the sum of the A/B-number of the current instruction 0608 (the primary offset) and the A-number of the instruction pointed to by 0609 the A/B-number of the current instruction (the secondary offset). 0610 5.3.4 B-number Indirect 0611 A B-number indirect mode operand indicates the primary offset 0612 (relative to the program counter) to the secondary offset (relative to 0613 the location of the instruction in which the secondary offset is 0614 contained). A B-number indirect A/B-mode indicates that the 0615 A/B-pointer is the sum of the A/B-number of the current instruction 0616 (the primary offset) and the B-number of the instruction pointed to by 0617 the A/B-number of the current instruction (the secondary offset). 0618 5.3.5 A-number Predecrement Indirect 0619 An A-number predecrement indirect mode operand indicates the primary 0620 offset (relative to the program counter) to the secondary offset 0621 (relative to the location of the instruction in which the secondary 0622 offset is contained) which is decremented prior to use. An A-number 0623 predecrement indirect A/B-mode indicates that the A/B-pointer is the 0624 sum of the A/B-number of the current instruction (the primary offset) 0625 and the decremented A-number of the instruction pointed to by the 0626 A/B-number of the current instruction (the secondary offset). 0627 5.3.6 B-number Predecrement Indirect 0628 A B-number predecrement indirect mode operand indicates the primary 0629 offset (relative to the program counter) to the secondary offset 0630 (relative to the location of the instruction in which the secondary 0631 offset is contained) which is decremented prior to use. A B-number 0632 predecrement indirect A/B-mode indicates that the A/B-pointer is the 0633 sum of the A/B-number of the current instruction (the primary offset) 0634 and the decremented B-number of the instruction pointed to by the 0635 A/B-number of the current instruction (the secondary offset). 0636 5.3.7 A-number Postincrement Indirect 0637 An A-number postincrement indirect mode operand indicates the primary 0638 offset (relative to the program counter) to the secondary offset 0639 (relative to the location of the instruction in which the secondary 0640 offset is contained) which is incremented after the results of the 0641 operand evaluation are stored. An A-number postincrement indirect 0642 A/B-mode indicates that the A/B-pointer is the sum of the A/B-number of 0643 the current instruction (the primary offset) and the A-number of the 0644 instruction pointed to by the A/B-number of the current instruction 0645 (the secondary offset). The A-number of the instruction pointed to by 0646 the A/B-number of the current instruction is incremented after the 0647 A/B-instruction is stored, but before the B-operand is evaluated (for 0648 A-number postincrement indirect A-mode), or the operation is executed 0649 (for A-number postincrement indirect B-mode). 0650 5.3.8 B-number Postincrement Indirect 0651 A B-number postincrement indirect mode operand indicates the primary 0652 offset (relative to the program counter) to the secondary offset 0653 (relative to the location of the instruction in which the secondary 0654 offset is contained) which is incremented after the results of the 0655 operand evaluation are stored. A B-number postincrement indirect 0656 A/B-mode indicates that the A/B-pointer is the sum of the A/B-number of 0657 the current instruction (the primary offset) and the B-number of the 0658 instruction pointed to by the A/B-number of the current instruction 0659 (the secondary offset). The B-number of the instruction pointed to by 0660 the A/B-number of the current instruction is incremented after the 0661 A/B-instruction is stored, but before the B-operand is evaluated (for 0662 B-number postincrement indirect A-mode), or the operation is executed 0663 (for B-number postincrement indirect B-mode). 0664 5.4 Modifiers 0665 5.4.1 A 0666 Instruction execution proceeds with the A-value set to the A-number of 0667 the A-instruction and the B-value set to the A-number of the 0668 B-instruction. A write to core replaces the A-number of the 0669 instruction pointed to by the B-pointer. 0670 For example, a CMP.A instruction would compare the A-number of the 0671 A-instruction with the A-number of the B-instruction. A MOV.A 0672 instruction would replace the A-number of the instruction pointed to 0673 by the B-pointer with the A-number of the A-instruction. 0674 5.4.2 B 0675 Instruction execution proceeds with the A-value set to the B-number of 0676 the A-instruction and the B-value set to the B-number of the 0677 B-instruction. A write to core replaces the B-number of the 0678 instruction pointed to by the B-pointer. 0679 For example, a CMP.B instruction would compare the B-number of the 0680 A-instruction with the B-number of the B-instruction. A MOV.B 0681 instruction would replace the B-number of the instruction pointed to 0682 by the B-pointer with the B-number of the A-instruction. 0683 5.4.3 AB 0684 Instruction execution proceeds with the A-value set to the A-number of 0685 the A-instruction and the B-value set to the B-number of the 0686 B-instruction. A write to core replaces the B-number of the 0687 instruction pointed to by the B-pointer. 0688 For example, a CMP.AB instruction would compare the A-number of the 0689 A-instruction with the B-number of the B-instruction. A MOV.AB 0690 instruction would replace the B-number of the instruction pointed to 0691 by the B-pointer with the A-number of the A-instruction. 0692 5.4.4 BA 0693 Instruction execution proceeds with the A-value set to the B-number of 0694 the A-instruction and the B-value set to the A-number of the 0695 B-instruction. A write to core replaces the A-number of the 0696 instruction pointed to by the B-pointer. 0697 For example, a CMP.BA instruction would compare the B-number of the 0698 A-instruction with the A-number of the B-instruction. A MOV.BA 0699 instruction would replace the A-number of the instruction pointed to 0700 by the B-pointer with the B-number of the A-instruction. 0701 5.4.5 F 0702 Instruction execution proceeds with the A-value set to both the 0703 A-number and B-number of the A-instruction (in that order) and the 0704 B-value set to both the A-number and B-number of the B-instruction 0705 (also in that order). A write to core replaces both the A-number and 0706 the B-number of the instruction pointed to by the B-pointer (in that 0707 order). 0708 For example, a CMP.F instruction would compare the A-number of the 0709 A-instruction to the A-number of the B-instruction and the B-number of 0710 the A-instruction to B-number of the B-instruction. A MOV.F 0711 instruction would replace the A-number of the instruction pointed to by 0712 the B-pointer with the A-number of the A-instruction and would also 0713 replace the B-number of the instruction pointed to by the B-pointer 0714 with the B-number of the A-instruction. 0715 5.4.6 X 0716 Instruction execution proceeds with the A-value set to both the 0717 A-number and B-number of the A-instruction (in that order) and the 0718 B-value set to both the B-number and A-number of the B-instruction 0719 (in that order). A write to to core replaces both the B-number and 0720 the A-number of the instruction pointed to by the B-pointer (in that 0721 order). 0722 For example, a CMP.X instruction would compare the A-number of the 0723 A-instruction to the B-number of the B-instruction and the B-number of the 0724 A-instruction to A-number of the B-instruction. A MOV.X instruction 0725 would replace the B-number of the instruction pointed to by the 0726 B-pointer with the A-number of the A-instruction and would also replace 0727 the A-number of the instruction pointed to by the B-pointer with the 0728 B-number of the A-instruction. 0729 5.4.7 I 0730 Instruction execution proceeds with the A-value set to the 0731 A-instruction and the B-value set to the B-instruction. A write to 0732 core replaces the entire instruction pointed to by the B-pointer. 0733 For example, a CMP.I instruction would compare the A-instruction to 0734 the B-instruction. A MOV.I instruction would replace the instruction 0735 pointed to by the B-pointer with the A-instruction. 0736 5.5 Instruction Set 0737 5.5.1 DAT 0738 No additional processing takes place. This effectively removes the 0739 current task from the current warrior's task queue. 0740 5.5.2 MOV 0741 Move replaces the B-target with the A-value and queues the next 0742 instruction (PC + 1). 0743 5.5.3 ADD 0744 ADD replaces the B-target with the sum of the A-value and the B-value 0745 (A-value + B-value) and queues the next instruction (PC + 1). ADD.I 0746 functions as ADD.F would. 0747 5.5.4 SUB 0748 SUB replaces the B-target with the difference of the B-value and the 0749 A-value (B-value - A-value) and queues the next instruction (PC + 1). 0750 SUB.I functions as SUB.F would. 0751 5.5.5 MUL 0752 MUL replaces the B-target with the product of the A-value and the 0753 B-value (A-value * B-value) and queues the next instruction (PC + 1). 0754 MUL.I functions as MUL.F would. 0755 5.5.6 DIV 0756 DIV replaces the B-target with the integral result of dividing the 0757 B-value by the A-value (B-value / A-value) and queues the next 0758 instruction (PC + 1). DIV.I functions as DIV.F would. If the 0759 A-value is zero, the B-value is unchanged and the current task is 0760 removed from the warrior's task queue. DIV.I, DIV.F, and DIV.X 0761 operate on pairs of operands. If either component of the A-value 0762 is zero, the corresponding component of the B-value is unchanged 0763 (the other component is divided normally), and the current task is 0764 removed from the warrior queue. 0765 5.5.7 MOD 0766 MOD replaces the B-target with the integral remainder of dividing the 0767 B-value by the A-value (B-value % A-value) and queues the next 0768 instruction (PC + 1). MOD.I functions as MOD.F would. If the 0769 A-value is zero, the B-value is unchanged and the current task is 0770 removed from the warrior's task queue. MOD.I, MOD.F, and MOD.X 0771 operate on pairs of operands. If either component of the A-value 0772 is zero, the corresponding component of the B-value is unchanged 0773 (the other component is divided normally), and the current task is 0774 removed from the warrior queue. 0775 5.5.8 JMP 0776 JMP queues the sum of the program counter and the A-pointer. 0777 5.5.9 JMZ 0778 JMZ tests the B-value to determine if it is zero. If the B-value is 0779 zero, the sum of the program counter and the A-pointer is queued. 0780 Otherwise, the next instruction is queued (PC + 1). JMZ.I functions 0781 as JMZ.F would, i.e. it jumps if both the A-number and the B-number 0782 of the B-instruction are zero. 0783 5.5.10 JMN 0784 JMN tests the B-value to determine if it is zero. If the B-value is 0785 not zero, the sum of the program counter and the A-pointer is queued. 0786 Otherwise, the next instruction is queued (PC + 1). JMN.I functions 0787 as JMN.F would, i.e. it jumps if the A-number or the B-number of the 0788 B-instruction (or both) is non-zero. This is the negation of the 0789 condition for JMZ.F. 0790 5.5.11 DJN 0791 DJN decrements the B-value and the B-target, then tests the B-value 0792 to determine if it is zero. If the decremented B-value is not zero, 0793 the sum of the program counter and the A-pointer is queued. 0794 Otherwise, the next instruction is queued (PC + 1). DJN.I functions 0795 as DJN.F would, i.e. it decrements both both A/B-numbers of the B-value 0796 and the B-target, and jumps if one (or both) of the A/B-numbers of the 0797 B-value is non-zero. 0798 5.5.12 SEQ and CMP 0799 SEQ and CMP are synonymous opcodes. SEQ is provided as an 0800 easy-to-remember mnemonic, and CMP is provided for backward 0801 compatibility. They are completely equivalent. SEQ (or CMP) compares 0802 the A-value to the B-value. If the result of the comparison is equal, 0803 the instruction after the next instruction (PC + 2) is queued (skipping 0804 the next instruction). Otherwise, the next instruction is queued 0805 (PC + 1). 0806 5.5.13 SNE 0807 SNE compares the A-value to the B-value. If the result of the 0808 comparison is not equal, the instruction after the next instruction 0809 (PC + 2) is queued (skipping the next instruction). Otherwise, the 0810 next instruction is queued (PC + 1). 0811 5.5.14 SLT 0812 SLT compares the A-value to the B-value. If the A-value is less than 0813 the B-value, the instruction after the next instruction (PC + 2) is 0814 queued (skipping the next instruction). Otherwise, the next 0815 instruction is queued (PC + 1). SLT.I functions as SLT.F would, i.e. 0816 the next instruction is skipped only if each of the A/B-numbers of the 0817 A-value is less than its B-value counterpart. 0818 5.5.15 SPL 0819 SPL queues the next instruction (PC + 1) and then queues the sum of 0820 the program counter and the A-pointer. If the queue is full, only the 0821 next instruction is queued. 0822 5.5.16 NOP 0823 NOP queues the next instruction (PC + 1). 0824 5.6 Example MARS Interpreter 0825 /************************************/ 0826 /* */ 0827 /* EMI94.c */ 0828 /* */ 0829 /* Execute MARS Instruction ala */ 0830 /* ICWS'94 Draft Standard. */ 0831 /* */ 0832 /* Last Update: November 8, 1995 */ 0833 /* */ 0834 /************************************/ 0835 /* This ANSI C function is the benchmark MARS instruction */ 0836 /* interpreter for the ICWS'94 Draft Standard. */ 0837 /* The design philosophy of this function is to mirror the */ 0838 /* standard as closely as possible, illuminate the meaning */ 0839 /* of the standard, and provide the definitive answers to */ 0840 /* questions of the "well, does the standard mean this or */ 0841 /* that?" variety. Although other, different implemen- */ 0842 /* tations are definitely possible and encouraged; those */ 0843 /* implementations should produce the same results as this */ 0844 /* one does. */ 0845 /* The function returns the state of the system. What the */ 0846 /* main program does with this information is not defined */ 0847 /* by the standard. */ 0848 enum SystemState { 0849 UNDEFINED, 0850 SUCCESS 0851 }; 0852 /* Any number of warriors may be executing in core at one */ 0853 /* time, depending on the run-time variable set and how */ 0854 /* many warriors have failed during execution. For this */ 0855 /* implementation, warriors are identified by the order in */ 0856 /* which they were loaded into core. */ 0857 typedef unsigned int Warrior; 0858 /* An Address in Core War can be any number from 0 to the */ 0859 /* size of core minus one, relative to the current */ 0860 /* instruction. In this implementation, core is an array */ 0861 /* of instructions; therefore any variable types which */ 0862 /* contain an Address can be considered to be of type */ 0863 /* unsigned int. One caveat: for the purposes of this */ 0864 /* standard, unsigned int must be considered to have no */ 0865 /* upper limit. Depending on the size of core, it may be */ 0866 /* necessary to take precautions against overflow. */ 0867 typedef unsigned int Address; 0868 /* The FIFO task queues and supporting functions are not */ 0869 /* presented. The function Queue() attempts to add a task */ 0870 /* pointer to the back of the currently executing warrior's */ 0871 /* task queue. No special actions are to be taken if */ 0872 /* Queue() is unsuccessful, which it will be if the warrior */ 0873 /* has already reached the task limit (maximum allowable */ 0874 /* number of tasks). */ 0875 extern void Queue( 0876 Warrior W, 0877 Address TaskPointer 0878 ); 0879 /* There is one support function used to limit the range of */ 0880 /* reading from Core and writing to Core relative to the */ 0881 /* current instruction. Behaviour is as expected (a small */ 0882 /* core within Core) only if the limits are factors of the */ 0883 /* size of Core. */ 0884 static Address Fold( 0885 Address pointer, /* The pointer to fold into the desired range. */ 0886 Address limit, /* The range limit. */ 0887 Address M /* The size of Core. */ 0888 ) { 0889 Address result; 0890 result = pointer % limit; 0891 if ( result > (limit/2) ) { 0892 result += M - limit; 0893 }; 0894 return(result); 0895 } 0896 /* Instructions are the principle data type. Core is an */ 0897 /* array of instructions, and there are three instruction */ 0898 /* registers used by the MARS executive. */ 0899 enum Opcode { 0900 DAT, 0901 MOV, 0902 ADD, 0903 SUB, 0904 MUL, 0905 DIV, 0906 MOD, 0907 JMP, 0908 JMZ, 0909 JMN, 0910 DJN, 0911 CMP, /* aka SEQ */ 0912 SNE, 0913 SLT, 0914 SPL, 0915 NOP, 0916 }; 0917 enum Modifier { 0918 A, 0919 B, 0920 AB, 0921 BA, 0922 F, 0923 X, 0924 I 0925 }; 0926 enum Mode { 0927 IMMEDIATE, 0928 DIRECT, 0929 A_INDIRECT, 0930 B_INDIRECT, 0931 A_DECREMENT, 0932 B_DECREMENT, 0933 A_INCREMENT, 0934 B_INCREMENT, 0935 }; 0936 typedef struct Instruction { 0937 enum Opcode Opcode; 0938 enum Modifier Modifier; 0939 enum Mode AMode; 0940 Address ANumber; 0941 enum Mode BMode; 0942 Address BNumber; 0943 } Instruction; 0944 /* The function is passed which warrior is currently */ 0945 /* executing, the address of the warrior's current task's */ 0946 /* current instruction, a pointer to the Core, the size of */ 0947 /* the Core, and the read and write limits. It returns the */ 0948 /* system's state after attempting instruction execution. */ 0949 enum SystemState EMI94( 0950 /* W indicates which warrior's code is executing. */ 0951 Warrior W, 0952 /* PC is the address of this warrior's current task's */ 0953 /* current instruction. */ 0954 Address PC, 0955 /* Core is just an array of Instructions. Core has been */ 0956 /* initialized and the warriors have been loaded before */ 0957 /* calling this function. */ 0958 Instruction Core[], 0959 /* M is the size of Core. */ 0960 Address M, 0961 /* ReadLimit is the limitation on read distances. */ 0962 Address ReadLimit, 0963 /* WriteLimit is the limitation on write distances. */ 0964 Address WriteLimit 0965 ) { 0966 /* This MARS stores the currently executing instruction in */ 0967 /* the instruction register IR. */ 0968 Instruction IR; 0969 /* This MARS stores the instruction referenced by the */ 0970 /* A-operand in the instruction register IRA. */ 0971 Instruction IRA; 0972 /* This MARS stores the instruction referenced by the */ 0973 /* B-operand in the instruction Register IRB. */ 0974 Instruction IRB; 0975 /* All four of the following pointers are PC-relative */ 0976 /* (relative to the Program Counter). Actual access of */ 0977 /* core must add-in the Program Counter (mod core size). */ 0978 /* The offset to the instruction referred to by the */ 0979 /* A-operand for reading is Read Pointer A (RPA). */ 0980 Address RPA; 0981 /* The offset to the instruction referred to by the */ 0982 /* A-operand for writing is Write Pointer A (WPA). */ 0983 Address WPA; 0984 /* The offset to the instruction referred to by the */ 0985 /* B-operand for reading is Read Pointer B (RPB). */ 0986 Address RPB; 0987 /* The offset to the instruction referred to by the */ 0988 /* A-operand for writing is Write Pointer B (WPB). */ 0989 Address WPB; 0990 /* Post-increment operands need to keep track of which */ 0991 /* instruction to increment. */ 0992 Address PIP; 0993 /* Before execution begins, the current instruction is */ 0994 /* copied into the Instruction Register. */ 0995 IR = Core[PC]; 0996 /* Next, the A-operand is completely evaluated. */ 0997 /* For instructions with an Immediate A-mode, the Pointer A */ 0998 /* points to the source of the current instruction. */ 0999 if (IR.AMode == IMMEDIATE) { 1000 RPA = WPA = 0; 1001 } else { 1002 /* For instructions with a Direct A-mode, the Pointer A */ 1003 /* points to the instruction IR.ANumber away, relative to */ 1004 /* the Program Counter. */ 1005 /* Note that implementing Core as an array necessitates */ 1006 /* doing all Address arithmetic modulus the size of Core. */ 1007 RPA = Fold(IR.ANumber, ReadLimit, M); 1008 WPA = Fold(IR.ANumber, WriteLimit, M); 1009 /* For instructions with A-indirection in the A-operand */ 1010 /* (A-number Indirect, A-number Predecrement, */ 1011 /* and A-number Postincrement A-modes): */ 1012 if (IR.AMode == A_INDIRECT 1013 || IR.AMode == A_DECREMENT 1014 || IR.AMode == A_INCREMENT) { 1015 /* For instructions with Predecrement A-mode, the A-Field */ 1016 /* of the instruction in Core currently pointed to by the */ 1017 /* Pointer A is decremented (M - 1 is added). */ 1018 if (IR.AMode == A_DECREMENT) { 1019 Core[((PC + WPA) % M)].ANumber = 1020 (Core[((PC + WPA) % M)].ANumber + M - 1) % M; 1021 }; 1022 /* For instructions with Postincrement A-mode, the A-Field */ 1023 /* of the instruction in Core currently pointed to by the */ 1024 /* Pointer A will be incremented. */ 1025 if (IR.AMode == A_INCREMENT) { 1026 PIP = (PC + WPA) % M; 1027 }; 1028 /* For instructions with A-indirection in the A-operand, */ 1029 /* Pointer A ultimately points to the instruction */ 1030 /* Core[((PC + PCA) % M)].ANumber away, relative to the */ 1031 /* instruction pointed to by Pointer A. */ 1032 RPA = Fold( 1033 (RPA + Core[((PC + RPA) % M)].ANumber), ReadLimit, M 1034 ); 1035 WPA = Fold( 1036 (WPA + Core[((PC + WPA) % M)].ANumber), WriteLimit, M 1037 ); 1038 }; 1039 /* For instructions with B-indirection in the A-operand */ 1040 /* (B-number Indirect, B-number Predecrement, */ 1041 /* and B-number Postincrement A-modes): */ 1042 if (IR.AMode == B_INDIRECT 1043 || IR.AMode == B_DECREMENT 1044 || IR.AMode == B_INCREMENT) { 1045 /* For instructions with Predecrement A-mode, the B-Field */ 1046 /* of the instruction in Core currently pointed to by the */ 1047 /* Pointer A is decremented (M - 1 is added). */ 1048 if (IR.AMode == DECREMENT) { 1049 Core[((PC + WPA) % M)].BNumber = 1050 (Core[((PC + WPA) % M)].BNumber + M - 1) % M; 1051 }; 1052 /* For instructions with Postincrement A-mode, the B-Field */ 1053 /* of the instruction in Core currently pointed to by the */ 1054 /* Pointer A will be incremented. */ 1055 if (IR.AMode == INCREMENT) { 1056 PIP = (PC + WPA) % M; 1057 }; 1058 /* For instructions with B-indirection in the A-operand, */ 1059 /* Pointer A ultimately points to the instruction */ 1060 /* Core[((PC + PCA) % M)].BNumber away, relative to the */ 1061 /* instruction pointed to by Pointer A. */ 1062 RPA = Fold( 1063 (RPA + Core[((PC + RPA) % M)].BNumber), ReadLimit, M 1064 ); 1065 WPA = Fold( 1066 (WPA + Core[((PC + WPA) % M)].BNumber), WriteLimit, M 1067 ); 1068 }; 1069 }; 1070 /* The Instruction Register A is a copy of the instruction */ 1071 /* pointed to by Pointer A. */ 1072 IRA = Core[((PC + RPA) % M)]; 1073 /* If the A-mode was post-increment, now is the time to */ 1074 /* increment the instruction in core. */ 1075 if (IR.AMode == A_INCREMENT) { 1076 Core[PIP].ANumber = (Core[PIP].ANumber + 1) % M; 1077 } 1078 else if (IR.AMode == B_INCREMENT) { 1079 Core[PIP].BNumber = (Core[PIP].BNumber + 1) % M; 1080 }; 1081 /* The Pointer B and the Instruction Register B are */ 1082 /* evaluated in the same manner as their A counterparts. */ 1083 if (IR.BMode == IMMEDIATE) { 1084 RPB = WPB = 0; 1085 } else { 1086 RPB = Fold(IR.BNumber, ReadLimit, M); 1087 WPB = Fold(IR.BNumber, WriteLimit, M); 1088 if (IR.BMode == A_INDIRECT 1089 || IR.BMode == A_DECREMENT 1090 || IR.BMode == A_INCREMENT) { 1091 if (IR.BMode == A_DECREMENT) { 1092 Core[((PC + WPB) % M)].ANumber = 1093 (Core[((PC + WPB) % M)].ANumber + M - 1) % M 1094 ; 1095 } else if (IR.BMode == A_INCREMENT) { 1096 PIP = (PC + WPB) % M; 1097 }; 1098 RPB = Fold( 1099 (RPB + Core[((PC + RPB) % M)].ANumber), ReadLimit, M 1100 ); 1101 WPB = Fold( 1102 (WPB + Core[((PC + WPB) % M)].ANumber), WriteLimit, M 1103 ); 1104 }; 1105 if (IR.BMode == B_INDIRECT 1106 || IR.BMode == B_DECREMENT 1107 || IR.BMode == B_INCREMENT) { 1108 if (IR.BMode == B_DECREMENT) { 1109 Core[((PC + WPB) % M)].BNumber = 1110 (Core[((PC + WPB) % M)].BNumber + M - 1) % M 1111 ; 1112 } else if (IR.BMode == B_INCREMENT) { 1113 PIP = (PC + WPB) % M; 1114 }; 1115 RPB = Fold( 1116 (RPB + Core[((PC + RPB) % M)].BNumber), ReadLimit, M 1117 ); 1118 WPB = Fold( 1119 (WPB + Core[((PC + WPB) % M)].BNumber), WriteLimit, M 1120 ); 1121 }; 1122 }; 1123 IRB = Core[((PC + RPB) % M)]; 1124 if (IR.BMode == A_INCREMENT) { 1125 Core[PIP].ANumber = (Core[PIP].ANumber + 1) % M; 1126 } 1127 else if (IR.BMode == INCREMENT) { 1128 Core[PIP].BNumber = (Core[PIP].BNumber + 1) % M; 1129 }; 1130 /* Execution of the instruction can now proceed. */ 1131 switch (IR.Opcode) { 1132 /* Instructions with a DAT opcode have no further function. */ 1133 /* The current task's Program Counter is not updated and is */ 1134 /* not returned to the task queue, effectively removing the */ 1135 /* task. */ 1136 case DAT: noqueue: 1137 break; 1138 /* MOV replaces the B-target with the A-value and queues */ 1139 /* the next instruction. */ 1140 case MOV: 1141 switch (IR.Modifier) { 1142 /* Replaces A-number with A-number. */ 1143 case A: 1144 Core[((PC + WPB) % M)].ANumber = IRA.ANumber; 1145 break; 1146 /* Replaces B-number with B-number. */ 1147 case B: 1148 Core[((PC + WPB) % M)].BNumber = IRA.BNumber; 1149 break; 1150 /* Replaces B-number with A-number. */ 1151 case AB: 1152 Core[((PC + WPB) % M)].BNumber = IRA.ANumber; 1153 break; 1154 /* Replaces A-number with B-number. */ 1155 case BA: 1156 Core[((PC + WPB) % M)].ANumber = IRA.BNumber; 1157 break; 1158 /* Replaces A-number with A-number and B-number with */ 1159 /* B-number. */ 1160 case F: 1161 Core[((PC + WPB) % M)].ANumber = IRA.ANumber; 1162 Core[((PC + WPB) % M)].BNumber = IRA.BNumber; 1163 break; 1164 /* Replaces B-number with A-number and A-number with */ 1165 /* B-number. */ 1166 case X: 1167 Core[((PC + WPB) % M)].BNumber = IRA.ANumber; 1168 Core[((PC + WPB) % M)].ANumber = IRA.BNumber; 1169 break; 1170 /* Copies entire instruction. */ 1171 case I: 1172 Core[((PC + WPB) % M)] = IRA; 1173 break; 1174 default: 1175 return(UNDEFINED); 1176 break; 1177 }; 1178 /* Queue up next instruction. */ 1179 Queue(W, ((PC + 1) % M)); 1180 break; 1181 /* Arithmetic instructions replace the B-target with the */ 1182 /* "op" of the A-value and B-value, and queue the next */ 1183 /* instruction. "op" can be the sum, the difference, or */ 1184 /* the product. */ 1185 #define ARITH(op) \ 1186 switch (IR.Modifier) { \ 1187 case A: \ 1188 Core[((PC + WPB) % M)].ANumber = \ 1189 (IRB.ANumber op IRA.ANumber) % M \ 1190 ; \ 1191 break; \ 1192 case B: \ 1193 Core[((PC + WPB) % M)].BNumber = \ 1194 (IRB.BNumber op IRA.BNumber) % M \ 1195 ; \ 1196 break; \ 1197 case AB: \ 1198 Core[((PC + WPB) % M)].BNumber = \ 1199 (IRB.ANumber op IRA.BNumber) % M \ 1200 ; \ 1201 break; \ 1202 case BA: \ 1203 Core[((PC + WPB) % M)].ANumber = \ 1204 (IRB.BNumber op IRA.ANumber) % M \ 1205 ; \ 1206 break; \ 1207 case F: \ 1208 case I: \ 1209 Core[((PC + WPB) % M)].ANumber = \ 1210 (IRB.ANumber op IRA.ANumber) % M \ 1211 ; \ 1212 Core[((PC + WPB) % M)].BNumber = \ 1213 (IRB.BNumber op IRA.BNumber) % M \ 1214 ; \ 1215 break; \ 1216 case X: \ 1217 Core[((PC + WPB) % M)].BNumber = \ 1218 (IRB.ANumber op IRA.BNumber) % M \ 1219 ; \ 1220 Core[((PC + WPB) % M)].ANumber = \ 1221 (IRB.BNumber op IRA.ANumber) % M \ 1222 ; \ 1223 break; \ 1224 default: \ 1225 return(UNDEFINED); \ 1226 break; \ 1227 }; \ 1228 Queue(W, ((PC + 1) % M)); \ 1229 break; 1230 case ADD: ARITH(+) 1231 case SUB: ARITH(+ M -) 1232 case MUL: ARITH(*) 1233 /* DIV and MOD replace the B-target with the integral */ 1234 /* quotient (for DIV) or remainder (for MOD) of the B-value */ 1235 /* by the A-value, and queues the next instruction. */ 1236 /* Process is removed from task queue if A-value is zero. */ 1237 #define ARITH_DIV(op) \ 1238 switch (IR.Modifier) { \ 1239 case A: \ 1240 if (IRA.ANumber != 0) \ 1241 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.ANumber; \ 1242 break; \ 1243 case B: \ 1244 if (IRA.BNumber != 0) \ 1245 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.BNumber; \ 1246 else goto noqueue; \ 1247 break; \ 1248 case AB: \ 1249 if (IRA.ANumber != 0) \ 1250 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.ANumber; \ 1251 else goto noqueue; \ 1252 break; \ 1253 case BA: \ 1254 if (IRA.BNumber != 0) \ 1255 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.BNumber; \ 1256 else goto noqueue; \ 1257 break; \ 1258 case F: \ 1259 case I: \ 1260 if (IRA.ANumber != 0) \ 1261 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.ANumber; \ 1262 if (IRA.BNumber != 0) \ 1263 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.BNumber; \ 1264 if ((IRA.ANumber == 0) || (IRA.BNumber == 0)) \ 1265 goto noqueue; \ 1266 break; \ 1267 case X: \ 1268 if (IRA.ANumber != 0) \ 1269 Core[((PC + WPB) % M)].BNumber = IRB.BNumber op IRA.ANumber; \ 1270 if (IRA.BNumber != 0) \ 1271 Core[((PC + WPB) % M)].ANumber = IRB.ANumber op IRA.BNumber; \ 1272 if ((IRA.ANumber == 0) || (IRA.BNumber == 0)) \ 1273 goto noqueue; \ 1274 break; \ 1275 default: \ 1276 return(UNDEFINED); \ 1277 break; \ 1278 }; \ 1279 Queue(W, ((PC + 1) % M)); \ 1280 break; 1281 case DIV: ARITH_DIV(/) 1282 case MOD: ARITH_DIV(%) 1283 /* JMP queues the sum of the Program Counter and the */ 1284 /* A-pointer. */ 1285 case JMP: 1286 Queue(W, RPA); 1287 break; 1288 /* JMZ queues the sum of the Program Counter and Pointer A */ 1289 /* if the B-value is zero. Otherwise, it queues the next */ 1290 /* instruction. */ 1291 case JMZ: 1292 switch (IR.Modifier) { 1293 case A: 1294 case BA: 1295 if (IRB.ANumber == 0) { 1296 Queue(W, RPA); 1297 } else { 1298 Queue(W, ((PC + 1) % M)); 1299 }; 1300 break; 1301 case B: 1302 case AB: 1303 if (IRB.BNumber == 0) { 1304 Queue(W, RPA); 1305 } else { 1306 Queue(W, ((PC + 1) % M)); 1307 }; 1308 break; 1309 case F: 1310 case X: 1311 case I: 1312 if ( (IRB.ANumber == 0) && (IRB.BNumber == 0) ) { 1313 Queue(W, RPA); 1314 } else { 1315 Queue(W, ((PC + 1) % M)); 1316 }; 1317 break; 1318 default: 1319 return(UNDEFINED); 1320 break; 1321 }; 1322 break; 1323 /* JMN queues the sum of the Program Counter and Pointer A */ 1324 /* if the B-value is not zero. Otherwise, it queues the */ 1325 /* next instruction. */ 1326 case JMN: 1327 switch (IR.Modifier) { 1328 case A: 1329 case BA: 1330 if (IRB.ANumber != 0) { 1331 Queue(W, RPA); 1332 } else { 1333 Queue(W, ((PC + 1) % M)); 1334 }; 1335 break; 1336 case B: 1337 case AB: 1338 if (IRB.BNumber != 0) { 1339 Queue(W, RPA); 1340 } else { 1341 Queue(W, ((PC + 1) % M)); 1342 }; 1343 break; 1344 case F: 1345 case X: 1346 case I: 1347 if ( (IRB.ANumber != 0) || (IRB.BNumber != 0) ) { 1348 Queue(W, RPA); 1349 } else { 1350 Queue(W, ((PC + 1) % M)); 1351 }; 1352 break; 1353 default: 1354 return(UNDEFINED); 1355 break; 1356 }; 1357 break; 1358 /* DJN (Decrement Jump if Not zero) decrements the B-value */ 1359 /* and the B-target, then tests if the B-value is zero. If */ 1360 /* the result is not zero, the sum of the Program Counter */ 1361 /* and Pointer A is queued. Otherwise, the next */ 1362 /* instruction is queued. */ 1363 case DJN: 1364 switch (IR.Modifier) { 1365 case A: 1366 case BA: 1367 Core[((PC + WPB) % M)].ANumber = 1368 (Core[((PC + WPB) % M)].ANumber + M - 1) % M 1369 ; 1370 IRB.ANumber -= 1; 1371 if (IRB.ANumber != 0) { 1372 Queue(W, RPA); 1373 } else { 1374 Queue(W, ((PC + 1) % M)); 1375 }; 1376 break; 1377 case B: 1378 case AB: 1379 Core[((PC + WPB) % M)].BNumber = 1380 (Core[((PC + WPB) % M)].BNumber + M - 1) % M 1381 ; 1382 IRB.BNumber -= 1; 1383 if (IRB.BNumber != 0) { 1384 Queue(W, RPA); 1385 } else { 1386 Queue(W, ((PC + 1) % M)); 1387 }; 1388 break; 1389 case F: 1390 case X: 1391 case I: 1392 Core[((PC + WPB) % M)].ANumber = 1393 (Core[((PC + WPB) % M)].ANumber + M - 1) % M 1394 ; 1395 IRB.ANumber -= 1; 1396 Core[((PC + WPB) % M)].BNumber = 1397 (Core[((PC + WPB) % M)].BNumber + M - 1) % M 1398 ; 1399 IRB.BNumber -= 1; 1400 if ( (IRB.ANumber != 0) || (IRB.BNumber != 0) ) { 1401 Queue(W, RPA); 1402 } else { 1403 Queue(W, ((PC + 1) % M)); 1404 }; 1405 break; 1406 default: 1407 return(UNDEFINED); 1408 break; 1409 }; 1410 break; 1411 /* SEQ/CMP compares the A-value and the B-value. If there */ 1412 /* are no differences, then the instruction after the next */ 1413 /* instruction is queued. Otherwise, the next instrution */ 1414 /* is queued. */ 1415 case CMP: 1416 switch (IR.Modifier) { 1417 case A: 1418 if (IRA.ANumber == IRB.ANumber) { 1419 Queue(W, ((PC + 2) % M)); 1420 } else { 1421 Queue(W, ((PC + 1) % M)); 1422 }; 1423 break; 1424 case B: 1425 if (IRA.BNumber == IRB.BNumber) { 1426 Queue(W, ((PC + 2) % M)); 1427 } else { 1428 Queue(W, ((PC + 1) % M)); 1429 }; 1430 break; 1431 case AB: 1432 if (IRA.ANumber == IRB.BNumber) { 1433 Queue(W, ((PC + 2) % M)); 1434 } else { 1435 Queue(W, ((PC + 1) % M)); 1436 }; 1437 break; 1438 case BA: 1439 if (IRA.BNumber == IRB.ANumber) { 1440 Queue(W, ((PC + 2) % M)); 1441 } else { 1442 Queue(W, ((PC + 1) % M)); 1443 }; 1444 break; 1445 case F: 1446 if ( (IRA.ANumber == IRB.ANumber) && 1447 (IRA.BNumber == IRB.BNumber) 1448 ) { 1449 Queue(W, ((PC + 2) % M)); 1450 } else { 1451 Queue(W, ((PC + 1) % M)); 1452 }; 1453 break; 1454 case X: 1455 if ( (IRA.ANumber == IRB.BNumber) && 1456 (IRA.BNumber == IRB.ANumber) 1457 ) { 1458 Queue(W, ((PC + 2) % M)); 1459 } else { 1460 Queue(W, ((PC + 1) % M)); 1461 }; 1462 break; 1463 case I: 1464 if ( (IRA.Opcode == IRB.Opcode) && 1465 (IRA.Modifier == IRB.Modifier) && 1466 (IRA.AMode == IRB.AMode) && 1467 (IRA.ANumber == IRB.ANumber) && 1468 (IRA.BMode == IRB.BMode) && 1469 (IRA.BNumber == IRB.BNumber) 1470 ) { 1471 Queue(W, ((PC + 2) % M)); 1472 } else { 1473 Queue(W, ((PC + 1) % M)); 1474 }; 1475 break; 1476 default: 1477 return(UNDEFINED); 1478 break; 1479 }; 1480 break; 1481 /* SNE compares the A-value and the B-value. If there */ 1482 /* is a difference, then the instruction after the next */ 1483 /* instruction is queued. Otherwise, the next instrution */ 1484 /* is queued. */ 1485 case SNE: 1486 switch (IR.Modifier) { 1487 case A: 1488 if (IRA.ANumber != IRB.ANumber) { 1489 Queue(W, ((PC + 2) % M)); 1490 } else { 1491 Queue(W, ((PC + 1) % M)); 1492 }; 1493 break; 1494 case B: 1495 if (IRA.BNumber != IRB.BNumber) { 1496 Queue(W, ((PC + 2) % M)); 1497 } else { 1498 Queue(W, ((PC + 1) % M)); 1499 }; 1500 break; 1501 case AB: 1502 if (IRA.ANumber != IRB.BNumber) { 1503 Queue(W, ((PC + 2) % M)); 1504 } else { 1505 Queue(W, ((PC + 1) % M)); 1506 }; 1507 break; 1508 case BA: 1509 if (IRA.BNumber != IRB.ANumber) { 1510 Queue(W, ((PC + 2) % M)); 1511 } else { 1512 Queue(W, ((PC + 1) % M)); 1513 }; 1514 break; 1515 case F: 1516 if ( (IRA.ANumber != IRB.ANumber) || 1517 (IRA.BNumber != IRB.BNumber) 1518 ) { 1519 Queue(W, ((PC + 2) % M)); 1520 } else { 1521 Queue(W, ((PC + 1) % M)); 1522 }; 1523 break; 1524 case X: 1525 if ( (IRA.ANumber != IRB.BNumber) || 1526 (IRA.BNumber != IRB.ANumber) 1527 ) { 1528 Queue(W, ((PC + 2) % M)); 1529 } else { 1530 Queue(W, ((PC + 1) % M)); 1531 }; 1532 break; 1533 case I: 1534 if ( (IRA.Opcode != IRB.Opcode) || 1535 (IRA.Modifier != IRB.Modifier) || 1536 (IRA.AMode != IRB.AMode) || 1537 (IRA.ANumber != IRB.ANumber) || 1538 (IRA.BMode != IRB.BMode) || 1539 (IRA.BNumber != IRB.BNumber) 1540 ) { 1541 Queue(W, ((PC + 2) % M)); 1542 } else { 1543 Queue(W, ((PC + 1) % M)); 1544 }; 1545 break; 1546 default: 1547 return(UNDEFINED); 1548 break; 1549 }; 1550 break; 1551 /* SLT (Skip if Less Than) queues the instruction after the */ 1552 /* next instruction if A-value is less than B-value. */ 1553 /* Otherwise, the next instruction is queued. Note that no */ 1554 /* value is less than zero because only positive values can */ 1555 /* be represented in core. */ 1556 case SLT : 1557 switch (IR.Modifier) { 1558 case A: 1559 if (IRA.ANumber < IRB.ANumber) { 1560 Queue(W, ((PC + 2) % M)); 1561 } else { 1562 Queue(W, ((PC + 1) % M)); 1563 }; 1564 break; 1565 case B: 1566 if (IRA.BNumber < IRB.BNumber) { 1567 Queue(W, ((PC + 2) % M)); 1568 } else { 1569 Queue(W, ((PC + 1) % M)); 1570 }; 1571 break; 1572 case AB: 1573 if (IRA.ANumber < IRB.BNumber) { 1574 Queue(W, ((PC + 2) % M)); 1575 } else { 1576 Queue(W, ((PC + 1) % M)); 1577 }; 1578 break; 1579 case BA: 1580 if (IRA.BNumber < IRB.ANumber) { 1581 Queue(W, ((PC + 2) % M)); 1582 } else { 1583 Queue(W, ((PC + 1) % M)); 1584 }; 1585 break; 1586 case F: 1587 case I: 1588 if ( (IRA.ANumber < IRB.ANumber) && 1589 (IRA.BNumber < IRB.BNumber) 1590 ) { 1591 Queue(W, ((PC + 2) % M)); 1592 } else { 1593 Queue(W, ((PC + 1) % M)); 1594 }; 1595 break; 1596 case X: 1597 if ( (IRA.ANumber < IRB.BNumber) && 1598 (IRA.BNumber < IRB.ANumber) 1599 ) { 1600 Queue(W, ((PC + 2) % M)); 1601 } else { 1602 Queue(W, ((PC + 1) % M)); 1603 }; 1604 break; 1605 default: 1606 return(UNDEFINED); 1607 break; 1608 }; 1609 break; 1610 /* SPL queues the next instruction and also queues the sum */ 1611 /* of the Program Counter and Pointer A. */ 1612 case SPL: 1613 Queue(W, ((PC + 1) % M)); 1614 Queue(W, RPA); 1615 break; 1616 /* NOP queues the next instruction. */ 1617 case NOP: 1618 Queue(W, ((PC + 1) % M)); 1619 break; 1620 /* Any other opcode is undefined. */ 1621 default: 1622 return(UNDEFINED); 1623 }; 1624 /* We are finished. */ 1625 return(SUCCESS); 1626 } 1627 6. Validation Suite 1628 6.1 Purpose and Requirements 1629 This validation suite exists to help developers test the compatibility 1630 of their Core War systems with the requirements set up in this 1631 standard. 1632 6.2 Assembly To Load File Test 1633 6.3 MARS tests 1634 6.3.1 DAT Tests 1635 6.3.2 MOV Tests 1636 6.3.3 ADD Tests 1637 6.3.4 SUB Tests 1638 6.3.5 MUL Tests 1639 6.3.6 DIV Tests 1640 6.3.7 MOD Tests 1641 6.3.8 JMP Tests 1642 6.3.9 JMZ Tests 1643 6.3.10 JMN Tests 1644 6.3.11 DJN Tests 1645 6.3.12 SEQ/CMP Tests 1646 6.3.13 SNE Tests 1647 6.3.14 SLT Tests 1648 6.3.15 SPL Tests 1649 6.3.16 NOP Tests 1650 7. Glossary and Index 1651 alphanumeric Any of the characters A-Za-z0-9 and the underscore. 1652 assembly file A file containing Redcode instructions. 1653 battle A contest between two or more warriors. 1654 core size See section 4.2 1655 Core War A game in which programs compete for control of a 1656 computer called a Memory Array Redcode Simulator. 1657 Core Wars More than one game of Core War. 1658 cycle See section 4.2 1659 Dwarf See sections 2.7 and 3.6 1660 initial instruction 1661 See section 4.2 1662 instruction A line of Redcode or object code indicating an action 1663 for MARS to execute. 1664 instruction limit 1665 See section 4.2 1666 loader A program or that part of a program which loads 1667 warriors into a MARS. 1668 load file A file containing a warrior's instructions in an 1669 assembled format. Any MARS program can be used with 1670 any and all Redcode assemblers which produce load 1671 files, allowing customized Core War systems. 1672 MARS An acronym for Memory Array Redcode Simulator. The 1673 computer in which Core War warriors run. 1674 newline A linefeed, carriage-return, or combination of linefeed 1675 and carriage-return. Whichever newline is native to 1676 the host operating system. 1677 object code The internal representation of a MARS instruction. 1678 read distance See section 4.2 1679 Redcode The assembly language of Core War. 1680 tournament A series of battles in which points, based upon the 1681 degree of success, are awarded for each battle and 1682 accumulated by each warrior (or programmer, depending 1683 upon the type of tournament). 1684 warrior A Redcode program. 1685 whitespace The space and tab characters. 1686 write distance See section 4.2 1687 A. Differences Between Standards 1688 A.1 Purpose 1689 This appendix lists some of the major differences between this standard 1690 and those standards which preceded it. The purpose is to help those 1691 who are familiar with a previous standard or standards to quickly 1692 understand those items which are new or have changed. 1693 A.2 Changes 1694 A.2.1 Assembly Files 1695 A comma is required for operand separation. 1696 Parenthetical expressions are allowed. 1697 There is a new pseudo-opcode, ORG, for specifying the first logical 1698 instruction. 1699 There is a new operator, modulus '%', for determining the remainder 1700 of integer division. 1701 A.2.1.1 ICWS'86 to ICWS'94 Conversion 1702 If a modifier is missing, it is assembled according to conversion 1703 rules that depend on whether the ICWS'86 or '88 standard is emulated. 1704 By default, a MARS should use the ICWS'88 conversion rules. Emulation 1705 of ICWS'86 is optional. 1706 Opcode A-mode B-mode modifier 1707 --------------------------------------------------------- 1708 DAT #$@<>*{} #$@<>*{} F 1709 MOV,CMP,SEQ,SNE # #$@<>*{} AB 1710 $@<>*{} # B 1711 $@<>*{} $@<>*{} I 1712 ADD,SUB,MUL,DIV,MOD # #$@<>*{} AB 1713 $@<>*{} #$@<>*{} B 1714 SLT # #$@<>*{} AB 1715 $@<>*{} #$@<>*{} B 1716 JMP,JMZ,JMN,DJN,SPL,NOP #$@<>*{} #$@<>*{} B 1717 --------------------------------------------------------- 1718 A.2.1.2 ICWS'88 to ICWS'94 Conversion 1719 The default modifier for ICWS'88 emulation is determined according 1720 to the table below. 1721 Opcode A-mode B-mode modifier 1722 --------------------------------------------------------- 1723 DAT #$@<>*{} #$@<>*{} F 1724 MOV,CMP,SEQ,SNE # #$@<>*{} AB 1725 $@<>*{} # B 1726 $@<>*{} $@<>*{} I 1727 ADD,SUB,MUL,DIV,MOD # #$@<>*{} AB 1728 $@<>*{} # B 1729 $@<>*{} $@<>*{} F 1730 SLT # #$@<>*{} AB 1731 $@<>*{} #$@<>*{} B 1732 JMP,JMZ,JMN,DJN,SPL,NOP #$@<>*{} #$@<>*{} B 1733 --------------------------------------------------------- 1734 A.2.2 Load Files 1735 A load file format is specified for the first time. (An object code 1736 did exist for ICWS'86). 1737 A.2.3 MARS 1738 There are no illegal instructions. 1739 The following addressing modes have been added: 1740 A-number indirect, A-number predecrement, A-number postincrement, 1741 and B-number postincrement. 1742 MUL, DIV, MOD, SNE, and NOP have been added. 1743 SEQ is an alias for CMP. 1744 Opcode modifiers have been added. 1745 Read and Write distance limitations have been imposed. From: Tom Demuyt Subject: Re: Richard's C++Robots Server -- Monthly Post Date: 1995/11/14 Message-ID: <489klp$epr@infoserv.rug.ac.be>#1/1 references: <47miep$6gu@ukelele.qnet.com> newsgroups: rec.games.programmer,comp.lang.c,comp.lang.c++,rec.games.corewar,comp.ai.games,comp.programming.contests How do I get my input ? From: sieben@IMAP1.ASU.EDU Subject: NSFCWT round 6 Date: 1995/11/15 Message-ID: #1/1 newsgroups: rec.games.corewar : So, are we allowed to "peep"? No. : And how about putting code/data after the bookkeeping section? I have : a sincerely sneaky reason for trying this :-) Not again. You are allowed to put code only in the middle of the skeleton. Nandor. From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: (no subject) Date: 1995/11/15 Message-ID: <1995Nov15.072135.3054@rhodes>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: [Prior quotes deleted] : Oh? That'll work... Cool. : But wouldn't setting up a full-scores message on the event of a new challenge : be simpler from Pizza's point of view? I don't know whether it would or not, but I hope that isn't implemented. I like seeing only how I did against the latest challenger. I do want a way to get all results, but that should be on the home page or a mail message like ;battles to return the results of all battles on the current hill. : But, what about switching the Hills? Is there anywhere near the ammount : of activity on Stormking as on Pizza? I would like to see the hills switch up too. I think the beginner's and standard have the most traffic. Speaking of the hills, has anyone else tried submitting to the -94x hill? I always get back messages showing my -94x warriors battling on the -94 standard hill. And there are no warriors on the -94x hill... : -- : / John K. Wilkinson - jwilkinson@mail.utexas.edu \ Randy From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Ideas for new instructions Date: 1995/11/15 Message-ID: <1995Nov15.073012.3055@rhodes>#1/1 references: <303@arbroath.win-uk.net> newsgroups: rec.games.corewar Derek Ross (rossd@arbroath.win-uk.net) wrote: : Secondly the nature of Core War programs is governed by their : purpose not the code they're written in. I have a feeling that if : we were using one of the standard machine codes rather than : Redcode, we would *still* be writing short, fast, specialised : programs for scanning, bombing, replication, etc. and grumbling that : there was no room for more 'intelligent' programs. If more : 'intelligent' programs are wanted then the process of winning has : to become a lot more subtle than it is just now. Round 6 of the : current tournament gives a fine example of how it could be done. I : gave another couple of suggestions the last time this question was : discussed. But if the object remains 'destroy the enemy before it : destroys you' then the best strategy will remain 'shoot first, ask : questions later' - Hey that's the way I like it!. I've said this same thing before. I think to make "intelligent" warriors, we have to redefine the objective of the game. The sorting round was an example of this, the random core round was, and the current round is too. Also, using read/write limits would, I believe, encourage this (although it would take some testing before we could tell). I think "challenges" are the only way we will have opportunity to write redcode programs that do something other than try to wipe out the enemy as quickly as possible. : Cheers : Derek Randy From: Boom Subject: VSYSOP Date: 1995/11/15 Message-ID: <30AA52A8.632B@bbs.tde.com>#1/1 newsgroups: rec.games.corewar VSYSOP by Bryant Software I am looking for hints and tips on a BBS game called Vsysop. If you can help please respond to the following address. Thank You BOOM@BBS.TDE.COM From: Beppe Bezzi Subject: Re: Less is more? Yes! Date: 1995/11/15 Message-ID: <199511151342.OAA20624@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar John K W wrote: >Interesting bit of trivia for all you imp-spiral watchers. :-) >Bigger spirals do not always equal more invincible spirals. > >In a clinical test really big spirals (300+ instructions) >performed WORSE than medium spirals (50 to 150 instructions). >Neither of these were pseudo-spirals. Both were "the real thing." >With the exception of the "tail", every instruction was excecuted >serially. > >Launch time was not even a factor. Both imps used the Evol Imp >launch scheme... which may be similar to Impfinity. (I don't know, >I haven't looked at Impfinity's code.) John, if you don't post or tell us what is the 'Evol Imp launch scheme', it's difficult for us to know what you are speaking of :-) There is a big difference in size beetween a jmp add launch of 300 instructions (not likely, it generates a real monster size spiral indeed, 2^295 processes) a vector launch like the one in the FAQ, a compact vector launch like the one of juliet storm or a classic binary launch. > >Anyway, when the spiral was really big, there occured a point >at which the vulnerability of the tail became a MAJOR factor. > >Not just against scanners, either! Simple stones had a chance >of damaging the really big spiral. What happened, in the case >of stones however, was that the spiral would be knocked down into >the normal size range, and would then become much more resiliant, >and resist further attack... > I'm not an imp expert but, if the objective of this game is having something alive at the end of the round, and a very big spiral can take many hits before becoming but a normal spiral, killing the big one is more difficult than killing its small sister. >-- > / John K. Wilkinson - jwilkinson@mail.utexas.edu \ >| "I don't have the power because I've got the monkeys. I've got | > \ the power because I'll set the monkeys LOOSE." -Dave Foley / > > > -Beppe Bezzi From: panzer@dhp.com (Matt 'Panzer Boy') Subject: Starting off Date: 1995/11/15 Message-ID: <48c0h7$62u@dhp.com>#1/1 newsgroups: rec.games.corewar I just recently started looking into corewars. I've know about the concept for quite some time, but decided to try my hand at coding soon. What I was wondering is if there is something that starts off and teaches about corewars, and redcode programming from a basic level. The tutorials I got started with lines like "this is an imp" "this is a 7 pointed spl imp". Umm sorry, any glossary? etc. Basically, how do people start learning this stuff if they don't have someone who already knows the basics? Has anyone written anything about it from a basic level, or is there a small bit of knowledge that is always assumed? -- -Matt (panzer@dhp.com) DI-1-9026 "That which can never be enforced should not be prohibited." From: sieben@imap1.asu.edu Subject: Re: MOD Generator Date: 1995/11/15 Message-ID: <48dm6g$2pn@news.asu.edu>#1/1 references: <48d6hf$vp@sauron.multiverse.com> newsgroups: rec.games.corewar Beretta (beretta@mail.multiverse.com) wrote: : Does AnyBody know where I could pick up a good mod calculating program : and where I could find a big list of them? Thanks What is a mod calculating program? Nandor. From: beretta@mail.multiverse.com (Beretta) Subject: MOD Generator Date: 1995/11/15 Message-ID: <48d6hf$vp@sauron.multiverse.com>#1/1 newsgroups: rec.games.corewar Does AnyBody know where I could pick up a good mod calculating program and where I could find a big list of them? Thanks From: Planar Subject: Re: (no subject) Date: 1995/11/15 Message-ID: <48co7i$gm1@news-rocq.inria.fr>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar In article <48aqb3$9oh@geraldo.cc.utexas.edu>, John K W writes: >But, what about switching the Hills? Is there anywhere near the ammount >of activity on Stormking as on Pizza? I agree. One of the most active hills (beginner or '94 draft) should go to Stormking to balance the load. Also, I'd like to know whether we can send warriors to the '94 experimental hill, or is it still broken ? Of course, not being the one who will have to do the work, I'm not in a position of demanding anything. -- Planar From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Core War Frequently Asked Questions (rec.games.corewar FAQ) Date: 1995/11/15 Message-ID: newsgroups: rec.games.corewar,rec.answers,news.answers Archive-name: games/corewar-faq Last-Modified: 95/10/12 Version: 3.6 These are the Frequently Asked Questions (and answers) from the Usenet newsgroup rec.games.corewar. A plain text version of this document is posted every two weeks. The hypertext version is available as _________________________________________________________________ Table of Contents 1. What is Core War 2. Is it Core War or Core Wars? 3. Where can I find more information about Core War? 4. Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? 5. What is ICWS'94? Which simulators support ICWS'94? 6. What is the ICWS? 7. What is TCWN? 8. How do I join? 9. What is the EBS? 10. Where are the Core War archives? 11. Where can I find a Core War system for ...? 12. I do not have FTP. How do I get all this great stuff? 13. I do not have access to Usenet. How do I post and receive news? 14. Are there any Core War related WWW sites? 15. When is the next tournament? 16. What is KotH? How do I enter? 17. Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 18. How does SLT (Skip if Less Than) work? 19. What is the difference between in-register and in-memory evaluation? 20. What does (expression or term of your choice) mean? 21. Other questions? _________________________________________________________________ What is Core War? 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 processes of the opposing program 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. [ToC] _________________________________________________________________ Is it "Core War" or "Core Wars"? 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. [ToC] _________________________________________________________________ Where can I find more information about Core War? 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 two anthologies: 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 Author: Dewdney, A. K. Title: The Magic Machine: A Handbook of Computer Sorcery Published: New York: W. H. Freeman (c) 1990 ISBN: 0-7167-2125-2 (Hardcover), 0-7167-2144-9 (Paperback) Library of Congress Call Number: QA76.6 .D5173 1990 A.K. Dewdney's articles are still the most readable introduction to Core War, even though the Redcode dialect described in there is no longer current. [ToC] _________________________________________________________________ Core War has changed since Dewdney's articles. Where do I get a copy of the current instruction set? A draft of the official standard (ICWS'88) is available as . This document is formatted awkwardly and contains ambiguous statements. For a more approachable intro to Redcode, take a look at Mark Durham's tutorial, and . Steven Morrell (morrell@math.utah.edu) is preparing a more practically oriented Redcode tutorial that discusses different warrior classes with lots of example code. Mail him for a preliminary version. Michael Constant (mconst@csua.berkeley.edu) is reportedly working on a beginner's introduction. [ToC] _________________________________________________________________ What is ICWS'94? Which simulators support ICWS'94? 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. You can try out the new standard by submitting warriors to the '94 hills of the KotH servers. Two corewar systems currently support ICWS'94, pMARS (many platforms) and Redcoder (Mac), both available at ftp.csua.berkeley.edu. [ToC] _________________________________________________________________ What is the ICWS? 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). [ToC] _________________________________________________________________ What is TCWN? 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 files. [ToC] _________________________________________________________________ How do I join? 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. [ToC] _________________________________________________________________ What is the EBS? 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. [ToC] _________________________________________________________________ Where are the Core War archives? 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 (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@csua.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. The plain text version of this FAQ is automatically archived by news.answers. [ToC] _________________________________________________________________ Where can I find a Core War system for . . . ? Core War systems are available via anonymous ftp from ftp.csua.berkeley.edu in the /pub/corewar/systems directory. Currently, there are UNIX, IBM PC-compatible, Macintosh, and Amiga Core War systems available there. It is a good idea to check for program updates first. 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 ftp.csua.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 ftp.csua.berkeley.edu: MADgic41.lzh - corewar for the Amiga, v4.1 MAD4041.lzh - older version? MAD50B.lha - corewar for the Amiga, beta version 5.0 Redcoder-21.hqx - corewar for the Mac, supports ICWS'88 and '94 (without extensions) 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) pmars08s.zip - portable system, ICWS'88 and '94, runs on UNIX, PC, Mac, Amiga. C source archive pmars08s.tar.Z - same as above pmars08.zip - PC executables with graphics display, req 386+ macpmars02.sit.hqx - pMARS executable for Mac (port of version 0.2) buggy, no display MacpMARS1.99a.cpt.hqx - port of v0.8 for the Mac, with display and debugger MacpMARS1.0s.cpt.hqx - C source (MPW, ThinkC) for Mac frontend ApMARS03.lha - pMARS executable for Amiga (port of version 0.3.1) wincor11.zip - MS-Windows system, shareware ($15) [ToC] _________________________________________________________________ I do not have FTP. How do I get all this great stuff? 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. If you don't have access to the net at all, send me a 3.5 '' diskette in a self-addressed disk mailer with postage and I will mail it back with an image of the Core War archives in PC format. My address is at the end of this post. [ToC] _________________________________________________________________ I do not have access to Usenet. How do I post and receive news? To receive rec.games.corewar articles by email, join the COREWAR-L list run on the Stormking.Com list processor. To join, send the message 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. [ToC] _________________________________________________________________ Are there any Core War related WWW sites? You bet. Each of the two KotH sites sport a world-wide web server. Stormking's Core War page is ; pizza's is . A third WWW site is in Koeln, Germany: . Last but not least, Stephen Beitzel's "Unofficial Core War Page" is . All site are in varying stages of construction, so it would be futile to list here what they have to offer. [ToC] _________________________________________________________________ When is the next tournament? 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 and other types of tournaments are held frequently among readers of the newsgroup; watch there for announcements or contact me. [ToC] _________________________________________________________________ What is KotH? How do I enter? 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 (warrior) with special comment lines. You will receive a reply indicating how well your program did against the current top programs "on the hill". There are two styles of KotH tournaments, "classical" and "multi-warrior". The "classical" KotH is a one-on-one tournament, that is your warrior 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. In "multi-warrior" KotH, all warriors on the hill fight each other at the same time. Score calculation is a bit more complex than for the one-on-one tournament. Briefly, points are awarded based on how many warriors survive until the end of a round. A warrior that survives by itself gets more points than a warrior that survives together with other warriors. Points are calculated from the formula (W*W-1)/S, where W is the total number of warriors and S the number of surviving warriors. The pMARS documentation has more information on multi-warrior scoring. The idea for an email-based Core War server came from David Lee. The original KotH was developed and run by William Shubert at Intel starting in 1991, 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). Up until May '95, the two sites provided overlapping services, i.e. the some of the hill types were offered by both "pizza" and "stormking". To conserve resources, the different hill types are now divided up among the sites. The way you submit warriors to both KotHs is pretty much the same. Therefore, the entry rules described below apply to both "pizza" and "stormking" unless otherwise noted. 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 a line starting with ";redcode" (or ";redcode-94, etc., see below) 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 seven separate hills you can select by starting your program with ;redcode-b, ;redcode-94, ;redcode-94x, ;redcode, ;redcode-icws, ;redcode-94m or ;redcode-94xm. The former three run at "pizza", the latter four at "stormking". 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 you should get mail back telling you whether your program assembled correctly or not. If it did assemble correctly, sit back and wait; if not, make the change required and re-submit. 5) In an hour or so you should get more mail telling you how your program performed against the current top 20 (or 10) 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. The server kills programs by assigning an impossibly low score; it may therefore take another successful challenge before a killed program is actually removed from the hill. 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") hillsize: 20 warriors rounds: 100 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") hillsize: 20 warriors rounds: 100 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'94 Draft Hill Specs: (Accessed with ";redcode-94", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft ICWS'94 Beginner's Hill Specs: (Accessed with ";redcode-b", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft max. age: after 100 successful challenges, warriors are retired. ICWS'94 Experimental (Big) Hill Specs: (Accessed with ";redcode-94x", available at "pizza") hillsize: 20 warriors rounds: 100 coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: extended ICWS '94 Draft ICWS'94 Draft Multi-Warrior Hill Specs: (Accessed with ";redcode-94m", available at "stormking") hillsize: 10 warriors rounds: 200 coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 instruction set: extended ICWS '94 Draft ICWS'94 Experimental (Big) Multi-Warrior Hill Specs: (Accessed with ";redcode-94xm", available at "stormking") hillsize: 20 warriors rounds: 100 coresize: 55440 max. processes: 10000 duration: after 500,000 cycles, a tie is declared. max. entry length: 200 minimum distance: 200 instruction set: extended 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. At stormking, a message body with ";help" will return brief instructions. If you submit code containing a ";test" line, your warrior will be assembled but not actually pitted against the warriors on the hill. All hills run portable MARS (pMARS) version 0.8, a platform-independent corewar system available at ftp.csua.berkeley.edu. The '94 and '94x hills allow three experimental opcodes and addressing modes currently not covered in the ICWS'94 draft document: SEQ - Skip if EQual (synonym for CMP) SNE - Skip if Not Equal NOP - (No OPeration) * - indirect using A-field as pointer { - predecrement indirect using A-field } - postincrement indirect using A-field [ToC] _________________________________________________________________ Is it DAT 0, 0 or DAT #0, #0? How do I compare to core? 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. [ToC] _________________________________________________________________ How does SLT (Skip if Less Than) work? 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. [ToC] _________________________________________________________________ What is the difference between in-register and in-memory evaluation? These terms refer to the way instruction operands are evaluated. The '88 Redcode standard ICWS'88 is unclear about whether a simulator should "buffer" the result of A-operand evaluation before the B-operand is evaluated. Simulators that do buffer are said to use in-register evaluation, those that don't, in-memory evaluation. ICWS'94 clears this confusion by mandating in-register evaluation. Instructions that execute differently under these two forms of evaluation are MOV, ADD, SUB, MUL, DIV and MOD where the effective address of the A-operand is modified by evaluation of the B-operand. This is best illustrated by an example: L1 mov L2, mov.i #0,impsize 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, mov.i #0,impsize Mirror see reflection. On-axis/off-axis On-axis scanners compare two locations M/2 apart, where M is the memory size. Off-axis scanners use some other separation. Optimal Constants (also optima-type constants) Bomb or scan increments chosen to cover core most effectively, i.e. leaving gaps of uniform size. Programs to calculate optimal constants and lists of optimal numbers are available at ftp.csua.berkeley.edu. Paper A Paper-like program. One which replicates itself many times. Part of the Scissors (beats) Paper (beats) Stone (beats Scissors) analogy. Pit-Trapper (also Slaver, Vampire). A program which enslaves another. Usually accomplished by bombing with JMPs to a SPL 0 pit with an optional core-clear routine. Quick Scan 2c scan of a set group of core locations with bombing if anything is found. Both of the following codes snips scan 16 locations and check for a find. If anything is found, it is attacked, otherwise 16 more locations are scanned. Example: start s1 for 8 ;'88 scan cmp start+100*s1, start+100*s1+4000 ;check two locations mov #start+100*s1-found, found ;they differ so set pointer rof jmn attack, found ;if we have something, get it s2 for 8 cmp start+100*(s2+6), start+100*(s2+6)+4000 mov #start+100*(s2+6)-found, found rof found jmz moveme, #0 ;skip attack if qscan found nothing attack cmp @found, start-1 ;does found points to empty space? add #4000, found ;no, so point to correct location mov start-1, @found ;move a bomb moveme jmp 0, 0 In ICWS'94, the quick scan code is more compact because of the SNE opcode: start ;'94 scan s1 for 4 sne start+400*s1, start+400*s1+100 ;check two locations seq start+400*s1+200, start+400*s1+300 ;check two locations mov #start+400*s1-found, found ;they differ so set pointer rof jmn which, found ;if we have something, get it s2 for 4 sne start+400*(s2+4), start+400*(s2+4)+100 seq start+400*(s2+4)+200, start+400*(s2+4)+300 mov #start+400*(s2+4)-found-100, found rof found jmz moveme, #0 ;skip attack if qscan found nothing add #100, -1 ;increment pointer till we get the which jmn -1, @found ;right place mov start-1, @found ;move a bomb moveme jmp 0, 0 Reflection Copy of a program or program part, positioned to make the active program invisible to a CMP-scanner. Replicator Generic for Paper. A program which makes many copies of itself, each copy also making copies. Self-Splitting Strategy of amplifying the number of processes executing a piece of code. example SPL 0 loop ADD #10, example MOV example, @example JMP loop Scanner A program which searches through core for an opponent rather than bombing blindly. Scissors A program designed to beat replicators, usually a (B-field scanning) vampire. Part of the Paper-Scissors-Stone analogy. Self-Repair Ability of a program to fix it's own code after attack. Silk A replicator which splits off a process to each new copy before actually copying the code. This allows it to replicate extremely quickly. This technique is only possible under the '94 draft, because it requires post-increment indirect addressing. Example: spl 1 mov.i -1, 0 spl 1 ;generate 6 consecutive processes silk spl 3620, #0 ;split to new copy mov.i >-1, }-1 ;copy self to new location mov.i bomb, >2000 ;linear bombing mov.i bomb, }2042 ;A-indirect bombing for anti-vamp jmp silk, {silk ;reset source pointer, make new copy bomb dat.f >2667, >5334 ;anti-imp bomb Slaver see Pit-Trapper. Stealth Property of programs, or program parts, which are invisible to scanners, accomplished by using zero B-fields and reflections. Stone A Stone-like program designed to be a small bomber. Part of the Paper-Scissors-Stone analogy. Stun A type of bomb which makes the opponent multiply useless processes, thus slowing it down. Example is referred to as a spl-jmp bomb. example spl 0 jmp -1 Two-Pass Core-Clear (also spl/dat Core-Clear) core clear that fills core first with SPL instructions, then with DATs. This is very effective in killing paper and certain imp-spiral variations. Vampire see Pit-Trapper. Vector Launch one of several means to start an imp-spiral running. As fast as Binary Launch, but requiring much less code. See also JMP/ADD Launch and Binary Launch. This example is one form of a Vector Launch: impsize equ 2667 example spl 1 ; extend by adding more spl 1's spl 1 djn.a @imp,#0 ; jmp @ a series of pointers dat #0,imp+(3*impsize) dat #0,imp+(2*impsize) dat #0,imp+(1*impsize) dat #0,imp+(0*impsize) imp mov.i #0,impsize [ToC] _________________________________________________________________ Other questions? Just ask in the rec.games.corewar newsgroup or contact me (address below). If you are shy, check out the Core War archives first to see if your question has been answered before. [ToC] _________________________________________________________________ Credits Additions, corrections, etc. to this document are solicited. Thanks in particular to the following people who have contributed major portions of this document: Paul Kline, Randy Graham. Mark Durham wrote the first version of the FAQ. The rec.games.corewar FAQ is Copyright 1995 and maintained by: Stefan Strack, PhD stst@vuse.vanderbilt.edu Dept. Molecular Physiol. and Biophysics stst@idnsun.gpct.vanderbilt.edu Rm. 762, MRB-1 stracks@vuctrvax.bitnet Vanderbilt Univ. Medical Center Voice: +615-322-4389 Nashville, TN 37232-6600, USA FAX: +615-322-7236 _________________________________________________________________ $Id: corewar-faq.html,v 3.6 1995/10/12 22:44:37 stst Exp stst $ From: John K W Subject: Less is more? Yes! Date: 1995/11/15 Message-ID: <48bm3f$gi@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar Interesting bit of trivia for all you imp-spiral watchers. :-) Bigger spirals do not always equal more invincible spirals. In a clinical test really big spirals (300+ instructions) performed WORSE than medium spirals (50 to 150 instructions). Neither of these were pseudo-spirals. Both were "the real thing." With the exception of the "tail", every instruction was excecuted serially. Launch time was not even a factor. Both imps used the Evol Imp launch scheme... which may be similar to Impfinity. (I don't know, I haven't looked at Impfinity's code.) Anyway, when the spiral was really big, there occured a point at which the vulnerability of the tail became a MAJOR factor. Not just against scanners, either! Simple stones had a chance of damaging the really big spiral. What happened, in the case of stones however, was that the spiral would be knocked down into the normal size range, and would then become much more resiliant, and resist further attack... Hmmmm. That post ended up being a lot bigger than I had originally planned it. Ah well, hope someone gains something from it. :-) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Robert Macrae Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <48ghup$15p@soap.news.pipex.net>#1/1 references: <9511160935.AA27224@su9-8.ida.liu.se> newsgroups: rec.games.corewar Anders Ivner wrote: From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: NSFCWT round 6 Date: 1995/11/16 Message-ID: <1995Nov16.081929.3060@rhodes>#1/1 references: newsgroups: rec.games.corewar sieben@IMAP1.ASU.EDU wrote: : : So, are we allowed to "peep"? : No. So this means I have to come up with a different way to load my first strategy? As an example, I currently do something like mov.ab 4004, #0 add.b 4006, -1 mul.f 4007, -2 add.ab -3, -3 mod.ab #3, -4 add.ab #1, -5 mov.b -6, my_hand So is this not allowed? : : And how about putting code/data after the bookkeeping section? I have : : a sincerely sneaky reason for trying this :-) : Not again. You are allowed to put code only in the middle of the : skeleton. I have all my code inside the right section. However, when I am running, I use space outside for data loading and storing (a temporary stack of sorts). I can do without it, but it makes it easier for me if I can use empty core instead of places inside the body. No big deal to change it, just let me know if I have to. : Nandor. Randy From: John K W Subject: Re: Ideas for new instructions Date: 1995/11/16 Message-ID: <48ga37$3vq@geraldo.cc.utexas.edu>#1/1 references: <303@arbroath.win-uk.net> <1995Nov15.073012.3055@rhodes> newsgroups: rec.games.corewar graham@hal.mathcs.rhodes.edu (Randy Graham) wrote: >I've said this same thing before. I think to make "intelligent" >warriors, we have to redefine the objective of the game. The sorting >round was an example of this, the random core round was, and the >current round is too. Also, using read/write limits would, I believe, Yeah, I think clearly the best example of a spot where intelligent warriors could shine is the random rules game. Perhaps something that would be really nice (and could be turned into a hill) would be a random core game, with THREE warriors fighting together. You would most likely need some sort of paper element (which is more difficult in the random core) or an imp ring (which Rand-Man so eloquently demonstrated). I think the three warrior random hill could have some real potential for the development of ADAPTIVE warriors. Which is what real intelligence is, wouldn't you say? I mean, if it can't adapt to new situations, it's not all that smart. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: h0444xoq@rz.hu-berlin.de Subject: Corewar? Date: 1995/11/16 Message-ID: <48eodv$2t5@suncom.rz.hu-berlin.de>#1/1 newsgroups: rec.games.corewar Hello Guys, It's possible, that I'm totally wrong in this newsgroup, but I received a copy of a game called 'CoreWar' today, but don't know, how it works... I saw a kind of listing in this group and tried to run it with CoreWar, but it was impossible... Do I need a special kind of CoreWar-program??? I would like to set up my own War-programs, so please tell me what I have to do. Please send your answers as e-mail to the address below, 'cause I don't read this group all the time... h0444xoq@rz.hu-berlin.de or mike.remmert@rz.hu-berlin.de P.S.: If I need a special CoreWar-program, it would be great if someone would send it UUencoded, BinHexEncoded or MIME-encoded to one of my addresses. Thanks, ???? MIKE !!!!!!!! From: John K W Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <48g9q4$3vq@geraldo.cc.utexas.edu>#1/1 references: <199511132239.RAA20143@valhalla.stormking.com> <1995Nov15.140308@acad.drake.edu> <1995Nov16.083000@acad.drake.edu> <48ftre$npo@soap.news.pipex.net> newsgroups: rec.games.corewar Robert Macrae wrote: >In the light of the above, this is a major relief (but I'm still going rub >the code in garlic, erase all my boot pointers, and run an imp spiral in the >background :) Wow, that's the first I've laughed out loud while reading rec.games.corewar. You deserve a prize! :> -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Robert Macrae Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <48ftre$npo@soap.news.pipex.net>#1/1 references: <199511132239.RAA20143@valhalla.stormking.com> <1995Nov15.140308@acad.drake.edu> <1995Nov16.083000@acad.drake.edu> newsgroups: rec.games.corewar >> And how about putting code/data after the bookkeeping section? I have >> a sincerely sneaky reason for trying this :-) >Nandor answered this vie email (NO!), but here is my reason. If peeping >were allowed, then you could camouflage yourself as one of the whites, putting >your actual code after the bookkeeping section and changing the ORG line. Lets get this straight. You wanted to get peeping permitted because you had a sneaky approach to foiling it?! >However, Nandor and Stefan are making sure we stick to the point of this >particular challenge, which is to see just how smart a program can get >without resorting to "tricks". In the light of the above, this is a major relief (but I'm still going rub the code in garlic, erase all my boot pointers, and run an imp spiral in the background :) From: pk6811s@acad.drake.edu Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <1995Nov16.083000@acad.drake.edu>#1/1 references: <199511132239.RAA20143@valhalla.stormking.com> <1995Nov15.140308@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu writes: [...] > And how about putting code/data after the bookkeeping section? I have > a sincerely sneaky reason for trying this :-) Nandor answered this vie email (NO!), but here is my reason. If peeping were allowed, then you could camouflage yourself as one of the whites, putting your actual code after the bookkeeping section and changing the ORG line. However, Nandor and Stefan are making sure we stick to the point of this particular challenge, which is to see just how smart a program can get without resorting to "tricks". Paul Kline pk6811s@acad.drake.edu From: turbulance@oia.net Subject: NEED HELP!!!!! Date: 1995/11/16 Message-ID: <48h9m2$nd9@news.zynet.com>#1/1 newsgroups: rec.games.corewar Can someone please tell me where to get a very precise, yet easy to understand file on redcode? I am new to this language, and it looks very similar to ASM. I can understand some of it, but i just need a detailed file on redcode that is easy to read. I am new to corewars, so any help would be appreciated. Thanks in advance.... -= Turbulance =- From: lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) Subject: koth settings Date: 1995/11/16 Message-ID: <48elo2$91v@nuscc.nus.sg>#1/1 newsgroups: rec.games.corewar Are the distances between warriors on the hill varied between rounds? TIA. -- Calvin Loh From: Planar Subject: fun with imp rings & a bit of useful code Date: 1995/11/16 Message-ID: <48g1bk$d9f@news-rocq.inria.fr>#1/1 newsgroups: rec.games.corewar I have discovered a new way of launching imp rings. Unfortunately, it only works for imp sizes of CORESIZE-1 and CORESIZE-2, which are a little unwieldy. CORESIZE-1 works in any core size, with a step of -1, and CORESIZE-2 works in any odd core size, with a step of (CORESIZE-1)/2. Essentially, it is a vector launch, except that the vector is [imp, imp-1, imp-2, ...] so we can replace it with a predecrement. Here is the program for CORESIZE-1. It works in any core of at least 2 cells. The case CORESIZE==1 is left as an exercise. I limited myself to less than 2**31, but you could easily extend it (you'll need a MARS with more than 32-bit integers...) ;redcode-94 ;name MaxImp ;author Planar ;strategy (CORESIZE-1)-point imp ring ;assert CORESIZE >= 2 && CORESIZE <= 2147483647 ; to launch N processes ;assert MAXPROCESSES >= CORESIZE-1 ; for the imp ring to work N equ (CORESIZE-1) ; number of processes to launch i for 31 + ((n=1073741824) && 0) ; generate N processes for N-1 >= n && (N-1) / n % 2 == 1 ; no need to do this by hand ! spl 1 ; rof ; for N-1 >= n && (N-1) / n % 2 == ((n=n/2) && 0) mov.i -1, 0 ; rof ; rof ; N processes generated jmp imp, {0 ; launch the ring imp mov 0, -1 end For a (CORESIZE-2)-point ring, you would use one more cell as a pointer, and a JMP Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <9511160935.AA27224@su9-8.ida.liu.se>#1/1 newsgroups: rec.games.corewar > INteresting. You could identify all the white programs and beat them > each 1000 times! And yourself as well :-) No, you can't beat yourself at all. Due to determinism everyone will score exacty 0/0/1000 against themselves (unless they use somekind of in-core handshaking, which shouldn't be allowed). > Probably there will be some close scores, going 990/5/5 against the whites > and 333/333/334 against many opponents, therefore a few extra wins might just > come in handy. > > Even worse, you could copy the opponent's code into core, execute it, and > see what comes out. Unless he is 500 lines or so, then your time would > expire and you'd be disqualified :-) > > So, are we allowed to "peep"? I hope not. > And how about putting code/data after the bookkeeping section? I have > a sincerely sneaky reason for trying this :-) > > Paul Kline > pk6811s@acad.drake.edu > /Anders From: t01mtm@abdn.ac.uk (t01mtm) Subject: VENUS Date: 1995/11/16 Message-ID: <48fio2$da7@fs2.abdn.ac.uk>#1/1 newsgroups: rec.games.corewar Does anyone know where I can get hold of a copy of Steen Rasmussen "VENUS"? A modification of Core War where the programs mutate. Q~Q | Michael McEwen : t01mtm@abdn.ac.uk ------------------------------------ | | - | Apathy Error: Don't bother striking any key V | From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Round 6 = Intelligent warriors? Date: 1995/11/16 Message-ID: <1995Nov16.171011.3063@rhodes>#1/1 newsgroups: rec.games.corewar Wel,l I think I am finished with round 6, but I am waiting to hear the results of my "random" number generator I used for my first round battle. I like this round much more than the last. This way we have time to have thoughtful, brooding warriors, each trying to outsmart the others. Worked down to about 100 total losses and ties against whites, and I am not sure I can improve. But, I am looking for ways to reduce that number, as I am sure someone has beat me out on this (someone always does). But I was just wondering if anyone else was enjoying this round as much as I am? Anyone find this too easy (I sure didn't)? Anyone not liking it. Just wondering others opinions. Randy From: sieben@IMAP1.ASU.EDU Subject: NSFCWT round 6 Date: 1995/11/16 Message-ID: #1/1 newsgroups: rec.games.corewar In my previous mail I made it possible for you to write in certain areas of the core. I can imagine that some of your already done warriors would suffer from this change. If so, please let me know soon. Since we don't have much time left I extend the deadline by one day. So the new deadline is Saturday. Nandor. From: sieben@IMAP1.ASU.EDU Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: #1/1 newsgroups: rec.games.corewar Is my previous mail satisfactory? Nandor. From: sieben@IMAP1.ASU.EDU Subject: NSFCWT Round 6 - Peeping Date: 1995/11/16 Message-ID: #1/1 newsgroups: rec.games.corewar > >No, you can't beat yourself at all. Due to determinism everyone will > >score exacty 0/0/1000 against themselves (unless they use somekind of > >in-core handshaking, which shouldn't be allowed). > > It's _very_ important to be _sure_ that handshaking isn't allowed. > > It should not be possible, to do that you have to read and write in the half > of core reserved to your opponent, and this should be considered 'peeping' > or 'bombing', but I would like to have a clear answer. This round creates a lot of difficulties but I think it's worth it. If you test pmars you can see that the maximal length (-l) of a warrior is 500. This is hardwired into pmars so you don't have a full half of the core. So I think it's reasonable to consider the area 500-3999 and 4500-8999 as common area. So it's not forbidden to write and read this area since this way a warrior cannot change the behaivor of his opponent. On the other hand you must not read or write your opponents own space. Also you cannot comit suicide, that is, the last part of the skeleton has to be executed. Too bad Stefan is gone. I have to make some hard decisions on my own in this round. Nandor. From: Beppe Bezzi Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <199511162212.XAA07787@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar Nandor Sieben wrote: > > >On Thu, 16 Nov 1995, Beppe Bezzi wrote: > >> At 04.52 16/11/95 -0500, you wrote: >> >> INteresting. You could identify all the white programs and beat them >> >> each 1000 times! And yourself as well :-) >> > >> >No, you can't beat yourself at all. Due to determinism everyone will >> >score exacty 0/0/1000 against themselves (unless they use somekind of >> >in-core handshaking, which shouldn't be allowed). >> > >> >> It's _very_ important to be _sure_ that handshaking isn't allowed. >> >> It should not be possible, to do that you have to read and write in the half >> of core reserved to your opponent, and this should be considered 'peeping' >> or 'bombing', but I would like to have a clear answer. >> >> >> >> >> Paul Kline >> >> pk6811s@acad.drake.edu >> >> >> >/Anders >> > >> > >> -Beppe >> >> > >I think I missed some of this talk. Please tell me again what the >question is exactly, because I don't understand the problem. > The problem is the battle against ourself; as Anders pointed out it's impossible to score anything different from 0/0/1000 but: If I can read/write in the region 4000-7999 I can set a flag with one of my warriors, the first to execute, and create an asimmetry in behaviour, this could lead, to a result of 500/500/0 I'm not _sure_ I can do it, I didn't ever try to implement because I guessed it was a sort of bombing/peeping, in case it is right I have to know _now_ If I can write in my opponent half, nothing prohibits me to store my data at your_hand +100, should happen it's enemy code ... I win :-) The only way to avoid that, is limiting the addressable field of a warrior to the region my_hand -> your_hand -1 Any read or write outside this area must be considered peeping or bombing. >Nandor. > > Randy Graham wrote: >MV (pan0178@comune.bologna.it) wrote: >: Just one question... >: Am I allowed to look at any cell (except your_hand, of course) in the core ? >: In example can I "peep" at enemy code? >I hope so. I pulled a couple of a- and b-fields from enemy code to >add and multiply to come up with a "random" first round strategy. I >didn't look at what their code is, I just needed some numbers. > You can use a number of your choice 'inside' your code as seed of the random generator; if you are against another warrior it doesn't know them, so they are random, if instead you are against yourself, the seed will be the same for both and so _not random_ > >: Maurizio Vittuari > >Randy > > -Beppe From: Beppe Bezzi Subject: Re: Less is more? Yes! Date: 1995/11/16 Message-ID: <199511162213.XAA07797@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar John K W wrote: >Beppe Bezzi wrote: >>John K W wrote: >>>Interesting bit of trivia for all you imp-spiral watchers. :-) >>>Bigger spirals do not always equal more invincible spirals. >>> >>John, if you don't post or tell us what is the 'Evol Imp launch scheme', >>it's difficult for us to know what you are speaking of :-) > >Oh fine, be that way, steal all my code. :) Yeah, I'll post it, once >I figure out how to make a successful warrior with it. > Core warrior staff is waiting it to publish, now you promised ;-) >>There is a big difference in size beetween a jmp add launch of 300 >>instructions (not likely, it generates a real monster size spiral indeed, >>2^295 processes) a vector launch like the one in the FAQ, a compact vector >>launch like the one of juliet storm or a classic binary launch. > >No no no. The size of the launcher was not a factor. The launcher is >quite small, and is easily able to generate a large spiral before being >bombed. > What I want to know is the size, in number of processes, of the spirals you are speaking of. If you speak of spirals of 200 and 400 processes the difference is academic, if you speak instead of 10 and 20 processes spirals we are in the range of common sizes. >>... a very big spiral can take many hits >>before becoming but a normal spiral, killing the big one is more difficult >>than killing its small sister. > >But see, that's what was weird! The stone would bomb the unusually large >spiral, and kill off a few processes in the middle somewhere, so that when >the now medium-sized spiral hit a gate, it was FAR more likely to die. > Maybe I miss something about imp spirals, very likely indeed, but how can you kill processes _in_the_middle_ of a compact spiral breaking it in two halves? > >-- > / John K. Wilkinson - jwilkinson@mail.utexas.edu \ -Beppe From: pan0178@comune.bologna.it (MV) Subject: little bug in white#5 Date: 1995/11/16 Message-ID: <199511162211.RAA15156@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Here's a piece of White Warrior #5: start strgy ldp STRAT,#strgy add #1,strgy ;next strategy no matter what mod #3,strgy ;123123.. stp strgy,STRAT ^^^^^^^^^ store add.ab #1,strgy mov.b strgy,my_hand It follows the strategy 231231231... (not 123123123..)! A very little bug ;-) From: sieben@IMAP1.ASU.EDU Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: #1/1 newsgroups: rec.games.corewar On Thu, 16 Nov 1995, Beppe Bezzi wrote: > At 04.52 16/11/95 -0500, you wrote: > >> INteresting. You could identify all the white programs and beat them > >> each 1000 times! And yourself as well :-) > > > >No, you can't beat yourself at all. Due to determinism everyone will > >score exacty 0/0/1000 against themselves (unless they use somekind of > >in-core handshaking, which shouldn't be allowed). > > > > It's _very_ important to be _sure_ that handshaking isn't allowed. > > It should not be possible, to do that you have to read and write in the half > of core reserved to your opponent, and this should be considered 'peeping' > or 'bombing', but I would like to have a clear answer. > > >> > >> Paul Kline > >> pk6811s@acad.drake.edu > >> > >/Anders > > > > > -Beppe > > I think I missed some of this talk. Please tell me again what the question is exactly, because I don't understand the problem. Nandor. From: Beppe Bezzi Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <199511161332.OAA01168@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 04.52 16/11/95 -0500, you wrote: >> INteresting. You could identify all the white programs and beat them >> each 1000 times! And yourself as well :-) > >No, you can't beat yourself at all. Due to determinism everyone will >score exacty 0/0/1000 against themselves (unless they use somekind of >in-core handshaking, which shouldn't be allowed). > It's _very_ important to be _sure_ that handshaking isn't allowed. It should not be possible, to do that you have to read and write in the half of core reserved to your opponent, and this should be considered 'peeping' or 'bombing', but I would like to have a clear answer. >> >> Paul Kline >> pk6811s@acad.drake.edu >> >/Anders > > -Beppe From: Beppe Bezzi Subject: Re: NSFCWT Round 6 - Peeping Date: 1995/11/16 Message-ID: <199511162317.AAA08839@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar Nandor Sieben wrote: Let me try to resume all questions: >> It's _very_ important to be _sure_ that handshaking isn't allowed. >> >> It should not be possible, to do that you have to read and write in the half >> of core reserved to your opponent, and this should be considered 'peeping' >> or 'bombing', but I would like to have a clear answer. > >This round creates a lot of difficulties but I think it's worth it. If >you test pmars you can see that the maximal length (-l) of a warrior is >500. This is hardwired into pmars so you don't have a full half of the >core. So I think it's reasonable to consider the area 500-3999 and >4500-8999 as common area. So it's not forbidden to write and read this >area since this way a warrior cannot change the behaivor of his opponent. Ok, if I store data at my_hand+600 and my opponent overwrites them, too bad for me. I cannot bomb or peep inside the safe zone your_hand -> your_hand+500, and I'm sure my opponent won't. >On the other hand you must not read or write your opponents own space. >Also you cannot comit suicide, that is, the last part of the skeleton has >to be executed. That's important too; if suicide is allowed: I write the flag, my other mine program does the same, and next instruction jmn my_hand, your_flag cause a 500/500 against myself. ++ I CANNOT DO THAT ++ It will be hard for you to verify none cheats, but we all are gentlemen, and warriors will be published ;-) (Just hope not to have a bug in my warrior :-) Deadline is moved to Saturday, same time. >Too bad Stefan is gone. I have to make some hard decisions on my own in >this round. The important is to have a decision _quickly_, and you are doing that, thanx. > >Nandor. > -Beppe From: Derek Ross Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/16 Message-ID: <312@arbroath.win-uk.net>#1/1 newsgroups: rec.games.corewar On Thu, 16 Nov 1995, Beppe Bezzi wrote: >The problem is the battle against ourself; as Anders pointed out it's >impossible to score anything different from 0/0/1000 but: > >If I can read/write in the region 4000-7999 I can set a flag with one of my >warriors, the first to execute, and create an asimmetry in behaviour, this >could lead, to a result of 500/500/0 > >I'm not _sure_ I can do it, I didn't ever try to implement because I guessed >it was a sort of bombing/peeping, in case it is right I have to know _now_ > I couldn't agree more, Beppe. And even if it does work, it still shouldn't be done. Why not? Well, think about what we're trying to do here. We're playing paper, scissors, stone. In the playground you win that game by outguessing your opponent not by checking for 'funny handshakes' and colluding with your opponent if he seems to be a member of your team. The intention of this round is surely to emulate the playground game as closely as possible and that means stick to outguessing your opponent. By all means use spare core for doing this. But not for anything else. Just my opinion of course. Derek MicroSoft Network may not carry this message without license to do so. License to carry this message requires a fee of $1000, payable within 30 days to Derek Ross. Appearance of this message on MicroSoft Network constitutes an agreement to terms. From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: summary on read/write limits [part 1] Date: 1995/11/17 Message-ID: <48iteu$bfk@lastactionhero.rs.itd.umich.edu>#1/1 references: <48idlv$s6s@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar (Damien.Doligez@inria.fr) wrote [edited for brevity]: : The arguments in favor of read/write limits were all versions of the : same argument: it forces programs to move around the core, thus : eliminating stones. The implicit argument here is that moving : programs are more complex/intelligent than non-moving programs. It's interesting that a long standing desire for more intelligent warriors has yet to yield any results of note. : If somebody else has a good argument for or against the limits, you're : welcome. : -- Planar I vote against limits. It complicates what should be simple. John Lewis From: ruhl@phoebe.cair.du.edu (Robert A. Uhl) Subject: Re: summary on read/write limits [part 1] Date: 1995/11/17 Message-ID: <48iog3$5ap@hermes.cair.du.edu>#1/1 references: <48idlv$s6s@news-rocq.inria.fr> newsgroups: rec.games.corewar Well, it seems to me that the best strategy in a read/write limit situation would be to have a known limit and spl a process at limit-1 and -(limit-1) (or so), each copying until enough had been launched to cover all of the core. In fact, this is the only winning strategy which I can see. I'm sure that someone has another, of course. Anyway, this is particularly brilliant. It just fosters really cool launch schemes and then fast strategies (so that the spled processes each can get something done). Also, I'd bet that it slows the entire game down rather much. I would particularly care for it, mostly because it just doesn't seem to make that much of a difference in the intelligence of programs. That's another reason that I am so against Pspace; it really doesn't encourage intelligence; it fosters cool start-ups and that is all. What's the deal with that? -- +------------------------------------------------------------------------+ | Bob Uhl | Spectre | `En touto nika' + | | U of D | PGG FR No. 42 | http://mercury.cair.du.edu/~ruhl/ | +------------------------------------------------------------------------+ From: lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) Subject: pmars08s is not ANSI C compliant:( Date: 1995/11/17 Message-ID: <48h3mg$kq@nuscc.nus.sg>#1/1 newsgroups: rec.games.corewar Downloaded source for pmars. Tried to compile it on my UNIX account. Failed because it is not ANSI C compliant. -- Calvin Loh From: lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) Subject: What does PIN do? Date: 1995/11/17 Message-ID: <48h3ju$kq@nuscc.nus.sg>#1/1 newsgroups: rec.games.corewar Just saw a new command for p-space, "pin". What does it do? TIA. -- Calvin Loh From: John K W Subject: Re: Less is more? Yes! Date: 1995/11/17 Message-ID: <48iujr$soo@geraldo.cc.utexas.edu>#1/1 references: <199511151342.OAA20624@iol-mail.iol.it> <48fqdh$lt1@geraldo.cc.utexas.edu> <48i8cn$q8t@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar wrote: >>Oh fine, be that way, steal all my code. :) Yeah, I'll post it, once >>I figure out how to make a successful warrior with it. > >Then you'd better do it fast because Impfinity v3 (or maybe v4) will >be in Core Warrior 7. Heh. I think you've already beat me to it. I still haven't figured out how to beat all the qscan->bomber->gate things. I'm still working on it though! :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Planar Subject: summary on read/write limits [part 1] Date: 1995/11/17 Message-ID: <48idlv$s6s@news-rocq.inria.fr>#1/1 newsgroups: rec.games.corewar I'm still reading the rec.games.corewar archives (only 2.5 Meg to go...), so I'll only summarize the discussions from the dawn of time up to 1992. The rest will have to wait till next week (or later). At the end of 1991 and the beginning of 1992, there was a lot of talk about SPL 0, and less about read/write limits. The goal of read/write limits is to promote complexity in warriors by preventing stationnary stones. Various ideas were proposed, ranging from the complex to the very complex. The arguments in favor of read/write limits were all versions of the same argument: it forces programs to move around the core, thus eliminating stones. The implicit argument here is that moving programs are more complex/intelligent than non-moving programs. The arguments against read/write limits are also versions of the same argument: it forces programs to move around the core, thus eliminating stones and scanners. Paper becomes the only viable strategy, so the programmer's choices are reduced. This is not good because paper are no more complex or intelligent than stones (and they can be just as short). Imp spirals had not been invented at that time, but I'd like to add that they become impossible except for short-step, many-points spirals, and very hard to launch. An interesting thing is that Stefan Strack posted in favor of read/write limits exactly four years ago (Nov 17, 1991). At the end of 1991 and during the first half of 1992, the experimental hill was using read/write limits. A number of warriors posted in 1992 were written for these rules (get the warriors from that time with "redcode-x" in the header if you want to have a look at them). Toward the end of 1992, Stefan said that he had not written a single warrior for the experimental hill. Now he says he doesn't like the read/write limits. There must be some good reason why you changed your mind, Stefan. Let's hear about it. If somebody else has a good argument for or against the limits, you're welcome. -- Planar P.S. I've tried not to show my bias too much, but my vote is against read/write limits. From: Planar Subject: Re: Ideas for new instructions Date: 1995/11/17 Message-ID: <48i8i7$q8t@news-rocq.inria.fr>#1/1 references: <486j3g$8rn@nuscc.nus.sg> newsgroups: rec.games.corewar In article <486j3g$8rn@nuscc.nus.sg>, lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) writes: >How about allowing pre-increment and post-decrement? Yes, it would be more symmetrical. But we already have 8 addressing modes. Do we want to add 4 and what symbols will we find for them ? -- Planar (more features means more work on the standard) From: Planar Subject: Re: Less is more? Yes! Date: 1995/11/17 Message-ID: <48i8cn$q8t@news-rocq.inria.fr>#1/1 references: <199511151342.OAA20624@iol-mail.iol.it> <48fqdh$lt1@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar In article <48fqdh$lt1@geraldo.cc.utexas.edu>, John K W writes: >No no no. The size of the launcher was not a factor. The launcher is >quite small, and is easily able to generate a large spiral before being >bombed. Then it must be very much like Impfinity v3. >Oh fine, be that way, steal all my code. :) Yeah, I'll post it, once >I figure out how to make a successful warrior with it. Then you'd better do it fast because Impfinity v3 (or maybe v4) will be in Core Warrior 7. "I will be back !" -- Planar From: John K W Subject: Re: Less is more? Yes! Date: 1995/11/17 Message-ID: <48h30l$lsq@geraldo.cc.utexas.edu>#1/1 references: <199511162213.XAA07797@iol-mail.iol.it> newsgroups: rec.games.corewar Beppe Bezzi wrote: >>Oh fine, be that way, steal all my code. :) Yeah, I'll post it, once >>I figure out how to make a successful warrior with it. >> >Core warrior staff is waiting it to publish, now you promised ;-) Yipe! >>No no no. The size of the launcher was not a factor. The launcher is >>quite small, and is easily able to generate a large spiral before being >>bombed. >> >What I want to know is the size, in number of processes, of the spirals you >are speaking of. If you speak of spirals of 200 and 400 processes the >difference is academic, if you speak instead of 10 and 20 processes spirals >we are in the range of common sizes. The imp spirals generated are 200+ for big spirals. 40- for small ones. >>But see, that's what was weird! The stone would bomb the unusually large >>spiral, and kill off a few processes in the middle somewhere, so that when >>the now medium-sized spiral hit a gate, it was FAR more likely to die. >> > >Maybe I miss something about imp spirals, very likely indeed, but how can >you kill processes _in_the_middle_ of a compact spiral breaking it in two >halves? It wasn't being split, it was just being messed up slightly. The real difference seen was in the case of scanners, because the scanner could actually hit imp twice before that section of the code operated. Similarly, stones could hit the imp several times. Then, if it got a lucky shot, and nailed the currently executing process, and lot of damage could be done. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: sieben@imap1.asu.edu Subject: Re: summary on read/write limits [part 1] Date: 1995/11/18 Message-ID: <48jaft$f7c@news.asu.edu>#1/1 references: <48idlv$s6s@news-rocq.inria.fr> newsgroups: rec.games.corewar : Imp spirals had not been invented at that time, but I'd like to add : that they become impossible except for short-step, many-points : spirals, and very hard to launch. It's not that hard to launch. I remember I posted a launcher a long time ago. I might be able to dig it up. Nandor. From: sieben@imap1.asu.edu Subject: Re: Ideas for new instructions Date: 1995/11/18 Message-ID: <48ja5b$f7c@news.asu.edu>#1/1 references: <486j3g$8rn@nuscc.nus.sg> <48i8i7$q8t@news-rocq.inria.fr> newsgroups: rec.games.corewar : In article <486j3g$8rn@nuscc.nus.sg>, lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) writes: : >How about allowing pre-increment and post-decrement? : Yes, it would be more symmetrical. But we already have 8 addressing : modes. Do we want to add 4 and what symbols will we find for them ? We could use a ;pre a< a> ;post Nandor. From: wtnewton@nc5.infi.net (wtnewton) Subject: Re: Newbie from Heck Date: 1995/11/18 Message-ID: <48knc7$dq9@news.infi.net>#1/1 references: <48jqd5$h7@daily-planet.nodak.edu> newsgroups: rec.games.corewar shutcs@prairie.NoDak.edu (David M Shutcs) wrote: >Hey Corewar people! >I've been reading this group for awhile, because I've heard about Corewar >from others, and I've always thought it sounded like fun. >Can anyone give me any info on how to start, I can't seem to find a FAQ? >Thanks in advance for nursing me along... > ---Wulfgar I'm a core-newbie too! All of the good stuff is at: ftp://ftp.csua.berkeley.edu/pub/corewar/ For a simulator, the best is pMARS - it runs the latest version of redcode. The pMARS home page is at: http://www.stormking.com/~koth/pmars.html It's command line driven, so you'll probably want a shell of some kind. Look for PTOOLS.ZIP, it's got PSHELL in it. I was unable to make it work for me because it likes to see the 386 version, but since I run Windows, I usually run the slightly older 286 version of PMARSV (graphical pmars). On my system the 386 version doesn't work under Windows. I wrote a batch file (DOS 6 only!) that lets me set the options and pick which binary to run. I'll post it here if anyone is interested. - Terry From: shutcs@prairie.NoDak.edu (David M Shutcs) Subject: Newbie from Heck Date: 1995/11/18 Message-ID: <48jqd5$h7@daily-planet.nodak.edu>#1/1 newsgroups: rec.games.corewar Hey Corewar people! I've been reading this group for awhile, because I've heard about Corewar from others, and I've always thought it sounded like fun. Can anyone give me any info on how to start, I can't seem to find a FAQ? Thanks in advance for nursing me along... ---Wulfgar From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: (no subject) Date: 1995/11/18 Message-ID: <48ldoo$6jv@valhalla.stormking.com>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> <48co7i$gm1@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar (Damien.Doligez@inria.fr) wrote: : In article <48aqb3$9oh@geraldo.cc.utexas.edu>, John K W writes: : >But, what about switching the Hills? Is there anywhere near the ammount : >of activity on Stormking as on Pizza? : I agree. One of the most active hills (beginner or '94 draft) should : go to Stormking to balance the load. Also, I'd like to know whether : we can send warriors to the '94 experimental hill, or is it still : broken ? As for the work, moving a hill would probably take less than an hour. As for which hill..... The beginner hill is sort of one of Thos's hills that he developed. Dunno how he'd feel. Tuc -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: (no subject) Date: 1995/11/18 Message-ID: <48ldm6$6jv@valhalla.stormking.com>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> newsgroups: rec.games.corewar sieben@imap1.asu.edu wrote: : John K W (jwilkinson@mail.utexas.edu) wrote: : : I figure if I'm annoying enough, then someone will take me seriously. :) : : So I'll keep asking this every week or so... : : Why can't Pizza and Stormking send out the current score of your warrior : : against EVERY other warrior, whenever your warrior is challenged on the Hill? : I requested a command to get detailed scores and I have a promise for it. : Nandor. What nandor forgot to mention is that I did promise it, I will deliver it, but I didn't give a date...... 8-( Tuc -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: (no subject) Date: 1995/11/18 Message-ID: <48ldkg$6jv@valhalla.stormking.com>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: : I figure if I'm annoying enough, then someone will take me seriously. :) : So I'll keep asking this every week or so... : Why can't Pizza and Stormking send out the current score of your warrior : against EVERY other warrior, whenever your warrior is challenged on the Hill? : Also, why can't one of the 94 Hills be moved over to Stormking, to even out : the server bandwidth a little... assuming this may be a problem... Maybe if the so-and-so at Stormking gets off his duff, this, and the ability to request the results whenever you want will be available. (DOH, thats me!) Sorry about this folks. I've been working on 3 different projects, and working mucho hours. I was sick for 2 weeks straight, and the doctors are not sure what it was. I am currently being poked and proded and tested to see if they can figure it out. (Incase I die, anyone interested in remotely admining the KotH???) As for balancing the hills....When Stefan, Thos and I decided to only run 1 of any type of hill, we tried to balance it. I guess Stormking got a lesser share than expected. I'd be interested in hearing NEW hill ideas. As for moving.... We'd need to talk to Thos about that. Tuc -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: Beppe Bezzi Subject: Re: Ideas for new instructions Date: 1995/11/18 Message-ID: <199511181626.RAA29565@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 08.36 18/11/95 -0500, you wrote: >: In article <486j3g$8rn@nuscc.nus.sg>, lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) writes: >: >How about allowing pre-increment and post-decrement? > >: Yes, it would be more symmetrical. But we already have 8 addressing >: modes. Do we want to add 4 and what symbols will we find for them ? > >We could use > > a ;pre > a< a> ;post > > Doing so we'll lose compatibility with current warriors. A solution may be: a ;post inc They are what we use now a< ;post dec This one is good but a> ;pre inc This one is not good, not mnemonic, not logical :-( not an easy problem to solve. >Nandor. > > -Beppe From: Randy Graham Subject: Re: Round 6 = Intelligent warriors? Date: 1995/11/18 Message-ID: <199511171338.HAA11130@hal.mathcs.rhodes.edu>#1/1 newsgroups: rec.games.corewar > Sorry for you but I'm able to recognize and kill whites whith near 30 > ties/losses :-) I'm sure _I_ cannot improve it. Well, I know how I can improve it some, but it will be harmful to my anti-human engine, I believe. As you point out later, beating just the whites isn't hard (I CAN improve my score, but at the expense of my overall engine when playing humans). What I am focusing on is an engine that will do very well against ALL opponents,, and I think I have that. > At first I liked it a lot, but when making the anti human part I discovered > that just changing a bit the strategy gave great changes in scoring. > I worked a lot to score > 2995 points average against whites, to discover > that changing anti human part of small bits gave changes of near 50 wins, > against another unmodified copy of my warrior, the sole test I can do, > without any apparent correlation. Yes, I found the same thing. Of course, like you, I only have old versions of me to test against. But, Against an old version that didn't even do right (I managed to get the strategy cycle off by one round), I did poorly with the engine that could beat the whites better. With giving up a little to the whites, I could beat the old me more regularly - enough to improve my overall score. > Being impossible to code a sequence recognizer able to work deep on > statistical basis on game history, I had to rely on a simpler engine, and > I'm not sure it's far from a random generator. :-) Mine is far from the random number generator idea I started out with. But, it is also far more effective. > I have no idea if it's able to pick an opponent sequence, but I'm rather > confident no opponent can pick mine :-) I have a high success rate picking opponent sequences in the tests I have run. But, I have to give up some early losses to gain the advantage later on. I sometimes take 50 rounds to learn the opponents scores, and give up a good bit in the time. Except for two whites, I loose no more than 2 times. But those 2 take me to 50 losses. I also tie no more than 2 times against all but three. Those three combine for almost 40 ties. I can improve the losses some, and I am working on that today. But because of how I learn, I doubt I can improve the ties. > What I'm sure is that I cannot win against a random generator, not very > difficult to implement with a long enough period. I started out with the random number generator idea. But I quickly found out that learning is FAR more productive point wise. Besides, you always start with the same random numbers at the beginning of each round. The only way to change it is to use the win/loss/tie number (last result) as part of uyour generator. > IMO there are too many random factors involved, an apparently good idea I > worked on with enthusiasm, and that's enough to congratulate with N & S, but > left me a bit unsatisfied. > The sort of feeling one has with beautiful and ice cold women ;-) I've never been with a cold, beautiful woman :) But this has been my favorite round to date. > -Beppe Randy From: Beppe Bezzi Subject: Re: Round 6 = Intelligent warriors? Date: 1995/11/18 Message-ID: <199511170917.KAA13544@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 20.26 16/11/95 -0500, Randy Graham wrote: >Wel,l I think I am finished with round 6, but I am waiting to hear the >results of my "random" number generator I used for my first round >battle. I like this round much more than the last. This way we have >time to have thoughtful, brooding warriors, each trying to outsmart >the others. Worked down to about 100 total losses and ties against >whites, and I am not sure I can improve. But, I am looking for ways >to reduce that number, as I am sure someone has beat me out on this >(someone always does). I'm near finished too, just have to polish the anti human strategy part, adding a few others recognizing engines, little job to do, having no need for compacting code and being far less than 500 lines. Sorry for you but I'm able to recognize and kill whites whith near 30 ties/losses :-) I'm sure _I_ cannot improve it. > >But I was just wondering if anyone else was enjoying this round as >much as I am? Anyone find this too easy (I sure didn't)? Anyone not >liking it. Just wondering others opinions. > At first I liked it a lot, but when making the anti human part I discovered that just changing a bit the strategy gave great changes in scoring. I worked a lot to score > 2995 points average against whites, to discover that changing anti human part of small bits gave changes of near 50 wins, against another unmodified copy of my warrior, the sole test I can do, without any apparent correlation. Being impossible to code a sequence recognizer able to work deep on statistical basis on game history, I had to rely on a simpler engine, and I'm not sure it's far from a random generator. :-) I have no idea if it's able to pick an opponent sequence, but I'm rather confident no opponent can pick mine :-) What I'm sure is that I cannot win against a random generator, not very difficult to implement with a long enough period. IMO there are too many random factors involved, an apparently good idea I worked on with enthusiasm, and that's enough to congratulate with N & S, but left me a bit unsatisfied. The sort of feeling one has with beautiful and ice cold women ;-) >Randy > > -Beppe From: Beppe Bezzi Subject: Re: Round 6 - Peeping? What an idea! Date: 1995/11/18 Message-ID: <199511170917.KAA13541@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 20.48 16/11/95 -0500, Derek Ross wrote: > >On Thu, 16 Nov 1995, Beppe Bezzi wrote: > > >The problem is the battle against ourself; as Anders pointed out it's > >impossible to score anything different from 0/0/1000 but: > > > >If I can read/write in the region 4000-7999 I can set a flag with one of my > >warriors, the first to execute, and create an asimmetry in behaviour, this > >could lead, to a result of 500/500/0 > > > >I'm not _sure_ I can do it, I didn't ever try to implement because I guessed > >it was a sort of bombing/peeping, in case it is right I have to know _now_ > > > >I couldn't agree more, Beppe. And even if it does work, it still >shouldn't be done. Why not? Well, think about what we're trying to >do here. We're playing paper, scissors, stone. > >In the playground you win that game by outguessing your opponent not >by checking for 'funny handshakes' and colluding with your opponent >if he seems to be a member of your team. The intention of this round >.. I agree at all with you Derek. I was just asking to be sure it were not possible to cheat, tweaking the spirit of the round. I don't like to do that so I just wanted to be sure none could. Now I know it's not possible to make agreements for suicide with my opponent and I won't do any strange handshake as in the spirit of the rules. > >Just my opinion of course. Same as mine > >Derek > > > >MicroSoft Network may not carry this message without license > to do so. License to carry this message requires a fee of > $1000, payable within 30 days to Derek Ross. Appearance of this > message on MicroSoft Network constitutes an agreement to terms. > Hope I can use MS Windows to reply you mail. :-) -Beppe From: Anders Ivner Subject: Re: Round 6 = Intelligent warriors? Date: 1995/11/18 Message-ID: <9511171016.AA29603@su8-6.ida.liu.se>#1/1 newsgroups: rec.games.corewar Wel,l I think I am finished with round 6, but I am waiting to hear the > results of my "random" number generator I used for my first round > battle. I like this round much more than the last. This way we have > time to have thoughtful, brooding warriors, each trying to outsmart > the others. Worked down to about 100 total losses and ties against > whites, and I am not sure I can improve. But, I am looking for ways > to reduce that number, as I am sure someone has beat me out on this > (someone always does). I have between 80-90 total losses and ties against the whites. Most from #6 (111112222233333...). I _may_ just add a special check for that one. > But I was just wondering if anyone else was enjoying this round as > much as I am? Anyone find this too easy (I sure didn't)? Anyone not > liking it. Just wondering others opinions. I'm hooked! I've spent far too much time on my program. As for easy, I've been optimizing like crazy to get my program under 1000 cycles. Although recent tests show that this may have been to no avil :-( > Randy > /Anders From: "Steven C. Morrell" Subject: Round 6 Comments Date: 1995/11/18 Message-ID: #1/1 newsgroups: rec.games.corewar Well, I just finished my silly game playing program, and out of all the white warrior battles, I lost 9 and tied 21. This was pretty fun, but only because of the white warriors. Without this initial structure, the game degenerates into pseudo-randomness. It turns out that no matter what strategy you use, the other player can match you by playing randomly. In the long run. So, I will be suprised if anyone can beat my program more than 450 times. I vote against making this a KotH hill, because without white warriors, the scores would stabilize much like the old '94x hill. Steven Morrell morrell@math.utah.edu From: Robert Macrae Subject: Handshaking in Round 6 Date: 1995/11/18 Message-ID: <48j95c$mul@soap.news.pipex.net>#1/1 newsgroups: rec.games.corewar I am concerned. Several people have voiced principled arguments against handshaking. Others, less principled (such as myself) will take the view that if not excluded by the rules, it is fair game, and the likely result is ill feeling. Might I suggest dropping the self fights from this round? Nothing of value to the contest is lost, no code needs rewriting, and everyone competes on an even basis however principled they may (have the misfortune to:) be. The only problem I see is that we lose the satisfaction of writing code which beats itself 1000/0/0, but -- hey -- there are still plenty of other guys to beat? From: Beppe Bezzi Subject: Re: summary on read/write limits [part 1] Date: 1995/11/19 Message-ID: <199511192359.AAA08783@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 08.46 19/11/95 -0500, Michael N Nonemacher wrote: >Excerpts from netnews.rec.games.corewar: 17-Nov-95 Re: summary on >read/write l.. by Robert A. Uhl@phoebe.cai >> That's another reason that I am so against Pspace; it really doesn't >> encourage intelligence; it fosters cool start-ups and that is all. >> What's the deal with that? > >I have to agree here. Part of the charm (?) of this game is that, for >any warrior, there is another warrior that will kill it consistently. >Pspace actually *discourages* warriors that do well against everything, >in favor of warriors that make "smart" decisions about which component >to use. I'm not playing corewar from long, and I beagan making good warriors of some success more or less when p-space was introduced; I like p-space, is another tool we have to develop warriors and, looking at hill results, didn't prove to be an absolute weapon. P-warrior have their weaknesses, they are susceptible of brainwashing and suffer from fast attacks due the delay in boot. Looking at present hill we have but two of them in top ten warriors and the two veterans, Armory and my Jack in the box, are both suffering a bit now. > ...Pspace will greatly cut down on warriors' ages - scanners and >imp-spirals have traditionally dominated the longevity category, but any >halfway-decent Pspace warrior will beat them easily 60% of the time. I >think Pspace changes the flavor of the game too much to continue using >it. Phq, Torch and myVamp are not p-spacers, and they are aging very well, because they are good against many kinds of different warriors, p-spacers included; your quiz is a scanner, at least in the ;strategy line, and beats heavily my Jack :-(, I hope something a little better than an halfway decent p-warrior, having been for long in the top five of the hill. :-) About the flavor of the game, I don't know how it was, I like it as is now. >...Then again, I might just be afraid some Pspacer will come along and >trash quiz... :) That's a big problem, how to trash quiz; that evil guy is giving me worries :-) > >Schitzo > > -Beppe From: Robert Macrae Subject: Re: Round 6 Comments Date: 1995/11/19 Message-ID: <48n2qe$q5t@soap.news.pipex.net>#1/1 references: newsgroups: rec.games.corewar "Steven C. Morrell" wrote: >Well, I just finished my silly game playing program, and out of all >the white warrior battles, I lost 9 and tied 21. This was pretty fun, >but only because of the white warriors. Without this initial >structure, the game degenerates into pseudo-randomness. It turns out >that no matter what strategy you use, the other player can match you >by playing randomly. There is an (partial) answer to the pseudo-random problem, which is to make the white warriors less predictable. If they each included a different, flawed random number generator (seed values could not be published, naturally) there would be an interesting problem in designing a warrior to find and exploit each weakness. Examples might include: -- Picking 50% paper, 30% scissors, 20% stone randomly. -- Never repeating the last play (but random between the other two) -- Repeating either opponents last or own last play -- A pseudo-random sequence which cycled in 50 plays All these strategies can be beaten decisively, once they are spotted, but are nontrivial to distinguish from a human player. Perhaps we might try this again, after all... From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: NSFCWT - rules for round 7 Date: 1995/11/19 Message-ID: <9511192307.AA05017@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar We hope you're happy that round 7 is again a program writing challenge. Since Stefan was not around I had to come up with a problem by myself for this round. The assignment is to write a program that calculates the K_0, K_1 groups and the positive cone of K_0 of approximately finite C* algebras. Input is given as the first 10 elements of the sequence of C* algebras and the inclusion maps. Your program should identify the remaining terms using heuristic, find the limit C* algebra and calculate the K groups. ( Hint: don't use the Pimsner-Voiculescu 6-term exact sequence. ) Since this problem might be a little harder than the previous ones, we let you can represent your data as you feel best fits. Make sure you give precise definitions how your data is represented and include test data. The score is calculated giving equal weight to 1) small size, 2) elegance of the solution, and 3) pretty formatting. As an extra challenge, your program has to withstand a gate-crashing 3-point imp-spiral. Since we don't want to evaluate this round over Thanksgiving break, submissions are due a little earlier, Tuesday, Nov. 21, 20:00. Good luck, Nandor & Stefan P.S.: Seriously though, we thought we'd give you a break and postpone round 7 until December 1. We'll post the real rules by midweek. From: Beppe Bezzi Subject: Bim bum bam - my round 6 entry. Date: 1995/11/19 Message-ID: <199511190808.JAA02704@iol-mail.iol.it> newsgroups: rec.games.corewar I finished my round 6 entry, sure not a masterpiece of redcoding; having no lenght limit (500 lines are a lot) and no real need to save space or execution time I used a very lazy coding. Sometimes I loaded from p-space a variable more than once, knowing I just did that, not to search where, in my spaghetti monster, I put it. 'Bim bum bam' is what we, in Italy, say when playing the game against another person, at the 'bam' we have to show our hands. The program quickly recognizes all whites, at the end of round 3 I'm done but for pssc6 (I get at round 5) and 7,8,9 (I get them at round 501) Once I recognize a warrior I set a flag and I expect all wins from then on, if I don't I look at the round counter, I can not win at r 5 against pssc6 and at round 501 against pssc 7-8-9, in case I switch to right strategy; should I lose or tie in a wrong round I recognize a human opponent activating the anti human engine. The anti human engine is a set of simple strategies I rotate according to results of previous rounds; If the strategy did well I go on, if not I change to the next; I have 8 of them with a 12 places rotation. Nothing more to say, here is the warrior for you to play against; please no comments on redcoding, I know I can do better :-) May be some comment in in Italian, some missing and some wrong, I had not checked them, they are what I wrote while coding. -Beppe ;----------- ;redcode-94 ;name Bim bum bam ;author Beppe Bezzi ;Warrior that plays the game of Paper-Scissors-Stone in NSFCWT round 5 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;strategy 'Bim bum bam' if what we say before showing hands when playing the game ;strategy Catches quickly and kills all whites giving but 1 win & 1 tie on average ;strategy Use an adaptive succession of engines to try foul and beat humans ;strategy using a -stay with good result- tactic. ;strategy Not even tried handshaking against myself, 1000 ties ;strategy No brainwashing this time :-) ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ;---BEGIN-VARIABLE-PART----------------------------------------------------- ;PIN 1112 ;Don't change any code outside this area. RES equ #0 ;last result ;ENGINEs anti w w ;1-e1 (1,9) 2-e2 (2,8) 3-e3 (3,7) 4-e4 (4) 5-e5 (5) 6-e6 7-e10 (10) 8-eh (human) ;P-space equ STR equ #1 ;last strategy YRSTR equ #2 ;last opponent move COUNT equ #3 ;round counter LAST equ #4 ;previous round result LENMOV equ #5 ;last enemy move HSTR equ #6 ;anti human strategy ENGINE equ #7 ;anti ww engine to use HRND equ #8 ;anti human str. round to play before change HSCORE equ #9 ;score with ahstr hrounds equ 4 ;rounds to play any ahstr hmin equ (hrounds*3/2) ;minimum score allowed ;-------------- check dat 0,0 start result ldp RES, check strat ldp STR, #0 ;last rnd strategy ldp.a ENGINE, eng ;detected enemy ? count ldp.a COUNT, go1 add.a #1, go1 ;update round counter jmn.a eng, eng ;go for selected strategy sne.ab #-1, check ;first round jmp first ;yes ;----non primo round rcnt mov.ab go1, #0 ;round counter r1 seq.ab #2, rcnt ;round 1 results jmp r2 mov.ba check, check1 check1 jmp @0, loss1 dat 0, win1 dat 0, tie1 r2 seq.ab #3, rcnt ;round 2 results jmp r3 mov.ba check, check2 check2 jmp @0, loss2 dat 0, win2 dat 0, tie2 loss1 ;played 1 loss, opponent played 2, ww 2-5-8-10 human ; stp #1, #102 ;next 2 -> -win ; stp #1, #105 ;next 3 -> -tie ; stp #1, #108 ;next 2 -> -win ; stp #1, #110 ;next 1 -> -loss mov.a #3, go0 ;play 3 jmp go0 win1 ;played 1 win, opp played 3, ww 3-4-7 human ; stp #1, #103 ;next 3 -> -tie ; stp #1, #104 ;next 2 -> -win ; stp #1, #107 ;next 3 -> -tie mov.a #3, go0 jmp go0 ; tie1 ;played 1 tie, opp played 1, ww 1-6-9 ; stp #1, #101 ;next 1 -> -win ; stp #1, #106 ;next 1 -> -win ; stp #1, #109 ;next 1 -> -win ; stp #1, HUMAN mov.a #2, go0 jmp go0 ; loss2 ;loss in rnd 2. stp #6, ENGINE ;if white is ww 10 mov.a #1, go0 ;play 1 jmp go0 tie2 ;tie in rnd 2, ww 5 3 7 llast ldp LAST, #0 ;previous result jmz set5, llast set37 stp #3, ENGINE ;ww 3 or 7 mov.a #1, go0 ;beat him jmp go0 set5 stp #5, ENGINE ;ww 5 mov.a #2, go0 ;beat him jmp go0 win2 ;win in rnd 2, ww 2-8 4 1-6-9 ; llast1 ldp LAST, #0 ;previous result jmz set2, llast1 ;loss in first djn set1, llast1 ;tie in first set4 stp #4, ENGINE ;win in first mov.a #2, go0 jmp go0 set2 stp #2, ENGINE mov.a #3, go0 jmp go0 ; set1 stp #1, ENGINE mov.a #2, go0 jmp go0 r3 eng jmp @0, eh ;never jumps here dat 0, e1 ;1 dat 0, e2 ;2 dat 0, e3 ;3 dat 0, e4 ;4 dat 0, e5 ;5 dat 0, e6 ;6 dat 0, e10 ;7 dat 0, eh ;8 ;--- Strategy engines e1 seq.ab #1, check ;we won, all right jmp wrong1 ;we lost :-( what's happened e1a mov.a #2, go0 jmp go0 ; wrong1 sne.a #6, go1 ;we lost round 5 jmp set6 ;w w 6 sne.a #502, go1 ;we lost round 501 jmp set9 ;ww 9 jmp seth e2 seq.ab #1, check ;we won, all right jmp wrong2 ;we lost :-( what's happened e2a mov.a #3, go0 jmp go0 wrong2 sne.a #502, go1 ;we lost round 501 jmp set8 ;ww 8 jmp seth e3 seq.ab #1, check ;we won, all right jmp wrong3 ;we lost :-( what's happened e3a mov.a #1, go0 jmp go0 wrong3 sne.a #502, go1 ;we lost round 501 jmp set7 ;ww 7 jmp seth ; set7 stp #1, ENGINE ;continue as if it were ww1 jmp e1a set8 stp #3, ENGINE jmp e3a set9 stp #3, ENGINE jmp e3a set6 stp #6, ENGINE mov.a #3, go0 jmp go0 ; e4 ;win same loss prec. -1 seq.ab #1, check ;we won, all right jmp wrong4 ;we lost :-( what's happened e4a mov.b strat, #0 add.ab #1, e4a ;round+1 mod.ab #3, e4a add.ab #1, e4a mov.ba e4a, go0 jmp go0 wrong4 e5 ;231231... seq.ab #1, check ;we won, all right jmp wrong5 ;we lost :-( what's happened e5a mov.ab go1, #0 add.ab #1, e5a mod.ab #3, e5a add.ab #1, e5a slt.b e5a, #4 mod #3, e5a mov.ba e5a, go0 jmp go0 ; wrong5 seq.a #5, go1 ;we lost round 5 jmp seth ;human jmp set10 ;ww0 ;-break e6 ;1111222223333311111... seq.ab #1, check ;we won, all right jmp wrong6 ;we lost :-( what's happened e6a mov.ab go1, #0 div.ab #5, e6a mod.ab #3, e6a add.ab #2, e6a ;-break slt.b e6a, #4 mod #3, e6a e6b mov.ba e6a, go0 jmp go0 wrong6 jmp seth e10 seq.ab #1, check ;we won, all right jmp wrong10 ;we lost :-( what's happened e10a mov.a #3, go0 jmp go0 ;-break set10 stp #7, ENGINE jmp e10a wrong10 jmp seth seth stp #8, ENGINE ;-break eh ;human coded opponent ;calculate last enemy move hlst ldp STR, #0 ;my last move hres mov.ba check, 1 ;result jmp @0, hloss dat 0, hwin dat 0, htie htie mov.b hlst, hmov ;enemy played my move = hlst jmp hmovfix hwin add.ab #3, hlst ;enemy played my move -1 sub #1, hlst mov.b hlst, hmov jmp hmovfix hloss ;enemy played my move +1 add #1, hlst mov.b hlst, hmov jmp hmovfix hmov nop 0, 0 ;.b holds last enemy move hmovfix mod #3, hmov jmn.b strsel, hmov add #3, hmov strsel ;select strategy hstr ldp HSTR, #0 ;load anti human strategy hrnd ldp HRND, #0 ;load round to play with it hscore ldp HSCORE, #0 ;load score with that strategy jmz.b change, hrnd ;some more rounds to play with it sub.ab #1, hrnd ;yes update counter stp.b hrnd, HRND mov.ba check, uphsc ;update score uphsc jmp @0, hloss1 dat 0, hwin1 dat 0, htie1 hwin1 add #2, upsch1 htie1 add #1, upsch1 hloss1 upsch1 add.b hscore, #0 stp.b upsch1, HSCORE mov.ba hstr, hselect ;-break hselect jmp @0, hs0 ;win tie same / loss next dat 0, hs6 ;beat last opp. dat 0, hs8 ;lose w/ last opp. dat 0, hs2 ;play 2 dat 0, hs3 ;win same / loss tie next dat 0, hs4 ;reverse anyway order 321 dat 0, hs5 ;stay with tie or win dat 0, hs7 ;play last opp. dat 0, hs6 ;beat last opp. dat 0, hs1 ;paso doble dat 0, hs7 ;play last opp. dat 0, hs8 ;lose w/ last opp. change slt #hmin, hscore ;check score (result in hscore.b) jmp nexth ;bad :-( jmp sameh ;good :-) nexth add #1, hstr mod #11, hstr ;**** NUMBER OF HSTR HERE **** stp.b hstr, HSTR sameh stp.ab #hrounds,HRND ;reset rounds to max stp.ab #0, HSCORE ;reset score mov.ba hstr, hselect jmp hselect hs0 ;win tie same / loss next ldp STR, #0 ;strat. hs0a mov.b check, #0 ;result jmn.b hs0z, hs0a add #2, hs0 mod #3, hs0 add.ab #1, hs0 hs0z mov.ba hs0, go0 jmp go0 hs1 ;paso doble ldp COUNT, #0 div #2, hs1 mod #3, hs1 add #1, hs1 mov.ba hs1, go0 jmp go0 hs2 mov.a #2, go0 jmp go0 hs3 ;win same / loss tie next ldp STR, #0 ;strat. hs3a mov.b check, #0 ;result sub #1, hs3a jmz hs3z, hs3a add #2, hs3 mod #3, hs3 add.ab #1, hs3 hs3z mov.ba hs3, go0 jmp go0 hs4 ldp COUNT, #0 hs4a sub.b hs4, #1000 mod #3, hs4a add #1, hs4a mov.ba hs4a, go0 jmp go0 hs5 ;stay with tie or win ldp STR, #0 hs5a mov.b check, #0 jmn hs5z, hs5a add #1, hs5 mod #3, hs5 jmn.b hs5z, hs5 add #3, hs5 hs5z mov.ba hs5, go0 jmp go0 hs6 ;beat last opponent's move mov.b hmov, #0 mod.ab #3, hs6 add.ab #1, hs6 mov.ba hs6, go0 jmp go0 hs7 ;play last opponent's move mov.ba hmov, go0 jmp go0 hs8 ;lose against last opponent's move mov.b hmov, #0 add.ab #1, hs7 mod.ab #3, hs7 add.ab #1, hs7 mov.ba hs7, go0 jmp go0 ;--fist round --- first mov.a #1, go0 ;to beat all those playing 3 against whites :-) ;---save data go0 nop 0, 0 mod.a #3, go0 ;normalize result jmn.a go01, go0 add.a #3, go0 go01 mov.a go0, go go stp #0, STR ;save used str go1 stp #0, COUNT ;update round counter stp.b check, LAST mov.ab go, my_hand ;---END-VARIABLE PART------------------------------------------------------- ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied From: John K W Subject: Re: Round 6 = Intelligent warriors? Date: 1995/11/19 Message-ID: <48ocgb$lh3@geraldo.cc.utexas.edu>#1/1 references: <199511170917.KAA13544@iol-mail.iol.it> newsgroups: rec.games.corewar Beppe Bezzi wrote: >IMO there are too many random factors involved, an apparently good idea I >worked on with enthusiasm, and that's enough to congratulate with N & S, but >left me a bit unsatisfied. >The sort of feeling one has with beautiful and ice cold women ;-) Although I spent very little time on this round, (Not that I wouldn't have LIKED to spend more. :-) ) I would say that the biggest problem is that it's not realistic. Stone doesn't ALWAYS beat paper. Etc, etc. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: koth settings Date: 1995/11/19 Message-ID: <48oc8v$lh3@geraldo.cc.utexas.edu>#1/1 references: <48elo2$91v@nuscc.nus.sg> newsgroups: rec.games.corewar lohwengk@iscs.nus.sg (Loh Weng Keong Calvin) wrote: >Are the distances between warriors on the hill varied between rounds? >TIA. I'm not sure what you want to know. If you're asking what I think you are, then yes. The distances MUST be varied, or the results of the battle would always be the same. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Kurt Franke Subject: ;kill teamwork? killed all my warriors Date: 1995/11/19 Message-ID: <48o92g$dto@larry.rice.edu>#1/1 newsgroups: rec.games.corewar I had these two lines in a warrior: .. ;name teamwork? ;kill teamwork? .. this seems to have killed all my warriors on beginner hill. Is there something funny about the question mark? tia, Kurt From: lewin@netcom.com (Karl Lewin) Subject: Round 6 Entry Date: 1995/11/19 Message-ID: newsgroups: rec.games.corewar Since the deadline for round 6 has passed (I hope)........ Here is my round six entry. I didn't know the final decision on the handshake issure so I sent one that had the handshake code and one that didn't. Included below is just the non handshaker. I don't know how this guy will do against "human" opponents. Have fun and go easy on this guy. :) ;redcode-94 ;name The Thinker (w/o handshake) ;strategy Think about what you want to do then do it. ;strategy Actually, keep track of what opponent does next ;strategy after each situation (ie Me-Rock/Him-Paper) and ;strategy choose the strategy that beats what opponent does ;strategy most often. ;strategy I hope it is good enough. Still having a few problems ;strategy with white #6, but haven't had time to try anything else. ;author Karl Lewin ;contact lewin@netcom.com ;NSFCWT Entry for Round 6 ;Needs to be paired with one opponent exactly half the coresize apart (-d 4000) ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART---------------------------------------------------- WIN EQU #1 LOSS EQU #0 TIE EQU #2 P_off EQU #-3 S_off EQU #-2 R_off EQU #-1 ROCK EQU #3 _RES EQU #0 _RND EQU #5 _MYLST1 EQU #1 _MYLST2 EQU #2 _OPLST1 EQU #3 _OPLST2 EQU #4 PP_P_S EQU #111 PP_S_R EQU #112 PP_R_P EQU #113 PS_P_S EQU #121 PS_S_R EQU #122 PS_R_P EQU #123 PR_P_S EQU #131 PR_S_R EQU #132 PR_R_P EQU #133 SP_P_S EQU #211 SP_S_R EQU #212 SP_R_P EQU #213 SS_P_S EQU #221 SS_S_R EQU #222 SS_R_P EQU #223 SR_P_S EQU #231 SR_S_R EQU #232 SR_R_P EQU #233 RP_P_S EQU #311 RP_S_R EQU #312 RP_R_P EQU #313 RS_P_S EQU #321 RS_S_R EQU #322 RS_R_P EQU #323 RR_P_S EQU #331 RR_S_R EQU #332 RR_R_P EQU #333 start round ldp.ab _RND, round nop >round stp.b round, _RND wlt ldp.b _RES, wlt seq.ab #-1, wlt jmp dtrmopp for 1 stp.ab #1, PP_S_R stp.ab #1, PS_S_R stp.ab #1, PR_S_R stp.ab #1, SP_R_P stp.ab #1, SS_R_P stp.ab #1, SR_R_P stp.ab #1, RP_P_S stp.ab #1, RS_P_S stp.ab #1, RR_P_S rof mov.a ROCK, choice jmp store dtrmopp mylst1 ldp.ab _MYLST1,mylst1 mylst2 ldp.ab _MYLST2,mylst2 oplst2 ldp.ab _OPLST2,oplst2 oplst1 nop 0, 0 sne.ab WIN, wlt jmp win sne.ab TIE, wlt jmp tie loss sne.ab ROCK, mylst1 jmp op_is_P sne.ab PAPER, mylst1 jmp op_is_S sne.ab SCISSORS,mylst1 jmp op_is_R win sne.ab ROCK, mylst1 jmp op_is_S sne.ab PAPER, mylst1 jmp op_is_R sne.ab SCISSORS,mylst1 jmp op_is_P tie sne.ab ROCK, mylst1 jmp op_is_R sne.ab PAPER, mylst1 jmp op_is_P sne.ab SCISSORS,mylst1 jmp op_is_S op_is_R mov ROCK, oplst1 jmp prjct op_is_P mov PAPER, oplst1 jmp prjct op_is_S mov SCISSORS,oplst1 jmp prjct table val1 dat 0, 0 val2 dat 0, 0 val3 dat 0, 0 comploc dat val3, val2 prjct slt.ab #2, round jmp hunds1 hunds0 mul.b mylst2, #100 tens0 mul.b oplst2, #10 ones0 add.b oplst1, ones0 add.b hunds0, ones0 add.b tens0, ones0 wght ldp.b ones0, wght nop >wght stp.b wght, ones0 hunds1 mul.b mylst1, #100 tens1 mul.b oplst1, #10 add.b hunds1, tens1 nop >tens1 P ldp tens1, val1 nop >tens1 S ldp tens1, val2 nop >tens1 R ldp tens1, val3 check slt.b @comploc,*comploc mov.ba comploc,comploc seq.i @comploc,table-1 jmp check, #1/1 newsgroups: rec.games.corewar Calvin Loh wrote: >Downloaded source for pmars. Tried to compile it on my UNIX account. >Failed because it is not ANSI C compliant. Odd, even the strictest compilers I've encountered emit but a couple of trivial warnings with the pmars code. It is true though that we sacrificed complete ANSI-C compliance so pmars would compile with older K&R C compilers (like SUN cc). Give details on machine/OS and C compiler, as well as a listing of all generated errors/warnings and we'll look into this. Email please :-) -Stefan From: sieben@IMAP1.ASU.EDU Subject: NSFCWT Round 6 results Date: 1995/11/20 Message-ID: newsgroups: rec.games.corewar Round 6 is finally over. There was some controversy over self fights and handshakes. At the end this didn't make much of a difference. The round was run twice. First without self fights and then with self fights. The results are almost the same except in one case. Karl Lewin sent in two versions of his warrior (The Thinker). One version with handshakes and another without handshakes. I included both of these versions in both runs. Special thanks for Karl Lewin for Test warrior. It was a valuable tool to find out about buggy submissions. Test warrior was run also in the tournament, and it gained the first place as it was supposed to. Notice that in the self fight run Test warrior didn't win 100 % . Since the only difference in the results of the two runs is the order of Thinker and Winner, we decided to call it a draw between these two submissions. Here is the result of the no self fights run: Elapsed time: 833 seconds (00:13:53) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Test for Timeouts Karl Lewin 100 0 0 75000 2 Blizzard Anders Ivner 71 18 10 56123 3 Psst Robert Macrae 67 21 12 53019 4 Round 6 Kline P.Kline 64 20 16 51936 5 nt entry #6 M R Bremer 64 21 16 51529 6 Winner Steven Morrell 63 21 16 51183 7 The Thinker (w/Handshak Karl Lewin 62 23 15 50479 8 The Thinker (w/o handsh Karl Lewin 62 23 15 50479 9 Machiavelli Maurizio Vittuari 62 23 15 50356 10 Maverick Randy Graham 63 25 12 50142 11 Miss Playful Derek Ross 61 22 16 50109 12 ?{whateverCT#$~S|[]~+'i Paulsson 59 27 14 47404 13 PlinySwitch - 2990 G. Eadon 58 27 15 47140 14 Bim bum bam Beppe Bezzi 57 30 13 46149 15 WhileAway JKW 54 31 16 44161 16 Paper-Scissors-Stone #4 Nandor Sieben & Stefan 35 58 7 27887 17 Paper-Scissors-Stone #6 Nandor Sieben & Stefan 17 68 15 16168 18 Paper-Scissors-Stone #7 Nandor Sieben & Stefan 19 74 7 16097 19 Paper-Scissors-Stone #3 Nandor Sieben & Stefan 17 74 9 15006 20 Paranoid Calvin Loh 16 73 10 14829 21 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 17 76 7 14507 22 Paper-Scissors-Stone #8 Nandor Sieben & Stefan 15 74 11 14084 23 Paper-Scissors-Stone #5 Nandor Sieben & Stefan 13 70 18 13834 24 Paper-Scissors-Stone #9 Nandor Sieben & Stefan 15 76 9 13589 25 Paper-Scissors-Stone #2 Nandor Sieben & Stefan 15 76 9 13386 26 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 1 94 4 2096 These is the result of the self fight run: Elapsed time: 942 seconds (00:15:42) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Test for Timeouts Karl Lewin 93 0 7 77000 2 Blizzard Anders Ivner 66 17 17 58123 3 Psst Robert Macrae 65 23 11 56019 4 Round 6 Kline P.Kline 59 19 22 53936 5 nt entry #6 M R Bremer 59 19 22 53529 6 The Thinker (w/Handshak Karl Lewin 61 25 14 53477 7 Winner Steven Morrell 58 20 22 53183 8 The Thinker (w/o handsh Karl Lewin 58 21 21 52479 9 Machiavelli Maurizio Vittuari 57 21 22 52356 10 Maverick Randy Graham 58 23 19 52142 11 Miss Playful Derek Ross 57 21 22 52109 12 ?{whateverCT#$~S|[]~+'i Paulsson 54 25 20 49404 13 PlinySwitch - 2990 G. Eadon 54 25 21 49140 14 Bim bum bam Beppe Bezzi 53 27 20 48149 15 WhileAway JKW 50 28 22 46161 16 Paper-Scissors-Stone #4 Nandor Sieben & Stefan 32 54 14 29887 17 Paper-Scissors-Stone #6 Nandor Sieben & Stefan 15 63 21 18168 18 Paper-Scissors-Stone #7 Nandor Sieben & Stefan 18 68 14 18097 19 Paper-Scissors-Stone #3 Nandor Sieben & Stefan 16 68 16 17006 20 Paranoid Calvin Loh 15 68 17 16829 21 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 16 70 14 16507 22 Paper-Scissors-Stone #8 Nandor Sieben & Stefan 14 68 18 16084 23 Paper-Scissors-Stone #5 Nandor Sieben & Stefan 12 65 24 15834 24 Paper-Scissors-Stone #9 Nandor Sieben & Stefan 14 70 16 15589 25 Paper-Scissors-Stone #2 Nandor Sieben & Stefan 14 71 16 15386 26 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 1 87 12 4096 This is the rank after round 6: Name 1 2 3 4 5 6 total Steven Morrell 5 10 9 13 14 10 61 P.Kline 7.5 9 7 11 11 12 57.5 Paulsson 7.5 11 11 9 2 5 45.5 Anders Ivner 5.5 8 4 0 10 14 41.5 Beppe Bezzi 7 7 13 2 8 3 40 M R Bremer 7 4 3.6 5 7 11 37.6 Maurizio Vittuari 6.5 5 6 3 9 8 37.5 John K. Wilkinson 4 6 12 0 13 2 37 Robert Macrae 0 0 0 12 12 13 37 Karl Lewin 0 0 10 4 6 10 30 Randy Graham 0 0 8 10 4 7 29 Derek Ross 3.5 3 3.3 7 3 6 25.8 G. Eadon 1.5 2 5 6 1 4 19.5 Kurt Franke 0 0 0 8 0 0 8 Michael Constant 0 0 0 0 5 0 5 Anders Scholl 0 1 2 1 0 0 4 John Lewis 0 0 3 0 0 0 3 Calvin Loh 0 0 1 0 0 1 2 Detailed results and the submissions will be sent in a separate file. It wasn't clear for a while if handshake is possible. So looking at the submissions will be very interesting. We let Corewarrior discuss this topic in depth. It is clear from game theory that assuming an optimal opponent the best strategy is to play randomly. If the opponent does not play using optimal strategy then we can do much better. Of course trying to outguess the opponent makes our strategy different from the optimal strategy. There was some concern about mts. The Borland C compiled version of mts has difficulty handling big scores. This didn't caused problem in this round since the djgpp compiled version was used which can handle huge scores. Thanks for playing, Nandor & Stefan. From: Loh Weng Keong Calvin Subject: Re: NSFCWT - rules for round 7 Date: 1995/11/20 Message-ID: #1/1 newsgroups: rec.games.corewar On Sun, 19 Nov 1995, Stefan Strack wrote: > We hope you're happy that round 7 is again a program writing challenge. Since > Stefan was not around I had to come up with a problem by myself for this round. > The assignment is to write a program that calculates the K_0, K_1 groups and > the positive cone of K_0 of approximately finite C* algebras. Input is > given as the first 10 elements of the sequence of C* algebras and the > inclusion maps. Your program should identify the remaining terms using > heuristic, find the limit C* algebra and calculate the K groups. ( Hint: > don't use the Pimsner-Voiculescu 6-term exact sequence. ) Since this Have to go home for my holidays (no internet access :() In any case, can someone translate the above into English :) ? Calvin Loh From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Round 6 = Intelligent warriors? Date: 1995/11/20 Message-ID: <1995Nov20.161215.3065@rhodes>#1/1 references: <9511171016.AA29603@su8-6.ida.liu.se> newsgroups: rec.games.corewar Anders Ivner (d91andiv@und.ida.liu.se) wrote: : > the others. Worked down to about 100 total losses and ties against : > whites, and I am not sure I can improve. But, I am looking for ways : > to reduce that number, as I am sure someone has beat me out on this : I have between 80-90 total losses and ties against the whites. Most from : #6 (111112222233333...). I _may_ just add a special check for that one. Yes, #6 was tricky. My way around it was when determining what strategy my opponent was most likely to use, I first checked if he had run a pattern of a long string of one thing, then switched to another. If he had, I checked the current run to see if he was at the same point in the string and ready to switch. If he was, then I switched, trying to anticipate and beat him. : > But I was just wondering if anyone else was enjoying this round as : > much as I am? Anyone find this too easy (I sure didn't)? Anyone not : > liking it. Just wondering others opinions. : I'm hooked! I've spent far too much time on my program. As for easy, : I've been optimizing like crazy to get my program under 1000 cycles. : Although recent tests show that this may have been to no avil :-( I spent too much time also. I didn't have any problem beating the 1000 cycle limit, but then my approach was pretty simplistic. It did allow me to do well against whites very quickly, but in truth I doubt I will do well against humans. At the time I submitted I thought it would be a good idea, but later thinking made me realize how simple mine was, and how easy it would be to beat. I got down to 10 losses and 19 wins (or maybe 11 and 18, I forget). I could have even gotten a little better by testing my default behaviors, but I decided I had other more important things to do (although I later realized that nothing is more important than winning:). I would post it, but I believe Nandor said all of them will be posted, so no need to send mine out now. Besides, I think I commented it well enough that any further explanation on my part would be redundant (And needlessly repeating the same thing...). Instead of worrying about this one anymore (but I still would like this and the sorter a regular hill), I am going to work on something for the hill again. I have an idea for a quick-scanner that might just get on the hill (but qscanners and decoys are the bane of PS+ existence, so I might gain with 1 and loose with another). : > Randy : > : /Anders Randy From: Derek Ross Subject: Re: round 6 Date: 1995/11/20 Message-ID: <323@arbroath.win-uk.net>#1/1 newsgroups: rec.games.corewar > >;strategy Confuse opponent by writing unreadable, uncommented code >;strategy with nonsense labels :-) > >This strategy seems to apply to a lot of the programs from round 6. >Please post an article explaining what your programs do. > >I will not mention any names, but the authors of these warriors should >be ashamed :-) > >?whatever? >machiavelli >plinyswitch >the thinker >winner > >This program is better, but I can't figure out its overall strategy: > >miss playful > >/Anders > Errr... , Sorry Mr Ivner, sir... , Ehm... it won't happen again, sir... ;name Miss Playful ;strategy The idea here is to use the UNKNOWN/WIN/LOSS/TIE results ;strategy from the previous n rounds to index an n-dimensional table of ;strategy best moves located in Pspace. UNKNOWN is used to represent the ;startegy result when a particular previous round does not exist or when I ;strategy don't care what the result is. As there isn't a lot of Pspace to ;strategy play with, the nth dimension of the table is packed into a single ;strategy Pspace location. This allows me to use up to 5 previous rounds. ;strategy ;strategy The array contains the predicted 'best' moves for previously ;strategy met situations. The moves are coded as follows: ;strategy ;strategy 0 - don't know, haven't met this situation ;strategy 1 - play PAPER ;strategy 2 - play SCISSORS ;strategy 3 - play STONE ;strategy ;strategy The algorithm proceeds in two possible phases. The first, ;strategy learning, phase is only executed if I lost or tied. ;strategy The second, predictive, phase is always executed. ;strategy ;strategy The learning strategy is basically to cycle through the possible ;strategy moves in the hope of finding a winner. The previous results are ;startegy used to look up the previous predicted best move and this is cycled down ;strategy one. This is complicated slightly because I also wanted to update ;strategy partial cases where only n-1, n-2, etc. previous rounds are used. ;strategy The predictive phase may want to use these partial cases if it can't ;strategy find the current full situation in a future round. ;strategy ;strategy The predictive phase adds the last result to the previous n results and ;strategy drops the oldest result. This gives the current last n results. It ;strategy then looks up the table for the move to play. If 'don't know' is found ;strategy then the phase attempts to repeat the table lookup using the previous ;strategy n-1 results then n-2 results, etc. until it either finds a move or ;strategy is forced to play a random one. If a random move *is* played then that ;strategy move is recorded in the table. Well that's it. You can add the above to the Miss Playful file. I feel that I did okay considering that there was no special code to deal with the white warriors. Although they were my basic test material of course. With hindsight I should have spent more time on a special case to deal with white #6 and less time fiddling with variations on the adaptive engine. But on the other hand that's the part I enjoyed coding so I don't feel too bad about it. (just a little bit :) As a matter of interest I have written what must be one of the world's shortest 'conversational' programs based on a technique similar to the above. And unlike Eliza etc, it will learn to 'converse' with you in your own language, whatever that may be. If anyone's interested I'll send them a copy but be warned - it's written in BASIC (I wrote it in 1984, that's my excuse:). Used to be a 20 liner although I think it's now about 60 lines after I added some *extremely* rudimentary file handling. Cheers Derek Then let us pray that come it may (as come it will for a' that) That Sense and Worth ower a' the Earth shall bear the gree and a' that For a' that and a' that, it's comin' yet for a' that That man tae man the world ower shall brithers be for a' that From: Robert Macrae Subject: Re: NSFCWT Round 6 results Date: 1995/11/20 Message-ID: <48qv3d$1qh@soap.news.pipex.net>#1/1 references: <1995Nov20.103150@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu wrote: >Ooops. Forgot to include strategy lines in my round 6 entry. Basically >this program keeps a 5-dimension array containing the result of 4 opponent >moves and my subsequent move. The result is scored on a base of 2000 for >a tie, adding 3 for a win and -3 for a loss. Then for each round looks at >the opponent's last 4 plays and selects 1/2/3 depending on which has the >better score in the table. Randomness occurs when the best score is 2000 >- a tie (or unknown), in which case a long-period random table is used >to select my play. > >That is the basic strategy. I tweaked it by slowly degrading the score >by 1 (towards 2000) each time it is repeated so as not to overcommit in >case the opponent memorizes MY responses. And by not selecting a known >losing strategy in the random routine. > >Also, to accomodate White #6, which others seemed to have the most trouble >with as well, I added code to monitor repeating tie events. If ties >recur at fixed intervals I bump up my selection on those intervals >to seek a win. Works against 6, don't know about the other submissions. [Test Test Test Test [Very embarasing start to a message; see below] [My earlier post was truncated; ask the Gods of netscape why...] [[Text inserted here for debugging. Please ignore [after reading the bottom bracketted section] ]] >I don't think I would have attempted Blizzard-logic given the short time >frame and 1000-cycle limit. Great job Anders! Maybe given this >two-week layover you could explain the algorithm. I would like to see the code of Blizzard too, but have yet to master uudecode. Could you post it, perhaps with analysis, Anders? [This gets weirder. My newsreader has refused to post since I have "More included text than new" or somesuch. I guess I'll have to drivel on... Its done it again, and now I _know_ I've written more. Can't it tell me from Paul Klein? I may hit identity problems...] From: Robert Macrae Subject: Re: NSFCWT Round 6 results Date: 1995/11/20 Message-ID: <48qj9u$qtv@soap.news.pipex.net>#1/1 references: <1995Nov20.103150@acad.drake.edu> newsgroups: rec.games.corewar >A little testing shows I beat everyone except Blizzard (just not as well >as PSST :-) If I nudge ahead of you a fourth time, I'll start calling myself Klein++ :-) > I sure did not expect to see anything as advanced as Blizzard in the tourney. From: John K W Subject: Re: NSFCWT Round 6 results Date: 1995/11/20 Message-ID: <48r21u$ne2@geraldo.cc.utexas.edu>#1/1 references: newsgroups: rec.games.corewar sieben@IMAP1.ASU.EDU wrote: > 15 WhileAway JKW 54 31 16 44161 I would just like to take a moment to complain like a poor loser, and say that code size and excecution time should've been factored in. My warrior was actually practicable... if not all that smart. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: pk6811s@acad.drake.edu Subject: Re: NSFCWT Round 6 results Date: 1995/11/20 Message-ID: <1995Nov20.103150@acad.drake.edu>#1/1 references: newsgroups: rec.games.corewar Ooops. Forgot to include strategy lines in my round 6 entry. Basically this program keeps a 5-dimension array containing the result of 4 opponent moves and my subsequent move. The result is scored on a base of 2000 for a tie, adding 3 for a win and -3 for a loss. Then for each round looks at the opponent's last 4 plays and selects 1/2/3 depending on which has the better score in the table. Randomness occurs when the best score is 2000 - a tie (or unknown), in which case a long-period random table is used to select my play. That is the basic strategy. I tweaked it by slowly degrading the score by 1 (towards 2000) each time it is repeated so as not to overcommit in case the opponent memorizes MY responses. And by not selecting a known losing strategy in the random routine. Also, to accomodate White #6, which others seemed to have the most trouble with as well, I added code to monitor repeating tie events. If ties recur at fixed intervals I bump up my selection on those intervals to seek a win. Works against 6, don't know about the other submissions. A little testing shows I beat everyone except Blizzard (just not as well as PSST :-) I sure did not expect to see anything as advanced as Blizzard in the tourney. While my program memorizes sequences of 4 opponent plays he is capable of memorizing much longer sequences and beating anybody using short-period logic. My algorithm is space-wasteful, but his only allocates space if a particular sequence occurs. I don't think I would have attempted Blizzard-logic given the short time frame and 1000-cycle limit. Great job Anders! Maybe given this two-week layover you could explain the algorithm. Or maybe you could show us how to find r0 and the cone of confusion per Nandor's outline :-) Paul Kline pk6811s@acad.drake.edu From: tuc@mars.superlink.net (Scott J. Ellentuch) Subject: Re: NSFCWT - rules for round 7 Date: 1995/11/20 Message-ID: <48q1um$did@earth.superlink.net>#1/1 references: newsgroups: rec.games.corewar Loh Weng Keong Calvin (lohwengk@iscs.nus.sg) wrote: : On Sun, 19 Nov 1995, Stefan Strack wrote: : > We hope you're happy that round 7 is again a program writing challenge. Since : > Stefan was not around I had to come up with a problem by myself for this round. : > The assignment is to write a program that calculates the K_0, K_1 groups and : > the positive cone of K_0 of approximately finite C* algebras. Input is : > given as the first 10 elements of the sequence of C* algebras and the : > inclusion maps. Your program should identify the remaining terms using : > heuristic, find the limit C* algebra and calculate the K groups. ( Hint: : > don't use the Pimsner-Voiculescu 6-term exact sequence. ) Since this : Have to go home for my holidays (no internet access :() In any case, can : someone translate the above into English :) ? : Calvin Loh Sure : Calvin, I'm playing an April Fools joke on the r.g.c group in November. (If you check the rest of the message, it basically says we need to wait for Stefan before we can continue). Nandor had me pretty lost at it too! Tuc From: jmwilson@access5.digex.net (John Wilson) Subject: A few Q's Date: 1995/11/20 Message-ID: <48qv0m$6gi@news4.digex.net>#1/1 newsgroups: rec.games.corewar Hello. I am somewhat interested in both Corewar and another program called PC-Robots. As I understand, Corewar is modeled against ASM code and PC-Robots against C, C++, Basic, Pascal, etc. Here is the question. I have virtually no ASM skills, only C. How difficult would it be to learn Corewar? It seems that most of the discussion here centers on Corewar, so I would assume that it is the most popular of the two. If I did attempt to learn it, is this the correct place to post questions about coding and such? Thanks for your help, -- John Wilson in NYC * jmwilson@access.digex.net http://www.access.digex.net/~jmwilson/ From: Beppe Bezzi Subject: Re: NSFCWT Round 6 results Date: 1995/11/20 Message-ID: <199511202147.WAA21800@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 00.35 20/11/95 -0700, Nandor Sieben wrote: >Round 6 is finally over. .... [results omitted] > >Detailed results and the submissions will be sent in a separate file. It wasn't >clear for a while if handshake is possible. So looking at the submissions >will be very interesting. We let Corewarrior discuss this topic in depth. > I gave but a quick look at results and the only thing I'm sure is that I submitted a very very bad (euphemism :-) warrior :-(((( so I'm not the most qualified to speak about winning strategies. What makes me really sorry is that, at a first look, I have beaten whites better than anyone else. I recognize almost all them in three rounds, I know how they start and how they have to behave to my move, I catch #6 at 6th round, and 7,8,9 at round 501. When I have an unespected loss or tie I look at the round counter, I can have a loss at round 5, showing ww 6, or at round 501 showing ww 7 8 9; any other loss or tie make me activate the inadequate anti human engine :-((( This week number is closed, but anyone wanting to send comments about his warrior's strategy, to publish in next number, is welcome. >Thanks for playing, > >Nandor & Stefan. > > -Beppe From: Derek Ross Subject: Re: NSFCWT Round 6 results Date: 1995/11/20 Message-ID: <322@arbroath.win-uk.net>#1/1 newsgroups: rec.games.corewar Congratulations to everyone who took part in this round. I enjoyed reading these warriors. Especially some of the comments ... . So the winning strategy turns out to be an adaptive lookup table, special treatment for #6 and three feet of snow to guarantee you spend enough time indoors to write it! I never stood a chance! Cheers Derek Then let us pray that come it may (as come it will for a' that) That Sense and Worth ower a' the Earth shall bear the gree and a' that For a' that and a' that, it's comin' yet for a' that That man tae man the world ower shall brithers be for a' that From: Anders Ivner Subject: round 6 Date: 1995/11/20 Message-ID: <9511201808.AA20082@su9-5.ida.liu.se>#1/1 newsgroups: rec.games.corewar ;strategy Confuse opponent by writing unreadable, uncommented code ;strategy with nonsense labels :-) This strategy seems to apply to a lot of the programs from round 6. Please post an article explaining what your programs do. I will not mention any names, but the authors of these warriors should be ashamed :-) ?whatever? machiavelli plinyswitch the thinker winner This program is better, but I can't figure out its overall strategy: miss playful /Anders From: John K W Subject: Re: NSFCWT - rules for round 7 Date: 1995/11/20 Message-ID: <48r1he$ne2@geraldo.cc.utexas.edu>#1/1 references: <48q1um$did@earth.superlink.net> newsgroups: rec.games.corewar tuc@mars.superlink.net (Scott J. Ellentuch) wrote: >: > inclusion maps. Your program should identify the remaining terms using >: > heuristic, find the limit C* algebra and calculate the K groups. ( Hint: >: > don't use the Pimsner-Voiculescu 6-term exact sequence. ) Since this > >: Have to go home for my holidays (no internet access :() In any case, can >: someone translate the above into English :) ? >: Calvin Loh > I'm playing an April Fools joke on the r.g.c group in November. >(If you check the rest of the message, it basically says we need to wait >for Stefan before we can continue). Nandor had me pretty lost at it too! > > Tuc You mean bastard! You confused the poor kid. :) I must admit, though, -I- thought it was funny. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: Core_Warrior_ #6 Date: 1995/11/20 Message-ID: <48qacl$npd@mozo.cc.purdue.edu> newsgroups: rec.games.corewar .xX$$x. .x$$$$$$$x. d$$$$$$$$$$$ ,$$$$$$$P' `P' , . $$$$$$P' ' .d b $$$$$P b ,$$x ,$$x ,$$x ,$$b $$. Y$$$$' `$. $$$$$$. $$$$$$ $$P~d$. d$$$b d d$$$ `$$$$ ,$$ $$$$$$$b $$$P `$ $$$b.$$b `Y$$$d$d$$$' . . a . a a .aa . a `$$$ ,$$$,$$' `$$$ $$$' ' $$P$XX$' `$$$$$$$$$ .dP' `$'$ `$'$ , $''$ `$'$ `Y$b ,d$$$P `$b,d$P' `$$. `$$. , `$$P $$$' Y $. $ $ $ Y..P $ `$$$$$$$' $$$P' `$$b `$$$P `P `$' `Y'k. $. $. $. $$' $. Issue 6 November 20, 1995 ______________________________________________________________________________ Core_Warrior_ is a weekly newsletter promoting the game of corewar. Emphasis is placed on the most active hills--currently the '94 draft hill and the beginner hill. Coverage will follow where ever the action is. If you have no clue what I'm talking about then check out these five-star internet locals for more information: FAQs are available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z FTP site is: ftp.csua.berkeley.edu /pub/corewar Web pages are at: http://www.stormking.com/~koth http://www.ecst.csuchico.edu/~pizza/koth http://pauillac.inria.fr/~doligez/corewar/ ______________________________________________________________________________ Greetings. The weeks keep getting shorter, but the tournament entries keep getting more complex. Even so, action on the '94 hill has been furious. And some old faces have returned--J. Pohjalainen, originator of the replication engine about everyone is using now. And Schitzo aka Michael Nonemacher ( I think; I haven't been playing all that long . . . ) whose quiz briefly ruled the hill this week. Welcome back. Damien Doligez seems to have a semi-regular column in the Core_Warrior_. This issue he discusses another variation of the continuously launching imp. Have a good Thanksgiving everyone. ______________________________________________________________________________ Tournament Time (details at http://www.stormking.com/~koth/nsfcwt.html) Round 6 is finally over. There was some controversy over self fights and handshakes. At the end this didn't make much of a difference. The round was run twice. First without self fights and then with self fights. The results are almost the same except in one case. Karl Lewin sent in two versions of his warrior (The Thinker). One version with handshakes and another without handshakes. I included both of these versions in both runs. Special thanks for Karl Lewin for Test warrior. It was a valuable tool to find out about buggy submissions. Test warrior was run also in the tournament, and it gained the first place as it was supposed to. Notice that in the self fight run Test warrior didn't win 100 % . Since the only difference in the results of the two runs is the order of Thinker and Winner, we decided to call it a draw between these two submissions. Here is the result of the no self fights run: Elapsed time: 833 seconds (00:13:53) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Test for Timeouts Karl Lewin 100 0 0 75000 2 Blizzard Anders Ivner 71 18 10 56123 3 Psst Robert Macrae 67 21 12 53019 4 Round 6 Kline P.Kline 64 20 16 51936 5 nt entry #6 M R Bremer 64 21 16 51529 6 Winner Steven Morrell 63 21 16 51183 7 The Thinker (w/Handshak Karl Lewin 62 23 15 50479 8 The Thinker (w/o handsh Karl Lewin 62 23 15 50479 9 Machiavelli Maurizio Vittuari 62 23 15 50356 10 Maverick Randy Graham 63 25 12 50142 11 Miss Playful Derek Ross 61 22 16 50109 12 ?{whateverCT#$~S|[]~+'i Paulsson 59 27 14 47404 13 PlinySwitch - 2990 G. Eadon 58 27 15 47140 14 Bim bum bam Beppe Bezzi 57 30 13 46149 15 WhileAway JKW 54 31 16 44161 16 Paper-Scissors-Stone #4 Nandor Sieben & Stefan 35 58 7 27887 17 Paper-Scissors-Stone #6 Nandor Sieben & Stefan 17 68 15 16168 18 Paper-Scissors-Stone #7 Nandor Sieben & Stefan 19 74 7 16097 19 Paper-Scissors-Stone #3 Nandor Sieben & Stefan 17 74 9 15006 20 Paranoid Calvin Loh 16 73 10 14829 21 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 17 76 7 14507 22 Paper-Scissors-Stone #8 Nandor Sieben & Stefan 15 74 11 14084 23 Paper-Scissors-Stone #5 Nandor Sieben & Stefan 13 70 18 13834 24 Paper-Scissors-Stone #9 Nandor Sieben & Stefan 15 76 9 13589 25 Paper-Scissors-Stone #2 Nandor Sieben & Stefan 15 76 9 13386 26 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 1 94 4 2096 These is the result of the self fight run: Elapsed time: 942 seconds (00:15:42) Rank Name Author %W %L %T Score ___________________________________________________________________________ 1 Test for Timeouts Karl Lewin 93 0 7 77000 2 Blizzard Anders Ivner 66 17 17 58123 3 Psst Robert Macrae 65 23 11 56019 4 Round 6 Kline P.Kline 59 19 22 53936 5 nt entry #6 M R Bremer 59 19 22 53529 6 The Thinker (w/Handshak Karl Lewin 61 25 14 53477 7 Winner Steven Morrell 58 20 22 53183 8 The Thinker (w/o handsh Karl Lewin 58 21 21 52479 9 Machiavelli Maurizio Vittuari 57 21 22 52356 10 Maverick Randy Graham 58 23 19 52142 11 Miss Playful Derek Ross 57 21 22 52109 12 ?{whateverCT#$~S|[]~+'i Paulsson 54 25 20 49404 13 PlinySwitch - 2990 G. Eadon 54 25 21 49140 14 Bim bum bam Beppe Bezzi 53 27 20 48149 15 WhileAway JKW 50 28 22 46161 16 Paper-Scissors-Stone #4 Nandor Sieben & Stefan 32 54 14 29887 17 Paper-Scissors-Stone #6 Nandor Sieben & Stefan 15 63 21 18168 18 Paper-Scissors-Stone #7 Nandor Sieben & Stefan 18 68 14 18097 19 Paper-Scissors-Stone #3 Nandor Sieben & Stefan 16 68 16 17006 20 Paranoid Calvin Loh 15 68 17 16829 21 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 16 70 14 16507 22 Paper-Scissors-Stone #8 Nandor Sieben & Stefan 14 68 18 16084 23 Paper-Scissors-Stone #5 Nandor Sieben & Stefan 12 65 24 15834 24 Paper-Scissors-Stone #9 Nandor Sieben & Stefan 14 70 16 15589 25 Paper-Scissors-Stone #2 Nandor Sieben & Stefan 14 71 16 15386 26 Paper-Scissors-Stone #1 Nandor Sieben & Stefan 1 87 12 4096 This is the rank after round 6: Name 1 2 3 4 5 6 total Steven Morrell 5 10 9 13 14 10 61 P.Kline 7.5 9 7 11 11 12 57.5 Paulsson 7.5 11 11 9 2 5 45.5 Anders Ivner 5.5 8 4 0 10 14 41.5 Beppe Bezzi 7 7 13 2 8 3 40 M R Bremer 7 4 3.6 5 7 11 37.6 Maurizio Vittuari 6.5 5 6 3 9 8 37.5 John K. Wilkinson 4 6 12 0 13 2 37 Robert Macrae 0 0 0 12 12 13 37 Karl Lewin 0 0 10 4 6 10 30 Randy Graham 0 0 8 10 4 7 29 Derek Ross 3.5 3 3.3 7 3 6 25.8 G. Eadon 1.5 2 5 6 1 4 19.5 Kurt Franke 0 0 0 8 0 0 8 Michael Constant 0 0 0 0 5 0 5 Anders Scholl 0 1 2 1 0 0 4 John Lewis 0 0 3 0 0 0 3 Calvin Loh 0 0 1 0 0 1 2 Detailed results and the submissions will be sent in a separate file. It wasn't clear for a while if handshake is possible. So looking at the submissions will be very interesting. We let Corewarrior discuss this topic in depth. It is clear from game theory that assuming an optimal opponent the best strategy is to play randomly. If the opponent does not play using optimal strategy then we can do much better. Of course trying to outguess the opponent makes our strategy different from the optimal strategy. There was some concern about mts. The Borland C compiled version of mts has difficulty handling big scores. This didn't caused problem in this round since the djgpp compiled version was used which can handle huge scores. Thanks for playing, Nandor & Stefan. ______________________________________________________________________________ Current Status of the Internet Pizza Server ICWS '94 Draft Hill: Hill Specs: coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 rounds fought: 250 instruction set: ICWS '94 Draft Last challenge: Sun Nov 19 10:25:06 PST 1995 # %W/ %L/ %T Name Author Score Age 1 42/ 25/ 33 test L 7e Beppe Bezzi 159 2 2 41/ 25/ 34 La Bomba Beppe Bezzi 157 46 3 47/ 39/ 14 quiz Schitzo 155 51 4 42/ 34/ 24 Derision M R Bremer 149 70 5 34/ 31/ 35 Torch t18 P.Kline 136 430 6 28/ 20/ 52 Fly Fishing w/Plastic Wor Karl Lewin 136 28 7 37/ 39/ 24 myVamp v3.7 Paulsson 134 398 8 40/ 46/ 13 Leprechaun on speed Anders Ivner 134 226 9 35/ 37/ 28 endpoint . M R Bremer 134 75 10 34/ 35/ 31 Phq Maurizio Vittuari 132 532 11 38/ 43/ 20 Porch Swing + Randy Graham 132 131 12 33/ 35/ 31 Son & Father Maurizio Vittuari 131 81 13 32/ 33/ 35 Father & Son Maurizio Vittuari 131 80 14 35/ 40/ 25 Armory - A5 Wilkinson 130 569 15 38/ 48/ 14 Scissors v.a1 John K. Wilkinson 129 22 16 25/ 22/ 54 juliet and paper M R Bremer, B. Bezzi 128 47 17 27/ 28/ 45 Jack in the box Beppe Bezzi 125 418 18 20/ 18/ 63 TimeScape (1.7) J. Pohjalainen 121 3 19 15/ 10/ 75 Evolve 6.3 John Wilkinson 121 11 20 31/ 45/ 23 myTry Paulsson 117 1 Bezzi continues to dominate the hill with La Bomba. His test L 7e is no doubt an improvement that no one wants to see ( but him ). quiz is the only serious contender for the throne at this point. Forty-seven percent wins is quite impressive. Karl Lewin makes the jump from the b hill with his Fly Fishing w/ Plastic Worms. One of the more original names I've seen. Jack in the box and Armory have been floating in the bottom half lately. It's too soon to tell if their effectiveness is gone. ______________________________________________________________________________ 94 - What's New 1 42/ 25/ 33 test L 7e Beppe Bezzi 159 2 3 47/ 39/ 14 quiz Schitzo 155 51 6 28/ 20/ 52 Fly Fishing w/Plastic Wor Karl Lewin 136 28 15 38/ 48/ 14 Scissors v.a1 John K. Wilkinson 129 22 16 25/ 22/ 54 juliet and paper M R Bremer, B. Bezzi 128 47 19 15/ 10/ 75 Evolve 6.3 John Wilkinson 121 11 20 31/ 45/ 23 myTry Paulsson 117 1 ______________________________________________________________________________ 94 - What's No More 21 38/ 48/ 14 Anti Die-Hard Bevo (3c) John Wilkinson 128 176 21 27/ 28/ 45 .Brain Vamp. B.Bezzi, M.Paulsson 125 74 21 37/ 48/ 15 Leprechaun deluxe Anders Ivner 126 284 21 28/ 34/ 37 Thieves Like Us M R Bremer 122 45 21 31/ 47/ 22 Frontwards Steven Morrell 116 323 21 15/ 7/ 78 Chugging Along Karl Lewin 122 84 21 24/ 22/ 54 Impfinity v3e7 Planar 125 70 Carnage on the '94 hill! A combined age of 1,056 was kicked off the hill this week. Hopefully the seven new warriors are worthy successors. ______________________________________________________________________________ Current Status of the Internet Pizza Server Beginner's Hill: Hill Specs: coresize: 8000 max. processes: 8000 duration: after 80,000 cycles, a tie is declared. max. entry length: 100 minimum distance: 100 maximum age: At age 100, warriors are retired. rounds fought: 250 instruction set: ICWS '94 Draft Last challenge: Sun Nov 19 15:33:24 PST 1995 # %W/ %L/ %T Name Author Score Age 1 44/ 37/ 19 Fire Master v1 JS Pulido 150 8 2 37/ 26/ 37 teamwork? Kurt Franke 149 4 3 40/ 31/ 29 Lurker 1.1 Kurt Franke 148 2 4 39/ 40/ 21 Look J. Doster 138 31 5 28/ 20/ 52 Schizo J. Doster 136 34 6 25/ 16/ 59 Impfinity v3c11 Planar 133 46 7 24/ 21/ 55 Paper8-II G. Eadon 127 18 8 32/ 39/ 29 Test-Fc G. Eadon 125 89 9 31/ 38/ 31 Hint Test v4 M R Bremer 123 35 10 24/ 26/ 49 Loh_tst_1.3 Calvin Loh 123 7 11 28/ 37/ 34 0.5 jmz scanner Kurt Franke 120 3 12 33/ 48/ 19 Recon V7.2 A. Nevermind 118 5 13 17/ 19/ 64 Sheet 1.0 J. Doster 115 44 14 13/ 10/ 77 Impfinity v1 Planar 115 78 15 12/ 10/ 79 RingWorm_v2.5 Calvin Loh 113 17 16 15/ 19/ 66 RingWorm_v2.4 Calvin Loh 112 32 17 28/ 46/ 25 Paper Shredder 2.1 Kurt Franke 110 1 18 10/ 5/ 5 teamwork? Kurt Franke 33 15 19 9/ 6/ 4 Lurker 1.1 Kurt Franke 30 64 20 8/ 7/ 4 Searching Kurt Franke 29 70 juliet storm was retired from the hill this week, meaning the hill has aged 100 warriors since the introduction of the Core_Warrior_. Franke managed to kill all his warriors somehow. Some new strategy? Franke, Doster, and Eadon have all been doing well on the hill, but none are savvy enough as Pulido to gain the top spot. I predict Kurt will be the next author to gain entry to the '94 hill. He better prove me right ( or somebody prove me wrong ). ______________________________________________________________________________ The Hint Hey kids. Look what we have in store for you today: the next installment of the Core_Warrior_ hint exploring standard warrior strategies. Scanners and replicators have been thouroughly ( hopefully ) discussed. Next in line are the dumb brutes--bombers. Bombers have been well treated in Morrell's tutorial 'chapter 2' accessible from the pizza or stormking pages at the berkeley ftp site, so we'll concentrate on two veterans--Blue Funk 3 and juliet storm along with the comments of their authors. These two warriors are typical of the 'classic' stone. Another group of bombers such as Torch, HeremScimitar, and Tornado represent another type that will be discussed next week. Stay tuned. ( For a detailed explanation on how stones work, see Morrell's book, chapter 2 ). Thanks to Morrell for his contribution on Blue Funk. ______________________________________________________________________________ BLUE FUNK 3 by Steven Morrell The two things a stone tries hardest to optimize are size and speed. A good metric to start out with is what I call the "stone index:" size/speed. Blue Funk 3 has a stone index of 5 instructions / approximately 33% c = 15. Iron Gate 1.5 has a stone index of 13 instructions/ 2/3 c = 19.5. Hence, if all else is equal, Blue Funk 3 will win more often. How much more often? If warrior A has a stone index of m and warrior B has a stone index of n, then warrior A will win n/(m+n) of the time. So Blue Funk 3 should win 56.5% of the time. (Iron Gate is very resistant to stones.) All else, of course, is not equal. The imp-ring slows Blue Funk 3 down dramatically and lends no aid to the warrior on the current hill, with every anti-imp strategy working against Blue Funk 3's imp. But, color is on the side of Blue Funk 3: While the scanner focuses upon the decoy, the bomber can color even more core with it's post-inc and DJN-stream. These aren't the main weapon, but they are free attacks, so quite useful. Against most scanners, a DJN.f stream can be remarkably lethal (as all the Genetic Algorithm folks find out). This is all academic, as Blue Funk 3 doesn't stand a chance on the modern hill. Frontwards, for instance, also has a stone index of 15 during the scanning phase, kills this kind of imp-ring, is very durable in the sense that 30% of its instructions are not used after the initial scan, and kills a better grade of paper than Blue Funk 3 could hope to. Also, there is a "mesh" issue when stones fight stones. Stones have an annoying habit of bombing themselves if things are not calibrated very well, so they don't generally use a very small mod (say, 1 to 3) for their step size. I was happy to get Blue Funk 3 down to mod 4, but this means that small programs, like P.Kline's deadly core-clear (3 executing instructions), can slip through the cracks. That's 25% non-contested wins! The best programs for both mesh and stone index that I know of are W.Sheppard's RedRain (mod 2, stone index 8) and No Ties Allowed (mod 2, stone index 9). Unfortunately, neither of them have a core-clear or imp gate, so they don't do too well on the hills anymore. Now for the details for Blue Funk 3: Ideally, a stone will bomb everywhere except for the stone itself. That is how P.Kline's Emerald (stone component) is supposed to work, but it has a very subtle bug in it. Blue Funk 3 uses the same general mechanism without the bugs. After it is booted, the stone looks like this: emerald SPL #-step,-step,step+1 ;hit ADD emerald,stone cnt DJN.f stone,0,n", which doesn't do anything except make the bombing pattern slip. The instruction that hits "cc" looks like "MOV >4,n" when cc contains n-4, so it is equally harmless and self-adjusting. (For instance, the first time cc is used, stone is MOV >4,-3, and cc is DAT #0,#-7. Hence stone-3 is copied neatly to itself, and cc becomes DAT #0,#-6 for the next time around.) The result of all of this foolishness is that the stone doesn't bomb itself until it has bombed all of the rest of core 1.5 times! ;redcode-94 verbose ;name Blue Funk 3 ;author Steven Morrell ;strategy Fixed another in-memory/in-register bug ;macro org boot step equ 3044 for 78 dat -step,step+1 ADD emerald,stone cnt DJN.f stone,out mov emerald+1,>out mov emerald+2,>out mov emerald+3,>out spl i spl i31 i12 spl imp2 imp1 jmp >0,imp i31 spl imp1 imp3 jmp >0,imp+5334 i spl i12 spl imp3 imp2 jmp >0,imp+2667 imp mov.i #3044,2667 ______________________________________________________________________________ JULIET STORM by M R Bremer I started coding juliet storm when B Panama X and Blue Funk 3 by Steven Morrell were both doing _very_ well on the hill. B Panama was a combination stone/paper and Blue Funk was a bomber/imp. Since B Panama was on top of the hill, I decided to follow the leader. juliet storm was originally intended to be part of my own stone/paper. That's why there are two splits in the stone--to keep up with the replicator. When I challenged the hill with my 'incomplete' warrior, it scored surprisingly well. Amazingly well. So I became obsessed with making it the best bomber on the hill. Out of that effort came juliet. The bombing step size was chosen to find size 5 and size 10 opponents rapidly and still be small enough for a decent imp gate. I found out that the double split consumed so many processes, that stun attacks on my imps had little effect. This greatly improved my score against Agony II. They also helped juliet to 'jump' into papers when overwritten. The extra 'gate' line was used in case the coreclear move was decremented. juliet continues to bomb as she clears, but I don't really think this matters much. The clear ends in a hyper-perfect gate ( I think ). The imp was taken from a posting by T. Hsu on vector launced imps. I wasn't quite savvy enough to write my own at the time. juliet ruled the '94 draft hill for a few weeks. It's a _HUGE_ rush when you finally get your first warrior to be King of the Hill. At least I thought so. The introduction of p-space killed her dead, dead, dead. A stand alone bomber has little chance of success on the current hill. BTW: the name: 'juliet storm' is a reference to Romeo and Juliet. Theirs was near perfect love. But in all my relationships, I always manage to really anger my girlfriend from time to time--hence the 'storm'. Nothing matches the fury of a woman. ;redcode-94 ;name juliet storm ;author M R Bremer ;strategy bomber--yippee ptr EQU -1333 gate dat <-445, <-446 s spl #445, <-445 spl #0, <-446 mov {445-1, -445+2 add -3, -1 djn.f -2, <-2667-500 mov 33, <-20 go dat #0, #ptr start mov {-1, <-1 mov {-2, <-2 mov {-3, <-3 mov {-4, <-4 mov {-5, <-5 mov {-6, <-6 mov gate, ptr+24 mov gate, ptr+24 spl @go, <-4000 jmp boot, <-4013 for 73 dat #0, #0 rof imp_sz equ 2667 boot spl 1 ,#0 spl 1 ,#0 spl <0 ,#vector+1 djn.a @vector,#0 imp mov.i #0,imp_sz jmp imp+imp_sz*7,imp+imp_sz*6 jmp imp+imp_sz*5,imp+imp_sz*4 jmp imp+imp_sz*3,imp+imp_sz*2 vector jmp imp+imp_sz ,imp end start ______________________________________________________________________________ You may have noticed the new Hint Warrior on the beginner hill. It is doing quite well. 4 38/ 34/ 28 Hint Test v4 M R Bremer 142 1 The old Hint Warrior suffered from scanners. By pspacing a bomber element as a backup, Hint Warrior vastly improves its score. Losses to papers have gone up due to the fact that when a replicator beats the scanner part of Mutagen, the bomber is almost sure to tie or lose the next round. By adding an imp, I should be able to reduce the number of losses at least. Another improvement may be to boot of a decoy. Something to think about for later weeks. ;redcode-b ;name Hint Test v4 ;author M R Bremer ;strategy Original code based on Scott Manley's Mutagen ;strategy Once through scan --> spl spl dat dat coreclear ;strategy Core_Warrior_ #2: compressed code ;strategy Core_Warrior_ #4: improved scanner ;strategy Core_Warrior_ #6: pspaced with small bomber ;kill Hint ;assert CORESIZE==8000 org start dist equ 98 scan equ dist*2 begin SPL b1+2 jmp a for 20 dat 0, 0 rof a add d,c c cmp a+2*dist,a+dist slt.a #dist+ptr2-a, c djn.f a,<7000 mov s, *c x mov m, @c jmn a,a s spl #-dist+1, <0 jmp b1 d dat ______________________________________________________________________________ Questions? Concerns? Comments? Complaints? Mail them to: Beppe Bezzi or Myer R Bremer From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: ;kill teamwork? killed all my warriors Date: 1995/11/20 Message-ID: <48p45e$ioh@valhalla.stormking.com>#1/1 references: <48o92g$dto@larry.rice.edu> newsgroups: rec.games.corewar Kurt Franke (kfranke@rice.edu) wrote: : I had these two lines in a warrior: : .. : ;name teamwork? : ;kill teamwork? : .. : this seems to have killed all my warriors on beginner hill. Is there : something funny about the question mark? If Thos is running the same base scripts I am, you probably got bitten by a pattern match. Scott -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: KOTH Tourney Server Subject: SKI-ICWS: Status - Standard 11/20/95 Date: 1995/11/20 Message-ID: <199511200500.AAA23750@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status See up to the second scores and the latest Core War information at : http://www.stormking.com/~koth *FAQ* is at http://www.stormking.com/~koth/corewar-faq.html Current Status of the StormKing Industries Standard KotH CoreWar Hill : Last battle concluded at : Fri Nov 17 18:06:57 EST 1995 # %W/ %L/ %T Name Author Score Age 1 28/ 14/ 58 Cannonade P.Kline 142 106 2 38/ 34/ 28 Giskard v0.5 Ken Mitton 141 44 3 30/ 20/ 50 CAPS KEY IS STUCK AGAIN Steven Morrell 140 72 4 39/ 39/ 22 Christopher Steven Morrell 140 71 5 40/ 41/ 19 Beholder's Eye V1.7 W. Mintardjo 139 150 6 42/ 44/ 14 Iron Gate Wayne Sheppard 139 200 7 28/ 18/ 53 Blue Funk 88 Steven Morrell 138 70 8 37/ 36/ 27 Keystone t21 P.Kline 138 93 9 30/ 23/ 47 Test Wayne Sheppard 137 95 10 34/ 31/ 35 Yop La Boum v2.1 P.E.M & E.C. 137 6 11 27/ 16/ 57 Peace Mr. Jones 136 80 12 37/ 38/ 24 Miss Carefree Derek Ross 136 4 13 26/ 17/ 57 ttti nandor sieben 136 56 14 30/ 25/ 45 Der Zweiter Blitzkrieg Mike Nonemacher 136 101 15 36/ 36/ 29 Double Clown v1.1 P.E.M 136 1 16 38/ 42/ 19 Request v2.0 Brant D. Thomsen 135 42 17 40/ 48/ 11 bigproba nandor sieben 132 94 18 26/ 19/ 55 jmp/add crasher Randy Graham 132 30 19 26/ 22/ 52 Hydra Stephen Linhart 130 180 20 20/ 12/ 67 Evol Imp v5a Wilkinson 128 17 21 5/ 87/ 8 Ginger Nuts Dave Newton 24 0 From: Planar Subject: Re: NSFCWT Round 6 results Date: 1995/11/21 Message-ID: <48shmo$mi1@news-rocq.inria.fr>#1/1 references: <1995Nov20.103150@acad.drake.edu> <48qv3d$1qh@soap.news.pipex.net> newsgroups: rec.games.corewar In article <48qv3d$1qh@soap.news.pipex.net>, Robert Macrae writes: >I would like to see the code of Blizzard too, but have yet to master >uudecode. Could you post it, perhaps with analysis, Anders? You'll find it on my web page: http://pauillac:80/~doligez/corewar/rc/Blizzard.txt As for the analysis, I can't help you, of course. -- Planar From: pan0178@comune.bologna.it (MV) Subject: Re: round 6 Date: 1995/11/21 Message-ID: <199511211907.OAA19614@valhalla.stormking.com> newsgroups: rec.games.corewar > >;strategy Confuse opponent by writing unreadable, uncommented code >;strategy with nonsense labels :-) > >This strategy seems to apply to a lot of the programs from round 6. >Please post an article explaining what your programs do. > >I will not mention any names, but the authors of these warriors should >be ashamed :-) > >?whatever? >machiavelli >plinyswitch >the thinker >winner > >This program is better, but I can't figure out its overall strategy: > >miss playful > >/Anders > Right... I'm blushing! ;-) So I'll post two words about my warrior... My strategy is the following: PLAY 1 WIN: set 347a strategy (that means that the enemy can be white 3,4,7 or Anders...obviously it could be another human!) at next round PLAY 3 RES=0: set a (I'll play 31313131... and Anders will play 1313131...) (this continues until the sequence go on) RES=1: set 4 'cos the enemy is ww#4 (or another human...) RES=2: set 37; at next round I'll use the 37 strat (who is the same of 28 so I'll use go37 routine) LOSS: PLAY 2 RES=0: set 50 (at next round I'll execute go50) RES=1: set 169 RES=2: set 28 If during a selected strategy something goes wrong jump to random strat... BTW thanx to Anders Ivner who has given me about 200 (useful!) points more, but perhaps even more than 200 ;-) Regards Maurizio ;redcode-94 ;name Machiavelli ;author Maurizio Vittuari ;contact pan0178.iperbole.bologna.it ;NSFCWT round 6 ;strategy Handshaking...? Noo! (that means... Yeah! ;-) ;strategy kill whites; score 500/500/0 against Anders; ;strategy pseudo random strat against others ;assert WARRIORS==1 || (WARRIORS == 2 && MINDISTANCE == CORESIZE/2) ;assert VERSION >= 80 ;my/your_hand are used to communicate between players your_hand equ (my_hand+CORESIZE/2) PAPER equ #1 ;some useful constants SCISSORS equ #2 STONE equ #3 org start my_hand dat 0,0 ; ; Variable part starts here. This is were I decide what hand to ; use next. I can use the value of the RESULTS cell (0 if lost, ; 1 if won, 2 if tied last round) and any other values I chose ; to store in pspace. The hand I decide to show is stored in the ; B-field of instruction 'my_hand'. ;---BEGIN-VARIABLE-PART----------------------------------------------------- RES_S equ #0 ;last result RND_S equ #1 ;round_number slot RAND_S equ #2 ;pseudo random number generation STRAT_S equ #3 ;my last strategy (0,4,5,169,etc.) M123_S equ #4 ;my last move (1,2,3) start round ldp RND_S, #0 res ldp RES_S, #0 strat ldp STRAT_S,#0 ; 0,4,5,169,28,37,etc. lmove ldp M123_S, #0 jmn go, strat ;strat is yet decided! jmz first, round ;round #0 sne #1, round jmp second ;goto second sne #2, round jmp third go sne #28, strat ;goto selected strategy jmp go28 sne #347, strat jmp go347a sne #50, strat jmp go50 sne #5, strat jmp go5 sne #169, strat jmp go169 sne #19, strat jmp go19 sne #37, strat jmp go28 sne #6, strat jmp go6 sne #4, strat jmp go4 sne #113, strat jmp goa gor ldp RAND_S, #0 ;pseudo random number generation add #1, gor ;do some stuffs... mul #3, gor add #5, gor mul #7, gor stp.b gor, RAND_S ;store the pseudo random number mod #11, gor ;that will be my next seed add.b gor, ptr num mov.b @ptr, 0 mod #3, num add #1, num mov.ba num, last jmp fine, >round ptr dat 0, 1 ;random table dat 0, 3 ;pseudo random number is used as pointer dat 0, 2 ;to an element of this table dat 0, 1 dat 0, 1 dat 0, 2 dat 0, 3 dat 0, 1 dat 0, 3 dat 0, 2 dat 0, 1 dat 0, 3 dat 0, 2 go28 sne #1, res jmp ok28 check28 seq #501, round jmp setr add #1, lmove mod #3, lmove ok28 mov.ba lmove, last jmp fine, >round go19 sne #1, res jmp ok19 check19 seq #501, round jmp setr add #2, lmove mod #3, lmove ok19 mov.ba lmove, last jmp fine, >round go169 sne #1, res jmp ok169 sne #5, round jmp set6 jmp set19 ok169 slt round, #10 jmp set19 mov.ba lmove,last jmp fine, >round go6 seq #1, res jmp setr add #1, lmove stp lmove, M123_S div #5, lmove add #2, lmove mod #3, lmove add #1, lmove mov.ba lmove, last jmp fine+1, >round go50 sne #1, res jmp ok0 sne #4, round seq #2, res jmp setr jmp set5 ok0 mov.ba lmove, last jmp fine, >round go5 seq #1, res jmp setr add #1, lmove mod.a #3, lmove mov.ba lmove, last jmp fine, >round go347a sne #1, res jmp set4 ;res=1 --> goto set4 jmz seta, res ;res=0 --> goto seta jmp set37 ;res=2 --> goto set37 go4 seq #1, res jmp setr add #1, lmove mod #3, lmove add #1, lmove mov.ba lmove, last jmp fine, >round goa mov round, data ;Maurizio versus Anders mod #2, data jmz uno, data seq #1, res jmp setr ;set random if cheated mov #3, last jmp fine, >round uno jmn setr, res ;set random if cheated mov.a #1, last jmp fine, >round data dat 0, 0 set347a stp #347, STRAT_S ;set a strategy mov.a #3, last jmp fine, >round set50 stp #50, STRAT_S mov.a #2, last jmp fine, >round set5 stp #5, STRAT_S mov.a #1, last jmp fine, >round set19 stp #19, STRAT_S mov.a #2, last jmp fine, >round set37 stp #37, STRAT_S mov.a #1, last jmp fine, >round set169 stp #169, STRAT_S mov.a #2, last jmp fine, >round set28 stp #28, STRAT_S mov.a #3, last jmp fine, >round set6 stp #6, STRAT_S mov #0, lmove jmp go6+2 setr stp #-1, STRAT_S stp #6, RAND_S mov.a #3, last jmp fine, >round seta stp #113, STRAT_S ;the enemy probably is Anders mov.a #1, last jmp fine, >round set4 stp #4, STRAT_S mov.a #2, last jmp fine, >round first mov.a #1, last jmp fine, >round second sne #1, res jmp set347a ;if win set 347a mov.a #2, last ;else don't set any strat yet jmp fine, >round third sne #2, res jmp set28 sne #1, res jmp set169 jmp set50 fine stp.ab last, M123_S stp.b round, RND_S last mov #1, my_hand ;---END-VARIABLE PART------------------------------------------------------- ; End of variable part. I wait for the other player to show his hand. ; I then analyze the outcome of the game. ; wait jmz.b wait,your_hand work mov.b your_hand,#work sub.b my_hand,work ;your_hand minus my_hand, loss=1,-2 add #2,work ;loss=3,0 mod #3,work ;loss=0 live jmn live,work ;die if lost, live if won or tied end From: Magnus Paulsson Subject: Re: round 6 Date: 1995/11/21 Message-ID: <199511211131.MAA15424@bottom.ifm.liu.se>#1/1 newsgroups: rec.games.corewar > ;strategy Confuse opponent by writing unreadable, uncommented code > ;strategy with nonsense labels :-) > > This strategy seems to apply to a lot of the programs from round 6. > Please post an article explaining what your programs do. > > I will not mention any names, but the authors of these warriors should > be ashamed :-) > > ?whatever? No I'm not ashamed, my master theisis is due in tree weeks. (do you say "due"? sounds like I'm pregnant :-) I'll try to give a short explanation (not very easy coz I'm not very confident of my program being bug free, but works ok against whites) ?whatever? uses a lookup table that is modified according to results of previous plays, it bases it's decition on the last play (that is my hand and your hand of the last play) and on my own hand in the second last play. This gives a table of 27 different cases. Each table position is three bytes describing what has happend in the past plays. The hand is choosen randomly with probability proportional to table values. The table values are initiated to 1, the right choise is ++'ed. Now I put it together in a few hours, I don't know if it works as it should but acording to results of the tournament the random number generator of my program is worthless. (does anyone know which programs that lost to ?whatever?, might be interesting!) -Magnus To Ivner: Om du vill veta mer kom till nya fysik huset rum G416 (Gauss korr. l�ngst upp) torsdag em efter 15.00. From: John K W Subject: Re: Hill Management Date: 1995/11/21 Message-ID: <48tbiv$nfa@geraldo.cc.utexas.edu>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> <48co7i$gm1@news-rocq.inria.fr> <48ldoo$6jv@valhalla.stormking.com> <1995Nov21.115536@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu wrote: >Better idea - separate hill-management and load-balancing by farming out >the battles. Instead of running all the battles themselves, the Hill >Manager could email the opponents and parameters to service sites that >would just run them and report the results. Hill Managers could also >run battles, just not all of them. Harness the power of networked >computers to run thousands of battles in a few minutes. I'd thought about that once before, but I didn't want to submit that idea when it seems to take months just to MOVE a Hill. :) There is one question though, the Manager would not be able to send out orders until the last battle is done. How long would it wait before timeing out a Service Site? >Another idea - I sure would like to see my pspace (non-zeros only?) >after finishing a round with an opponent. > >... of course that would result in submitting a program like this :-) > > first round: > find opponent > copy to pspace > die > other rounds: > die Heh. :) But, without opcodes or instructions, how useful would those numbers be? :/ You could probably figure out what your opponent is doing, but it would not be easy... -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: pk6811s@acad.drake.edu Subject: Hill Management Date: 1995/11/21 Message-ID: <1995Nov21.115536@acad.drake.edu>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> <48co7i$gm1@news-rocq.inria.fr> <48ldoo$6jv@valhalla.stormking.com> newsgroups: rec.games.corewar Better idea - separate hill-management and load-balancing by farming out the battles. Instead of running all the battles themselves, the Hill Manager could email the opponents and parameters to service sites that would just run them and report the results. Hill Managers could also run battles, just not all of them. Harness the power of networked computers to run thousands of battles in a few minutes. Another idea - I sure would like to see my pspace (non-zeros only?) after finishing a round with an opponent. ... of course that would result in submitting a program like this :-) first round: find opponent copy to pspace die other rounds: die Paul Kline pk6811s@acad.drake.edu From: akemi@netcom.com (David Boeren) Subject: Re: Ideas for new instructions Date: 1995/11/21 Message-ID: #1/1 references: <486j3g$8rn@nuscc.nus.sg> <48i8i7$q8t@news-rocq.inria.fr> <48ja5b$f7c@news.asu.edu> <48ofpa$spa@pan.otol.fi> <48rse0$b10@news.asu.edu> <48si40$mi1@news-rocq.inria.fr> <48t80v$kp5@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: : Planar wrote: : >How about using two characters: : > : > <@a >@a ; decrement/increment, then indirection : > @a ; indirection, then decrement/increment Heck, I'd prefer something a little less cryptic. I always end up checking the charts to remind myself of which little funny symbol is which. How about something more like this: ++a, --a, a++, a-- Well? Too funky? At least a lot of beginners would get to understand it a lot easier, asn we can of course also allow the "old-style" modifiers too, so it doesn't break existing code. From: sieben@imap1.asu.edu Subject: Re: Ideas for new instructions Date: 1995/11/21 Message-ID: <48rse0$b10@news.asu.edu>#1/1 references: <486j3g$8rn@nuscc.nus.sg> <48i8i7$q8t@news-rocq.inria.fr> <48ja5b$f7c@news.asu.edu> <48ofpa$spa@pan.otol.fi> newsgroups: rec.games.corewar Juho Snellman (poke@lyseo.otol.fi) wrote: : sieben@imap1.asu.edu wrote: : : We could use : : a ;pre : : a< a> ;post : Wasn't one of the requirements for the new standard that all old : programs run unchanged ? Now post-increment would change into : pre-increment, so one would have to modify old warriors. And if i don't : know when the program has been done, i don't know whether modification is : needed. But i do like the symbols othervise, they look quite clear. I know this is a problem. My only excuse is that I suggested these symbols before we implemented post increment. Nandor. From: Michael N Nonemacher Subject: Re: Core_Warrior_ #6 Date: 1995/11/21 Message-ID: #1/1 references: <48qacl$npd@mozo.cc.purdue.edu> newsgroups: rec.games.corewar Myer R. Bremer wrote, in Core Warrior #6: > And some old > faces have returned--J. Pohjalainen, originator of the replication engine > about everyone is using now. And Schitzo aka Michael Nonemacher ( I think; > I haven't been playing all that long . . . ) whose quiz briefly ruled the > hill this week. Welcome back. Hehe... "quiz" is a pretty surprising little guy. It's basically a 2/3c bomber/scanner that switches to a multi-pass coreclear after it finds a certain number of things to bomb. I made a few improvements - took 2 lines off by sacrificing a little robustness, then took only 1 line off by sacrificing a lot less robustness, and tried 'em under the name "blister soul". In my tests, "blister soul" consistently outperformed "quiz", getting an average of 4 or 5 more wins out of 100 battles, against every warrior I had to test against. But on the hill, it didn't quite work out that way. *shrug* Maybe I introduced a few bugs, maybe I just don't realize how important that extra level of robustness is. Oh, well. Someday when I have time I just might try again. But with all the scanners and replicators sent to the hill this week, there was a point in time when "quiz" scored 50% wins, and that was enough for me. Until I can fine-tune "blister soul", that is... :) Oh, and I just may publish the source sometime soon... Especially if I try to improve it and fail... :) Schitzo From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: round 6 results Date: 1995/11/21 Message-ID: <48roat$i83@mozo.cc.purdue.edu>#1/1 newsgroups: rec.games.corewar Greetings. Does anyone have the results from round 6 in the round robin type format? I would like to see how I did against who ( and others against who ) and I don't really have the time to do it ( I'm leaving for break and all the dos computers here are being used by people doing some projects. I don't have a computer . . . yet. ) Just thought that someone would have it already. Thanks. M R Bremer From: John K W Subject: Re: (no subject) Date: 1995/11/21 Message-ID: <48rf59$g3t@geraldo.cc.utexas.edu>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48ldkg$6jv@valhalla.stormking.com> newsgroups: rec.games.corewar tuc@news.stormking.com (Scott J. Ellentuch) wrote: > As for balancing the hills....When Stefan, Thos and I decided to >only run 1 of any type of hill, we tried to balance it. I guess Stormking >got a lesser share than expected. I'd be interested in hearing NEW hill >ideas. As for moving.... We'd need to talk to Thos about that. > > > Tuc Who is the legendary "Thos" I keep hearing about? -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: sieben@imap1.asu.edu Subject: Re: Newbie from Heck Date: 1995/11/21 Message-ID: <48rs91$b10@news.asu.edu>#1/1 references: <48jqd5$h7@daily-planet.nodak.edu> <48knc7$dq9@news.infi.net> newsgroups: rec.games.corewar : It's command line driven, so you'll probably want a shell of some : kind. Look for PTOOLS.ZIP, it's got PSHELL in it. I was unable to make : it work for me because it likes to see the 386 version, but since I : run Windows, I usually run the slightly older 286 version of PMARSV : (graphical pmars). On my system the 386 version doesn't work under : Windows. I wrote a batch file (DOS 6 only!) that lets me set the : options and pick which binary to run. I'll post it here if anyone is : interested. I don't wanna start a discussion about windows, but you pay a big penalty for using windows. The 386 version is much faster than the 286, it can handle bigger coresizes. Actually the 386 version runs under windows if you use emxwin or something like that, though even if you do that pmars runs much faster from Dos. You are better of using pshell than using the command line from windows. Finally it's hard to imagine someone playing corewar who likes windows :-) Nandor. From: John K W Subject: Re: Ideas for new instructions Date: 1995/11/21 Message-ID: <48t80v$kp5@geraldo.cc.utexas.edu>#1/1 references: <486j3g$8rn@nuscc.nus.sg> <48i8i7$q8t@news-rocq.inria.fr> <48ja5b$f7c@news.asu.edu> <48ofpa$spa@pan.otol.fi> <48rse0$b10@news.asu.edu> <48si40$mi1@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar wrote: >How about using two characters: > > <@a >@a ; decrement/increment, then indirection > @a ; indirection, then decrement/increment > >Then the old notation keeps its old meaning. Heh. Good symbols, I think. But, does Corewar really need those extra two instructions?? -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Newbie from Heck Date: 1995/11/21 Message-ID: <48t7ua$kp5@geraldo.cc.utexas.edu>#1/1 references: <48jqd5$h7@daily-planet.nodak.edu> <48knc7$dq9@news.infi.net> <48rs91$b10@news.asu.edu> newsgroups: rec.games.corewar sieben@imap1.asu.edu wrote: >I don't wanna start a discussion about windows, but you pay a big >penalty for using windows. The 386 version is much faster than the 286, >it can handle bigger coresizes. Actually the 386 version runs under >windows if you use emxwin or something like that, though even if you do >that pmars runs much faster from Dos. You are better of using pshell than >using the command line from windows. Finally it's hard to imagine someone >playing corewar who likes windows :-) I've got a SLIP Net account. Sadly, Windows is pretty much the only option for running Netscape... Often I'll get a sudden idea, shell to DOS, and run PShell. So far, I've never had any problems whatsoever. BTW, for those who remember that memory failure in PShell I mentioned: Those problems only ever occured in DOS... Hmmmm... Kinda makes me want to install Linux or something. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: koth settings Date: 1995/11/21 Message-ID: <48t7o9$kp5@geraldo.cc.utexas.edu>#1/1 references: <48elo2$91v@nuscc.nus.sg> <48oc8v$lh3@geraldo.cc.utexas.edu> <48rrpu$b10@news.asu.edu> newsgroups: rec.games.corewar sieben@imap1.asu.edu wrote: >: I'm not sure what you want to know. If you're asking what I think >: you are, then yes. The distances MUST be varied, or the results of >: the battle would always be the same. > >Well, this is no longer true after the introduction of pspace. > >Nandor. Stop nitpicking, you bastard! Seriously though, that is important to keep in mind, it's why Armory is still alive. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: NSFCWT - rules for round 7 Date: 1995/11/21 Message-ID: <1995Nov21.090722.3067@rhodes>#1/1 references: <9511192307.AA05017@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar Stefan Strack (stst@idnsun.gpct.Vanderbilt.Edu) wrote: : The assignment is to write a program that calculates the K_0, K_1 groups and : the positive cone of K_0 of approximately finite C* algebras. Input is : given as the first 10 elements of the sequence of C* algebras and the : inclusion maps. Your program should identify the remaining terms using : heuristic, find the limit C* algebra and calculate the K groups. ( Hint: : don't use the Pimsner-Voiculescu 6-term exact sequence. ) Since this : problem might be a little harder than the previous ones, we let you can : represent your data as you feel best fits. Make sure you give precise : definitions how your data is represented and include test data. Well, the data representation was tough, but I have made up inputs that allow me to generate correct, and provable, results on all test inputs I have used. My problem is for certain sets, 8000 core locations is insufficient. So, since you didn't specify, I have chosen to run my warrior in a size 55440 core. : The score is calculated giving equal weight to 1) small size, 2) elegance : of the solution, and 3) pretty formatting. As an extra challenge, your : program has to withstand a gate-crashing 3-point imp-spiral. Since we : don't want to evaluate this round over Thanksgiving break, submissions are : due a little earlier, Tuesday, Nov. 21, 20:00. Through "tricky" programming, and a number of optimizations, I have mine working in 41 instructions. However, I did have to add in the redcode op "CPU.ab #num, #num" which passes a pointer to a text string in core to the real CPU and a pointer to core for the return. Again, you did not specify that addtional opcodes could not be used. The elegance is undeniable, and needs no further explanation. As for the pretty printing - when printed on a 1200 DPI or better laser printer, it reproduces perfectly the hubble telescope picture of Elvis estimated to be formed 679,253,623.17453523474287 light years away from earth (approximately). Stopping the imp was a challenge, but when I moved to size 55440 core, that went away (as there are no 3-point spirals). However, to increase the challenge, I allow imps to use fractional moves, thus re-introducing the 3-points spiral in 55440 core. Then, I included a new opcode "STI" for STop-Imp. It operates by running a 17c scan through core, locating any imps (through an advanced heuristic algorithm) and turning the imp into a 200% self-gating core-clear. So, do I win this round? : Good luck, Nandor & Stefan : P.S.: Seriously though, we thought we'd give you a break and postpone round 7 : until December 1. We'll post the real rules by midweek. Darn, this was a joke? I was expecting my 78 points for 1st-6th place to catapult me into first in the tournament. Randy From: John K W Subject: Re: summary on read/write limits [part 1] Date: 1995/11/21 Message-ID: <48rh86$gn7@geraldo.cc.utexas.edu>#1/1 references: <48idlv$s6s@news-rocq.inria.fr> <48iog3$5ap@hermes.cair.du.edu> newsgroups: rec.games.corewar Michael N Nonemacher wrote: >I have to agree here. Part of the charm (?) of this game is that, for >any warrior, there is another warrior that will kill it consistently. >Pspace actually *discourages* warriors that do well against everything, This is true... to a certain extent. Q-scanners, which are now prevelant, can do quite well against p-spacers. >in favor of warriors that make "smart" decisions about which component >to use. Pspace will greatly cut down on warriors' ages - scanners and >imp-spirals have traditionally dominated the longevity category, but any >halfway-decent Pspace warrior will beat them easily 60% of the time. I >think Pspace changes the flavor of the game too much to continue using >it. Then again, I might just be afraid some Pspacer will come along and >trash quiz... :) To the contrary. It would seem the p-space efforts have INCREASED the longevity, by reducing hill fluctuations somewhat. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: ruhl@phoebe.cair.du.edu (Robert A. Uhl) Subject: Re: Ideas for new instructions Date: 1995/11/22 Message-ID: <48u17p$63n@hermes.cair.du.edu>#1/1 references: <48ofpa$spa@pan.otol.fi> <48rse0$b10@news.asu.edu> <48si40$mi1@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar spake thusly: > >How about using two characters: > > <@a >@a ; decrement/increment, then indirection > @a ; indirection, then decrement/increment > >Then the old notation keeps its old meaning. Well, first of all, it is rather ugly, not that I could do better. Also, it raises the question: shouldn't a decrement and increment the referenced vars (similar to C --/++)? I'd guess that since this is just a draft standard we change whatever we can get away with and rewrite warriors as necessary. It shoudl be pretty straightforward. Or we could add a ;redcode xx field (already used; we'd need to codify it) vor versioning, i.e. ;redcode 94a (no pspace), ;redcode 94b (pspace) and ;redcode 94c (pspace + new pre/postfixes). Or we could name our new standard the 95 (or 96) draft standard, with which nothing is compatible. Although I'm not too happy with: a a> ; ++*a, *a++ but they'll have to do. Hw about: --a a-- ; modify a itself ++a a++ ; modify a itself This could work. -- +------------------------------------------------------------------------+ | Bob Uhl | Spectre | `En touto nika' + | | U of D | PGG FR No. 42 | http://mercury.cair.du.edu/~ruhl/ | +------------------------------------------------------------------------+ From: sieben@imap1.asu.edu Subject: Re: Newbie from Heck Date: 1995/11/22 Message-ID: <48vif5$lis@news.asu.edu>#1/1 references: <199511220858.JAA09431@iol-mail.iol.it> newsgroups: rec.games.corewar : I have the same problem John has, SLIP account, and sometimes I run pmars : from inside Windows 3.1 patched to 32 bits. This allows me to use a slightly : better editor than DOS edit; Pmars gives me no problems, but turtle speed, : while Pmarsv refuses to run giving some system error. : Is there some way to make it run? I'll look into this problem. There are thousnads of good free editors for DOS some with source that you can modify to your own taste. One thing to try would be to check out the new version of djgpp. Did anybody try it? If you check out the author's home page you can find a jpeg/gif viewer called pix... something. It's compiled with djgpp2 and I was able to run it from windows. Nandor. From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: Ideas for new instructions Date: 1995/11/22 Message-ID: <48vqb9$ch5@lastactionhero.rs.itd.umich.edu>#1/1 references: <486j3g$8rn@nuscc.nus.sg> <48i8i7$q8t@news-rocq.inria.fr> <48ja5b$f7c@news.asu.edu> <48ofpa$spa@pan.otol.fi> newsgroups: rec.games.corewar Actually if the line ;redcode-94 is present then it would work just fine... ;redcode-95 would denote the new addressing system. Juho Snellman (poke@lyseo.otol.fi) wrote: : sieben@imap1.asu.edu wrote: : : We could use : : a ;pre : : a< a> ;post : Wasn't one of the requirements for the new standard that all old : programs run unchanged ? Now post-increment would change into : pre-increment, so one would have to modify old warriors. And if i don't : know when the program has been done, i don't know whether modification is : needed. But i do like the symbols othervise, they look quite clear. : -- : Juho Snellman From: Tim Chapman Subject: Re: Ideas for new instructions Date: 1995/11/22 Message-ID: #1/1 newsgroups: rec.games.corewar On Tue, 21 Nov 1995, David Boeren wrote: > John K W (jwilkinson@mail.utexas.edu) wrote: > : Planar wrote: > : >How about using two characters: > : > > : > <@a >@a ; decrement/increment, then indirection > : > @a ; indirection, then decrement/increment > > Heck, I'd prefer something a little less cryptic. I always end up checking > the charts to remind myself of which little funny symbol is which. > > How about something more like this: > > ++a, --a, a++, a-- > > Well? Too funky? At least a lot of beginners would get to understand it > a lot easier, asn we can of course also allow the "old-style" modifiers > too, so it doesn't break existing code. > > I could be wrong, but I don't think this method allows for which of the A or B fields is to be incremented/decremented. -Tim From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: Newbie from Heck Date: 1995/11/22 Message-ID: <9511221758.AA05717@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Bepe Bezzi wrote: >I have the same problem John has, SLIP account, and sometimes I run pmars >from inside Windows 3.1 patched to 32 bits. This allows me to use a slightly >better editor than DOS edit; Pmars gives me no problems, but turtle speed, >while Pmarsv refuses to run giving some system error. >Is there some way to make it run? > The pmarsv text mode display, which comes up by default, is probably what's causing the trouble. For extra speed, pmarsv writes directly to screen memory rather than going thru bios, and from what I've been told, direct hardware access is a no-no under Windows. The VGA display (-v 13) however should work fine. -Stefan From: Anders Ivner Subject: random in round 6. Date: 1995/11/22 Message-ID: <9511221407.AA22031@su8-3.ida.liu.se>#1/1 newsgroups: rec.games.corewar My hypothesis was that having a pseudo-random backup-strategy had played a major role in the outcome of round 6. Looking at which programs incorporated such a strategy it looked like my hypothesis might be correct. However, a closer examination of the matches showed that random strategies were seldom used. In fact, only Machiavelli uses random against other programs than Blizzard. That, and the cooperation, is what pushed it ahead of Maverick and Miss Playful. Conclusion: Random backup-strategies did not play a major role in the outcome of round 6. R - Has random protection of some kind W - Wins big L - Loses big w - Would've won l - Would've lost, but saved by random . - more or less equal Bl Ps Ro nt Wi Th Mac Mav Mi ?w Pl Bi Wh Pa ------------------------------------------------------------------------ Blizzard R : w w w w W c W . W W W W W Psst R : l . . . W- . W- . . W W W W Round 6 Kline R : l . . . . w . . W W- W W W nt entry #6 R : l . . . W . W . W- . . W W Winner R : l . . . . . . . . W- W W- W The Thinker : L . . L . . . . W- W W W W Machiavelli R : c . l . . . . . l? . . . W Maverick : L . . L- . . . . . W . . W Miss Playful R : . . . . . W- . . . W . W W ?whatever? : L . L L- . . w? . . W- W W W PlinySwitch : L L L- . L- L . L L L- . L W Bim bum bam : L L L . L L . . . L . L W WhileAway : L L L L L L . . L L W W W Paranoid : L L L L L L L L L L L L L /Anders From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: Hill Management Date: 1995/11/22 Message-ID: <48vaik$odk@valhalla.stormking.com>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> <48co7i$gm1@news-rocq.inria.fr> <48ldoo$6jv@valhalla.stormking.com> <1995Nov21.115536@acad.drake.edu> <48tbiv$nfa@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: : I'd thought about that once before, but I didn't want to submit : that idea when it seems to take months just to MOVE a Hill. :) I really need to take issue with this. In the beginning there was INTEL, and INTEL was good. Then came STORMKING, and STORMKING was good, but due to a UUCP link it was SLOW. Then INTEL left, and that was sad. Then came PIZZA, and PIZZA was good, except for STORMKING because PIZZA was on the net directly. PIZZA became competition for STORMKING, and STORMKING needed to react. STORMKING bought a 56K and put up a web site, and hoped for the best. Then came "Why do two servers run the same hill, we need to consolidate!". This was a good idea, but needed to be worked between the two KotH maintainers. Then stepped in Stefan, and Stefan got Tuc and Thos to agree on splitting up the hills. (I was going somewhere with this....) I think what I'm trying to say is we both are trying to get your Corewar business and wanting to be *THE* premier site. But then again, maybe thats me. So, thats why its been taking so long, ESPECIALLY cause I haven't heard from Thos! Tuc -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: (no subject) Date: 1995/11/22 Message-ID: <48v9r4$odk@valhalla.stormking.com>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48ldkg$6jv@valhalla.stormking.com> <48rf59$g3t@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: : tuc@news.stormking.com (Scott J. Ellentuch) wrote: : > As for balancing the hills....When Stefan, Thos and I decided to : >only run 1 of any type of hill, we tried to balance it. I guess Stormking : >got a lesser share than expected. I'd be interested in hearing NEW hill : >ideas. As for moving.... We'd need to talk to Thos about that. : > : > : > Tuc : Who is the legendary "Thos" I keep hearing about? He who maintains the Pizza hills. Tuc -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: lewin@netcom.com (Karl Lewin) Subject: Re: Hill Management Date: 1995/11/22 Message-ID: #1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> <48co7i$gm1@news-rocq.inria.fr> <48ldoo$6jv@valhalla.stormking.com> <1995Nov21.115536@acad.drake.edu> newsgroups: rec.games.corewar pk6811s@acad.drake.edu wrote: : Better idea - separate hill-management and load-balancing by farming out : the battles. Instead of running all the battles themselves, the Hill : Manager could email the opponents and parameters to service sites that : would just run them and report the results. Hill Managers could also : run battles, just not all of them. Harness the power of networked : computers to run thousands of battles in a few minutes. If anyone decides to start working on this and wants some help let me know. I had a prototype that ran on a local network (no email used though) for my last attempt at the GA-evolver type deal. I don't know if I still have the code lying around but as long as we don't have to get too elegant I don't remember it being that hard (although the mail stuff may add some complexity) Enough rambling. Let me know if anyone wants to work on this. Karl -- From: max@alcyone.darkside.com (Erik Max Francis) Subject: pMARS Date: 1995/11/23 Message-ID: #1/1 newsgroups: rec.games.corewar Is there a version of pMARS (or any other good Corewar system, for that matter) that runs under Linux/X? Erik Max Francis, &tSftDotIotE || uuwest!alcyone!max, max@alcyone.darkside.com San Jose, California, U.S.A. || 37 20 07 N 121 53 38 W || the 4th R is respect H.3`S,3,P,3$S,#$Q,C`Q,3,P,3$S,#$Q,3`Q,3,P,C$Q,#(Q.#`-"C`- || 1love || folasade _Omnia quia sunt, lumina sunt._ || GIGO Omega Psi || http://www.spies.com/max/ "Hands that once picked cotton can now pick Presidents." -- Jesse Jackson From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Ideas for new instructions Date: 1995/11/23 Message-ID: <4917q8$g84@agate.berkeley.edu>#1/1 references: <48si40$mi1@news-rocq.inria.fr> <48t80v$kp5@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar David Boeren wrote: >How about something more like this: > >++a, --a, a++, a-- > >Well? Too funky? At least a lot of beginners would get to understand it >a lot easier, asn we can of course also allow the "old-style" modifiers >too, so it doesn't break existing code. Neat idea, but it doesn't quite fit with what's actually happening. "a++" strongly implies that the value being accessed by the instruction is the same value that's being incremented -- but it's not, because all the increment and decrement modes are really forms of indirection. (The correct C syntax would be *(a++), etc.). My personal preference is to use Nandor's original suggestion (a, a>) and use the versioning system which I explain fully in my next post. Basically, the idea is to use extra header lines to allow programs written for incompatible standards to work together seamlessly. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: proposal for new MARS version system Date: 1995/11/23 Message-ID: <491j3p$jud@agate.berkeley.edu> newsgroups: rec.games.corewar I was just looking at all the systems people have suggested to add pre- increment and post-decrement addressing modes to pmars and still maintain backward compatibility. It annoyed me that there is a wonderfully simple and intuitive way to represent these modes (a, a>) which has the slight problem that it is not backward compatible. Well, we could always add a ";preincr" header field that activates the new modes. But that's ugly. So, I thought, there must be a better way: and here it is. In all the text below, "incompatibility" refers to incompatibility for *assembly* only. It is assumed that the warriors will be compatible once they get to run-time, as long as they were assembled correctly. The system I propose handles run-time incompatibility as well, but this is less important since it is very unlikely in practise for a slight change in a standard to cause run-time incompatibilities. I have given some thought to this; please look it over and let me know if you think there's something that could be improved. ======================================================================= Add two new header lines: ;standard and ;features. ;standard XX means the warrior is designed to run under ICWS standard XX, where XX is 88, 94, etc. Since "94" ought to be reserved for the official 94 standard when it is approved, we will use 94P for the 94 standard as proposed in the icws94.0202 draft. A warrior without a ;standard line is treated as ;standard 94P. ;features X Y Z etc. means the warrior uses certain enhancements to the standard. Examples might be "macro" (which would do what ";macro" does now) or "pspace". A warrior without a ;features line uses nothing except what is provided by the appropriate ICWS standard. The ;macro header is obsoleted, as is ";assert VERSION > XXX". The ;assert and ;redcode lines would *not* be obsoleted -- ;assert is for battle options rather than assembly options, and ;redcode is just for hill submission and should not be involved (as someone suggested) in assembly options either. Note that standards can be incompatible with each other, and features can be incompatible with each other and even with the standard they modify. Everything pmars has added to the 94 draft (seq/sne/nop opcodes, a-field indirection, for/rof macro expansion, p-space) will count as "features". Each will have its own keyword (sne, a-indr, macro, pspace). The proposed addition of pre-increment and post-decrement would also be a feature (perhaps "postdec"). This system will have some major advantages over the way we handle standards now: It makes it possible to add new features, such as pre-increment and post- decrement, even if the implementation is incompatible with the current standard. Warriors that don't request the feature in their ;features line will be assembled as if the feature did not exist -- so old warriors which use >a for post-increment instead of pre-increment will still work fine. It eliminates the need for ";assert VERSION > XXX". Code that uses ";assert VERSION > XXX" is tied to pmars, and will not work on any other MARS system -- even one which supports all the necessary features! ;standard and ;features are portable across MARS systems. It removes the need for the ;macro header, which is really a kluge to make old warriors work, and replaces it with a general system for making sure old warriors work regardless of the way redcode standards change. It allows for the parallel evolution of different MARS systems. Suppose someone writes a new 94 MARS system, and they provide support for a new pseudo-op called "foo". If you try to assemble a warrior using "foo" under pmars, it will correctly reject it with a message that it doesn't implement the "foo" feature. (Note that if you try this now, pmars will interpret the "foo" as a label, and all sorts of bad things could happen -- including your warrior appearing to assemble, but in fact assembling *wrong*.) Then, when pmars adds support for "foo", the new warrior will work with no modification. Even better, an old warrior that uses "foo" as a *label* will work fine under the new MARS, again with no modification required. If at some point there are many MARS systems, each with a slightly different feature set, this system will allow a warrior to run on all MARS systems that it can run on, without the warrior author having to specify a list of which MARS systems (and version numbers) it is compatible with. Any MARS system which is not capable of running the program will be able to detect this immediately and give an error. It permits new MARS systems to remove support for old syntaxes, and give an error if a program attempts to use an old syntax. For example, suppose that two years from now, everyone is using the new indirection system. Someone is writing a new MARS which needs to be as small as possible, so they remove support for the old indirection system. Now, to make sure that no one tries to use the old system, the MARS checks the ;features line of every program, and if it does *not* request the new indirection system, the MARS gives an error. Wow, that was longer than I thought it would be... it's really not a complicated idea :-) So, what do you think? -- Michael Constant (mconst@soda.csua.berkeley.edu) From: EBonney@gnn.com (Eric Bonney) Subject: What is this game and what do I need, is there a FAQ? Date: 1995/11/23 Message-ID: <493bqf$7k4@news-e1a.megaweb.com>#1/1 newsgroups: rec.games.corewar I am new to this area. What is this game all about, and what would I need to play? Is there an FAQ I could get? If anyone could respond to my email address as I am not sure I will be able to get back to this area again. Thanks, -Eric Bonney EBonney@gnn.com Prejudism is a Learned trait, so What are you teaching your children? From: Bart.Libert@ping.be (Bart Libert, EducaSoft Belgium) Subject: Looking for some GREAT GAMES to DOWNLOAD ???? LOOK HERE !!!!!! Date: 1995/11/23 Message-ID: <492nri$k4e@ping1.ping.be>#1/1 newsgroups: rec.games.corewar We have a huge collection of all sorts of games at. http://www.ping.be/educasoft/english/bbs/games/games.htm Try it and see for yourself !!! Bye, Bart.Libert@ping.be PS: We have 3D-games, Shooting-games, Fighting-games, Puzzles, Card games, Space-games and lots more.... From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: 16-bit version of pMARS v0.8 uploaded Date: 1995/11/24 Message-ID: <9511241618.AA06147@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar We had several requests for this from people with lower end (286-) machines and those who couldn't run 32-bit pmarsv under Windows. Available as: ftp://ftp.csua.berkeley.edu/pub/corewar/incoming/pmars286.zip and from the pMARS home page. -Stefan From: Beppe Bezzi Subject: Beginners ??? hill Date: 1995/11/24 Message-ID: <199511241325.OAA04598@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar Having to monitor beginners hill for Core Warrior, Myer is home for Thanksgiving, I submitted my last test warrior Test L9, third on 94 hill with 144 pts, to Pizza's beginners hill. Here is the (unexpected indeed) result: Your overall score: 137.028571 ChainBomber has been pushed off the Beginner hill. The current Beginner hill: # %W/ %L/ %T Name Author Score Age 1 46/ 38/ 16 Fire Master v1.5 JS Pulido 154 3 2 41/ 30/ 29 Lurker 1.1 Kurt Franke 152 18 3 36/ 21/ 43 teamwork? Kurt Franke 150 20 4 43/ 40/ 17 TEST JS Pulido 145 2 5 29/ 16/ 56 Schizo J. Doster 142 50 6 34/ 30/ 35 Hint Test v4 M R Bremer 139 16 7 33/ 29/ 38 test L 9 Beppe Bezzi 137 1 8 38/ 40/ 22 Look J. Doster 135 47 .... Now I'm not so sure which hill is the beginner's one. :-) -Beppe From: Tim Chapman Subject: Re: proposal for new MARS version system Date: 1995/11/24 Message-ID: #1/1 newsgroups: rec.games.corewar Just thought that I'd say that I like Michael Constant's new proposal for warrior specifications. It seems a simple and flexible system, and will also allow new ideas to be tried out easily, without too many implementation problems. -Tim Chapman From: sieben@imap1.asu.edu Subject: Re: summary on read/write limits [part 1] Date: 1995/11/24 Message-ID: <495hot$90t@news.asu.edu>#1/1 references: <48idlv$s6s@news-rocq.inria.fr> <48jaft$f7c@news.asu.edu> <494k4n$hjq@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar (Damien.Doligez@inria.fr) wrote: : In article <48jaft$f7c@news.asu.edu>, sieben@imap1.asu.edu writes: : >It's not that hard to launch. I remember I posted a launcher a long time : >ago. I might be able to dig it up. : You'll find it there: : http://pauillac.inria.fr/~doligez/corewar/post/launch.txt : You posted it on November 11, 1993: only a little bit more than 2 : years ago. : But it was under JMP range limits, not write limits (or was it both ?) As I remember it works under both. The idea is to have a small worm that copies itself into the starting locations of the impring and starts the components of the ring at the same time. I think it could be easily modified to launch an infinite impring. Nandor. From: sieben@imap1.asu.edu Subject: Re: Ideas for new instructions Date: 1995/11/24 Message-ID: <494raf$2c5@news.asu.edu>#1/1 references: <4943hh$eur@news-rocq.inria.fr> newsgroups: rec.games.corewar : How about: : <>a a>> (pre- and post-increment) : And of course the old notation keeps its meaning. I don't really like two different notations for the same thing. It seems most of us likes a a> and the only problem with it is backward compatibility. On the other hand >a is not standard. In fact we don't even have a standard. The idea behind pmars is to experiment. It seems that if we ever want to add post decrement then our choice for post decrement was a bad one. So what. We can change it any time. I know we might loose some good warriors. But if we implement some form of ;feature suggested by Michael then it's not a problem. Also it's easy to write a translator program that changes >a to a> and adds a comments like ;feature postinc. My point is that we shouldn't care so much about backward compatibility for non standard features. Another thing is that we talk maybe too much about notation before we decide if we really want these new addressing modes. Nandor. From: Planar Subject: Re: proposal for new MARS version system Date: 1995/11/24 Message-ID: <4946jl$f6e@news-rocq.inria.fr>#1/1 references: <491j3p$jud@agate.berkeley.edu> newsgroups: rec.games.corewar In article <491j3p$jud@agate.berkeley.edu>, mconst@soda.CSUA.Berkeley.EDU (Michael Constant) writes: >means the warrior is designed to run under ICWS standard XX, where XX >is 88, 94, etc. Since "94" ought to be reserved for the official 94 >standard when it is approved, we will use 94P for the 94 standard as >proposed in the icws94.0202 draft. A warrior without a ;standard line >is treated as ;standard 94P. IMHO, it would be better to use the draft version numbers. There is already a new version of the draft, and there will be at least one more. >Wow, that was longer than I thought it would be... it's really not a >complicated idea :-) So, what do you think? I was going to say we don't need something so sophisticated, but... In my Web page, there are some old warriors written for the '86 standard, some for the '88 standard, some for '88 with write limits, and some for an extended version of '88 with pre-increment (that's right, PRE-increment, with the same syntax that we use for post-increment...) Of course, these warriors are mainly of historical interest, but I'd like to be able to run the warriors from the last two years without problems. The only problem I see with your proposal is that writing a MARS system becomes a more complex task. Oh, and while I'm talking about my Web page, I've finished going through the rec.games.corewar archives. I still have a huge hole between August 1994 and July 1995: there are no archives for that period, and I couldn't read the newsgroup. If somebody has saved many articles from this period (or even only the warriors, preferably with the author's comments) please contact me by e-mail. -- Planar And if you're not yet tired of seeing the URL, here it is: http://pauillac.inria.fr/~doligez/corewar/ From: akemi@netcom.com (David Boeren) Subject: Re: Ideas for new instructions Date: 1995/11/24 Message-ID: #1/1 references: <4943hh$eur@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar (Damien.Doligez@inria.fr) wrote: : How about: : <>a a>> (pre- and post-increment) : And of course the old notation keeps its meaning. I'll definately support this notation. MUCH easier to understand than the old style with it's obscure symbols. And it doesn't break compatibility, so that's another major plus. Can we have a show of hands? : Oh, and I've found a use for IJN. Are we going to add it ? And how : about SLE, SGT, and SGE ? This discussion will never end. I don't : know where to stop. Well, we could add an entire set of jump condition opcodes. There are only about 8-10 or so, right? I see no reason NOT to add them, as long as everyone feels they serve a purpose and aren't just more baggage. I have no idea what IJN is supposed to do though. Can someone enlighten me? Looks like increment, jump not zero, parallel to DJN now, but I don't want to presume. But if it is, does this add very much capability to corewar, or is it just a way to reduce someone's pet warrior by 1 instruction? Actually, I think the same question can be asked of a lot of things. One major effect of the .MODE in the new pmars is to ability to have lots of extra instruction scrambling occur whenever you use an instruction which one needs one operand. Now warriors end up modifying more locations by cramming decrements into every nook and cranny of their code hoping to kill an imp or wound something. I know I'm only a beginner, but is the point supposed to be to restructure the language so that one instruction can screw up as much core as possible? Anyway, I'm definately in favor of the new notation, and I'm glad that both incrementing and decrementing will be available. From: Planar Subject: Re: summary on read/write limits [part 1] Date: 1995/11/24 Message-ID: <494k4n$hjq@news-rocq.inria.fr>#1/1 references: <48idlv$s6s@news-rocq.inria.fr> <48jaft$f7c@news.asu.edu> newsgroups: rec.games.corewar In article <48jaft$f7c@news.asu.edu>, sieben@imap1.asu.edu writes: >It's not that hard to launch. I remember I posted a launcher a long time >ago. I might be able to dig it up. You'll find it there: http://pauillac.inria.fr/~doligez/corewar/post/launch.txt You posted it on November 11, 1993: only a little bit more than 2 years ago. But it was under JMP range limits, not write limits (or was it both ?) -- Planar P.S. I spent two weeks on that Web page. I learned a lot of tricks. Now I'll put them to good use. From: Planar Subject: summary on read/write limits [part 2] Date: 1995/11/24 Message-ID: <494lli$hjq@news-rocq.inria.fr>#1/1 references: <48idlv$s6s@news-rocq.inria.fr> newsgroups: rec.games.corewar Actually, there's not much to say. In 1993 and 1994, a few people have proposed that the way of encouraging smarter warriors was a big core size. Hence the shape of the current experimental hill (if only it would work). One argument against read/write ranges is that there are strange effects when the read range is different from the write range: a predecrement indirect access would decrement one location but use another location for the indirection. Ugh. The alternative is to make the write access fail. The good old argument was of course repeated: with write limits, the only viable warrior form is the replicator, and we'd only write papers. I don't quite buy this argument, but I do believe that read/write ranges would reduce the variety of strategies instead of increasing it. It seems that most of the veterans already had alread made up their minds against read/write limits, at the beginning of 1994. I guess I've stopped trying to be objective and I've been making the case against read/write limits (not that I consider myself a veteran). What I really want is that we come to some sort of concensus about whether to remove them from the draft. And I'd prefer the answer to be yes. Finally, I'll quote Nandor's counter-argument to people who complain about the lack of intelligence of current core war programs: >From: >Date: Sat, 6 Nov 1993 22:07:40 MST >I've read the dumb bomber expression many times in the last few weeks. >A bomber might look dumb but writing a good bomber with self modification, >coreclear, gates etc. is not so simple. Look for example at Twill. I wouldn't >say it's a dumb bomber but rather a masterpice. Writing complicated and still >very short warriors is an important part of corewar. [...] >Nandor. -- Planar P.S. Since the X-hill on pizza is broken, maybe we could have one on StormKing ? It would even spare Thos the work of fixing the pizza X-hill. You see, I have a feeling that continuous launching is going to be more useful in the big core. From: Planar Subject: Re: Ideas for new instructions Date: 1995/11/24 Message-ID: <4943hh$eur@news-rocq.inria.fr>#1/1 references: newsgroups: rec.games.corewar >On Tue, 21 Nov 1995, David Boeren wrote: > >> ++a, --a, a++, a-- In article , Tim Chapman writes: > >I could be wrong, but I don't think this method allows for which of the >A or B fields is to be incremented/decremented. I think you're right, and moreover "--a" already means something else: it is the same as a, because the pMARS evaluator knows about unary minus (and I think we should add it to the draft). How about: <>a a>> (pre- and post-increment) And of course the old notation keeps its meaning. Oh, and I've found a use for IJN. Are we going to add it ? And how about SLE, SGT, and SGE ? This discussion will never end. I don't know where to stop. -- Planar From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: 94x hill and P-space (was Re: summary on read/write limits [part 2]) Date: 1995/11/24 Message-ID: <9511241853.AA06183@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Planar wrote: >P.S. Since the X-hill on pizza is broken, maybe we could have one on > StormKing ? It would even spare Thos the work of fixing the > pizza X-hill. You see, I have a feeling that continuous > launching is going to be more useful in the big core. > I'd also like the 55440 coresize hill reopened. Best at stormking to even out the load. Even though this hill hasn't seen a lot of action lately, I'd expect interest to resurge again now that we have P-space. Qscanners seem to keep pspacers in check on the 8000 hill, and since qscanners are that much less effective in a large core, this hill could become a fertile ground for complex switching mechanisms. -Stefan From: Beppe Bezzi Subject: Re: Beginners ??? hill Date: 1995/11/25 Message-ID: <199511252309.AAA18822@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 13.39 25/11/95 -0500, sieben@imap1.asu.edu wrote: >Beppe Bezzi (bezzi@iol.it) wrote: >: Having to monitor beginners hill for Core Warrior, Myer is home for >: Thanksgiving, I submitted my last test warrior Test L9, third on 94 hill >: with 144 pts, to Pizza's beginners hill. > >: Here is the (unexpected indeed) result: > >: Your overall score: 137.028571 >:... > >: Now I'm not so sure which hill is the beginner's one. :-) > >Well this is the way corewar works. When a warrior gets on a hill it only >means it's good against those 20 warriors on the hill. It doesn't mean >it's good against anything else. Also when an expert plays against a >beginner (say in chess) the expert can win quickly by taking risks. >Playing moves that would be dangerous against another expert but the same >moves are very effective and not very risky against a beginner. > That's true about corewar; when I wrote the warrior I knew what I were going to meet in the hill and I used the right counter measures; the beginners hill was something totally unknown to me and the unexpected happened. :-) In chess an expert always beats a beginner, and has no need to take, against him, the risks it has to take to try winning against another expert. Now I'm a bit curious to see if La Bomba, 94 king, would be king in beginners hill too, and a lot scared it won't; better not to try and risk to lose my, and other veterans, face :-) [if you see an unnamed warrior, sent by 'no name' through an anonymous remailer, score high, but not on top, in the beginners hill, it's _not_ La Bomba :-] What I hope is that beginner start submitting their warriors to 94 hill, once they proved to do well in -b; they have nothing to lose, the worst thing that may happen is scoring 80 points, but is likely that a few of the top scoring -b programs will enter 94 hill too, if they find here a favourable environment. >Nandor. > > > > > From: sieben@imap1.asu.edu Subject: Re: Beginners ??? hill Date: 1995/11/25 Message-ID: <497j1o$pih@news.asu.edu>#1/1 references: <199511241325.OAA04598@iol-mail.iol.it> newsgroups: rec.games.corewar Beppe Bezzi (bezzi@iol.it) wrote: : Having to monitor beginners hill for Core Warrior, Myer is home for : Thanksgiving, I submitted my last test warrior Test L9, third on 94 hill : with 144 pts, to Pizza's beginners hill. : Here is the (unexpected indeed) result: : Your overall score: 137.028571 : : ChainBomber has been pushed off the Beginner hill. : The current Beginner hill: : # %W/ %L/ %T Name Author Score Age : 1 46/ 38/ 16 Fire Master v1.5 JS Pulido 154 3 : 2 41/ 30/ 29 Lurker 1.1 Kurt Franke 152 18 : 3 36/ 21/ 43 teamwork? Kurt Franke 150 20 : 4 43/ 40/ 17 TEST JS Pulido 145 2 : 5 29/ 16/ 56 Schizo J. Doster 142 50 : 6 34/ 30/ 35 Hint Test v4 M R Bremer 139 16 : 7 33/ 29/ 38 test L 9 Beppe Bezzi 137 1 : 8 38/ 40/ 22 Look J. Doster 135 47 : .... : Now I'm not so sure which hill is the beginner's one. :-) Well this is the way corewar works. When a warrior gets on a hill it only means it's good against those 20 warriors on the hill. It doesn't mean it's good against anything else. Also when an expert plays against a beginner (say in chess) the expert can win quickly by taking risks. Playing moves that would be dangerous against another expert but the same moves are very effective and not very risky against a beginner. Nandor. From: sieben@imap1.asu.edu Subject: Re: Ideas for new instructions Date: 1995/11/25 Message-ID: <497ieu$pih@news.asu.edu>#1/1 references: <4943hh$eur@news-rocq.inria.fr> newsgroups: rec.games.corewar David Boeren (akemi@netcom.com) wrote: : Planar (Damien.Doligez@inria.fr) wrote: : : How about: : : <>a a>> (pre- and post-increment) : : And of course the old notation keeps its meaning. : I'll definately support this notation. MUCH easier to understand than the : old style with it's obscure symbols. And it doesn't break compatibility, so : that's another major plus. Can we have a show of hands? I can't see the major difference. It's basically the same notation with mores symbols. I wouldn't say it's MUCH easier to understand. I would say It's much more to type. Nandor. From: John K W Subject: Re: (no subject) Date: 1995/11/25 Message-ID: <495r1h$bg7@geraldo.cc.utexas.edu>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48ldm6$6jv@valhalla.stormking.com> <48rf2o$g3t@geraldo.cc.utexas.edu> <48uevo$pat@earth.superlink.net> newsgroups: rec.games.corewar tuc@mars.superlink.net (Scott J. Ellentuch) wrote: >John K W (jwilkinson@mail.utexas.edu) wrote: >wrong!) I do have it on my list, and I do plan to do it. However, it >seems that when I ask for comments on things I *DO* get put in, I don't >hear much back. (Not an excuse........Just a comment) > > Tuc Tuc, we love you. It's time for a group hug, people! -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: 94x hill and P-space (was Re: summary on read/write limits [part 2]) Date: 1995/11/25 Message-ID: <495qm9$bg7@geraldo.cc.utexas.edu>#1/1 references: <9511241853.AA06183@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) wrote: >I'd also like the 55440 coresize hill reopened. Best at stormking to even out >the load. Even though this hill hasn't seen a lot of action lately, I'd expect >interest to resurge again now that we have P-space. Qscanners seem to keep >pspacers in check on the 8000 hill, and since qscanners are that much less >effective in a large core, this hill could become a fertile ground for complex >switching mechanisms. Good idea, with one caviat. (Is that how you spell that word??) Anyway, 55440 is awfully large... larger than perhaps is nescessary. Should the size of the Hill be looked at, or is 55440 a better choice, in part because of it's past use as a Hill? -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: sieben@IMAP1.ASU.EDU Subject: standard Date: 1995/11/26 Message-ID: #1/1 newsgroups: rec.games.corewar Subject: Re: Ideas for new instructions Newsgroups: rec.games.corewar References: <9511260803.AA06477@idnsun.gpct.vanderbilt.edu.noname> <499g59$e3f@agate.berkeley.edu> Distribution: : Speaking of which: I think now would be a very good time to stop and : evaluate all the things we've added to the draft over the past few : months. They may not all necessarily be good! So far, the attitude : towards new features has been "let's try it out and see what it's : like". Which is good, in moderation -- but periodically, we have to : go back and throw out all the ones that were not, in fact, worthwhile. : Otherwise, the redcode language will just continue to accumulate cruft : without necessarily gaining any power. X-Newsreader: TIN [version 1.2 PL2] : My personal opinion is that P-space, especially, needs to be : evaluated. Granted, it makes for some wonderful tournament problems, : but we need to consider whether it's something we really want in our : "mainstream" standard. I think that P-space ought to end up as an : extension to the 94 standard -- perhaps used in a hill or two, and : perhaps used for tournament problems, but *not* included in the ICWS'94 : proposal. Corewar has always had extended standards, and I think this : the best way for corewar veterans to experiment with new ideas without : complicating the basic standard -- and increasing the difficulty of : learning corewar -- unncessarily. : -- : Michael Constant (mconst@soda.csua.berkeley.edu) I think that features that are already implemented but not in the future standard still could be described in the standard. We could use Michael's description idea. We describe many features like read-write limits etc. and then we say that the standard includes this and that feature. So even if a feature is not in the stanfard, everybody knows what it is and so it can be used in tournaments or in future standards. Nandor. From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Ideas for new instructions Date: 1995/11/26 Message-ID: <499g59$e3f@agate.berkeley.edu>#1/1 references: <9511260803.AA06477@idnsun.gpct.vanderbilt.edu.noname> newsgroups: rec.games.corewar Stefan Strack wrote: >Michael Constant wrote: >>Of course, this brings up a basic philosophical point: all other things >>being equal, do we want redcode to be restrictive or permissive? [...] > >That's a very good point. Any new feature we add will make it harder for >beginners to get into core war. The A-indirect modes were a nice complement >to the opcode modifiers, making A-operands just as easy to access as B- >operands. P-space was an attempt to add memory to warriors without too much >impact on their actual battle operation. I am not sure whether any of the >recently proposed new addressing modes or opcodes add any more to the game >than making existing warriors shorter. Speaking of which: I think now would be a very good time to stop and evaluate all the things we've added to the draft over the past few months. They may not all necessarily be good! So far, the attitude towards new features has been "let's try it out and see what it's like". Which is good, in moderation -- but periodically, we have to go back and throw out all the ones that were not, in fact, worthwhile. Otherwise, the redcode language will just continue to accumulate cruft without necessarily gaining any power. My personal opinion is that P-space, especially, needs to be evaluated. Granted, it makes for some wonderful tournament problems, but we need to consider whether it's something we really want in our "mainstream" standard. I think that P-space ought to end up as an extension to the 94 standard -- perhaps used in a hill or two, and perhaps used for tournament problems, but *not* included in the ICWS'94 proposal. Corewar has always had extended standards, and I think this the best way for corewar veterans to experiment with new ideas without complicating the basic standard -- and increasing the difficulty of learning corewar -- unncessarily. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: Ideas for new instructions Date: 1995/11/26 Message-ID: <9511260803.AA06477@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Michael Constant wrote: > Of course, this >brings up a basic philosophical point: all other things being equal, do >we want redcode to be restrictive or permissive? The 88 standard had a >rather clear answer to that question -- "restrictive" -- but 94 seems >to be moving away from that. We have to weigh the possible added power >of new features with the added complexity they bring. ICWS'88 redcode >is a very simple language; the current pmars implementation of 94 is >much less so. Do we want to continue in this direction? I don't know. That's a very good point. Any new feature we add will make it harder for beginners to get into core war. The A-indirect modes were a nice complement to the opcode modifiers, making A-operands just as easy to access as B-operands. P-space was an attempt to add memory to warriors without too much impact on their actual battle operation. I am not sure whether any of the recently proposed new addressing modes or opcodes add any more to the game than making existing warriors shorter. -Stefan From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: proposal for new MARS version system Date: 1995/11/26 Message-ID: <498jeu$3rk@agate.berkeley.edu>#1/1 references: <491j3p$jud@agate.berkeley.edu> newsgroups: rec.games.corewar Since the response to my versioning system has been relatively good, I'd like to correct a mistake I made in my initial post and also suggest an "official" list of standards and features for us to use. I agree with Planar that draft version numbers are a good way to keep track of the current 94 standard. At this point, there is only one standard we need to support: 94D33 the draft 94 standard, v3.3 After talking a little with Nandor, I think this is a complete list of features we need to support: for for/rof macros multiequ multi-line equ statements a-indr a-field indirection: { } * pspace p-space as implemented in pmars v8 postdec (proposed) post-decrement and pre-increment addressing The "seq" feature I proposed earlier has been removed, because it was added to v3.3 of the 94 draft. Also, the behavior I specified for warriors without a ;standard or ;features line was a little inconsistent. Here's what I meant to say: A warrior without a ;standard line is not allowed to have a ;features line, and it is assembled as if it had: ;standard 94D33 ;features for multiequ a-indr pspace A warrior with a ;standard line but no ;features line is compatible with the standard and requires no special extensions. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Ideas for new instructions Date: 1995/11/26 Message-ID: <498evp$2e5@agate.berkeley.edu>#1/1 references: <4943hh$eur@news-rocq.inria.fr> newsgroups: rec.games.corewar >Planar (Damien.Doligez@inria.fr) wrote: >: How about: >: <: >>a a>> (pre- and post-increment) > >I'll definately support this notation. MUCH easier to understand than the >old style with it's obscure symbols. And it doesn't break compatibility, >so that's another major plus. Can we have a show of hands? "MUCH easier" to understand than the current a? A tad easier, perhaps... and it's certainly no easier than a a>. At the risk of restating myself, I think that Nandor's original proposal is the simplest and most intuitive of all. The proposed 94 standard is in the playtesting phase right now. This is the point at which we're supposed to try out new ideas and see what works and what is worthwhile. We can't afford to introduce clumsy notation just to maintain compatibility with warriors written to an earlier revision of the draft. We must be willing to alter the draft when we think the change would improve it. I already posted a very complete system for dealing with revisions of standards and features, so the change would *not* even break warriors written with the "old" 94 notation. (And compatibility issues aside, I think we all agree that a a> is by far the best notation proposed so far.) >I have no idea what IJN is supposed to do though. Can someone enlighten me? >Looks like increment, jump not zero, parallel to DJN now, but I don't want >to presume. Yup, that's exactly what it is. >But if it is, does this add very much capability to corewar, or is it just a >way to reduce someone's pet warrior by 1 instruction? I believe this was the argument that was brought up last time IJN was proposed -- no one could think of any real use for it. Of course, this brings up a basic philosophical point: all other things being equal, do we want redcode to be restrictive or permissive? The 88 standard had a rather clear answer to that question -- "restrictive" -- but 94 seems to be moving away from that. We have to weigh the possible added power of new features with the added complexity they bring. ICWS'88 redcode is a very simple language; the current pmars implementation of 94 is much less so. Do we want to continue in this direction? I don't know. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: Beppe Bezzi Subject: Core warrior #7 - 1/2 Date: 1995/11/27 Message-ID: <199511271756.SAA03660@iol-mail.iol.it> newsgroups: rec.games.corewar .xX$$x. .x$$$$$$$x. d$$$$$$$$$$$ ,$$$$$$$P' `P' , . $$$$$$P' ' .d b $$$$$P b ,$$x ,$$x ,$$x ,$$b $$. Y$$$$' `$. $$$$$$. $$$$$$ $$P~d$. d$$$b d d$$$ `$$$$ ,$$ $$$$$$$b $$$P `$ $$$b.$$b `Y$$$d$d$$$' . . a . a a .aa . a `$$$ ,$$$,$$' `$$$ $$$' ' $$P$XX$' `$$$$$$$$$ .dP' `$'$ `$'$ , $''$ `$'$ `Y$b ,d$$$P `$b,d$P' `$$. `$$. , `$$P $$$' Y $. $ $ $ Y..P $ `$$$$$$$' $$$P' `$$b `$$$P `P `$' `Y'k. $. $. $. $$' $. Issue 7 November 27, 1995 ______________________________________________________________________________ Core_Warrior_ is a weekly newsletter promoting the game of corewar. Emphasis is placed on the most active hills--currently the '94 draft hill and the beginner hill. Coverage will follow where ever the action is. If you have no clue what I'm talking about then check out these five-star internet locals for more information: FAQs are available by anonymous FTP from rtfm.mit.edu as pub/usenet/news.answers/games/corewar-faq.Z FTP site is: ftp.csua.berkeley.edu /pub/corewar Web pages are at: http://www.stormking.com/~koth ;Stormking http://www.ecst.csuchico.edu/~pizza/koth ;Pizza http://pauillac.inria.fr/~doligez/corewar/ ;Planar ______________________________________________________________________________ Greetings. This week there is another juicy, at least in my hopes, number of Core warrior. The hint will cover bombers and bombs, including Paul Kline's contribute and Torch 18 code; Robert Mcrae introduces you to quickscannes secrets and Planar finishes the continual launch imps topic, and unveils his new warrior Impfinity 3i. Many thanks to them and to all contributing to the newsletter. Last minute new: big (CORESIZE 55440) hill has been reopened at Stormking server, address: ;redcode-94x Enjoy it and many thanks Tuc. ______________________________________________________________________________ Current Status of the Internet Pizza Server ICWS '94 Draft Hill: # %W/ %L/ %T Name Author Score Age 1 47/ 38/ 14 quiz Schitzo 156 78 2 43/ 34/ 23 test lp 2 Beppe Bezzi 152 4 3 38/ 25/ 37 La Bomba Beppe Bezzi 151 73 4 43/ 36/ 22 Derision M R Bremer 150 97 5 37/ 31/ 32 Torch t18 P.Kline 143 457 6 37/ 39/ 24 myVamp v3.7 Paulsson 135 425 7 36/ 37/ 27 endpoint . M R Bremer 134 102 8 38/ 43/ 19 Porch Swing + Randy Graham 134 158 9 26/ 20/ 54 Fly Fishing w/Plastic Wor Karl Lewin 131 55 10 38/ 45/ 17 Frontwards Steven Morrell 131 5 11 33/ 35/ 32 Phq Maurizio Vittuari 131 559 12 40/ 48/ 13 Leprechaun on speed Anders Ivner 131 253 13 33/ 35/ 32 Son & Father Maurizio Vittuari 130 108 14 36/ 44/ 20 myZizzor v2.0 Paulsson 128 8 15 27/ 27/ 46 Jack in the box Beppe Bezzi 128 445 16 20/ 12/ 67 Impfinity v3i Planar 128 7 17 31/ 34/ 36 Father & Son Maurizio Vittuari 127 107 18 33/ 41/ 25 Armory - A5 Wilkinson 126 596 19 24/ 22/ 54 juliet and paper M R Bremer, B. Bezzi 125 74 20 19/ 21/ 60 test4 Kurt Franke 118 1 After last week revolution we had a quiet one. Very little to report: quiz takes the head even if La Bomba is still in top positions, Morrell and Paulsson submitted new version of their warriors pushed off last week. Planar's new Impfinity enters the hill, you can see the code in Planar's corner, Kline attempted a new p-spacer without success. In the bottom Armory is shuffling a bit, but still resists junger warrior challenges. Franke, one of beginners hill top scorers, enters the bottom of 94 ______________________________________________________________________________ 94 - What's New 11 39/ 43/ 19 myZizzor v2.0 Paulsson 135 1 10 23/ 13/ 64 Impfinity v3i Planar 133 1 19 37/ 47/ 16 Frontwards Steven Morrell 128 1 20 19/ 21/ 60 test4 Kurt Franke 118 1 ______________________________________________________________________________ 94 - What's No More 21 34/ 49/ 17 Scissors v.a1 John K. Wilkinson 119 28 21 31/ 50/ 19 Scissors v.a4 John K. Wilkinson 113 4 21 20/ 17/ 63 TimeScape (1.7) J. Pohjalainen 122 17 21 14/ 11/ 75 Evolve 6.3 John Wilkinson 118 24 The calm after the tempest, no aged warrior has been pushed off. ______________________________________________________________________________ What's old 18 33/ 41/ 25 Armory - A5 Wilkinson 126 596 11 33/ 35/ 32 Phq Maurizio Vittuari 131 559 5 37/ 31/ 32 Torch t18 P.Kline 143 457 15 27/ 27/ 46 Jack in the box Beppe Bezzi 128 445 6 37/ 39/ 24 myVamp v3.7 Paulsson 135 425 12 40/ 48/ 13 Leprechaun on speed Anders Ivner 131 253 Veterans surviving last week carnage improve their scores a little. Armory and Jack in the box are having some problems, while Torch and myVamp are still very effective. _____________________________________________________________________________ Current Status of the Internet Pizza Server Beginner's Hill: # %W/ %L/ %T Name Author Score Age 1 45/ 35/ 20 Clear Sighted v1 JS Pulido 156 3 2 45/ 38/ 18 dualstrat v.0.2 Brian Haskin 152 2 3 36/ 22/ 41 teamwork? Kurt Franke 150 23 4 44/ 39/ 17 Fire Master v1.5 JS Pulido 148 6 5 36/ 33/ 31 Lurker 1.1 Kurt Franke 139 21 6 33/ 29/ 38 test L 9 Beppe Bezzi 136 4 7 26/ 20/ 54 Schizo J. Doster 132 53 8 31/ 31/ 38 Hint Test v4 M R Bremer 131 19 9 21/ 12/ 67 Impfinity v3c11 Planar 130 65 10 21/ 21/ 58 Trapper 1.1 Kurt Franke 121 1 11 20/ 19/ 61 Paper8-III G. Eadon 120 11 12 32/ 45/ 23 Look J. Doster 120 50 13 19/ 18/ 64 Sheet 1.0 J. Doster 120 63 14 14/ 9/ 77 RingWorm_v2.5 Calvin Loh 118 36 15 17/ 17/ 65 RingWorm_v2.4 Calvin Loh 118 51 16 12/ 7/ 81 Impfinity v1 Planar 116 97 17 28/ 41/ 31 Good old DJN Test Karl Lewin 115 16 18 20/ 26/ 53 Loh_tst_1.3 Calvin Loh 114 26 19 10/ 9/ 81 NewerPaper Kurt Franke 111 17 20 27/ 45/ 28 Paper Shredder 2.1 Kurt Franke 108 20 The very active beginners hill shows five new entries in the top ten positions. Pulido, Haskin and Franke seem ready to make the jump to veterans. Bezzi, a new author, at least from when I'm following beginners, enters in 6th position with a warrior that was 3rd in 94 hill :-) The morale of the story is that: The beginners hill level has grown in these weeks, perhaps it's higher than ever. All those who have a warrior doing well in -b hill have to try the -94, at worst you'll score 90 points finding 94 hill hostile to the warrior kind you are submitting, but with a little luck you can enter and begin making experience. _____________________________________________________________________________ HALL OF FAME * means the warrior is still running. Pos Name Author Age Strategy 1 Iron Gate 1.5 Wayne Sheppard 926 CMP scanner 2 Agony II Stefan Strack 912 CMP scanner 3 Blue Funk Steven Morrell 869 Stone/ imp 4 Thermite 1.0 Robert Macrae 802 Qscan -> bomber 5 Blue Funk 3 Steven Morrell 766 Stone/ imp 6 HeremScimitar A.Ivner,P.Kline 666 Bomber 7 Armory - A5 Wilkinson 596 * P-warrior 8 Phq Maurizio Vittuari 559 * Qscan -> replicator 9 B-Panama X Steven Morrell 518 Stone/ replicator 10 Torch t18 P.Kline 457 * Bomber 11 Jack in the box Beppe Bezzi 445 * P-warrior 12 myVamp v3.7 Paulsson 425 * Vampire 13 NC 94 Wayne Sheppard 387 Stone/ imp 14 Cannonade P.Kline 382 Stone/ imp 15 Torch t17 P.Kline 378 Bomber 16 Lucky 3 Stefan Strack 355 Stone/ imp 17 Request v2.0 Brant D. Thomsen 347 Qvamp -> vampire 18 Dragon Spear c w blue 346 CMP scanner 19 juliet storm M R Bremer 333 Stone/ imp 20 Frontwards Steven Morrell 323 One shot scanner Armory, very near 600 age now, and Phq consolidate their position in the hall of fame; Torch enters top ten trailing Jack and myVamp, all three well over 400 age. Frontwards enters bottom place pushing Timescape off. ______________________________________________________________________________ The Hint Hello folks, last week Myers introduced the bomber topic with two classic stones, Blue Funk and juliet storm; these guys are four-five lines long, and found their effectiveness on their small size and resilience more than on speed, they are both at 33% c, one bomb every three cycles, and effectiveness of their bombs, simple dat 0,0. There is another category of more complex bombers that balance the increased size with a greater speed and/or deadlier bombs. Who better than Paul Kline, Torch's author, can speak of this argument. ---------- Your basic 'stone' bomber is based on this fragment: incr spl #step,#-step <- self-splitter add incr,1 <- step up the pointers mov <0,0 <- decrement one and bomb the other djn -2,<-10 <- loop and sequential decrement Steven Morrell's discussion last issue showed how to optimize this for maximum bombing duration, but his comment about Emerald is too generous. I never realized or designed Emerald's pattern, it was just the best of a large number of step sizes I tried. Anyway, the above delivers one decrement and one bomb in three cycles. However it is possible for the opponent to immunify part of his code to decrements, and thereby reduce this bomber to something much less than 66% effective speed. A search through old programs (still a gold mine!) turns up this one by Paul Kilroy: ;name Ike v.21 ;author Paul S. Kilroy ;strategy A bomber with a cool twist bomb spl 0 ,jump ptr dat #0 ,#0 inc add #468,b start jmz inc ,@b b mov bomb,@464 mov bomb,@b jump jmp inc mov 10 ,<-2 end start Which is your basic spl-bombing b-scanner with, as he says "a cool twist". When he finds a non-zero location he uses it as a pointer and bombs through it, then bombs the found location. In other words, bombing two locations without an intermediate ADD. I was wanting to make this a pure non-scanning bomber, which is easy enough. But the results were not exceptional. With this code you get a nice 50% hard bomber: bomber add #step+step,2 mov bomb,@1 mov bomb,@0 jmp bomber bomb dat #0,step Unfortunately it is a little bigger than the 4-line version and not quite as fast, even though it delivers real bombs instead of decrements. It becomes a little more durable with a leading SPL which keeps single dat-bombs from killing it. And it still loses completely to paper. Anders Ivner's HeremII uses similar code to drop alternating spl and dat-bombs that are very widely spaced in core. HeremII works somewhat against old style paper, but is helpless against Silk. To kill paper requires some kind of spl-bomb that slows it down enough to give a sequential clear time to wipe the whole core. A split-carpet like Agony's works very well, but this bombing routine won't accomodate one. A spl-jmp could be delivered by alternating spl's and jmp's, with an eventual wrap-around to match spl's to jmp's. But single spl's and single jmp's are not only useless against today's paper, they are actually dangerous, since they can mutate the opponent into a whole lot of sequential core-clear/bombers. Enter the mov-spl ('incendiary') bomb, which is a little two-line program that you drop on the opponent causing him to write and execute his own spl-carpet. The important feature of this bomb is that the components can be well separated - hence alternating bombs. Here is the working part of Torch 18, which bombs extensively with mov-spl bombs, does one core wipe with a spl, then goes into a repeating forward core-clear with dat. It also has a nice feature in that if it is overrun with a djn-stream it immediately starts the forward dat-clear process, usually killing the nasty opponent. gate dat 0,0 for 3 dat 0,0 rof w2 dat -7,cp-gate+3 dat 0,0 wipe dat -7,cp-gate+3 sp spl #-1-step,-step ; spl half of the incendiary in sub #step+step,@msp msm mov sm,*tgt+(step*count)-17228 msp mov sp,@msm ; bomb alternately with spl & mov tgt jmz in,#0 ; bombed with spl to start clear clr mov @cp,>gate cp djn.b clr,{wipe+1 for 2 dat 0,0 rof sm mov step+1,>step+1 ; mov half of the incendiary Notice that in the inner loop the instructions are reversed from the example - instructions following a SPL execute in reverse order. Torch is bigger than a 4-line stone and will lose most of those battles. However, those stones are paper-bait even with supporting imps while Torch has the punch to stay on the Hill. The current version also uses a decoy to foil programs like Withershins Thrice and Porch Swing. Questions for thought: What is the best 1-line bomb? What is the best 2-line bomb? What is the best 3-line bomb? Answer correctly and you could go straight to the top of the heap .. uh Hill! Paul Kline pk6811s@acad.drake.edu ---------- Let's speak a bit of bombs; what is the best possible bomb? The answer to this question is another question: who are you shooting at? If our enemy is a single process, long warrior like a scanner the answer is easy, no bomb at all... yes no bomb, taking a cell from somewhere in the core, usually a dat 0,0 and throwing it in the middle of our enemy is enough to kill him, and we have no need to include the bomb in our code, reducing our size. This is the approach of Blue Funk and juliet. If our enemy is a replicator this is pointless; we have no chance to kill all paper bodies at the rate they spread. To kill them we have to slow them first and, at the end deliver our deadly blow at wounded enemy, yes a very evil act :-) This can be accomplished with more complex bombs either spl 0 followed by jmp -1, as Iron gate does when it finds a target, or with the so called incendiary, mov step, >step ;alternated with spl 0, -step+1 when the mov is executed it take the spl, step cells away, and moves it immediatly after the mov itself; if the mov is executed by a multiprocess paper the effect is creating a spl carpet. Devastating indeed. If our enemy is a coreclear, something with a very reduced footprint like: gate dat -20,20 wipe spl #-20,20 ... split spl 0,0 move mov @1,>gate jump djn -1,{wipe A dat 0,0 hit at the gate, split or jump instruction won't stop the clear running, we need something more effective like Tornado's bomb, (I have not invented it, it's due to Paul Kline if I'm not wrong, I just used it) mov step,1 ;step away there is another one Using this bomb we have added to our target the 'split' line and the 'gate' line, increasing our chances to kill. To finish bombers argument I'll introduce now Tornado, the faster pure bomber and, BTW, one of my favourite babies. It has never had a great success alone, its best version stayed on hill little more than 200 challenges, never climbing higher than 10th position, but proved very effective as component of successful warrior like Jack in the box. Tornado pushes the indirect bombing one step farther, he lays down two bombs and uses the second one as pointer for the third reaching a speed of 60% c, three bombs in a five instruction loop. This is the version included as scanner/clear killer in the p-warrior Jack in the box step equ 95 count equ 533 bomber mov bd, *stone mov bm @stone stone mov *step+2,*(2*step)+2 stone line is the hearth of the bomber. It can be changed slightly if we want to use bombs with fixed a or b fields of values different from the step What's important is that the bomb addressed by b field of stone had one of its fields with the value step add incr, stone jump djn.b bomber, #count Three bombs in a 5 instructions loop means 60% c speed, comparable with that of a cmp scanner (66%c) and without any problem of being delayed by decoys and bomb's color. In fact Tornado easily kills any scanner and clear incr spl #3*step,#3*step clr mov -12, }bomber+1 djmp jmp clr, clear to try catching imps, but is the best fit for the role of 'scanners/clears killer' in the p-warrior. Tweaking a litle the code Tornado can be armed with incendiary bombs too; the incendiary version has been submitted to the hill as Firestorm, and was included in the p-warrior Brain Wash. I won't tell you now, without a substantial payment to my bank account :-), what I have put in La Bomba, and how I use it; stay tuned near Christmas, with most chances I'll make you a gift. For next hint I'm waiting your suggestions. From: John K W Subject: Re: The future of redcode Date: 1995/11/27 Message-ID: <49cn31$m6t@geraldo.cc.utexas.edu>#1/1 references: <9511260803.AA06477@idnsun.gpct.Vanderbilt.Edu.noname> <499g59$e3f@agate.berkeley.edu> <498jeu$3rk@agate.berkeley.edu> <49c51v$sb8@news-rocq.inria.fr> newsgroups: rec.games.corewar Planar wrote: >I thought the major reason for opcode modifiers and A-indirect modes >was to make everything more symmetrical. In my opinion, preincrement >indirect modes and IJN are one more step in the same direction. Symmetrical? :/ But program excecution is not bi-directional. Perhaps it should be? Heh, now THAT could get ammusing... :) Yeah! Backwards-running imps crashing into forwards-running imps... -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Ideas for new instructions Date: 1995/11/27 Message-ID: <49cmbr$m6t@geraldo.cc.utexas.edu>#1/1 references: <4943hh$eur@news-rocq.inria.fr> newsgroups: rec.games.corewar akemi@netcom.com (David Boeren) wrote: >: How about >: <: >>a a>> (pre- and post-increment) > >: And of course the old notation keeps its meaning. > >I'll definately support this notation. MUCH easier to understand than the >old style with it's obscure symbols. And it doesn't break compatibility, so >that's another major plus. Can we have a show of hands? Nope, I don't like that at all. Symbols shouldn't come after variables or pointers. It makes everything more complicated to read. Bad bad bad. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Ideas for new instructions Date: 1995/11/27 Message-ID: <49cm3f$m6t@geraldo.cc.utexas.edu>#1/1 references: newsgroups: rec.games.corewar >> : Planar wrote: >> : >How about using two characters: >> : > >> : > <@a >@a ; decrement/increment, then indirection >> : > @a ; indirection, then decrement/increment >I could be wrong, but I don't think this method allows for which of the >A or B fields is to be incremented/decremented. You're right, that OTHER method didn't. The method quoted above is by far the best, and so the only one worth mentioning. It would, of course, need another four sets for a-field inderection thusly: <@a >@a ; decrement/increment, then indirection @a ; indirection, then decrement/increment {@a }@a ; decrement/increment, then indirection @{a @}a ; indirection, then decrement/increment The biggest problem with something like a> is that having a symbol after the variable is hard to read, and could POTENTIALLY limit variable name choices. Is something like "loop>" currently disallowed as a variable name?? All in all, however, I don't think the 4 new extra symbols are all that needed... not worth the bother to change them. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Planar Subject: The future of redcode Date: 1995/11/27 Message-ID: <49c51v$sb8@news-rocq.inria.fr>#1/1 references: <9511260803.AA06477@idnsun.gpct.Vanderbilt.Edu.noname> <499g59$e3f@agate.berkeley.edu> <498jeu$3rk@agate.berkeley.edu> newsgroups: rec.games.corewar >From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) >The A-indirect modes were a nice complement >to the opcode modifiers, making A-operands just as easy to access as >B-operands. >P-space was an attempt to add memory to warriors without too much impact on >their actual battle operation. I am not sure whether any of the recently >proposed new addressing modes or opcodes add any more to the game than making >existing warriors shorter. I thought the major reason for opcode modifiers and A-indirect modes was to make everything more symmetrical. In my opinion, preincrement indirect modes and IJN are one more step in the same direction. Adding addressing modes and instructions does not really make the implementor's task more complex. Read/write limits do. >From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) > 94D33 the draft 94 standard, v3.3 > a-indr a-field indirection: { } * One minor point: a-indr is already in version 3.3 of the draft. The more I think about your proposal, the more I like it. Make it a lowercase d, and I'll definitely be with you. Note that some old warriors already have ";standard 88" or ";standard 86" in their comments, so you could add these two to your list of standards, just for completeness, even if 86 is obsolete and 88 is included in 94. >From: sieben@IMAP1.ASU.EDU >I think that features that are already implemented but not in the future >standard still could be described in the standard. We could use Michael's >description idea. We describe many features like read-write limits etc. >and then we say that the standard includes this and that feature. >Nandor. I'd rather describe the standard first, and then "standard extensions" in an appendix, with their keyword for Michael's "features" header. How do we manage the example code ? With or without extensions ? Two example interpreters ? Lots of #ifdefs ? -- Planar From: KOTH Tourney Server Subject: SKI-ICWS: Status - ICWS Experimental 94 11/27/95 Date: 1995/11/27 Message-ID: <199511270500.AAA25083@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 11/27/95 See up to the second scores at http://www.stormking.com/~koth Check it out for the latest in Core War information *FAQ* is at http://www.stormking.com/~koth/corewar-faq.html Current Status of the StormKing Industries ICWS Experimental 94 CoreWar Hill: Last battle concluded at : Sun Nov 26 17:45:55 EST 1995 # %W/ %L/ %T Name Author Score Age 1 19/ 6/ 18 Variation M-1 Jay Han 75 17 2 22/ 14/ 6 Pyramid v5.3 Michael Constant 73 8 3 17/ 6/ 20 Big Phoenix 1.0 J.Pohjalainen 71 14 4 22/ 16/ 5 Test Stefan Strack 71 7 5 21/ 16/ 5 bigproba nandor sieben 69 27 6 21/ 17/ 4 Rave B4.1 Stefan Strack 68 24 7 14/ 2/ 27 TimeScapeX (0.1) J. Pohjalainen 68 1 8 16/ 7/ 20 Big Silk Warrior 1.0 J.Pohjalainen 68 15 9 20/ 15/ 9 Request-55440 Brant D. Thomsen 68 69 10 15/ 9/ 18 Lucky 13 Stefan Strack 65 35 11 19/ 16/ 8 Vanity IIx Stefan Strack 64 23 12 19/ 18/ 5 Dagger v7.0 Michael Constant 63 29 13 13/ 6/ 24 Imperfection v2.3 Michael Constant 63 63 14 14/ 9/ 20 Bakers Dozen Wayne Sheppard 62 28 15 16/ 13/ 14 Sauron v2.4 Michael Constant 61 20 16 12/ 9/ 22 BigImp Alex MacAulay 58 110 17 15/ 14/ 14 Variation D-1 Jay Han 57 30 18 12/ 11/ 20 BigImps James Layland 55 129 19 16/ 19/ 8 Raiden Richard van der Brug 55 18 20 13/ 16/ 14 Train Station Nelson Gallash 54 3 21 2/ 98/ 0 94X-HILL-HAS-BEEN-RE-OPEN Scott J. Ellentuch 7 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - ICWS Tournament 11/27/95 Date: 1995/11/27 Message-ID: <199511270500.AAA25058@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 11/27/95 See up to the second scores at http://www.stormking.com/~koth Check it out for the latest in Core War information *FAQ* is at http://www.stormking.com/~koth/corewar-faq.html Current Status of the StormKing Industries Annual ICWS Tournament CoreWar Hill: Last battle concluded at : Tue Oct 10 04:29:50 EDT 1995 # %W/ %L/ %T Name Author Score Age 1 60/ 9/ 31 Cannonade Paul Kline 212 71 2 57/ 31/ 12 Miss Carefree Derek Ross 182 3 3 47/ 29/ 24 Giskard v0.5 Ken Mitton 165 44 4 49/ 37/ 14 Old Tire Swing Randy Graham 162 28 5 48/ 37/ 15 Yop La Boum v2.1 P.E.M & E.C. 160 1 6 50/ 41/ 9 Miss Carry Derek Ross 159 35 7 50/ 42/ 8 Agony T Stefan Strack 158 72 8 45/ 35/ 20 stone matthew householder 154 83 9 44/ 41/ 15 warrior 42 stefan roettger 147 84 10 45/ 43/ 11 Illusion Randy Graham 146 30 11 43/ 42/ 15 DoubleStone v0.7 Christoph C. Birk 144 14 12 43/ 43/ 14 Maya v1.6 Christoph C. Birk 143 45 13 42/ 44/ 14 Slaver v1.1i Christoph C. Birk 140 32 14 41/ 43/ 16 WhirlWind-88 Randy Graham 138 8 15 43/ 50/ 7 xtc stefan roettger 135 76 16 37/ 45/ 18 scissors matthew householder 130 86 17 36/ 49/ 15 Cat v2.0 Tim Scheer 122 68 18 35/ 51/ 13 Smartbomb 4.0 Devin Kilminster 119 70 19 31/ 58/ 11 BigBomb v0.4b (300) Christoph C. Birk 104 4 20 24/ 63/ 13 test Christoph C. Birk 84 10 21 3/ 40/ 57 get names Anonymous 67 2 From: KOTH Tourney Server Subject: SKI-ICWS: Status - Standard 11/27/95 Date: 1995/11/27 Message-ID: <199511270500.AAA12759@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 11/27/95 See up to the second scores and the latest Core War information at : http://www.stormking.com/~koth *FAQ* is at http://www.stormking.com/~koth/corewar-faq.html Current Status of the StormKing Industries Standard KotH CoreWar Hill : Last battle concluded at : Fri Nov 24 03:30:24 EST 1995 # %W/ %L/ %T Name Author Score Age 1 28/ 14/ 58 Cannonade P.Kline 142 106 2 38/ 33/ 28 Giskard v0.5 Ken Mitton 142 44 3 40/ 38/ 22 Christopher Steven Morrell 142 71 4 41/ 40/ 19 Beholder's Eye V1.7 W. Mintardjo 141 150 5 38/ 35/ 27 Keystone t21 P.Kline 140 93 6 42/ 43/ 14 Iron Gate Wayne Sheppard 140 200 7 30/ 20/ 50 CAPS KEY IS STUCK AGAIN Steven Morrell 140 72 8 28/ 18/ 53 Blue Funk 88 Steven Morrell 138 70 9 34/ 31/ 35 Yop La Boum v2.1 P.E.M & E.C. 138 6 10 30/ 23/ 46 Test Wayne Sheppard 138 95 11 31/ 25/ 44 Der Zweiter Blitzkrieg Mike Nonemacher 137 101 12 27/ 16/ 57 Peace Mr. Jones 137 80 13 27/ 16/ 57 ttti nandor sieben 136 56 14 39/ 41/ 19 Request v2.0 Brant D. Thomsen 136 42 15 36/ 36/ 29 Double Clown v1.1 P.E.M 136 1 16 28/ 21/ 51 Hydra Stephen Linhart 133 180 17 41/ 48/ 11 bigproba nandor sieben 133 94 18 26/ 19/ 55 jmp/add crasher Randy Graham 132 30 19 21/ 12/ 67 Evol Imp v5a Wilkinson 129 17 20 35/ 41/ 24 Miss Carefree Derek Ross 128 4 21 5/ 93/ 1 Scuttle 2 Steve Gunnell 17 0 From: KOTH Tourney Server Subject: SKI-ICWS: Status - Multiwarrior Experimental 94 11/27/95 Date: 1995/11/27 Message-ID: <199511270500.AAA13043@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 11/27/95 See up to the second scores at http://www.stormking.com/~koth Check it out for the latest in Core War information *FAQ* is at http://www.stormking.com/~koth/corewar-faq.html Current Status of the StormKing Industries MultiWarrior Experimental 94 CoreWar Hill: Last battle concluded at : Mon Oct 30 22:39:03 EST 1995 # Name Author Score Age 1 Lucky 13 Stefan Strack 8805 37 2 TimeScapeX (0.1) J. Pohjalainen 7087 35 3 Paperone Beppe Bezzi 6654 20 4 life Nandor Sieben 6395 36 5 jaded M R Bremer 6004 6 6 Paper8 G. Eadon 5861 1 7 Hidden M.C.Diskett Bullfrog 5248 5 8 lifedwarf Nandor Sieben 5108 12 9 Futility M R Bremer 4963 2 10 Illusion-94/55 Randy Graham 4922 14 11 Miss Careless Derek Ross 4815 4 12 Miss Treatment Derek Ross 4659 15 13 Piggy 2 Bob Uhl 4608 10 14 Shwing! T. H. Davies 4552 31 15 Piggy 3 Bob Uhl 4513 8 16 Miss Understanding Derek Ross 4505 11 17 AB Scanner 2.9 Chris Hodson 4260 24 18 Miss Carry Derek Ross 4237 16 19 Whirlwind Bob Uhl 4114 22 20 Whirlwind 2 Bob Uhl 3851 23 21 Enlightenment II Scott Manley 3468 3 From: KOTH Tourney Server Subject: SKI-ICWS: Status - MultiWarrior 94 11/27/95 Date: 1995/11/27 Message-ID: <199511270500.AAA12779@valhalla.stormking.com>#1/1 newsgroups: rec.games.corewar Weekly Status on 11/27/95 See up to the second scores at http://www.stormking.com/~koth Check it out for the latest in Core War information *FAQ* is at http://www.stormking.com/~koth/corewar-faq.html Current Status of the StormKing Industries Multiwarrior 94 CoreWar Hill: Last battle concluded at : Fri Nov 24 19:29:30 EST 1995 # Name Author Score Age 1 Son of Imp Steven Morrell 5096 30 2 60% Cotton Wilkinson 5084 13 3 75% Cotton v3b Wilkinson 5084 14 4 Silkworm 1.1 Beppe Bezzi 5084 27 5 TESTI Maurizio Vittuari 5083 5 6 90% Cotton v5c Wilkinson 5083 12 7 TJ Maurizio Vittuari 5081 6 8 Die Hard P.Kline 5035 17 9 P_Banzai_v1.2 Calvin Loh 4972 2 10 P_Banzai_v1.1 Calvin Loh 4958 1 11 Miss Informed Derek Ross 4865 0 From: John K W Subject: Re: Ideas for new instructions Date: 1995/11/27 Message-ID: <49cmnk$m6t@geraldo.cc.utexas.edu>#1/1 references: <4943hh$eur@news-rocq.inria.fr> <498evp$2e5@agate.berkeley.edu> newsgroups: rec.games.corewar mconst@soda.CSUA.Berkeley.EDU (Michael Constant) wrote: >94 notation. (And compatibility issues aside, I think we all agree that >a a> is by far the best notation proposed so far.) No... I don't like that at all. :/ >I believe this was the argument that was brought up last time IJN was >proposed -- no one could think of any real use for it. Of course, this >brings up a basic philosophical point: all other things being equal, do >we want redcode to be restrictive or permissive? The 88 standard had a >rather clear answer to that question -- "restrictive" -- but 94 seems >to be moving away from that. We have to weigh the possible added power >of new features with the added complexity they bring. ICWS'88 redcode >is a very simple language; the current pmars implementation of 94 is >much less so. Do we want to continue in this direction? I don't know. Hmmm... IJN.F can only serve ONE purpose that I can think of. A stream such as "IJN.B -1, >-100"... awfully deadly to imps. In fact, "IJN.F -1, >-100" might be even more so. That could convert itself to a pure stream and if the next instruction was "IJN.F #0, >-100", you'd be in imp-killing heaven. Ah well. Somebody check my logic, I only superficially thought this through. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: The Future of Pizza Date: 1995/11/27 Message-ID: <49dhpn$6l9@charnel.ecst.csuchico.edu>#1/1 newsgroups: rec.games.corewar As most of you know, I am the maintainer for the Pizza Hills. I've been gone recently (Thanksgiving et. al.), and I have finally returned. Reading the recent messages posted here, I see there are a few people who want to move one of my hills to StormKing. Let me start by explaining why Pizza is sometimes so slow. Currently the Pizza Hills are running on the same machine used for all of CSU Chico's WWW traffic. Generally the web doesn't require much CPU time, but CSU Chico also allows students to put up their own web pages, including cgi scripts. Now and then a student's script will have a bug and get hung, and start taking a lot of CPU time, so the hills slow down. Sometimes it takes a day or more to realize what is happening, and by then there could be 20 or more warriors waiting to run. Currently I have made the hill scripts "less nice" to compensate for the runaway scripts, so we shouldn't be quite so slow any more. I am also looking in to getting a more dedicated machine, which may be a little slower, but more consistent. I have also finally put the finishing touches on the 94x hill (the 5x50 idea) and will be starting it soon. Now I have a few questions for you: Would you rather stay on the current machine, which is generally faster, but inconsistent, or move to a slower but more consistent machine? Would you like the hills to stay at 20 places and 250 rounds, or move to 25 places and 200 rounds? (the 5x50 hill would go to 5x40). Do you really think we should move one of Pizza's hills (currently 2 hills, soon to be 3) to StormKing (currently 5 hills)? Thanks for your time... Thos From: Beppe Bezzi Subject: Core warrior #7 - 2/2 Date: 1995/11/27 Message-ID: <199511271757.SAA03676@iol-mail.iol.it> newsgroups: rec.games.corewar ______________________________________________________________________________ Tournament Time (details at http://www.stormking.com/~koth/nsfcwt.html) No tournament round this week, Thanksgiving break. This is the rank after round 6: Name 1 2 3 4 5 6 total Steven Morrell 5 10 9 13 14 10 61 P.Kline 7.5 9 7 11 11 12 57.5 Paulsson 7.5 11 11 9 2 5 45.5 Anders Ivner 5.5 8 4 0 10 14 41.5 Beppe Bezzi 7 7 13 2 8 3 40 M R Bremer 7 4 3.6 5 7 11 37.6 Maurizio Vittuari 6.5 5 6 3 9 8 37.5 John K. Wilkinson 4 6 12 0 13 2 37 Robert Macrae 0 0 0 12 12 13 37 Karl Lewin 0 0 10 4 6 10 30 Randy Graham 0 0 8 10 4 7 29 Derek Ross 3.5 3 3.3 7 3 6 25.8 G. Eadon 1.5 2 5 6 1 4 19.5 Kurt Franke 0 0 0 8 0 0 8 Michael Constant 0 0 0 0 5 0 5 Anders Scholl 0 1 2 1 0 0 4 John Lewis 0 0 3 0 0 0 3 Calvin Loh 0 0 1 0 0 1 2 ______________________________________________________________________________ Planar's Corner: Continuous imp-launching (final part) Impfinity v1 is now close to dying of old age, after being published in Core Warrior 4 and spending most of its life in the bottom half of the beginner hill. I was writing version 2 when I realized that binary launching is not the only way of launching a continuous spiral. The JMP/ADD launch can also be adapted. I'll first explain JMP/ADD launching. Old-timers may want to skip three paragraphs. This is a JMP/ADD launcher, taken from the FAQ: A spl 1, 0 B spl 1, 0 C spl E, 0 D jmp imp, 0 E add.a #step, D F dat 0, 0 imp mov.i #0, step This is how it works: [A] [B B] [C C C C] [D E D E D E D E] [imp F imp+step F imp+2*step F imp+3*step F] [imp+1 imp+step+1 imp+2*step+1 imp+3*step+1] It's pretty straightforward: we interleave processes at D and E, the processes at D jump to the spiral, and the processes at E increment the JMP at D to make it point to the right place for each jump. How do we convert this into a continuous launch ? We have to alternate ADDs and JMPs. The easiest way to do it: Z spl 0, 0 A add.a #step+1, J J jmp imp-step-1, 0 Here is what it does: [Z] [A Z] [J A Z] [imp J A Z] [imp+1 imp+step+1 J A Z] So this code will alternate ADDs and JMPs and add one process to the spiral at each turn. We have to ADD step+1 because the spiral will advance by one location before we add a process. The above piece of code is what I call the "pump", because it pumps processes into the spiral. There's one little problem because the pump only adds one process per round. An incomplete spiral is not viable, its processes will die within one round. So we have to keep the spiral alive until the first ring is completed. There are several ways of doing this. I've considered launching a complete ring with one of the three classical launchers, and synchronizing the pump to add processes at the right place. Finally, I've decided to use a little piece of code to prime the pump: instr mov.i #0, step primer spl 0, >1 mov.i instr, imp This will unroll a carpet of imp instructions under the tail of the spiral. If you locate the primer at the right place in front of the spiral, it will be overwritten by the spiral when its job is finished (or you can arrange for your stone to kill it, or whatever). Note that you have to do one MOV in each turn. A DJN loop will not work here. So this is it. Six lines of code, three of them can be located away from the three others, and they are only used for a few dozen cycles. What is left for scanners to find is just three lines. Pretty good, no ? A few ideas occured to me while I was writing this. I'll give them as exercises to the reader: - There may be a way of launching several processes per round with something like this: Z spl Z, }J A spl 1, 0 B spl 1, 0 C spl E, 0 J jmp imp, 0 E add.a #step, J F dat 0, 0 imp mov.i #0, step This will add 4 processes to the imp in each round, so it doesn't need a primer for a 3-point imp. It launches faster but it's longer. - We could incorporate the primer into the pump (build an auto-prime pump ?) like this: Z spl 0, >P P mov.i imp, imp A add.a #step+1, J J jmp imp-step-1, 0 imp mov.i #0, step Hmm, I think I'm going to integrate something like this into a future version of Impfinity. - Because in a core of size 55440 imp spirals have at least 13 points, launchers tend to be bigger and easier to kill. This is not true for this launcher, so this technique may be more useful in the experimental hill. Finally, I'll give you the latest version of Impfinity. I've provided a reasonable set of constants that are completely different from what I've sent to the hill. Impfinity v3i implements the ideas given by Magnus Paulsson in Core Warrior 2 about how Die Hard might be working. We now know that Die Hard has nothing to do with Magnus' guesses, but his ideas are still good. I'll quote him: >Now if you place two spirals on top of each other, and plan in which order >they and the rest of the code will be in the execution. In the coreclear the >spl processes will be like 4000 processes, spiral, 4000 processes, spiral. >That means the clear has to kill spiral in 4000 cycles which isn't possible >in a clear. Right. And since scanners were the real danger for Impfinity, I've interleaved the two spirals with two self-splitting stones that eat most of the processes (because they will be stunned anyway). When one of the stone is stunned, the other one keeps going at about the same speed because it splits almost as fast as the stunned one. In the real world, it's more like 2000 processes, spiral, 6000 processes, spiral. But it does give better protection against core-clears. >So, because there is a thing called gate which kills spirals. In order to tie >you have to have something like 100 processes in a spiral to slow it down as >much that it doesn't reach the gate. Now you can't launch such a monster >without getting killed before the launch is complete. Aha, but with continuous launching, you can launch a monster of any size with a 3-line launcher that scanners (and stones) will find hard to kill. And because the self-splitting stones eat most of the cycles, 60 processes in the spirals are largely enough: by the time the stones are killed and the spirals advance at full speed, the game is almost over. Impfinity v3i starts with an SPL that divides the cycles in half. Each half is doing the same thing (but with different offsets): bootstrap the pump, primer, and stone; launch the pump and primer. The primer will launch the stone after a (short) while. If I start the stone too early, the spiral is too short (it doesn't grow much, once the stone is started). So we have two stones and two spirals. The spirals are exactly on top of each other, so they help keep each other alive. The stones are synchronized with magic01, magic02, stnof01, and stnof02, so they won't kill each other (or themselves) until very late, and one of them turns itself into a core-clear (one-pass, unfortunately). Oh, and I have a 7-point spiral, so I can use anti-3-point bombs, but I have no idea how much good it does. Finally, I think the stone design warrants a few words. It is self-splitting, changes 3 core locations in 4 cycles, throws colored bombs, and turns itself into a suicidal core-clear if you use the right magic constant. And I can make it switch bombs in the middle of the bombing run (not shown here). Is it original ? I don't know. A little bit of version history: Version 3e7, which stayed on the bottom half of the '94 hill for some time, didn't have the twin spirals and stones, and had a slower bootstrap. Version 3c11 (sent to the beginner hill after it failed to enter the '94 hill) has a slower stone and an 11-point spiral. I'll put them both on my Web page, along with version 3i, when this issue of Core Warrior is posted. ;redcode-94 ;name Impfinity v3i ;author Planar ;strategy boot,imp,stone,clear ;assert CORESIZE == 8000 ; The constants on the lines marked with "C" are all different ; from the version on the hill. ; To synchronize the two stones, I had to do a lot of tweaking of ; magic01, magic02, stnof01, and stnof02. Thanks to cdb, it only ; took a few hours. istep equ 1143 bstep01 equ 2214 bstep02 equ 3285 magic01 equ (-2) ; C magic02 equ (-3) ; C fuse equ 13 ; C trash equ (Z-200) ; C impoff equ (Z+500) ; C prmof01 equ (impoff+2*istep+20) ; C prmof02 equ (impoff+5*istep+20) ; C pmpof01 equ (impoff+4*istep-20) ; C pmpof02 equ (impoff+1*istep-20) ; C stnof01 equ (impoff+3*istep-21) ; C stnof02 equ (impoff+6*istep-19) ; C org boot Z boot spl boot02 i FOR 2 boot&i mov.i {ppmp&i, trash-15-i*2, pstn&i spl @ppmp&i, >pprm&i mov.i >trash-i*2, ppmp&i spl @pprm&i, >trash-5-i*2 mov.i >trash-10-i*2, pprm&i ppmp&i dat ptr&i+1, pmpof&i+ptr&i+1-pump&i pprm&i dat prime&i+3, prmof&i+prime&i+3-instr&i pstn&i dat jump&i+1, stnof&i+jump&i+1-bomb&i pump&i spl #1, >ptr&i add.f #istep+1, ptr&i ptr&i jmp pump&i-pmpof&i+impoff-istep-1, {200 ; C instr&i mov.i #1, istep prime&i spl #instr&i-prmof&i+impoff, >23 ; C mov.i instr&i, }prime&i jmn.b instr&i-prmof&i+stnof&i+1, instr&i-prmof&i+impoff+fuse bomb&i dat <5334, <2667 stone&i spl #stone&i+bstep&i+magic&i, {-1000 ; C mov.i bomb&i, }stone&i add.f #bstep&i-1, stone&i jump&i djn.f stone&i, <-30 ; C ROF FOR (MAXLENGTH-CURLINE)/3 mov #1, 1 mov #1, @1 spl #1, 1 ROF FOR MAXLENGTH-CURLINE dat #1, 1 ROF end Unless I'm mistaken, Calvin Loh has not published his JMP/ADD continuous launching design yet. Does it look like the above ? ______________________________________________________________________________ Extra Extra: Quickscanners by Robert Mcrae Core_Warrior_#4 carried a description of scanners. 0.66c or 0.80c is fast, but they're not _quick_! Lets look at the central loop of a very basic 0.66c scanner and ask what baggage can be removed. ; Code loosely based on simplified Core_Warrior_#4 scanner inc add.f step, scan ; nudge scan along scan sne.i 100, 112 ; scan djn.b inc, #1000 ; repeat 1000 times attack step dat 24, 24 The main loop takes 3 cycles to check 2 locations, hence the 0.66c figure. INC nudges the locations which are compared by SEQ instruction, DJN is needed to jump back to INC -- this looks like about as fast as we can get. But... Quickscanners Use INLINE CODING. The essential instruction to the above code is the comparison SNE. If we "unwrap" the loop into a long list of SNEs with no ADDs (since we hard-code the addresses to be scanned) and no DJNs (because we are not looping) then the comparison speed hits 2c -- every (executed) instruction is a SNE comparing _2_ locations. The result might look like this: start sne.i start+100, start+112 mov.ab #100, target sne.i start+124, start+136 mov.ab #124, target sne.i start+148, start+160 mov.ab #148, target sne.i start+172, start+184 mov.ab #172, target sne.... etc where target is used by the attack code as a pointer to the locations which have failed the SNE test. These may be attacked by any method such as SPL carpet, incendiary etc, but before considering attacks, ask whether the above code gains more than it loses compared to the scanner we derived it from: Good We have scanned 8 locations in just 4 cycles (given no hits). Bad The code to scan 8 locations fills 8 locations, so we are very vulnerable to bombers and scanners. We don't know where we've hit till the end of the inline sequence. A maximum-length warrior (100 instruction) can only scan 100 locations, or 1.3% of core. What do we do then? These features make Quickscans rather specialised tools. They are always (AFAIK) used as the _first_ stage of a composite warrior. Scanning less than 100 locations they cannot guarantee to hit anything, so some fallback strategy is needed -- scanner, bomber, whatever -- to handle the warriors they miss. If they hit, you should win. If they miss, you've just lost a few tens of cycles. Since they are run once through and then discarded, the vulnerability to bombers is ameliorated. It is a good exercise to calculate how likely a c=0.33 bomber is to kill a Quickscanner (say) 80 words long. (No, I don't know either, but I'd like to :) Quickscanners will be scanning early in the battle, certainly in the first 100 cycles, before many bombs have been thrown or replicators sprouted. Anything they detect is quite likely to be the enemy warrior code or a decoy close to it. This means they can afford to invest a _lot_ of effort on damaging that area of core. This completes the outline and philosophy of Quickscanners (didn't take long:), so now onto practical tips. Actually, since asking the right kind of question is more useful than reading a recipe, most of the work is up to you... Where to Scan? You occupy 100 cells, and the enemy is at least 100 away. That gives you 7700 to examine; why not space them evenly? Where should the end points be? What Order to Scan? If you do enough scans so that the spacing between locations is less than 100, here is a minor gain to scanning 1st, 3rd, 5th .. n-1th before you do 2nd, 4th .. nth. To see why, imagine your target is 100 cells long. Once you have scanned the 3rd location and found it empty, you have eliminated _some_ of the possible positions of the enemy which would give rise to a hit in the 2nd and 4th locations. This makes them worse bets than other locations, so leave them till later. (How big is the gain here? Is there any cost?) Are There Other Forms of QS? Several. The most interesting makes somewhat more efficient use of space by a sequence: SNE.i start+150, start+250 SEQ.i start+350, start+450 MOV.ab #150, Target ... Speed is still 2c, but this method packs 4 comparisons into 3 locations at the cost of requiring more work in decoding exactly where the hit occurred. This method was used in Pyramid and Thermite, which aim to win via their thorough QS, but Paul Klein's recently-published Die Hard used the simpler SNE/MOV scheme for maximum speed in decoding. He was just aiming to hit often enough to do damage with his brainwash, so packing density came second to decoding speed. Randy Graham came up with a scheme intermediate between a QS and a scanner, in which a long block of DAT pointers were used. This scans at "only" c=1, but has benefits in robustness (why?) and packing. SNE.i @ListTop, *ListTop DJN.f -1, -1 List DAT #7750, #7850 ... ListTop DAT #150, #250 [BTW I should credit the rest of the article too. Most of the things I know about Quickscanners came from experimenting with Michael Constant's Sauron-T, which is in the 1993 competition archive. Pyramid, a later QS of Michael's, is an excellent basis for experiment because it is fully parameterised. Apologies for any missed names, mistakes, misrepresentations or misrecollections.] How Should I Attack? Big topic, vital to any warrior so I'm going to digress. Any attack has to pay off being deadly against being quick to deliver. Classic bombers go for fast delivery, but typically of a single <, DAT or SPL. Scanners only spend time attacking plausible targets, by ignoring blank areas, so when they find something they can afford to take more time and deliver bigger, nastier bombs -- SPL carpets, incendiaries etc. Right at the end of the quick-to-nasty spectrum come Quickscanners. These will usually only find one target, but it is very high quality, meaning that there is a good chance that the enemy has a substantial fraction of his processes working near to the scanned location. We should invest substantial time flattening the whole area. I've seen various schemes for this. I like launching vampiric JMP instructions which suck enemy processes into a prepared SPL pit. Multiple incendiaries could do the trick, and so could SPL carpets, though this gets slow if you want to carpet a large area. How large Should the Area Be? Well... not more than +-100 cells from the location scanned. (Why?) This decision interacts with the speed of the method of bombing you use. We _hope_ we have clobbered the opponents code before he can boot away, but we cannot assume it. Another salutary calculation is just how fast we have to be; big imps are easy meat (you should probably make that "extinct" meat) but a bomber can boot in 20 cycles and leave you pasting his decoy. If he has booted away, we can't waste too long bombing air before we fall back on our second strategy... +-50 cells is probably as long as is needed, and you certainly hit diminishing returns if you bomb more than every 4th cell. Using a 0.33c bomber and hitting every 6th cell takes about 50 cycles to complete. Die Hard hit a smaller range, every 8th cell, with a 0.4c bomber for 20 cycles or so. The best solution here, as usual, is to experiment. If you can get hold of likely opponents and work out how quickly they boot, this will help guide the choices. Thermite [Editor note: Thermite has been posted in Core warrior # 5; you can find it at Planar's home page - http://pauillac.inria.fr/~doligez/corewar/rc/Thermite.txt] I hope that these notes have given sufficient background so that the choices made in Thermite (Core_Warrior_#5) make sense. These notes go into a little more detail than the in-code comments but see #5 for the source. Most importantly, I use FOR/ROF rather than typing the addresses! Pyramid goes further, with adjustable parameters for number of scans etc. I use the SNE/SEQ form of scan to get the scan spacing down to 81 cells. When I have a hit, I scan through the 4 alternatives in a short loop. (Spot the weakness here; Randy pointed out a wasted cycle or two, but I don't remember where...) I launch an SPL bomb straight at my hit, before starting the main vampiric bomb run. I believe this reduces the chance of the enemy booting away before the bomb-run gets back to the original hit (but why not check?). The occasional JMN instructions check whether a hit has been made. If it has, I jump direct to the bombing routine saving a few wasted scanning cycles. The gain is not great, because each JMN test is guaranteed to cost one cycle but has a relatively small chance of saving any. (For _real_ enthusiasts, what is the spacing of the JMNs which optimises expected speed of hits? I think there are more JMNs near the beginning...) I bite at 0.33c, from about 50 after the hit to 100 before. The asymmetry arose because I was keen to bomb "near" the original hit quickly, but didn't mind spending a few extra cycles "making sure" on the far end. Does the asymmetry pay? What is the chance that I miss a kill by not biting +50 to +100? What is the (weak) reason for bombing from -81 to -100? I use fangs which do an indirect jump via a location well away from the trap. This is meant to help against indirect-bombing silks, because I have only 1 pointer to the trap which is shared by all the bites. My pit concentrates on splitting as fast as possible, but why not add a brainwash? Beppe pointed out that if you plan to use the QS with a paper, the pit should commit suicide eventually because the paper cannot guarantee to kill it. Perhaps use a DJN trail wrapping round core? Or should the pit work as a bomber? How many points do I lose not booting? There are lots of options to explore. It is easy to add a QS to most conventional warriors and the performance gain can be substantial. If you already have a reasonable warrior less than 70 cycles long, why not trade in the decoy for a QS, which will work for its living..? ______________________________________________________________________________ Questions? Concerns? Comments? Complaints? Mail them to: Beppe Bezzi or Myer R Bremer From: John K W Subject: Re: Newbie from Heck Date: 1995/11/27 Message-ID: <49b9is$ofj@geraldo.cc.utexas.edu>#1/1 references: <9511221758.AA05717@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) wrote: >Bepe Bezzi wrote: >The pmarsv text mode display, which comes up by default, is probably what's >causing the trouble. For extra speed, pmarsv writes directly to screen memory >rather than going thru bios, and from what I've been told, direct hardware >access is a no-no under Windows. The VGA display (-v 13) however should work >fine. Pmarsv? What is that? Hmmmm... I've always run pmars.exe under Windows. What's the difference between that and pmarsv? Heh. Direct access is a BIG no-no. If that's what pmarsv is doing, you shouldn't attempt to run it under Windows 3.1. It could crash the system... or worse. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: 94x hill and P-space (was Re: summary on read/write limits [part 2]) Date: 1995/11/27 Message-ID: <49bet8$nb2@valhalla.stormking.com>#1/1 references: <9511241853.AA06183@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar Stefan Strack (stst@idnsun.gpct.Vanderbilt.Edu) wrote: : Planar wrote: : >P.S. Since the X-hill on pizza is broken, maybe we could have one on : > StormKing ? It would even spare Thos the work of fixing the : > pizza X-hill. You see, I have a feeling that continuous : > launching is going to be more useful in the big core. : > : I'd also like the 55440 coresize hill reopened. Best at stormking to even out : the load. Even though this hill hasn't seen a lot of action lately, I'd expect : interest to resurge again now that we have P-space. Qscanners seem to keep : pspacers in check on the 8000 hill, and since qscanners are that much less : effective in a large core, this hill could become a fertile ground for complex : switching mechanisms. Dunno how this happened, but I missed this thread totally! Well, since it was ALREADY in the code to support a 94x hill, I've re-opened it. It has also been changed from 10,000 to 55,440 of a coresize. I have left the warriors that USED to be there there for now, but I'm sure you guys will displace them all in a matter of days. You can see it again from email and from my http://www.stormking.com/~koth site. Now, Mr Strack, care to put it BACK in the FAQ? Tuc -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: John K W Subject: Re: Ideas for new instructions Date: 1995/11/27 Message-ID: <49bcvn$rm1@geraldo.cc.utexas.edu>#1/1 references: <9511260803.AA06477@idnsun.gpct.vanderbilt.edu.noname> <499g59$e3f@agate.berkeley.edu> newsgroups: rec.games.corewar mconst@soda.CSUA.Berkeley.EDU (Michael Constant) wrote: <"...pspace should be considered for removal..."> >proposal. Corewar has always had extended standards, and I think this >the best way for corewar veterans to experiment with new ideas without >complicating the basic standard -- and increasing the difficulty of >learning corewar -- unncessarily. I don't think pspace complicates things at all. It's so highly seperate from other instructions, and yet integrated so nicely into any program or programs. I'm not convinced it should go. Rather... just the opposite, I think it's nifty. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Hill Management Date: 1995/11/27 Message-ID: <49bbpj$ofj@geraldo.cc.utexas.edu>#1/1 references: <48ai5d$3sr@geraldo.cc.utexas.edu> <48aphb$96b@news.asu.edu> <48aqb3$9oh@geraldo.cc.utexas.edu> <48co7i$gm1@news-rocq.inria.fr> <48ldoo$6jv@valhalla.stormking.com> <1995Nov21.115536@acad.drake.edu> <48tbiv$nfa@geraldo.cc.utexas.edu> <48vaik$odk@valhalla.stormking.com> newsgroups: rec.games.corewar tuc@news.stormking.com (Scott J. Ellentuch) wrote: >: I'd thought about that once before, but I didn't want to submit >: that idea when it seems to take months just to MOVE a Hill. :) > > (I was going somewhere with this....) I think what I'm trying Where?? :) 'Course I love nostalgia... >to say is we both are trying to get your Corewar business and wanting to >be *THE* premier site. But then again, maybe thats me. So, thats why >its been taking so long, ESPECIALLY cause I haven't heard from Thos! Corewar business?? Well, it's not like we're uh... paying you or anything. So I don't feel that I'm in any position to make demands. Anyway, moving the hill shouldn't be that tough. I don't see why you can't work together in a Communistic Fascist manner, much like the National Football League , to solve this problem! -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Beginners ??? hill Date: 1995/11/27 Message-ID: <49b8ac$ofj@geraldo.cc.utexas.edu>#1/1 references: <199511241325.OAA04598@iol-mail.iol.it> <497j1o$pih@news.asu.edu> newsgroups: rec.games.corewar sieben@imap1.asu.edu wrote: >: Here is the (unexpected indeed) result: >Well this is the way corewar works. When a warrior gets on a hill it only >means it's good against those 20 warriors on the hill. It doesn't mean >it's good against anything else. Also when an expert plays against a >beginner (say in chess) the expert can win quickly by taking risks. >Playing moves that would be dangerous against another expert but the same >moves are very effective and not very risky against a beginner. That's one of the more subtly nifty points of corewar. The hill system creates an almost stock market-like scenario. You must to some degree figure out what everyone is doing now, and then try to figure out what they'll do next, and find a strategy that beats both. It's always interesting... :) I'm still amazed at how long warriors can last. Especially Agony! It's weird because that program scores poorly against simple stones... and yet it lasted soooo long. Hmmm... -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: 94x hill and P-space (was Re: summary on read/write limits [part 2]) Date: 1995/11/27 Message-ID: <49b7ks$ofj@geraldo.cc.utexas.edu>#1/1 references: <9511250642.AA06262@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) wrote: >55440, although 7x larger than the regular core, never produced any radically >new strategies by itself. With P-space it just may. We chose the number >55440 because it has many small divisors -- good for a multitude of bombing >patterns. The main reason for keeping the hill specs is that there's >already a lot of working code for it. Ah. I suspected as much. :) Allrighty, then, make a Big hill. I'd like to submit away to it. "Just do it!" -Nike -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/28 Message-ID: <9511281935.AA07423@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar John Wilkinson wrote: >tradon@cyf-kr.edu.pl (Tomasz.Radon) wrote: >>All agree that we need full set of pre-/post- inc/dec modes > >I don't agree. > For once, I actually agree with John (just kidding, John :). I don't think we need any more modes than we already have, and the "post-operand" notation is not particularly clear. Operands can be complex expressions with parentheses, etc., and an appended addressing mode symbol might be overlooked. -Stefan From: Beppe Bezzi Subject: Re: Core warrior #7 - 2/2 Date: 1995/11/28 Message-ID: <199511281440.PAA17562@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar Michael Constant wrote: >Beppe Bezzi wrote: I'm but the _ir_responsible editor, I'll cut author's pay by half :-) Having made a bit of experience writing my last warrior I answer anyway happy that the newsletter started a technical discussion. > >>.. >>Anything they detect is quite likely to be the enemy warrior code or a decoy >>close to it. This means they can afford to invest a _lot_ of effort on >>damaging that area of core. > >Unfortunately, this isn't true :-) It might be instructive for me to >repost the comments I gave with my original posting of Pyramid: > >: ... 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. In fact the main problem I found coding La Bomba was what to once I find it. The tradeoff is beetween bombing a wide area around or a small one and if using highly dangerous, time consuming, bombs or simpler and faster to drop ones. > >>The most interesting makes somewhat more efficient use of space by a >>sequence: >> >> SNE.i start+150, start+250 >> SEQ.i start+350, start+450 >> MOV.ab #150, Target >> ... >> >>Speed is still 2c, but this method packs 4 comparisons into 3 locations at >>the cost of requiring more work in decoding exactly where the hit occurred. >>... > >Hmm, you speak as if it takes serious work to do the decoding. Pyramid >does it in two cycles, and I don't believe it's *possible* to write code >so badly that it takes more than four or five :-) >>[BTW I should credit the rest of the article too. Most of the things I know >>about Quickscanners came from experimenting with Michael Constant's Sauron-T, >>which is in the 1993 competition archive. > >Ah *ha*! No wonder you have strange ideas about quickscanners :-) >Sauron-T was a pretty horrible warrior. It was Sauron v2.4, hurriedly >adapted for tournament parameters -- and Sauron was never very good in the >first place :-) If you want to write a quickscanner, read Pyramid v5.5. I'm too young in corewar for having seen Pyramid in action and, even if I have its code, I used for La Bomba the slow decoding that is in the FAQs; using Pyramid one I can save some time, interesting for next improvement.... >> .... We should invest substantial >>time flattening the whole area. > >Again, this works in theory but not in practice. Bootstrapping really >doesn't take very long. To see this in action, try playing with the >constants in Pyramid v5.5 and see how badly it begins to score if you >tell it to bomb a wide area around the spot where it found the enemy, >and also see how badly it scores if you tell it to bomb very thoroughly. > As I told before it's very important to well tune time spent bombing something that may or may not be our target. IMO there is not a definitive answer, it's depends a lot from what you find in the hill. My Qscan warrior 3rd in 94 and 6th in beginner's hill is a clear example. >BTW, just as I typed this in, I came up with a truly diabolical idea >that could put Pyramid back on the hill... perhaps even back in its >favorite spot on the hill :-) Stay tuned -- Pyramid v6.0 is coming >soon to a hill near you! The fall of Pyramid was caused by the vampire, not very effective against modern papers, and not only because of A-postincrement bombing (but this is another argument), replacing it with a more effective attack form it's not difficult to foreview a pyramid return. I hope you'll crunch quiz heavily so La Bomba will go back to its favourite spot on hill :-) >-- > Michael Constant (mconst@soda.csua.berkeley.edu) > > -Beppe Bezzi From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: Re: The Future of Pizza Date: 1995/11/28 Message-ID: <49g7o3$p4k@charnel.ecst.csuchico.edu>#1/1 references: <9511280542.AA07259@idnsun.gpct.Vanderbilt.Edu.noname> <49ff20$n1d@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar In article <49ff20$n1d@geraldo.cc.utexas.edu>, John K W wrote: > >5*50? I was opposed to it from the start... Well, I always thought it was a good idea for a hill, just to see what the differences might be. It explores another area of pspace. > > >Goooood Thos. >Goooood Tuc. > > MMMMmmm. Kudos. Got a Dr. Pepper to go with that? > / John K. Wilkinson - jwilkinson@mail.utexas.edu \ Thos From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: Re: The Future of Pizza Date: 1995/11/28 Message-ID: <49g34g$o81@charnel.ecst.csuchico.edu>#1/1 references: <49dhpn$6l9@charnel.ecst.csuchico.edu> <49dkse$hbj@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar In article <49dkse$hbj@geraldo.cc.utexas.edu>, John K W wrote: >sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >> >>Would you rather stay on the current machine, which is generally faster, >>but inconsistent, or move to a slower but more consistent machine? > >Um... could you put one of the Hills on a separate machine? Nope. It is possible, but it would require a bit of coding, and I don't think the school would like me tieing up two machines. >Oh, also it might be a good idea to limit the warrior cache to >say 8 or so. That time the server hung and people submitted >multiple warriors backed it up for an extra day. With the less nice code, I don't think people will be submitting multiple copies of the same warrior anymore. > / John K. Wilkinson - jwilkinson@mail.utexas.edu \ Thos From: Planar Subject: Re: Beginner's paper needs help Date: 1995/11/28 Message-ID: <49fk40$lp5@news-rocq.inria.fr>#1/1 references: <49ebvb$cj9@newsbf02.news.aol.com> <49femn$n1d@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar >agserm@aol.com (AGSerm) wrote: >>;name Mulberry 1.3 >>;author Ansel G. Sermersheim >>;strategy Standard paper >>step equ 5766 >> >> org start >> >>start spl 2 >> spl 1 >> jmp inst >>ptr1 dat step, 0 >>inst mov >ptr1, }ptr1 >>cplst jmp inst+step In article <49femn$n1d@geraldo.cc.utexas.edu>, John K W writes: >Well, for starters use this to make three instructions: > >spl 1 >mov -1, 0 This is the only part of his code that works properly ! You're going to confuse him. Let's see what Mulberry does. A start spl 2 B spl 1 C jmp inst D ptr1 dat step, 0 E inst mov >ptr1, }ptr1 F cplst jmp inst+step A and B will start three processes at C, which will jump to E. E will copy D, E, and F to D+step, E+step and F+step, and F will jump to E+step. So this program copies itself step locations away and jumps to the copy. This is not a paper because there is only one copy alive at a time. I'd call this a modern variant of BIGFOOT (described in Dewdney's '84 article). To make a paper, you'll have to split to the new copy, like this: A spl 2 B spl 1 D ptr1 spl step, 0 E mov >ptr1, }ptr1 F jmp ptr1, Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/28 Message-ID: <49ffoq$n1d@geraldo.cc.utexas.edu>#1/1 references: newsgroups: rec.games.corewar tradon@cyf-kr.edu.pl (Tomasz.Radon) wrote: >All agree that we need full set of pre-/post- inc/dec modes I don't agree. >It seems be logical BUT >b - is not backward compatibile! That's not incredibly important... :/ >What do you thing about this: Icky. :( >We can also replace @ and * by and {b} Even worse. >it is clear, isn't it? Not really. I do NOT want operands after variables if it is at all possible to avoid it. >Simple example: > > old new > > mov.i <12,>34 mov.i -<12> , +<34> > add @15,{22 add <15> , -{22} > sub 21>,22} sub <21>+, {22}+ Heh. You wouldn't happen to work for your local government now would you? :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Qscan vs stone (was Re: Core warrior #7 - 2/2) Date: 1995/11/28 Message-ID: <49ffgt$n1d@geraldo.cc.utexas.edu>#1/1 references: <199511280957.KAA14215@iol-mail.iol.it> newsgroups: rec.games.corewar Beppe Bezzi wrote: >>I got a .1252334 ratio. That's about a 12.5% chance. >>Much higher than I would've expected. >>This is assuming no boot code. Just plain bombing. >I guess you refer to the chance a 33%c stone has to kill an 80 lines qscan. Yeah. The 12.5% refers to the odds that that the qscan will have died before it reaches the old-standby section of it's code. The paper, or stone or whatever. Also, this fails to take into account any possibility of the q-scan FINDING the stone. In order to take -that- into account, you would need much more specific info... >I got a little greater but similar result 13.7% using this approximated >approach: > >The stone drops 27 bombs (80/3) while the qscan finishes to execute, and the >qscan average footprint can be approximated to 80/2 = 40 lines (the qscan >footprint reduces while it executes, it doesn't loop back so hitting an >already executed line causes no damage) >The chance to kill is therefore: 27*40/7900 = 0.1367 or 1/7 Yep, that's a reasonable approx, and since it backs up my answer by being slightly larger (as to be expected from an increasing series) I will accept the number as fairly accurate. >In real word thing are even worse for the qscan because it has but a chance >of 5% to catch the stone, so its footprint is 40 + xx because the warrior >following the qscan and its boot code are vulnerable to the stone attack. >Supposing to add 10 other lines we have a 17% chance for the stone to win >before the qscan begin working, not too bad for the qscan cosidering the >advantages it gets agains bigger and slower opponents. Heh. So many variables... so little time. ;-) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: The Future of Pizza Date: 1995/11/28 Message-ID: <49ff20$n1d@geraldo.cc.utexas.edu>#1/1 references: <9511280542.AA07259@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) wrote: >94x hasn't been "moved". Remember, you killed the 55440 hill to make room >for the 5*50 round hill (anyone still interested in that?). There's been some 5*50? I was opposed to it from the start... >interest to revive the big hill lately, so Tuc reopened it at stormking. >This is in your best interest because it evens out the load. Your two >hills (94 and beginners) still get more traffic than all of the stormking >hills combined. Which is BAD. 'Course I think the 94x Hill will more than compensate for that. We should be overloading Stormking easily with just a few submissions a day. :) >This is a good place to thank both Thos and Tuc for their service to the >core war community; where would we be without KotH? When making requests >for new features, you should realize that hill maintenance and script >writing is not a trivial job. Goooood Thos. Goooood Tuc. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Planar Subject: Re: The Future of Pizza Date: 1995/11/28 Message-ID: <49fe44$j83@news-rocq.inria.fr>#1/1 references: <9511280542.AA07259@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar In article <9511280542.AA07259@idnsun.gpct.Vanderbilt.Edu.noname>, stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) writes: >This is a good place to thank both Thos and Tuc for their service to the >core war community; where would we be without KotH? When making requests >for new features, you should realize that hill maintenance and script >writing is not a trivial job. I wholeheartedly agree. Many thanks to Thos and Tuc. I've been spending a lot of time on my Web page, and I didn't get a lot of feedback, except from the Web server's log files... If you find a broken link in my page, I'll see it and I'll fix it. Just try again a few days later. And while I'm talking about my Web page, I'm going to add an archive of rec.games.corewar. Derek Ross sent me everything from January 10, 1995, so I'd like to get the postings from July 94 to January 95. If anybody has them or know where to get them from, please send me some mail. -- Planar From: tradon@cyf-kr.edu.pl (Tomasz.Radon) Subject: Post/pre inc/dec modes - new idea Date: 1995/11/28 Message-ID: #1/1 newsgroups: rec.games.corewar Hi, All agree that we need full set of pre-/post- inc/dec modes Most people suggested: b preincrement b< postdecrement b> postincrement It seems be logical BUT >b - is not backward compatibile! What do you thing about this: - - B-field predecrement old form - B-field preincrement NEW - - B-field postdecrement NEW + - B-field postincrement old form >b -{a} - A-field predecrement old form {a +{a} - A-field preincrement NEW {a}- - A-field postdecrement NEW {a}+ - A-field postincrement old form }a We can also replace @ and * by and {b} - A-field indirect old form @b {a} - B-field indirect old form *a it is clear, isn't it? For me it looks realy nice and easy to understand. Of course old style formats (@b b *a {a }a) should be still accepted! It allow us to use one compiler for old and new warriors. Simple example: old new mov.i <12,>34 mov.i -<12> , +<34> add @15,{22 add <15> , -{22} sub 21>,22} sub <21>+, {22}+ Any comments? Thomas Radon From: John K W Subject: Re: Core warrior #7 - 2/2 Date: 1995/11/28 Message-ID: <49e3co$r5l@geraldo.cc.utexas.edu>#1/1 references: <199511271757.SAA03676@iol-mail.iol.it> newsgroups: rec.games.corewar I got a .1252334 ratio. That's about a 12.5% chance. Much higher than I would've expected. This is assuming no boot code. Just plain bombing. I got this number from the following BASIC program: 10 X = .33/8000 20 SUM = 0 30 INC = INC+ 1 40 PRINT SUM 50 SUM = SUM + (1-SUM)*X*INC 60 IF (INC < 81) THEN 30 X*INC is the odds that any random spot has been bombed, I think. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Juha Pohjalainen Subject: One more idea for new commands (SWP) Date: 1995/11/28 Message-ID: <49eg5p$e5d@idefix.eunet.fi>#1/1 newsgroups: rec.games.corewar Because you have been talking about new commands, I just decided to share one of my new command ideas with all of you. So, what about new command SWP = swap. With this command you could swap contents of two locations, like wery weak wimp imp: swp.i 0,1 or some core messing swp.i <2667, <1143 or just swap two data values swp.ab 1,2 Think about it, talk about it, forget ... ? Jippo From: agserm@aol.com (AGSerm) Subject: Beginner's paper needs help Date: 1995/11/28 Message-ID: <49ebvb$cj9@newsbf02.news.aol.com>#1/1 newsgroups: rec.games.corewar This is my first attempt to write a paper, and I wondered if anybody could offer some criticism. ;name Mulberry 1.3 ;author Ansel G. Sermersheim ;strategy Standard paper step equ 5766 org start start spl 2 spl 1 jmp inst ptr1 dat step, 0 inst mov >ptr1, }ptr1 cplst jmp inst+step TIA for anything anybody wants to offer, Ansel Greenwood Sermersheim From: John K W Subject: Re: The Future of Pizza Date: 1995/11/28 Message-ID: <49dkse$hbj@geraldo.cc.utexas.edu>#1/1 references: <49dhpn$6l9@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >I have also finally put the finishing touches on the 94x hill (the >5x50 idea) and will be starting it soon. > >Now I have a few questions for you: > >Would you rather stay on the current machine, which is generally faster, >but inconsistent, or move to a slower but more consistent machine? Um... could you put one of the Hills on a separate machine? Oh, also it might be a good idea to limit the warrior cache to say 8 or so. That time the server hung and people submitted multiple warriors backed it up for an extra day. >Would you like the hills to stay at 20 places and 250 rounds, or move >to 25 places and 200 rounds? (the 5x50 hill would go to 5x40). I like the 25x200 places idea, myself. It'd allow for more hills, AND allow you to get at-a-glance results faster. (Dividing by 2.5 sometimes takes a calculator. :) >Do you really think we should move one of Pizza's hills (currently >2 hills, soon to be 3) to StormKing (currently 5 hills)? Well, before the StormKing Big Hill, I would've said yes. Now, maybe not. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: PMARS under OSs (was, um... something else. :-) Date: 1995/11/28 Message-ID: <49dncq$bob@agate.berkeley.edu>#1/1 references: <48jqd5$h7@daily-planet.nodak.edu> <48t7ua$kp5@geraldo.cc.utexas.edu> <49141q$eq6@agate.berkeley.edu> <49bcht$rm1@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W wrote: >mconst@soda.CSUA.Berkeley.EDU (Michael Constant) wrote: >>Get a real OS, then! :-) I'm running FreeBSD and pmars works wonderfully >>with the X display. It looks a lot nicer than dos, in fact, because it's > >What the hell is FreeBSD? Give us more info! FreeBSD is a free, fully source-code available Un*x operating system for PCs and compatibles. Personally, I like it a lot better than Linux for the following reasons: it's much faster for virtual memory-intensive operations (try writing a program which mallocs all available memory, then touches a byte of every page -- this will bring Linux to its knees); it's more stable, especially in the networking code; it's written by a tighter group of people, so everything is better integrated; and it actually has decent security. Note that many old Linux users are now switching to FreeBSD, mostly for the reasons I just gave. I think FreeBSD is a wonderful OS, myself... of course, YMMV. You can get more information at http://www.freebsd.org. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: jklewis@stimpy.us.itd.umich.edu (John K. Lewis) Subject: Re: Beginner's paper needs help Date: 1995/11/28 Message-ID: <49fpo6$gcu@lastactionhero.rs.itd.umich.edu>#1/1 references: <49ebvb$cj9@newsbf02.news.aol.com> newsgroups: rec.games.corewar One thing a paper needs is a way to make more of itself. Currently your 'paper' is only making more of itself. You need to spl to another copy so that you can create numbers. Right now there is only one "paper" running around. Check out the papers in the listing of warriors from Pizza. John AGSerm (agserm@aol.com) wrote: : This is my first attempt to write a paper, and I wondered if anybody could : offer some criticism. : ;name Mulberry 1.3 : ;author Ansel G. Sermersheim : ;strategy Standard paper : step equ 5766 : org start : : start spl 2 : spl 1 : jmp inst : ptr1 dat step, 0 : inst mov >ptr1, }ptr1 : cplst jmp inst+step : TIA for anything anybody wants to offer, Ansel Greenwood Sermersheim From: Beppe Bezzi Subject: Re: The Future of Pizza Date: 1995/11/28 Message-ID: <199511280957.KAA14220@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 20.33 27/11/95 -0500, sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >As most of you know, I am the maintainer for the Pizza Hills. > >Now I have a few questions for you: > >Would you rather stay on the current machine, which is generally faster, >but inconsistent, or move to a slower but more consistent machine? > The question here is for you :-) How much slower and how much more consistent? How long does it take to run 20 match times 200 rounds now, and how long in the slower machine ? The average load is approximately 10 challenges/day considering both hills 94 and -b, with wide fluctuations; to avoid queuing too much the slower machine has to be able to run a challenge in less than half an hour. >Would you like the hills to stay at 20 places and 250 rounds, or move >to 25 places and 200 rounds? (the 5x50 hill would go to 5x40). > Adding five places is good, even if a bit unfair toward dead Hall of Fame warriors. Jack, my warrior, will appreciate it a lot :-) >Do you really think we should move one of Pizza's hills (currently >2 hills, soon to be 3) to StormKing (currently 5 hills)? > If you fixed the script, so as future student's bugs won't hang the hill, there is no need to move. > >Thanks for your time... Thanks to you for the work you make to allow us playing. > >Thos > > > -Beppe Bezzi From: poke@lyseo.otol.fi (Juho Snellman) Subject: Re: The future of redcode Date: 1995/11/28 Message-ID: <49ejpt$ll0@pan.otol.fi>#1/1 references: <9511260803.AA06477@idnsun.gpct.Vanderbilt.Edu.noname> <499g59$e3f@agate.berkeley.edu> <498jeu$3rk@agate.berkeley.edu> <49c51v$sb8@news-rocq.inria.fr> <49cn31$m6t@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: : Yeah! Backwards-running imps crashing into forwards-running imps... Heh, does anyone remember the old backwardsrunning imp :) Look in the early r.c.g digest for the source. -- Juho Snellman From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Core warrior #7 - 2/2 Date: 1995/11/28 Message-ID: <49ek04$oo4@agate.berkeley.edu> references: <199511271757.SAA03676@iol-mail.iol.it> newsgroups: rec.games.corewar Beppe Bezzi wrote: >start sne.i start+100, start+112 > mov.ab #100, target > sne.i start+124, start+136 > mov.ab #124, target > sne.... etc You *did* mean seq, right? :-) >Quickscanners will be scanning early in the battle, certainly in the first >100 cycles, before many bombs have been thrown or replicators sprouted. >Anything they detect is quite likely to be the enemy warrior code or a decoy >close to it. This means they can afford to invest a _lot_ of effort on >damaging that area of core. Unfortunately, this isn't true :-) It might be instructive for me to repost the comments I gave with my original posting of Pyramid: : 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. [...] >The most interesting makes somewhat more efficient use of space by a >sequence: > > SNE.i start+150, start+250 > SEQ.i start+350, start+450 > MOV.ab #150, Target > ... > >Speed is still 2c, but this method packs 4 comparisons into 3 locations at >the cost of requiring more work in decoding exactly where the hit occurred. >This method was used in Pyramid and Thermite, which aim to win via their >thorough QS, but Paul Klein's recently-published Die Hard used the simpler >SNE/MOV scheme for maximum speed in decoding. He was just aiming to hit often >enough to do damage with his brainwash, so packing density came second to >decoding speed. Hmm, you speak as if it takes serious work to do the decoding. Pyramid does it in two cycles, and I don't believe it's *possible* to write code so badly that it takes more than four or five :-) >[BTW I should credit the rest of the article too. Most of the things I know >about Quickscanners came from experimenting with Michael Constant's Sauron-T, >which is in the 1993 competition archive. Ah *ha*! No wonder you have strange ideas about quickscanners :-) Sauron-T was a pretty horrible warrior. It was Sauron v2.4, hurriedly adapted for tournament parameters -- and Sauron was never very good in the first place :-) If you want to write a quickscanner, read Pyramid v5.5. There's no substitute. I've only posted it 10 or 15 times, but I'll post it again if anyone's missing a copy :-) >Right at the end of the quick-to-nasty spectrum come Quickscanners. These >will usually only find one target, but it is very high quality, meaning that >there is a good chance that the enemy has a substantial fraction of his >processes working near to the scanned location. We should invest substantial >time flattening the whole area. Again, this works in theory but not in practice. Bootstrapping really doesn't take very long. To see this in action, try playing with the constants in Pyramid v5.5 and see how badly it begins to score if you tell it to bomb a wide area around the spot where it found the enemy, and also see how badly it scores if you tell it to bomb very thoroughly. BTW, just as I typed this in, I came up with a truly diabolical idea that could put Pyramid back on the hill... perhaps even back in its favorite spot on the hill :-) Stay tuned -- Pyramid v6.0 is coming soon to a hill near you! -- Michael Constant (mconst@soda.csua.berkeley.edu) From: stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) Subject: Re: The Future of Pizza Date: 1995/11/28 Message-ID: <9511280542.AA07259@idnsun.gpct.Vanderbilt.Edu.noname>#1/1 newsgroups: rec.games.corewar Thos wrote: >Do you really think we should move one of Pizza's hills (currently >2 hills, soon to be 3) to StormKing (currently 5 hills)? > 94x hasn't been "moved". Remember, you killed the 55440 hill to make room for the 5*50 round hill (anyone still interested in that?). There's been some interest to revive the big hill lately, so Tuc reopened it at stormking. This is in your best interest because it evens out the load. Your two hills (94 and beginners) still get more traffic than all of the stormking hills combined. This is a good place to thank both Thos and Tuc for their service to the core war community; where would we be without KotH? When making requests for new features, you should realize that hill maintenance and script writing is not a trivial job. -Stefan From: John K W Subject: Re: Beginner's paper needs help Date: 1995/11/28 Message-ID: <49femn$n1d@geraldo.cc.utexas.edu>#1/1 references: <49ebvb$cj9@newsbf02.news.aol.com> newsgroups: rec.games.corewar agserm@aol.com (AGSerm) wrote: >This is my first attempt to write a paper, and I wondered if anybody could >offer some criticism. Well, for starters you might wanna check out the 94b Hill. Use ;redcode-94b instead of ;redcode-94. >;name Mulberry 1.3 >;author Ansel G. Sermersheim >;strategy Standard paper Hmmm. Well, this is certainly not standard paper. Check out http://pauillac.inria.fr/~doligez/corewar/ and go to the link on "paper" for some examples of good code. >step equ 5766 > > org start > >start spl 2 > spl 1 > jmp inst >ptr1 dat step, 0 >inst mov >ptr1, }ptr1 >cplst jmp inst+step Well, for starters use this to make three instructions: spl 1 mov -1, 0 -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Michael Constant Subject: Re: Core warrior #7 - 2/2 Date: 1995/11/28 Message-ID: <199511282308.PAA06627@soda.CSUA.Berkeley.EDU>#1/1 newsgroups: rec.games.corewar > I'm too young in corewar for having seen Pyramid in action and, even if I > have its code, I used for La Bomba the slow decoding that is in the FAQs; > using Pyramid one I can save some time, interesting for next improvement.... Ah... Pyramid spent quite a while on top of the hill :-) At one point I believe there was a 16-point gap between Pyramid and second place. As you quite correctly pointed out, Pyramid's decline and eventual fall was due to the rise of silk paper. And yes, Pyramid v6.0 does not use a vampire as its main attack (I'm not sure whether to keep the vampiric quickscan or replace that too). Yes, Pyramid v6.0 should crunch quiz quite nicely. I don't know how La Bomba will fare against it, though... }:-) You do have a copy of the latest Pyramid, right? I know that Planar only has v2.0 on his web page, and v5.5 has some substantial improvements and bugfixes, not to mention better constants. - Michael Constant From: ruhl@phoebe.cair.du.edu (Robert A. Uhl) Subject: Re: Ideas for new instructions Date: 1995/11/29 Message-ID: <49g97s$nb8@hermes.cair.du.edu>#1/1 references: <9511260803.AA06477@idnsun.gpct.vanderbilt.edu.noname> <499g59$e3f@agate.berkeley.edu> <49bcvn$rm1@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W spake thusly: > >I don't think pspace complicates things at all. It's so highly seperate >from other instructions, and yet integrated so nicely into any program >or programs. Well, i believe that pspace should be used via an operand prefix, just another addressing mode. I really don't like the current situation. But I also have no solid ideas for a good implementation of the idea. Perhaps )^( could be used. I know that it was implemented as an instruction for a reason, but I really dislike it that way. It just isn't clean enough for me. This is not to say that I beleive that it should stay; I still have my doubts as to its usefulness. It does enable warriors to be more intelligent. The question is: how much more intelligent are they? -- +------------------------------------------------------------------------+ | Bob Uhl | Spectre | `En touto nika' + | | U of D | PGG FR No. 42 | http://mercury.cair.du.edu/~ruhl/ | +------------------------------------------------------------------------+ From: Anders Ivner Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/29 Message-ID: <9511291338.AA04121@su6-1.ida.liu.se>#1/1 newsgroups: rec.games.corewar > > > >All agree that we need full set of pre-/post- inc/dec modes > > > > (I am fairly new to core war, but still I can't be silent while opinions > are put in my mouth..) > > I don't agree. I can write fine code with just predec and postinc. > Having even more addressing modes seems to shift the emphasis from > strategy to code packing. What will be next, predecrement double > indirect? I disagree as well. There's a variety of indirect modes that could be useful at one time or another. That's no reason to add them. Part of the fun is making things work with whatever means are available. > Actually, (and less seriously) I could use some of the following opcodes: > > brs bribe redcode simulator > cpd close the pod bay doors > cps crash pizza server > dra offer a draw > fow find other warrior > gpb goto plan b > hid hide from scanner > jgs jump to good strategy > jtr jump if time is right > lgs launch gate crashing spiral > rep repair code > run run away!! > sde solve the Dirac equation (useful for Stefan&Nandor's tourney) > srt quicksort other warrior (this one is also useful) > stb send terminator back in time > tbr throw bombs randomly > tim call a "time-out" > > - Kurt How about: bwa brainwash other warrior rdo redefine opcode (JMP -> DAT etc...) shs set hill score for warrior /Anders, the die-hard conservative who dreams of the good-old-days of the '88 standard. From: ruhl@phoebe.cair.du.edu (Robert A. Uhl) Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/29 Message-ID: <49ga4b$nm2@hermes.cair.du.edu>#1/1 references: <49ffoq$n1d@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W spake thusly: >tradon@cyf-kr.edu.pl (Tomasz.Radon) wrote: >>All agree that we need full set of pre-/post- inc/dec modes > >I don't agree. Well, in all sincerity, you _do_ seem to be in the minority. It makes the instruction set that much more symmetrical. >>What do you thing about this: > >Icky. :( Think of it not as `open angle bracket, a, close angle bracket,' but rather `a in angle brackets,' just as you you think of `(2x+y)' as `2x plus y in parentheses.' It's really a nice way of doing it, although it took me a second to realise it. >>We can also replace @ and * by and {b} > >Even worse. They're just another form of parentheses. >>it is clear, isn't it? > >Not really. I do NOT want operands after variables if it is at all >possible to avoid it. Again, do not think of it as operands after variables; think of it as grouping, just like parentheses. -- +------------------------------------------------------------------------+ | Bob Uhl | Spectre | `En touto nika' + | | U of D | PGG FR No. 42 | http://mercury.cair.du.edu/~ruhl/ | +------------------------------------------------------------------------+ From: ruhl@phoebe.cair.du.edu (Robert A. Uhl) Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/29 Message-ID: <49g9sp$nlv@hermes.cair.du.edu>#1/1 references: newsgroups: rec.games.corewar Tomasz.Radon spake thusly: > >All agree that we need full set of pre-/post- inc/dec modes Well, not all, but most (including myself) would at least like to see them in action. >Most people suggested: > > >b preincrement > b< postdecrement > b> postincrement > >It seems be logical BUT >b - is not backward compatibile! Well, it sort of is; we're just working with a draft, after all. >What do you thing about this: > > - - B-field predecrement old form + - B-field preincrement NEW > - - B-field postdecrement NEW > + - B-field postincrement old form >b > > -{a} - A-field predecrement old form {a > +{a} - A-field preincrement NEW > {a}- - A-field postdecrement NEW > {a}+ - A-field postincrement old form }a > >We can also replace @ and * by and {b} > > - A-field indirect old form @b > {a} - B-field indirect old form *a > >it is clear, isn't it? You know, I like it. It seems like the assembler which I've done. I'd add [] for pspace: -[p] - pspace (what does psapce stand for anyway?) predec +[p] - pspace preinc [p] - pspace access [p]- - pspace postdec [p]+ - pspace postinc What do y'al think about it? I like it; it's nicely symmetrical, and I really don't believe that it'd be too powerful. >For me it looks realy nice and easy to understand. >Of course old style formats (@b b *a {a }a) should be still accepted! >It allow us to use one compiler for old and new warriors. It really is nice. The crucial bit is to not think of as `open angle bracket, a, close angle bracket,' but rather `a in angle brackets,' just like you think of `2x + y in parentheses.' In order to demonstrate this, I have reproduced the fellow's demonstration. > old new > > mov.i <12,>34 mov.i -<12> , +<34> > add @15,{22 add <15> , -{22} > sub 21>,22} sub <21>+, {22}+ -- +------------------------------------------------------------------------+ | Bob Uhl | Spectre | `En touto nika' + | | U of D | PGG FR No. 42 | http://mercury.cair.du.edu/~ruhl/ | +------------------------------------------------------------------------+ From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Quickscanners (Was: Re: Core warrior #7 - 2/2) Date: 1995/11/29 Message-ID: <49igek$na1@agate.berkeley.edu>#1/1 references: <199511271757.SAA03676@iol-mail.iol.it> <49i2qe$b5u@onramp.arc.nasa.gov> newsgroups: rec.games.corewar Dave Darling wrote: > This is much more nit-picky than I had first intended. My first >thought was, "No way! Not all of core in 39 cycles!" Now that I've done >the number-crunching, I can see what you mean. > I think that one of the difficulties is that most programs that >I've seen published here that boot-and-decoy get away in *far* fewer than >39 cycles--most take <10, and that's if they're pretty big. Well, just because 39 cycles is the maximum doesn't mean that's how long it always takes :-) When quickscanners get lucky, they can be very *very* quick... even QuickFreeze, the original quickscanner, had a nasty habit of nailing boot-and-decoy programs when they were least expecting it. And if you optimize your quickscan constants, you can do this with a certain amount of consistency. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: richb@haven.ios.com (Bernard Rich) Subject: Getting Started...Again Date: 1995/11/29 Message-ID: <49i8t8$5q1@news.ios.com>#1/1 newsgroups: rec.games.corewar I first learned about Core Wars via Scientific American. For a long time I was limited to a C-64, then I joined ICWS after getting an 8088 PC-compatible. Unfortunately, I had to drop out before finding an opponent. What software and documentation are available on the Internet? (for Windows 3.1 and/or DOS 6.x) From: pk6811s@acad.drake.edu Subject: Re: Quickscanners (Was: Re: Core warrior #7 - 2/2) Date: 1995/11/29 Message-ID: <1995Nov29.180407@acad.drake.edu>#1/1 references: <199511271757.SAA03676@iol-mail.iol.it> <49i2qe$b5u@onramp.arc.nasa.gov> newsgroups: rec.games.corewar Dave Darling writes: [...] > I think that one of the difficulties is that most programs that > I've seen published here that boot-and-decoy get away in *far* fewer than > 39 cycles--most take <10, and that's if they're pretty big. However, most [...] In this scenario you would find your 100-length opponent in 20 cycles about half the time, which is why most qscanners use a JMN about half-way through the scan to see if anything was found. Some check more frequently. 20 cycles is a serious upper limit to booting, especially if that has to include SPL's to launch an imp or multiple copies of paper - or just about any kind of startup besides copying code to another location. Paul Kline pk6811s@acad.drake.edu From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: Re: The Future of Pizza Date: 1995/11/29 Message-ID: <49imsc$aqh@charnel.ecst.csuchico.edu>#1/1 references: <49dhpn$6l9@charnel.ecst.csuchico.edu> <49dkse$hbj@geraldo.cc.utexas.edu> <49g34g$o81@charnel.ecst.csuchico.edu> <49gdk5$hit@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W wrote: >sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >> >>With the less nice code, I don't think people will be submitting >>multiple copies of the same warrior anymore. > >Um. What? Could you 'splain that? Before, if the machine was lagged, it could take a while for you to receive a confirmation of your submission. Now, the reply should be fairly quick. Therefore, you won't submit again thinking something happened to your warrior. Now do I make any sense? :) > / John K. Wilkinson - jwilkinson@mail.utexas.edu \ Thos From: John K W Subject: ;kill Date: 1995/11/29 Message-ID: <49httu$f5m@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar I just checked the status of the Pizza Hill, and NOW my test warriors are dead, which is pointless, since the only reason I wanted to submit one warrior at a time was to keep from knocking Armory off. After the third submission, it suddenly killed the previous two at the same time... but "Evolve 7.4" is still alive... I think figured out what happened. The missing ;redcode-94 must have pushed one of my tests out of sequence, and apparently ";kill test" kills everything that starts with "test". How odd. Does that mean if I'd submitted "Porch Swing" and "Porch Swing 2" I couldn't kill one without killing the other? -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/29 Message-ID: <49ht79$ei6@geraldo.cc.utexas.edu>#1/1 references: <49gpe6$lk@larry.rice.edu> <1995Nov29.074010.3077@rhodes> newsgroups: rec.games.corewar graham@hal.mathcs.rhodes.edu (Randy Graham) wrote: >Kurt Franke (kfranke@rice.edu) wrote: >[ideas for new opcodes deleted] >You forgot > win - win this round > >of course, then everyone would have a 50/50/0 score, as the first >warrior to execute the win opcode would win... > >: - Kurt > >Randy srg - switch the rules of the game This would allow you to simply password protect the MARS during the first round, and not allow the other warrior to run it's code in the following rounds, thusly allowing a quick 100 wins. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Armory... Date: 1995/11/29 Message-ID: <49hss9$ei6@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar Well, do to some sort of error in the Pizza server, I think due to one of my warriors missing a ;redcode-94 line, combined with the nine warrior queue that had added up... I ended up with three test warriors on the Hill at one time. This was enough to kill off my baby! I'm truly bummed that the death of Armory came from an error in one of my own submissions for a new warrior... I think I'm going to go sulk for a few weeks. Cya later. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Kurt Franke Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/29 Message-ID: <49gpe6$lk@larry.rice.edu>#1/1 references: newsgroups: rec.games.corewar tradon@cyf-kr.edu.pl (Tomasz.Radon) wrote: > > >Hi, > >All agree that we need full set of pre-/post- inc/dec modes > (I am fairly new to core war, but still I can't be silent while opinions are put in my mouth..) I don't agree. I can write fine code with just predec and postinc. Having even more addressing modes seems to shift the emphasis from strategy to code packing. What will be next, predecrement double indirect? Actually, (and less seriously) I could use some of the following opcodes: brs bribe redcode simulator cpd close the pod bay doors cps crash pizza server dra offer a draw fow find other warrior gpb goto plan b hid hide from scanner jgs jump to good strategy jtr jump if time is right lgs launch gate crashing spiral rep repair code run run away!! sde solve the Dirac equation (useful for Stefan&Nandor's tourney) srt quicksort other warrior (this one is also useful) stb send terminator back in time tbr throw bombs randomly tim call a "time-out" - Kurt From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Bye to Porch Date: 1995/11/29 Message-ID: <1995Nov29.075006.3078@rhodes>#1/1 newsgroups: rec.games.corewar Well, Porch Swing + finally fell off the hill yesterday. I was going to make some changes to it and resubmit itwhen it fell off. But, right before he fell, JKW put up Porch Swing 2. I don't know what's in PS2, but I am assuming from the name it is an adaption of Porch Swing. So, I doubt you'll see another version of PS from me. Instead, I suppose I'll have to start working on my new idea for a qscanner. And, of course, the tournament (which I hope goes to 10 rounds, even though the longer I play the further I fall away from the top). Hope to see you all on the hill again soon. Randy From: John K W Subject: 25 and 200 Hill on Pizza. Date: 1995/11/29 Message-ID: <49ikrv$34p@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar Yay! The Pizza 25 opponent, 200 round setup it going. Well... sort of 'yay'. I mean, not only did a ";kill" bug knock off Armory, but 10 hours later 5 new slots are added. How nice. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: Re: ;kill Date: 1995/11/29 Message-ID: <49in7l$aum@charnel.ecst.csuchico.edu>#1/1 references: <49httu$f5m@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W wrote: > >I just checked the status of the Pizza Hill, and NOW my test warriors >are dead, which is pointless, since the only reason I wanted to submit >one warrior at a time was to keep from knocking Armory off. >After the third submission, it suddenly killed the previous >two at the same time... but "Evolve 7.4" is still alive... Does that mean you were unsuccessful in artificially inflating Armory's age? :) >I think figured out what happened. The missing ;redcode-94 must >have pushed one of my tests out of sequence, and apparently >";kill test" kills everything that starts with "test". How odd. > >Does that mean if I'd submitted "Porch Swing" and "Porch Swing 2" >I couldn't kill one without killing the other? The way kill works is it kills all your warriors which contain that substring. This is the way it has always worked. If you submit "warrior a" and then "warrior b", you can kill them both with ";kill warrior" when you submit "warrior c". So to answer your question, yes, you cannot kill "Porch Swing" without killing "Porch Swing 2", unless you kill it when submitting "Porch Swing 2". > / John K. Wilkinson - jwilkinson@mail.utexas.edu \ Thos From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: New Hill at Pizza Date: 1995/11/29 Message-ID: <49inea$b07@charnel.ecst.csuchico.edu>#1/1 newsgroups: rec.games.corewar Well, I finally got the 5x40 hill running. It's only 2 months late, but who's counting. :) For now, when you submit a warrior to the 94 hill or the 94x hill, it will go to both hills. I'll probably split them after a month or two, but for now we're going to see if there's a big margin of error. All hills are now 25 places and 200 rounds as well. Thos From: John K W Subject: Re: Quickscanners (Was: Re: Core warrior #7 - 2/2) Date: 1995/11/29 Message-ID: <49ih36$68@geraldo.cc.utexas.edu>#1/1 references: <199511271757.SAA03676@iol-mail.iol.it> <49i2qe$b5u@onramp.arc.nasa.gov> newsgroups: rec.games.corewar Dave Darling wrote: > Seems like we have another (much weaker) rock-paper-scissors analogy. >The Qscanners can beat P-spacers, the P-spacers can beat (many) non-P-spa- >cers, and the (faster-booting) non-P-scpacers can beat the Qscanners. > > Funny, when I started this post, I thought I knew where it was going. > >--DD Just in case you thought you'd figured out where you were going, you forgot about Brainwashers. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: graham@hal.mathcs.rhodes.edu (Randy Graham) Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/29 Message-ID: <1995Nov29.074010.3077@rhodes>#1/1 references: <49gpe6$lk@larry.rice.edu> newsgroups: rec.games.corewar Kurt Franke (kfranke@rice.edu) wrote: [ideas for new opcodes deleted] You forgot win - win this round of course, then everyone would have a 50/50/0 score, as the first warrior to execute the win opcode would win... : - Kurt Randy From: Dave Darling Subject: Re: Quickscanners (Was: Re: Core warrior #7 - 2/2) Date: 1995/11/29 Message-ID: <49i2qe$b5u@onramp.arc.nasa.gov>#1/1 references: <199511271757.SAA03676@iol-mail.iol.it> newsgroups: rec.games.corewar In article <49ek04$oo4@agate.berkeley.edu> Michael Constant, mconst@soda.CSUA.Berkeley.EDU writes: >: 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) ... [snip!] ^^^^^^^^^^^^^^^^^^^^^ [Head scratching; quick calculations:] 8000 cells, -100 (my space) -100 (your space) = 7800 cells / 39 cycles = 200 cells per cycle to be scanned / 2 cells scanned per cycle = 100 cells per cycle. Okay, so you're assuming a length-100 warrior. Not always a valid assumption, you'd miss warriors that were shorter--like a little 5-instruc- tion bomber with no boot and no decoy (is there one of those on the hill?) would only be found 5% of the time. This is much more nit-picky than I had first intended. My first thought was, "No way! Not all of core in 39 cycles!" Now that I've done the number-crunching, I can see what you mean. I think that one of the difficulties is that most programs that I've seen published here that boot-and-decoy get away in *far* fewer than 39 cycles--most take <10, and that's if they're pretty big. However, most of those warriors are just booting a little stone or a smaller scanner. Some warriors do other stuff first, particularly the P-warriors, which is why Qscanners just murder them. Seems like we have another (much weaker) rock-paper-scissors analogy. The Qscanners can beat P-spacers, the P-spacers can beat (many) non-P-spa- cers, and the (faster-booting) non-P-scpacers can beat the Qscanners. Funny, when I started this post, I thought I knew where it was going. --DD Dave Darling darling@simlab.arc.nasa.gov From: John K W Subject: (no subject) Date: 1995/11/29 Message-ID: <49htt7$f5m@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar I just checked the status of the Pizza Hill, and NOW my test warriors are dead, which is pointless, since the only reason I wanted to submit one warrior at a time was to keep from knocking Armory off. After the third submission, it suddenly killed the previous two at the same time... but "Evolve 7.4" is still alive... I think figured out what happened. The missing ;redcode-94 must have pushed one of my tests out of sequence, and apparently ";kill test" kills everything that starts with "test". How odd. Does that mean if I'd submitted "Porch Swing" and "Porch Swing 2" I couldn't kill one without killing the other? -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: mconst@soda.CSUA.Berkeley.EDU (Michael Constant) Subject: Re: Core warrior #7 - 2/2 Date: 1995/11/29 Message-ID: <49hcle$729@agate.berkeley.edu>#1/1 references: <199511282308.PAA06627@soda.csua.berkeley.edu> newsgroups: rec.games.corewar Aargh! Please, *please* respond to a message on the corewar-l, *or* respond to a message by private email, but not both! For those of us who read the rec.games.corewar newsgroup instead of subscribing to the corewar-l list, it's very confusing, because a response a message that appears to be private email ends up actually going to the entire list (and thus, the entire newsgroup). Some mailers are particularly bad, and edit the To: and CC: headers so that it appears that the message was sent only to me, rather than to an entire mailing list. The only cue then is in the original From line (not the From: line), which many people (including me) have their mail readers configured to hide :-/ So, please, if you respond to a message on the corewar-l, *don't* CC the response to the original sender. Thanks. -- Michael Constant (mconst@soda.csua.berkeley.edu) From: John K W Subject: Re: Core warrior #7 - 2/2 Date: 1995/11/29 Message-ID: <49ge2v$hit@geraldo.cc.utexas.edu>#1/1 references: <199511282308.PAA06627@soda.CSUA.Berkeley.EDU> newsgroups: rec.games.corewar Michael Constant wrote: >You do have a copy of the latest Pyramid, right? I know that Planar >only has v2.0 on his web page, and v5.5 has some substantial improvements >and bugfixes, not to mention better constants. Planar has v5.5. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: tuc@news.stormking.com (Scott J. Ellentuch) Subject: Re: The Future of Pizza Date: 1995/11/29 Message-ID: <49gk6o$omn@valhalla.stormking.com>#1/1 references: <9511280542.AA07259@idnsun.gpct.Vanderbilt.Edu.noname> <49ff20$n1d@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W (jwilkinson@mail.utexas.edu) wrote: : : Goooood Thos. : Goooood Tuc. : (I'd much rather have grapes or carrots, but I greatfully accept the Kudos bar) Tuc (Along my merry way) -- * --- --- |Scott J. Ellentuch, Pres | The Telecom Security Group * * | | | |Comm. and Comp. Security | (Storm King family of Companies) * * | |__|__ |Consultants and Engineers | P.O. Box 69, Newburgh, NY 12551 * From: John K W Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/29 Message-ID: <49gdp7$hit@geraldo.cc.utexas.edu>#1/1 references: <9511281935.AA07423@idnsun.gpct.Vanderbilt.Edu.noname> newsgroups: rec.games.corewar stst@idnsun.gpct.Vanderbilt.Edu (Stefan Strack) wrote: >>>All agree that we need full set of pre-/post- inc/dec modes >> >>I don't agree. >> > >For once, I actually agree with John (just kidding, John :). I don't think Heh. I'm used to being a lone wolf... Arooo! >we need any more modes than we already have, and the "post-operand" notation >is not particularly clear. Operands can be complex expressions with >parentheses, etc., and an appended addressing mode symbol might be overlooked. Yeah! You tell 'im, Stefan! Down with post-operands! After I've written the "perfect" 94 warrior, we can add those in. :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: The Future of Pizza Date: 1995/11/29 Message-ID: <49gdk5$hit@geraldo.cc.utexas.edu>#1/1 references: <49dhpn$6l9@charnel.ecst.csuchico.edu> <49dkse$hbj@geraldo.cc.utexas.edu> <49g34g$o81@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >Nope. It is possible, but it would require a bit of coding, and I >don't think the school would like me tieing up two machines. Ah. Ok. >>Oh, also it might be a good idea to limit the warrior cache to >>say 8 or so. That time the server hung and people submitted >>multiple warriors backed it up for an extra day. > >With the less nice code, I don't think people will be submitting >multiple copies of the same warrior anymore. Um. What? Could you 'splain that? -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: Re: The Future of Pizza Date: 1995/11/29 Message-ID: <49g8ho$pbs@charnel.ecst.csuchico.edu>#1/1 references: <199511280957.KAA14220@iol-mail.iol.it> newsgroups: rec.games.corewar In article <199511280957.KAA14220@iol-mail.iol.it>, Beppe Bezzi wrote: >At 20.33 27/11/95 -0500, sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: > >>Would you rather stay on the current machine, which is generally faster, >>but inconsistent, or move to a slower but more consistent machine? >> >The question here is for you :-) How much slower and how much more consistent? > >How long does it take to run 20 match times 200 rounds now, and how long in >the slower machine ? Right now, on webhead, 20x250 will take a maximum of 45 minutes when we are getting >80% of the CPU. By maximum I mean 100% ties. That means it will take less than 20 minutes for the average battle. Unfortunately, with so many other processes running on webhead, especially during peak web hours, we sometimes get less than 20% of the CPU. This can push the return time for challenges to an hour or more in some cases. On the slower machine, 20x250 would take a maximum of about 75 minutes, but I think we would never get less than 50% of the CPU, except in rare cases. Right now I think staying on webhead would be best. If the instances of clogging increase, I may consider moving the hills to the more consistent machine. >>Do you really think we should move one of Pizza's hills (currently >>2 hills, soon to be 3) to StormKing (currently 5 hills)? >> >If you fixed the script, so as future student's bugs won't hang the hill, >there is no need to move. With the scripts less nice, the hills will never "hang", but they will be slowed considerably at certain times. >-Beppe Bezzi Thos From: Beppe Bezzi Subject: Pizza 5 x 40 hill Date: 1995/11/30 Message-ID: <199511300812.JAA09242@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar I got those results by my last submission to -94 hill (echoed to 94x) Program "Die Hard" (length 99) by "P.Kline" (contact address "PDK@ADMIN.DRAKE.EDU"): ;strategy minimal kill+, maximal survival Smart bomb wins: 28 Die Hard wins: 47 Ties: 125 Program "Smart bomb" (length 100) by "Beppe Bezzi" (contact address "bezzi@iol.it"): has challenged the ICWS '94 Experimental hill. Program "Die Hard" (length 99) by "P.Kline" (contact address "PDK@ADMIN.DRAKE.EDU"): ;strategy minimal kill+, maximal survival Smart bomb wins: 8 8 8 8 8 Total: 40 Die Hard wins: 7 7 7 7 7 Total: 35 Ties: 25 25 25 25 25 Total 125 It's not difficult to guess that -F pmars option is in use; the only thing I know comparing results is that I begin winning, to be catched and surpassed by Paul in the long run :-( Either Thos will change the -F number every time pspace is reset (if possible in the same way it will change running the 41th round in the usual way, to be able to compare results), or it's simpler to run but 40 rounds and multiply result times five. I would also like that 94x fights be queued with a lower priority than ordinary one, i.e. be run when no warrior is waiting for 94; this to reduce wait time for the, IMO at least being 94x only to compare results, more important 94 hill. -Beppe Bezzi From: Beppe Bezzi Subject: Re: Smart bomb challenge results Date: 1995/11/30 Message-ID: <199511302337.AAA21379@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar .... Your program Smart bomb fights 200 times: Smart bomb wins: 89 Smart bomb wins: 101 Ties: 10 ... I'm _sure_ I sent but one copy of the warrior as much as I'm sure I sent, I got good compile, a warrior two days ago (a one liner to kill my test) and never got results. -Beppe From: John K W Subject: Re: Pizza 5 x 40 hill Date: 1995/11/30 Message-ID: <49l3h3$o2g@geraldo.cc.utexas.edu>#1/1 references: <199511300812.JAA09242@iol-mail.iol.it> newsgroups: rec.games.corewar >It's not difficult to guess that -F pmars option is in use; the only thing I >know comparing results is that I begin winning, to be catched and surpassed >by Paul in the long run :-( If you missed my post, I told him, and it's fixed. >I would also like that 94x fights be queued with a lower priority than >ordinary one, i.e. be run when no warrior is waiting for 94; this to reduce >wait time for the, IMO at least being 94x only to compare results, more >important 94 hill. Yeah, that's sounds good, in theory. In practice, the Pizza Hill queue is rarely empty. :/ -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: ;kill Date: 1995/11/30 Message-ID: <49itdn$9mn@geraldo.cc.utexas.edu>#1/1 references: <49httu$f5m@geraldo.cc.utexas.edu> <49in7l$aum@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >John K W wrote: >> >>I just checked the status of the Pizza Hill, and NOW my test warriors >>are dead, which is pointless, since the only reason I wanted to submit >>one warrior at a time was to keep from knocking Armory off. >>After the third submission, it suddenly killed the previous >>two at the same time... but "Evolve 7.4" is still alive... > >Does that mean you were unsuccessful in artificially inflating >Armory's age? :) Well, that wasn't really my intention. (Truth be known I was trying to kill PHQ. :) But I WAS successful in artificially DEFLATING Armory's age... Which is annoying. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: New Hill at Pizza Date: 1995/11/30 Message-ID: <49kn6r$evd@geraldo.cc.utexas.edu>#1/1 references: <49inea$b07@charnel.ecst.csuchico.edu> <49j0b6$c5t@geraldo.cc.utexas.edu> <49jg10$gii@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >John K W wrote: >>Um, do you have the -F option on still? I think you do. >>It defeats the purpose of that Hill entirely. > >Um... Ooops. > Heh. :) Stefan told me I was being silly, but I noticed that "testing 1 2 3" got different scores, so it looks fixed. Coo'. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: Anders Ivner Subject: round 7...brrr Date: 1995/11/30 Message-ID: <9511302113.AA02302@su6-1.ida.liu.se>#1/1 newsgroups: rec.games.corewar Round 7 seems to me to be the hardest one so far. I haven't a clue about what is a good strategy. Also, there does not appear to be a way to 'play it safe' (You will suffer heavily from 'lucky hits' from the opponent). /Anders From: Beppe Bezzi Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/30 Message-ID: <199511301802.TAA16469@iol-mail.iol.it>#1/1 newsgroups: rec.games.corewar At 10.54 30/11/95 -0500, Anders Ivner wrote: >> > >> >All agree that we need full set of pre-/post- inc/dec modes >> >> Well, not all, but most (including myself) would at least like to see >> them in action. >> > >Huh? I thought most people were against, judging from the last few days' >posts. > I'm against. I see no need to introduce new arguments. With > and < we can make almost all we want and, as you told in a previous posting, part of the fun is using what we have. >/Anders > > -Beppe From: "Tomasz Radon" Subject: Re: "Re: Post/pre inc/dec modes - new idea" Date: 1995/11/30 Message-ID: <458C1D6BE4@pen_kom.penetrator.krakow.pl>#1/1 newsgroups: rec.games.corewar > Tomasz.Radon spake thusly: > > > >All agree that we need full set of pre-/post- inc/dec modes > > Well, not all, but most (including myself) would at least like to see > them in action. > > >Most people suggested: > > > > > >b preincrement > > b< postdecrement > > b> postincrement > > > >It seems be logical BUT >b - is not backward compatibile! > > Well, it sort of is; we're just working with a draft, after all. > > >What do you thing about this: > > > > - - B-field predecrement old form > + - B-field preincrement NEW > > - - B-field postdecrement NEW > > + - B-field postincrement old form >b > > > > -{a} - A-field predecrement old form {a > > +{a} - A-field preincrement NEW > > {a}- - A-field postdecrement NEW > > {a}+ - A-field postincrement old form }a > > > >We can also replace @ and * by and {b} > > > > - A-field indirect old form @b > > {a} - B-field indirect old form *a > > > >it is clear, isn't it? > > You know, I like it. It seems like the assembler which I've done. > I'd add [] for pspace: > > -[p] - pspace (what does psapce stand for anyway?) predec > +[p] - pspace preinc > [p] - pspace access > [p]- - pspace postdec > [p]+ - pspace postinc > > What do y'al think about it? I like it; it's nicely symmetrical, and > I really don't believe that it'd be too powerful. I though about using %p as a P-space related mode but [p] seems to be much better than % (it's similar to {} and <> ) > > >For me it looks realy nice and easy to understand. > >Of course old style formats (@b b *a {a }a) should be still accepted! > >It allow us to use one compiler for old and new warriors. > > It really is nice. The crucial bit is to not think of as `open > angle bracket, a, close angle bracket,' but rather `a in angle > brackets,' just like you think of `2x + y in parentheses.' In order > to demonstrate this, I have reproduced the fellow's demonstration. > > > old new > > > > mov.i <12,>34 mov.i -<12> , +<34> > > add @15,{22 add <15> , -{22} > > sub 21>,22} sub <21>+, {22}+ Let's sum it up #x - immediate $x - address pre-dec post-dec pre-inc post-inc indirect - A-field related - - + + {x} - B-field related -{x} {x}- +{x} {x}+ {x} [x] - P-space related -[x] [x]- +[x] [x]+ [x] It's clear, logical easy to undestand! If we want to limit the power of P-space we can not allow to use any p-space mode except [x] All comments are _realy_ welcome! Thomas Radon -------------------------------------------------------------------------- __/__/__/ __/__/ __/ __/ __/__/__/ __/ __/ __/ __/ __/ __/__/ __/__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/__/ __/__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/__/ __/ __/ __/__/__/ __/ __/ +---------------------------------+ |Tomasz.Radon@Penetrator.Krakow.pl| |tradon@cyfronet.krakow.pl | +---------------------------------+ From: Anders Ivner Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/30 Message-ID: <9511301547.AA01745@su6-1.ida.liu.se>#1/1 newsgroups: rec.games.corewar > > > >All agree that we need full set of pre-/post- inc/dec modes > > Well, not all, but most (including myself) would at least like to see > them in action. > Huh? I thought most people were against, judging from the last few days' posts. /Anders From: "Tomasz Radon" Subject: Re: "Re: Ideas for new instructions" Date: 1995/11/30 Message-ID: <4537092069@pen_kom.penetrator.krakow.pl>#1/1 newsgroups: rec.games.corewar > John K W spake thusly: > > > >I don't think pspace complicates things at all. It's so highly seperate > >from other instructions, and yet integrated so nicely into any program > >or programs. > > Well, i believe that pspace should be used via an operand prefix, just > another addressing mode. I really don't like the current situation. > But I also have no solid ideas for a good implementation of the idea. > Perhaps )^( could be used. > I know that it was implemented as an instruction for a reason, but I > really dislike it that way. It just isn't clean enough for me. I agree! LDP and STP are very artifficial. 1. they are use _only_ for p-space 2. they use immediate (#) value as a first operand! (P-space is more like address ($) not value (#)) 3. We can store _only_ numbers, Q: why? A: Because it would be too powerful (???) It seems be very logical to implement it in this way: %value - new addressing mode related to P-space P-Space - contain full instructions LDP, STP - eliminated STP #a,#b == mov %a,#b LDP #a,b == mov b,%a mul, div, sub etc. with %mode could be allowed or not. Thomas Radon -------------------------------------------------------------------------- __/__/__/ __/__/ __/ __/ __/__/__/ __/ __/ __/ __/ __/ __/__/ __/__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/__/ __/__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/__/ __/ __/ __/__/__/ __/ __/ +---------------------------------+ |Tomasz.Radon@Penetrator.Krakow.pl| |tradon@cyfronet.krakow.pl | +---------------------------------+ From: John K W Subject: Re: Post/pre inc/dec modes - new idea Date: 1995/11/30 Message-ID: <49ko2m$evd@geraldo.cc.utexas.edu>#1/1 references: <49ffoq$n1d@geraldo.cc.utexas.edu> <49ga4b$nm2@hermes.cair.du.edu> newsgroups: rec.games.corewar ruhl@phoebe.cair.du.edu (Robert A. Uhl) wrote: >>>All agree that we need full set of pre-/post- inc/dec modes >> >>I don't agree. > >Well, in all sincerity, you _do_ seem to be in the minority. It makes >the instruction set that much more symmetrical. I may be in the minority of people who've bothered to speak up... That'd different though. >>Not really. I do NOT want operands after variables if it is at all >>possible to avoid it. > >Again, do not think of it as operands after variables; think of it as >grouping, just like parentheses. Heh. Fine: "I do NOT want _grouping symbols_ after variables if it is at all possible to avoid it." Better? :) -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Um. Pizza wackiness. Date: 1995/11/30 Message-ID: <49knrb$evd@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar I sent a program called "myZizzor 4" to the Hill. I got confirmation from the server that it was being run. A few hours later, I submitted "Thermite 2.5". I got confirmation that it was being run. The next day I check my mail and find two copies of Thermite have been run, and that myZizzor 4 has not yet challenged the Hill. Just thought I'd mention that... I'm not sure if the information will be useful to anyone or not. :/ -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: bremermr@cartoon.ecn.purdue.edu (Myer R. Bremer) Subject: Re: Ideas for new instructions Date: 1995/11/30 Message-ID: <49klpo$7l6@mozo.cc.purdue.edu>#1/1 references: <9511260803.AA06477@idnsun.gpct.vanderbilt.edu.noname> <499g59$e3f@agate.berkeley.edu> <49bcvn$rm1@geraldo.cc.utexas.edu> <49g97s$nb8@hermes.cair.du.edu> newsgroups: rec.games.corewar In article <49g97s$nb8@hermes.cair.du.edu>, Robert A. Uhl wrote: > This is not to say that I beleive that it should stay; I still have >my doubts as to its usefulness. It does enable warriors to be more >intelligent. The question is: how much more intelligent are they? > Greetings. In my humble opinion, pspace hasn't really done much for more intelligent warriors on the hill much past--if I lose or tie than switch otherwise stay. Plus with brainwashes and qscans making 'thinking' rather dicey, lots of programs simply abandon their 'protected' memory. Hopefully we'll see more intelligent warriors on the big hill where qscans aren't as effective, but brainwashes will still be a problem. Why implement some slick learning algorithm when all your learned data could be wiped out with any loss? M R Bremer From: John K W Subject: PHQ Date: 1995/11/30 Message-ID: <49l4t8$p5c@geraldo.cc.utexas.edu>#1/1 newsgroups: rec.games.corewar Heh. Maurizio's gonna be pissed. :) PHQ just got killed by the same accident that made me kill Armory. More Kudos to the Pizza elves, though, because there is now a to-be-run listing on the Pizza web page, so this shouldn't ever happen again... -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: John K W Subject: Re: New Hill at Pizza Date: 1995/11/30 Message-ID: <49j0b6$c5t@geraldo.cc.utexas.edu>#1/1 references: <49inea$b07@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar Um, do you have the -F option on still? I think you do. It defeats the purpose of that Hill entirely. -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley / From: sd@ecst.csuchico.edu (Gubznf U. Qnivrf) Subject: Re: New Hill at Pizza Date: 1995/11/30 Message-ID: <49jg10$gii@charnel.ecst.csuchico.edu>#1/1 references: <49inea$b07@charnel.ecst.csuchico.edu> <49j0b6$c5t@geraldo.cc.utexas.edu> newsgroups: rec.games.corewar John K W wrote: >Um, do you have the -F option on still? I think you do. >It defeats the purpose of that Hill entirely. Um... Ooops. From: John K W Subject: Re: The Future of Pizza Date: 1995/11/30 Message-ID: <49ithh$9mn@geraldo.cc.utexas.edu>#1/1 references: <49dhpn$6l9@charnel.ecst.csuchico.edu> <49dkse$hbj@geraldo.cc.utexas.edu> <49g34g$o81@charnel.ecst.csuchico.edu> <49gdk5$hit@geraldo.cc.utexas.edu> <49imsc$aqh@charnel.ecst.csuchico.edu> newsgroups: rec.games.corewar sd@ecst.csuchico.edu (Gubznf U. Qnivrf) wrote: >>Um. What? Could you 'splain that? > >Before, if the machine was lagged, it could take a while for you >to receive a confirmation of your submission. Now, the reply should >be fairly quick. Therefore, you won't submit again thinking something >happened to your warrior. > >Now do I make any sense? :) Yes, thanks. Oh, and also something went wrong and I sent my last post without mentioning the fact that I don't like the current ";kill" setup. Ah well... -- / John K. Wilkinson - jwilkinson@mail.utexas.edu \ | "I don't have the power because I've got the monkeys. I've got | \ the power because I'll set the monkeys LOOSE." -Dave Foley /