'series of commands to the CPU'
hmm; that's a very context sensitive question. The *.BAT solution is under the category of 'scripting languages', eg Perl, PHP,
JS, bash, csh, sh, ... and on it goes.
But scripting is sending a series of commands to a command interpreter, not the CPU per se.
The CPU fetches 'chunks' of RAM and then starts to process them in sequence. The size of the CHUCK is architecture dependent and can be any thing from four bytes to 128 bytes or more on a mainframe.
The 'chunk' is prefetched into a cache and then each instruction is
a) setup for execution
b) possible jump locations calculated
c) and then 'sent to the CPU' for execution.
The higher the difference in RAM speed and Cache speed make the size of the 'chunk' more important. If the cache is depleted and the cpu needs more instructions to process, the CPU goes into a WAIT until more instructions are available for processing. The goal is to NEVER WAIT the CPU, but that can be impractical; consider:
a) fetch 128 words from ram
b) calculate the branch targets
c) execute the instruction,
d) only to discover that the BRANCH target is outside the cache
only choice is to WAIT the CPU, fetch another 'chunk' of ram and then
resume at b)