does the code inside the until loop run at a certain interval?
e.g. do no other instructions get processed until the loop is complete, or does the loop run between every other instruction?
Thanks
does the code inside the until loop run at a certain interval?
e.g. do no other instructions get processed until the loop is complete, or does the loop run between every other instruction?
Thanks
All of your high-level language code is broken down into assembly (or an intermediate code, then assembly) by a compiler. Assembly is then executed one instruction at a time.
However, certain instructions take more clock ticks than others do (for example, having to read/write to/from main memory).
Because of the pipeline architecture of a processor, it is often beneficial to perform other instructions in the interim. Please read this on the instruction pipeline of a processor to understand the basic phases.
Many compilers will perform optimization to ordering of the assembly instructions in order to reduce the amount of wait time (maximizing the pipeline-nature of processors).
A loop, in and of itself, is not a single instruction, but several in assembly.
In the end, I don't think you can make any guarantees about the time it will take. But know that it will more than likely not be discernible the time one iteration takes as opposed to another.
I'm not sure if I answered your question, or over-answered it. If you'd like more detail or resources, let me know. This is all top of dome.
Suppose a thread of control begins processing a loop. The loop will run to completion before any other code is executed on that thread of control.
If you have a multithreaded program, your program can keep doing other things while that loop is running. Different threads execute independently and their execution can overlap in a multithreaded environment.
What really happens underneath depends upon the hardware and how threads are scheduled on processors. If the threads are scheduled on the same processor core, then their execution will be interleaved: the scheduler will typically allocate some quantum to one thread, the next quantum to some other thread, etc. If threads are scheduled on different processors, the quanta can overlap and the threads can actually both process instructions simultaneously.
High-level language loops are typically translated into machine language code which relies on jumps (at least one of which points to an earlier address in the program). First some condition is evaluated - on Intel architectures you might have CMP
or SUB
or really any instruction that sets appropriate flags - and then you'll have an instruction like JNZ
(jump if not zero) or JG
(jump if greater than) which rely on flags set by comparison instructions to update the instruction pointer to the appropriate value. Once the instruction pointer has been updated, the next instruction fetched for that thread of control is from the correct location.
When the scheduler switches threads of control around on a processor core, it does what is called context switching to update the instruction pointer, registers, etc. with the correct values so that the thread of control sees the same observable processor state as when it last executed. This takes some time and represents an inefficiency associated with the time-quanta scheduling approach (it would be possible, for instance, to only schedule threads of control out when they no longer need to remember state, or to allow threads to explicitly yield after storing the state in a way the thread can later retrieve it explicitly, etc.)
How this works is the subject of Computer Architecture, so I would recommend a good undergraduate-level textbook for further reading.
At the lowest level, there's a whole lot of physics that has very little to do with computer science, loops, etc. At the chip level, modern chips are able to run lots of stuff in parallel. Even ignoring multiple cores, if you're running a program that has a long loop, it's fairly likely that multiple interrupts will happen which will cause the chip to pause execution of the loop, handle the interrupt, and return. Note that if you're running on any sort of operating system, that interrupt might cause the OS to pause the process running the loop and run an entirely different process.