@mnrvovrfc beat me to it.
It DOES sound like optimization at work.
If the compiler decides that the value of SCREEN(j, k + i) doesn't change between calls, then it may be holding that value in a register variable (storing the results of the first call in a CPU register), which would be faster to access than a standard RAM-based variable.
Even better: after the return value of SCREEN(j, k + i) is loaded into a register for first use, if that register remains unchanged between calls to SCREEN and the compiler determines that the return value of SCREEN will not change, then the compiler may not have to do anything with the value; just leave that register alone and use that held value as needed instead of calling SCREEN. That would be fast.
It DOES sound like optimization at work.
If the compiler decides that the value of SCREEN(j, k + i) doesn't change between calls, then it may be holding that value in a register variable (storing the results of the first call in a CPU register), which would be faster to access than a standard RAM-based variable.
Even better: after the return value of SCREEN(j, k + i) is loaded into a register for first use, if that register remains unchanged between calls to SCREEN and the compiler determines that the return value of SCREEN will not change, then the compiler may not have to do anything with the value; just leave that register alone and use that held value as needed instead of calling SCREEN. That would be fast.