Marking of attacked squares to weed out illegal King moves is just one of the two things the accelerated check test does. The other thing is that it tabulates for each board square which (attempted) sliding moves visit it.
It's not the same thing that you're doing, but I have now made a quicker version of stalemated called stalemated-quick, which does some preprocessing to reduce the work involved in checking for check. It starts by creating an array of the King's location and each space it may move to, and for each location in this array, it makes an array of every location with an enemy piece that has it in its range. The code looks like this:
// Build threat lists
set krange merge fn join const alias space #kingpos "-Range" #kingpos #kingpos;
set threats ();
for to #krange:
set threats.{#to} ();
next;
for (from piece) fn #enemies:
set in intersection var krange fn join const alias var piece "-Range" var from;
for to #in:
push threats.{#to} #from;
next;
next;
So it creates multiple elements of an array called threats, each of which is an array of the enemy pieces that include that space in its full range of movement. At the start of Chess, threats.d2 and threats.d1 both have one element set to d8, and the others (elements e1, e2, f1, and f2 of threats) are empty.
To check for check, it first assumes a value of false, and it tries out the move only if there are pieces potentially threatening the space the King is on. That move looks like this:
set checkpos cond == #from #kingpos #to #kingpos;
set checked false;
if count elem var checkpos threats:
move #from #to;
set checked fn threatened #checkpos;
restore;
endif;
Instead of using the checked function, it used the threatened function, which looks like this:
def threatened anytrue lambda (fn const alias space #0 #0 var king)
elem var king threats
=movetype CHECK
=king;
This function expects threats to be populated with appropriate values. So it can't be used everywhere checked can.
In tests with Chess, everything seems to be working. After making sure it worked, I did some speed tests comparing 100 calls to stalemated with 100 calls to stalemated-quick. In each pair, stalemated is first, and stalemated-quick is second. The results show that stalemated-quick is normally quicker.
It's not the same thing that you're doing, but I have now made a quicker version of stalemated called stalemated-quick, which does some preprocessing to reduce the work involved in checking for check. It starts by creating an array of the King's location and each space it may move to, and for each location in this array, it makes an array of every location with an enemy piece that has it in its range. The code looks like this:
So it creates multiple elements of an array called threats, each of which is an array of the enemy pieces that include that space in its full range of movement. At the start of Chess, threats.d2 and threats.d1 both have one element set to d8, and the others (elements e1, e2, f1, and f2 of threats) are empty.
To check for check, it first assumes a value of false, and it tries out the move only if there are pieces potentially threatening the space the King is on. That move looks like this:
Instead of using the checked function, it used the threatened function, which looks like this:
This function expects threats to be populated with appropriate values. So it can't be used everywhere checked can.
In tests with Chess, everything seems to be working. After making sure it worked, I did some speed tests comparing 100 calls to stalemated with 100 calls to stalemated-quick. In each pair, stalemated is first, and stalemated-quick is second. The results show that stalemated-quick is normally quicker.