From news-rocq.inria.fr!jussieu.fr!uvsq.fr!nntp-out.monmouth.com!newspeer.monmouth.com!news-hh.maz.net!news-feed.dus.tfi.de!news-feed.sto.telegate.se!nntp.inet.fi!news.sci.fi!iltzu Tue Apr 7 18:19:08 1998 Article: 8773 of rec.games.corewar From: iltzu@sci.fi (Ilmari Karonen) Newsgroups: rec.games.corewar Subject: Re: fast scanners Date: 7 Apr 1998 16:03:46 GMT Organization: (dis)Order of the Holy Spoon (or whatever) Lines: 98 Distribution: world Message-ID: <6gdip2$2o8$1@tron.sci.fi> References: <19980405012506.8720.rocketmail@send1d.yahoomail.com> <3527c7b1.1670121@news.lrz-muenchen.de> NNTP-Posting-Host: sci.fi X-Newsreader: TIN [version 1.2 PL2] Path: news-rocq.inria.fr!jussieu.fr!uvsq.fr!nntp-out.monmouth.com!newspeer.monmouth.com!news-hh.maz.net!news-feed.dus.tfi.de!news-feed.sto.telegate.se!nntp.inet.fi!news.sci.fi!iltzu Bjoern Guenzel (guenzel.p1@usa.net) wrote: : On 5 Apr 1998 03:39:03 -0400, Paul-V Khuong : wrote: : >add.f inc, scan : >spl -1 : >sne.f loc1, loc2 : >jmp -2 : The main problem you will probably have is when it get's to the : attack, because you don't know anymore which locations you have : scanned (other processes will have executed the add before you get to : the attack) Still, it's not impossible. Here, I have proof of that.. (opens old redcode directory, digs around, blows some dust off) Cough, cough.. Ah, there. I think this is the last version I have of Time Lag, my self-splitting scanner from almost a year back. I don't think I'll improve it any more, so I might as well pass it to Planar (and the rest of you). ;redcode-94 ;name Time Lag ;author Ilmari Karonen ;strategy self-splitting scanner ;history 1c Works! ;history 1g Back to 1c, new switch method, mod-5 ;history 1h mod-6/4 (predecrement makes it ~mod-5) ;date March 14, 1997 ;planar scan, stun, clear, gate ;assert CORESIZE == 8000 ; This is my attempt at writing a self-splitting scanner. It uses 2 add ; instructions to keep track of the number of processes in the loop. Since ; the first add is executed more often than the second one, the find ; pointer lags behind the scan pointers. In fact, the first add is executed ; once more than the second one every time the number of processes 'on' it ; increases. Since the number of processes on that instruction determines ; how many times the scan pointers will be incremented before a scanned ; location will be 'found', any processes skipping to find will, on the ; next iteration of the process queue, have the same pointer there than ; they had when they executed scan. ; Surprisingly enough, this actually works perfectly without having to use ; any 'magic numbers' to tune the delay, as long as the order of the ; process queue doesn't change. The loop in this version is effectively 5 ; instructions long, making this a 0.4c scanner, with a 0.2c stun attack. ; Of course, these are only approximations, as is the case with all ; self-splitting programs. ; The greatest problem has been making this one switch to the clear well. ; Since there are many processes in the loop, it's not enough to get one of ; them to fall through. Another related problem has been resistance to ; self-hitting, especially with the clear. org bomb step equ 3030 ; mod-10 sorg equ (stun-step) ; scan origin cptr equ (bomb-1) cend equ (cbmb+1) ; *** Time Lag kill dat 0, 4000 dat 0, 0 bomb spl 0, -4 stun mov.i bomb, >kill ; .2c clear (a-decr triggers switch) loop add.f next, scan ; move scan location add.a next, find ; *** stay in phase *** scan sne.i {sorg, cptr ; d-clear djn.f clear, >cptr cbmb dat >5335+1, cend-kill ; (a-decr) dat 0, 0 dat 0, 0 dat 0, 0 dat 0, 5335-3 ; avoid self-hit? end Why doesn't this do well, then? It's big, it's slow, and the long main loop means it can't be made much smaller or faster. The response time is something horrible as well. -- ii 3D .sigXIlmari KaronenAscii 3D .sigIlmari Karonen_Ascii 3D .sigIlmari Kar fi.stereo@graphic.iltzu@sci.fi.stereo@graphiciltzu@sci.fin.stereo@graphicilt ltzu/ba/http://www.sci.fi/~iltzu/bahttp://www.sci.fi/~iltzu/1bahttp://www.sc is a stereogram!>