Re:Stack-Oriented Programming
by skocznymroczny on Wednesday January 15, 2020 @05:27AM
(#22053121)
In CoreWars, which used assembly-like language to create programs fighting each other, one of the most powerful strategies was to inject a SPL instruction (basically fork) into an enemy program, preferably jumping to the SPL instruction itself. As a result, the enemy program would quickly be split into 64 processes (usual maximum number), so the actual logic would be running at 1/64 speed, bogged down by the dummy processes.
If you could successfully do that, why wouldn't you just bomb a DAT in instead?
Because the opponent could already be running multiple processes - killing one would only speed up the others.
The programs that uses the SPL-bomb tactic usually tried to catch all the enemy processes (slowed down to uselessness by the SPL-bomb) in the same place before finishing them off with a DAT.
I see. I don't think the original version of CoreWars had multiple program counters? Got to admit it's been a while.
You're right, the version described in the original article in the Scientific American did not have the SPL instruction, but the first "Core Wars Standard" proposal in 1988 introduced it.
You can see the different versions collected here: https://corewar.co.uk/standards/
One of the interesting aspects of the game was the way the CPU was limited to a very small number of instructions per tick. At most you would get 50. So if you had a complex task that had to be executed in one tick, like filling the screen with bullets before your robot shut down due to lack of power, the way to do it was to preload all of the arguments onto the stack, wait for the tick to turn over, then call all of the functions at once. Basically allowing you to bank processing time for the turn you needed it.