• #### Introducing: Hyperscan

From Roy van Rijn@21:1/5 to All on Sun Feb 20 15:13:30 2022
After experimenting a lot with quick scanners I had this crazy idea:
What if we could combine the speed of a qscan with for example a oneshot?

Sometimes it's refreshing to tinker around with new strategies and this is one I've tried before. Based on other failed attempts I didn't think it was possible. In the end however I managed to create something that works well enough to possibly be
competative after more iterations.

To get this high scanning speed we need to create a table with all the positions that we want to have scanned. Like this:

n for 79
dat zero - (47*n) , zero + 50 + (49*n)
rof

Now we can scan using this cute tiny 1C scanner:

wPtr sne.i *tableEnd , @tableEnd
djn.f {0 , }0

When we find something, we translate back the position:

add.f *wPtr , wPtr ; move pointer over for clear
jmz.f clear , *wPtr ; jump if A-field is zero
mov.x wPtr , wPtr ; swap A - B, we attack B
jmp clear

Obviously the table is a giant target for scanners and quick scanners, so we quickly boot away our code and turn it all into a decoy. It has a rather limited scan run of course, just 79*2 = 158 positions. One is actually a self-scan to activate the clear
in a better spot. Including boot it just takes 166 cycles to accomplish this, approaching hyperspeed 1C.

I'm not able to make it work well enough for a hill, but the idea is there and it scores about the same as other oneshots I've created.

It might be very benificial to have other ordering in the table or use mixed stepsizes, you're free to pick whatever numbers you like, where you like. I haven't dared to put it into an optimizer to tweak all 158 values.

Another idea I'd like to try is skipping "the compare and swap" and do a bi-clear style clear on both A/B fields at the same time... if anybody tries this let me know!

What do you think?

Here is the code:

;redcode-94nop
;name Hyperscan
;author Roy van Rijn
;strategy Rethinking what a qscan can be
;strategy Scans 158 positions in 166 cycles
;assert 1

zero equ wGo-100

bDist equ 4011
bPtr equ wPtr + bDist

; Big table with scan pointers, do whatever you like here:

n for 79
dat zero - (47*n) , zero + 50 + (49*n)
rof

; Boot the code using least possible lines:

wGo mov.i wPtr + 8 , bPtr + 10
mov.i wPtr + 7 , bPtr + 9
mov.i wPtr + 7 , bPtr + 8
mov.i wPtr + 6 , bPtr + 7
add.b wPtr + 6 , } bPtr + 6
mov.i wPtr + 5 , bPtr + 5
mov.i wPtr + 4 , bPtr + 4
mov.i wPtr + 3 , bPtr + 3
mov.i wPtr + 2 , bPtr + 2
mov.i wPtr + 1 , bPtr + 1
mov.i wPtr , bPtr
boot djn.f bPtr , bPtr + 9

; small scanner

wPtr sne.i *wGo-1-bDist , @wGo-1-bDist
djn.f {0 , }0

; set up the clear:

add.f *-2 , *0 ; move pointer over for clear
jmz.f 4 , *wPtr ; compare and
mov.x wPtr , wPtr ; swap
djn.b 2 , wPtr ; jump to clear and decrement scan

; simple SD clear:

; dat 1 , 13 ;generated by boot
spl #224 , 13
mov *-2 , >-8
; mov *-3 , >ptr ;generated by boot
djn.f -2 , }-3

end wGo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Stephen Gunnell@21:1/5 to roy.va...@gmail.com on Sun Feb 20 16:21:36 2022
On Monday, 21 February 2022 at 7:13:32 am UTC+8, roy.va...@gmail.com wrote:
After experimenting a lot with quick scanners I had this crazy idea:
What if we could combine the speed of a qscan with for example a oneshot?

Sometimes it's refreshing to tinker around with new strategies and this is one I've tried before. Based on other failed attempts I didn't think it was possible. In the end however I managed to create something that works well enough to possibly be
competative after more iterations.

To get this high scanning speed we need to create a table with all the positions that we want to have scanned. Like this:

n for 79
dat zero - (47*n) , zero + 50 + (49*n)
rof

Now we can scan using this cute tiny 1C scanner:

wPtr sne.i *tableEnd , @tableEnd
djn.f {0 , }0

When we find something, we translate back the position:

add.f *wPtr , wPtr ; move pointer over for clear
jmz.f clear , *wPtr ; jump if A-field is zero
mov.x wPtr , wPtr ; swap A - B, we attack B
jmp clear

Obviously the table is a giant target for scanners and quick scanners, so we quickly boot away our code and turn it all into a decoy. It has a rather limited scan run of course, just 79*2 = 158 positions. One is actually a self-scan to activate the
clear in a better spot. Including boot it just takes 166 cycles to accomplish this, approaching hyperspeed 1C.

I'm not able to make it work well enough for a hill, but the idea is there and it scores about the same as other oneshots I've created.

It might be very benificial to have other ordering in the table or use mixed stepsizes, you're free to pick whatever numbers you like, where you like. I haven't dared to put it into an optimizer to tweak all 158 values.

