From news-rocq.inria.fr!news2.fnet.fr!julienas!EU.net!howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.mtholyoke.edu!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!math.utah.edu!news.math.utah.edu!morrell Tue Jun 28 20:28:04 1994 Article: 979 of rec.games.corewar Newsgroups: rec.games.corewar Path: news-rocq.inria.fr!news2.fnet.fr!julienas!EU.net!howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.mtholyoke.edu!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!math.utah.edu!news.math.utah.edu!morrell From: morrell@uglab10.math.utah.edu (Steven C. Morrell) Subject: Blue Funk, Blue Funk 3, and in-register vs. in-memory Sender: news@math.utah.edu Date: Mon, 27 Jun 1994 18:26:24 GMT Organization: Department of Mathematics, University of Utah Message-ID: Lines: 120 The following post contains the source code and the story behind Blue Funk and Blue Funk 3, which happens to be in first place on the '94 hill right now. It illustrates some of the subtleties of in-memory/ in-register addressing. As I was working on chapter two ("Stones") of my tutorial, I extracted a lot of stones from various warriors and ran them on Jon Neuman's Core! MARS for the macintosh. The most elegant of these was P.Kline's Emerald, which bombed the entire core before self-destructing. Upon closer investigation, I noticed something fishy -- after a mod 5 bombing run, the bombing instruction turned into MOV <0,2. Now under in-memory evaluation, which Core! incorrectly uses, this instruction decrements the 2, and then moves the next instruction onto itself (essentially a NOP.) Under in-register evaluation, the 2 is decremented and the source pointer is 1, but since things are in-register, the destination pointer is 2, messing up the stone. I watched the Emerald stone play out on William Shubert's KOTH, and sure enough, it only bombed 40% of the core before ruining itself. But, says I, we now have post-increment in the '94 draft, so I can use a MOV >0,n instruction and things will work out perfectly. (Well, almost perfectly.) Thus was the stone made for Blue Funk. I took a cue from Wayne Sheppard's Night Crawler and got the stone bombing early before I launched the imp-ring. Not a good strategy against quickscanners, but in practice it works pretty well. And here is Blue Funk: ;redcode-94 verbose ;name Blue Funk ;author Steven Morrell ;strategy Stone like Emerald without the in-memory/in-register problem ;strategy Imp added for fun ;macro step equ 3044 for 81 dat -step,step-1 ADD emerald,stone cnt DJN.f stone,boot mov emerald+1,>boot mov emerald+2,>boot mov emerald+3,>boot 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 end boot That brings me up to the middle of last week, when I finally downloaded Alex MacAulay's Redcoder, and got a visual perspective on my warriors. Much to my horror, I found that Blue Funk was only bombing half of core, and without a core-clear anywhere to back it up. What happened was that the MOV statement turned into MOV >0,-1 at the end of the first run and MOV >0,0 at the end of the second run and MOV >0,0 at the end of the third and all consequent runs. When a MOV >0,0 executes correctly, it loads MOV >0,0 into a register, increments the memory, and then stores MOV >0,0 into the same memory. The net effect is no decrement! So after another bug fix, here is Blue Funk 3, which bombs the entire core one and a half times before the stone component kills itself. ;redcode-94 verbose ;name Blue Funk 3 ;author Steven Morrell ;strategy Fixed another in-memory/in-register bug ;macro 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 end boot --- Steven Morrell morrell@math.utah.edu