Article 1044 of rec.games.corewar: Newsgroups: rec.games.corewar From: stst@vuse.vanderbilt.edu (Stefan Strack) Subject: Sucker 3 Message-ID: <1992Jun5.062117.19851@vuse.vanderbilt.edu> Sender: news@vuse.vanderbilt.edu (News Manager) Nntp-Posting-Host: vuse2 Organization: Vanderbilt University School of Engineering, Nashville, TN, USA Date: Fri, 5 Jun 1992 06:21:17 GMT Lines: 42 Sucker 3 has been floating around the top of the standard hill for a while now, so I guess it's time to post the code. It is a self-splitting vampire with a standard jump to a core-clearing pit that sacrifices speed for robustness to SPL and DAT bombs. Improvements with respect to Sucker 2 are: 1) a much-denser, mod-2 bombing pattern. The JMP bomb will hit the bombing loop only after every other core address has been covered. Interestingly, while the bomb increment of 34 assures a very even spread, it is neither fibonacci a la Andy Pierce, nor remotely optimal by Nandor Sieben's s(a) criterion. 2) no DAT #0,#0 spacer between the bomb loop and the slave pit. Since KotH initializes core with DAT 0,0 since recently (thanks to Andy for finding out), spacers will attract CMP scanners. Enjoy, Stefan (stst@vuse.vanderbilt.edu) ;redcode verbose ;name Sucker 3 ;kill Sucker ;author Stefan Strack ;strategy Self-splitting, pattern-bombing vampire ;strategy 2: with confusion ;strategy 3: merger of Union and Sucker: much denser, mod-2 bomb-pattern ;strategy Submitted: @date@ mark equ start-1-4+10+44+350+44 ;development history mess jump jmp clear-mark,mark start spl 0 loop sub clear,jump ;'jump' will land here after 12,000 cycles mov jump,@jump djn loop,<4003 ;mutagenize core/confuse scanners clear mov 34,<-34 ;entry for captured processes spl clear jmp clear end start From news-rocq.inria.fr!jussieu.fr!oleane!tank.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!newsfeed.internetmci.com!in2.uu.net!news.new-york.net!news.stormking.com!PK6811S@ACAD.DRAKE.EDU Fri Jul 19 10:31:12 1996 Article: 5629 of rec.games.corewar Path: news-rocq.inria.fr!jussieu.fr!oleane!tank.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!newsfeed.internetmci.com!in2.uu.net!news.new-york.net!news.stormking.com!PK6811S@ACAD.DRAKE.EDU From: PK6811S@ACAD.DRAKE.EDU Newsgroups: rec.games.corewar Subject: Re: Indirect Jumps Date: 17 Jul 1996 12:16:09 -0400 Organization: Storm King Ind. Inc. Lines: 80 Sender: server@news.stormking.com Distribution: world Message-ID: <01I76AY7K0MG002LOR@ACAD.DRAKE.EDU> Reply-To: PK6811S@ACAD.DRAKE.EDU NNTP-Posting-Host: valhalla.stormking.com Originator: corewar-l@stormking.com Criss wrote: >Years ago I programed some Core-Warriors. > >Standard '86 or '88 can't remember. I used inderect jumps >to 'catch' the other program. > >I 'poked' into the other program something like: > >jmp @3 >jmp @2 >jmp @1 >dat -3128 > >the 'DAT' pointed to some pit of mine. > >A direct jump was not possible back that days, since you couldn't >mix the A and B fields, so calculating the right jump address was >sort of tricky. Check out this '88 vampire to see how to use direct jumping: ;redcode verbose ;name Sucker 3 ;kill Sucker ;author Stefan Strack ;strategy Self-splitting, pattern-bombing vampire ;strategy 2: with confusion ;strategy 3: merger of Union and Sucker: much denser, mod-2 bomb-pattern ;strategy Submitted: @date@ mark equ start-1-4+10+44+350+44 ;development history mess jump jmp clear-mark,mark start spl 0 loop sub clear,jump ;'jump' will land here after 12,000 cycles mov jump,@jump djn loop,<4003 ;mutagenize core/confuse scanners clear mov 34,<-34 ;entry for captured processes spl clear jmp clear end start -------------------------------------------- >OK my problem now. I downloaded PMARS (MSDOS) version 0.8. > >When I compile my old version the above sequence doesn't work the way it >used to work. The jump instructions 'JUMP' to the DAT instruction >rather then to the address it is pointing to. Why is that? >I checked the papers (instruction) I downloaded as well and in my >opinion the above SHOULD work allright. > >I just did some other testing, a program like > >------------------------------------------------------------- >mov #1,1 >jmp @this_is_changing >dat -2 >------------------------------------------------------------- > >would have been an infinite loop. Under any proper implementation this would never have worked, and the '94 standard is 100% backward compatible. Your code actually looks like this: mov #1,1 jmp @this_is_changing,0 dat 0,-2 The #1 gets moved to the b-field of the jmp under any of the standards, and the jmp has always jumped to the address pointed to by it's a-operand. We're not getting any younger Criss, and they say memory is the first to go :-) Welcome back to CoreWars. Paul Kline pk6811s@acad.drake.edu