Another idea I'd like to try is skipping "the compare and swap" and do a bi-clear style clear on both A/B fields at the same time... if anybody tries this let me know!

What do you think?

Here is the code:

;redcode-94nop
;name Hyperscan
;author Roy van Rijn
;strategy Rethinking what a qscan can be
;strategy Scans 158 positions in 166 cycles
;assert 1

zero equ wGo-100

bDist equ 4011
bPtr equ wPtr + bDist

; Big table with scan pointers, do whatever you like here:

n for 79
dat zero - (47*n) , zero + 50 + (49*n)
rof

; Boot the code using least possible lines:

wGo mov.i wPtr + 8 , bPtr + 10
mov.i wPtr + 7 , bPtr + 9
mov.i wPtr + 7 , bPtr + 8
mov.i wPtr + 6 , bPtr + 7
add.b wPtr + 6 , } bPtr + 6
mov.i wPtr + 5 , bPtr + 5
mov.i wPtr + 4 , bPtr + 4
mov.i wPtr + 3 , bPtr + 3
mov.i wPtr + 2 , bPtr + 2
mov.i wPtr + 1 , bPtr + 1
mov.i wPtr , bPtr
boot djn.f bPtr , bPtr + 9

; small scanner

wPtr sne.i *wGo-1-bDist , @wGo-1-bDist
djn.f {0 , }0

; set up the clear:

add.f *-2 , *0 ; move pointer over for clear
jmz.f 4 , *wPtr ; compare and
mov.x wPtr , wPtr ; swap
djn.b 2 , wPtr ; jump to clear and decrement scan

; simple SD clear:

; dat 1 , 13 ;generated by boot
spl #224 , 13
mov *-2 , >-8
; mov *-3 , >ptr ;generated by boot
djn.f -2 , }-3

end wGo

It is probably scans for too long as it stands. I threw it against my 94nop hill and it came in a fair way down.

stimpy2.red 124.65 173 by Brant D. Thomsen / Stimpy v2.0
geraldton-nlkl.red 124.43 174 by Steve Gunnell / Geraldton A nlkl
dugiteD-ptsp.red 123.91 175 by Steve Gunnell / Dugite D ptsp
hyperscan.red 123.36 176 by Roy van Rijn / Hyperscan
creakyoldcode.red 122.96 177 by John Metcalf / Creaky old code
drrecover.red 122.63 178 by Franz / Dr. Recover
anlss.red 122.43 179 by RNNredgen / anlss

While I was working on round 4 of Christian's recent tournament I bumped into T-Scan and Afterglow where John M does something similar but I hadn't followed them up yet.

But it is probably worth adding to a strong-ish warrior to see if there is an advantage to be had. Does Ziggy have a Qscan? Starlink has been sitting high enough on my hill that I thought it might be a valid upcycling candidate - it might be worth a try.

Cheers,
Steveg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From Roy van Rijn@21:1/5 to All on Mon Feb 21 02:13:28 2022
While I was working on round 4 of Christian's recent tournament I bumped into T-Scan and Afterglow where John M does something similar but I hadn't followed them up yet.

Haha nice, I just looked up Table Scan (https://users.obs.carnegiescience.edu/birk/COREWAR/TINY/HILL/tablescan.red) and it does almost exactly the same thing, SNE/DJN, nice.
Perhaps I can use those warriors to improve the strategy further.

Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From John Metcalf@21:1/5 to Roy van Rijn on Mon Feb 21 16:45:52 2022
On Mon, 21 Feb 2022 02:13:28 -0800, Roy van Rijn wrote:

While I was working on round 4 of Christian's recent tournament I
bumped into T-Scan and Afterglow where John M does something similar
but I hadn't followed them up yet.

Haha nice, I just looked up Table Scan (https://users.obs.carnegiescience.edu/birk/COREWAR/TINY/HILL/
tablescan.red)
and it does almost exactly the same thing, SNE/DJN, nice.
Perhaps I can use those warriors to improve the strategy further.

Thanks!

I think Floody River was the first to use a table scan:

* https://users.obs.carnegiescience.edu/birk/COREWAR/94/HILL/
floodyriver.red

They're still effective on the tiny hill - I had one on there briefly
last week :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
• From skybuck2000@21:1/5 to All on Thu Feb 24 19:47:51 2022
You just gave me a funny idea for a new type of bomber/scanner not sure if it already exists, and completely unsure if it would be effective maybe a little bit.

The idea is:

1. Scan for bombs.

2. When a bomb is found scan for the next bomb.

3. If next bomb is found, increase search pattern.

4. Repeat

So basically it's an exponential search algorithm that tries to find the source of the bombing.

So some bombers bomb like:

x x x x x x x x x x x x x x x x x x x x x

So the idea is to skip over many x's by exponential search.

Maybe it's a stupid idea for some reasons:

1. Smarter bombers might bomb away from their own position

2. Expontential search might skip over a large part ?!

Then again problem 2 could be solved by scanning backwards half size.

It might require a division.

This is mostly ment as a fun bomber that can just quickly find simple bombers and neutralize them.

Bye for now.
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)